The common semantics and syntax rules for cell name spaces
are defined in
Implementations that conform to this specification interoperate according to the following rule: any conforming CDS clerk implementation interoperates with any conforming CDS server or GDA implementations, and any conforming CDS server implementations interoperate.
If a component of a name passed as input to a CDS enumeration operation contains one of the wildcard metacharacters (that is, unescaped * (asterisk) or ? (question mark)), and if this component is the terminal component of a CDS name, then the following filter algorithm is applied to the component:
Implementations intended to comply with the The Open Group DCE shall adhere to this specified functional model. The internal design of facilities may vary, but they shall provide the defined semantics to ensure interoperability.
CDS is functionally divided into a number of major modules:
The following sections summarise the functions of these CDS modules.
For further information, see
A client accesses CDS through the client application programming interface.
This interface is provided by a CDS module called clerk.
The clerk is the only CDS module that must reside on all DCE nodes. The clerk
ascertains an appropriate CDS server to process a request, and then invokes
the clerk/server operations of the transaction protocol to communicate
to as many CDS servers (including the Global Directory Agent) as necessary
to satisfy the request. The clerk presents the client's login context to the
RPC interface.
Clerks are responsible for initially learning about at least one CDS server that is able either to process a complete request or provide information (referrals) about other candidate CDS servers. This initial information is obtained via the solicitation protocol. CDS servers periodically advertise their availability using the RPC broadcast execution semantic. Clerks listen for these CDS server advertisements and thereby learn of the existence of servers and name spaces.
To improve responsiveness when CDS is initialised, a clerk is also permitted (although not required) to issue a single solicitation request (using the RPC broadcast execution semantic) to provoke announcements from CDS servers that may be waiting to advertise.
In order to maximise performance, it is likely that a clerk implementation maintains a cache of recently accessed information; the algorithm for managing such a cache is not specified in this document. Also, the clerk may execute a number of management operations to initialise itself; these operations are not further specified in this document.
Each CDS consists of one or multiple instances of servers that provide the services requested by clerks. CDS servers communicate with clerks and other servers via the transaction protocol.
The CDS server supports the solicitation protocol specified in
CDS stores name space data in a partitioned and possibly partially
replicated database. The database is partitioned because parts of
the name space are stored in different locations. The database may
be partially replicated because parts of the name space may be
simultaneously stored in multiple locations. The unit of both
partitioning and replication is the directory; a collection of
directories stored on a particular node is called a clearinghouse.
Clearinghouses are integral to CDS servers. Partitioning is
accomplished by controlling which directories are stored in which
clearinghouse. Replication is accomplished by storing a directory in
more than one clearinghouse.
Any copy of a directory (including the original copy) stored in a particular
clearinghouse is called a replica. In order to simplify the algorithms
for name creation and general name space maintenance, one of the replicas of
a directory must be designated to be the master replica.
Conforming CDS implementations may provide replication services that maintain other types of replicas (such as read-only replicas). These services must ensure that the contents of all replicas of a directory remain consistent.
Further control functions of the CDS server, such as the overall coordination of the server operation (bringing clearinghouses on line, and so on) are implementation-specific and thus not specified in this document.
The Global Directory Agent (GDA) handles CDS clerk requests for CDS entries that are not local to the requesting cell (that is, any global compound name that does not match the name of the local cell). The GDA returns an updated progress record whose replica pointers (on successful GDA look-up operations) contain information about the appropriate clearinghouses in the targeted foreign cell. This is true as well if the targeted foreign cell is, in fact, another cell within a cell hierarchy.
Any CDS clerk may treat the GDA as a special-case server which it invokes to resolve the global compound name of an unresolved fully-qualified name. The fact that a replica set returned by a CDS server identifies a set of GDAs rather than CDS servers is transparent to the clerk. In the case mentioned here, the global root /... may be returned in the progress record as the resolved part of the name, and the remaining composite name as the unresolved part of the name.
This behaviour is based on the assumption that the clerk has been referred to, or a priori knows of, a CDS server that holds a replica of the cell's root directory. The directory entry is referenced by the cell's root directory via a GDA pointer (instead of a child pointer entry) containing a set-valued attribute CDS_GDAPointers. Each value in CDS_GDAPointers identifies a GDA.1
Progress records returned by the GDA only return partial results; the PR_done flag in the progress record always has the value FALSE.
The status returned by the GDA can be one of the following:
If the unresolved name in the progress record becomes empty, and the type is not PR_directory, it should be treated as [CDS_UNKNOWNENTRY], as all cell names must be directories.
This section specifies the external requirements of CDS for other services, as specified in other volumes of The Open Group DCE. The usage of CDS by other services is specified in the service specifications.
The protocols are encoded as RPC interfaces in IDL notation. Protocol Data Units (PDUs) are represented as operations of RPC interfaces.
CDS relies on the distributed time provided by the DCE Distributed Time Service, as specified in the DCE Time Services specification, to maintain synchronised clocks in the network for use in the sequencing of updates in the name space. It is not guaranteed that the CDS protocol works correctly if server clocks differ by more than five minutes.
CDS uses the Security Service and authenticated RPC, as specified in the DCE Security Services specification and the DCE Remote Procedure Call specification respectively, for mutual authentication and authorisation of CDS entities.
CDS clerks, the mediators between clients and servers, are authenticated by impersonating their clients' identity.
CDS servers of a cell are registered in an authorisation group which puts all cell servers within a single protection boundary. This allows for obtaining the required credentials in inter-server communication. Servers accept peer update requests from servers who are recognised as peers.
CDS accommodates the architecture as outlined in
CDS does not guarantee things such as external consistency, atomic transactions, and so on.
These objects are protected by Access Control Lists (ACLs), as specified in the DCE Security Services specification.
ACLs attached to CDS clerks and servers exist for maintenance purposes, and are local to those facilities.
The protected objects of CDS are supported by its ACL Managers, which are derived from the Common ACL Manager. For the algorithm used by the Common ACL Manager, and for further details on the access control model, refer to the DCE Security Services specification. The CDS ACL Manager types are as follows:
The UUID of this ACL manager type is:
The UUID of this ACL manager type is:
The UUID of this ACL manager type is:
The UUID of this ACL manager type is:
The UUID of this ACL manager type is:
To protect both terminal object and directory entries, and to enable newly created entries automatically to inherit default ACLs from their parent directory, the CDS ACL facility supports the following DCE ACL types. For further information on these ACL types as defined by the access control model, refer to the DCE Security Services specification.
ACL entry types are used to specify the category of principal for which the ACL entry is created. See the DCE Security Services specification for a description of DCE ACL entry types.
CDS supports the following DCE permissions:
Each permission has a slightly different meaning, depending on the kind of CDS name with which it is associated. In general, the permissions are defined as follows:
The required permissions for successful invocation of RPC interface
operations on CDS protected objects are specified in
Inter-server communication runs within one protection boundary. Each CDS server of a particular cell is registered in a single authorisation group, and is permitted access to peer servers through its group permission rights.
This authorisation group has the well known relative name subsys/dce/cds-server at the top level in the security name space. Whenever a CDS server is created, it must be added to this group.
The cell creation procedure must grant full permission on the cell root directory to this group. Object ACL and Initial Container Creation ACL entries are also created specifying subsys/dce/cds-server as the principal in each ACL entry, to ensure that the group has full access to all future directories and their contents.
In
| Attribute | Per- | Usage | |||
|---|---|---|---|---|---|
| _ | _ | _ | _ | _ | |
| Name | Type | Syntax | missions | Entry Type | Presence |
| CDS_CTS | Single | VT_Timestamp | R | All | Mandatory |
| CDS_UTS | Single | VT_Timestamp | R | All | Mandatory |
| CDS_Class | Single | VT_byte | RW | Object | Optional |
| CDS_ClassVersion | Single | VT_Version | RW | Object | Optional |
| CDS_ObjectUUID | Single | VT_uuid | RW * | Object | Optional |
| R | Directory, Child Pointer | Mandatory | |||
| CDS_Replicas | Set | VT_ReplicaPointer | R | Directory, Child Pointer | Mandatory |
| CDS_AllUpTo | Single | VT_Timestamp | R | Directory | Mandatory |
| CDS_Convergence | Single | VT_small | RW | Directory | Mandatory |
| CDS_InCHName \(dg | Single | VT_small | R | Directory | Conditional |
| CDS_ParentPointer | Set | VT_ParentPointer | R | Directory | Mandatory |
| CDS_DirectoryVersion | Single | VT_Version | R | Directory, Clearinghouse | Mandatory |
| CDS_UpgradeTo \(dg | Single | VT_Version | RWD | Directory | Conditional |
| CDS_LinkTarget | Single | VT_FullName | RW | Soft Link | Mandatory |
| CDS_LinkTimeout | Single | VT_Timeout | RW | Soft Link | Mandatory |
| CDS_Towers | Set | VT_byte | RWD | Object, Clearinghouse | Optional |
| CDS_CHName | Set | VT_FullName | R | Clearinghouse | Mandatory |
| CDS_CHLastAddress | Single | VT_byte | R | Clearinghouse | Mandatory |
| CDS_CHState | Single | VT_small | R | Clearinghouse | Mandatory |
| CDS_CHDirectories | Set | VT_CHDirectory | R | Clearinghouse | Mandatory |
| CDS_ReplicaState | Single | VT_small | R | Directory | Mandatory |
| CDS_ReplicaType | Single | VT_small | R | Directory | Mandatory |
| CDS_LastSkulk | Single | VT_Timestamp | R | Directory | Mandatory |
| CDS_LastUpdate | Single | VT_Timestamp | R | Directory | Mandatory |
| CDS_RingPointer \(dg§ | Set | VT_uuid | R | Directory | Conditional |
| CDS_Epoch | Single | VT_uuid | R | Directory | Mandatory |
| CDS_ReplicaVersion | Single | VT_Version | R | Directory | Mandatory |
| CDS_NSCellname | Single | VT_char | R | Clearinghouse | Mandatory |
| CDS_GDAPointers \(dg | Set | VT_gdaPointer | R | Directory | Conditional |
| CDS_CellAliases | Set | VT_GroupMember | RWD | Directory | Conditional |
| CDS_ParentCellPointers | Single | VT_ReplicaPointer | RWD | Directory | Conditional |
| RPC_ClassVersion | Single | VT_byte | RWD | Object | Optional |
| RPC_ObjectUUIDs | Single | VT_byte | RWD | Object | Optional |
| RPC_Group | Set | VT_byte | RWD | Object | Optional |
| RPC_Profile | Set | VT_byte | RWD | Object | Optional |
| RPC_Codesets | Set | VT_byte | RWD | Object | Optional |
| SEC_RepUUID | Single | VT_byte | R | Object | Conditional |
CDS_CTS (Creation Time Stamp) is a single-valued attribute which is present and non-null in every entry. It contains a space- and time-unique handle on the entry, which is assigned when the entry is made and which is never changed. This attribute is also used as a timestamp marking the creation time of the entry.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_UTS (Update Time Stamp) is a single-valued attribute which is present and non-null in any entry that has been updated. The time portion of the UTS gives the time at which the most recent update to any attribute of the entry took place. For object entries, the UTS gives the timestamp of the most recent update to any attribute of the object entry. For directory entries, the UTS gives the timestamp of the most recent update to an attribute of the directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_Class is a single-valued operational attribute which may be present and non-null in object entries. This attribute is used to classify object entries according to the type of object being named. Object classes have names that are printable strings (with a maximum length of 31 characters).
The usage of this attribute is application determined. The contents of this attribute are not specified in this document.
Note that only object entries have a CDS_Class attribute. The only built-in class is for clearinghouse objects, identified as CDS_Clearinghouse.
CDS_ClassVersion is a single-valued attribute which may be present and non-null in object entries. It allows the definition of an object class to be evolved over time (for example, by changing the definition of the class-specific attributes), without confusing the clients of the CDS. It consists of a one octet major version, and a one octet minor version. The setting and interpretation of the class version is the responsibility of the application that defined the corresponding object class.
CDS_ObjectUUID is a single-valued attribute which is present and non-null in any directory and child pointer entry; it may be present in an object entry.
Directory and child pointer entries use this attribute internally to store the UUID that uniquely identifies the entry.
On object entries it can optionally be used to store the UUID of the actual object being referenced by the CDS entry. It is the responsibility of clients to properly maintain this attribute for the object they are interested in; CDS makes no effort to ensure the correctness of the values stored in the CDS_ObjectUUID attribute for object entries.
On object entries, this attribute can be set only on creation, and is thereafter not modifiable.
CDS_Replicas is a set-valued attribute which is present and non-null in every directory and child pointer entry. Each member of the set identifies one of the clearinghouses that stores a replica of this directory. The CDS_Replicas attribute may not be modified directly; the set is updated as a side effect of the operations which create, destroy or change the replication of a directory.
Each element of the set consists of four parts:
See the data type definition of cds_ReplicaPointer_t in
CDS_AllUpTo is a single-valued attribute which gives a bound on how out of date various replicas of this directory are. This attribute is present in every directory entry. All replicas of a directory are guaranteed to have received all updates of entries whose timestamps are less (that is, older) than the value of CDS_AllUpTo.
This attribute is read-only across the clerk-to-server RPC interface.
The usage and maintenance of this attribute depends on the replication service.
CDS_Convergence is a single-valued attribute which specifies how persistent a directory should be in trying to keep its replica up to date.
The usage and maintenance of this attribute depends on the replication service.
CDS_InCHName is a single-valued attribute which indicates whether a directory or any of its descendants can store clearinghouse names. If this value is TRUE, the directory can store clearinghouse names. If it is FALSE, the directory cannot store clearinghouse names. CDS will create this attribute on the cell root directory and give it a value of TRUE, it will not appear in any other directory.
CDS_ParentPointer is a set-valued attribute which is present in every directory entry except the cell root (see below). It contains a set of pointers to each directory's parent in the name space tree. This attribute is maintained automatically by CDS servers in order to keep the graph of the name space properly connected at all times. Only one value for the set is supported currently.
The attribute links a child directory to its parent, allowing clerks and
servers to work up the tree as well as down. The attribute is used to make
sure that parent and child directories always point to each other during
normal operation, and it is used during directory creation to allow a child
directory to link itself into the tree by creating a child pointer entry in
the parent directory.
For directory version 3.0 (value of the CDS_DirectoryVersion attribute), this set-valued attribute contains a single value with the following information:
CDS_ParentPointer attributes are periodically checked to make sure that the name space controlled by CDS remains connected and that failures are reported in a timely fashion.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_DirectoryVersion records the current version of a directory.
Multiple directory versions are supported in a name space in order to
enable the graceful migration to newer versions. This document specifies
directory version 3.0.
This attribute has an additional role when present on the clearinghouse pseudo-directory. There it controls the storage format and semantics of new directories created using that clearinghouse master as a replica.
Implementations must ensure that upgrade operations (proceeding in the background) in each replica are completed before the value of CDS_DirectoryVersion reflects the upgraded status of the directory indicated by the CDS_UpgradeTo attribute.
CDS_LinkTarget is a single-valued attribute which is present and
non-null in every soft link entry. It contains the fully-qualified global
name of the entry to which the soft link points.
CDS_LinkTimeout is a single-valued attribute which is present and
non-null in every soft link entry. It contains a timeout data structure
with two fields, which contain the expiration and extension time of the
soft link. The algorithm that applies to the interpretation of these
timeout value fields is shown in
| Expiration Field | Extension Field | Action at Expiration Timeout |
|---|---|---|
| zero | zero | The link never expires. |
| zero | non-zero | Invalid. The behaviour is undefined, but implementations may simply ignore the value. |
| non-zero | zero | Entry is deleted. |
| non-zero | non-zero | If target still exists, extends life of entry by value of extension field. Otherwise entry is deleted. |
CDS_CHName is a set-valued attribute which is present and non-null in every clearinghouse pseudo-directory entry. In directory version 3.0 (the value of the CDS_DirectoryVersion attribute is 3.0), this attribute may have only one value, namely the primary fully-qualified global name of the clearinghouse. A set of values is allowed in order to support operations such as renaming or merging cells.
The attribute is used for the following purposes:
This attribute is read-only across the clerk-to-server RPC interface.
CDS_CHLastAddress is a single-valued attribute which is present and non-null in every clearinghouse pseudo-directory entry. It stores the location information at which the clearinghouse most recently reported itself to the rest of the name space. For directory version 3.0 and higher (the value of the CDS_DirectoryVersion attribute is 3.0), this value is structured as a protocol tower.
The value of this attribute is used to determine whether the clearinghouse has moved to a new CDS server.
This attribute is read-only across the clerk-to-server RPC interface.
Its value describes the current state of the clearinghouse, and can be one of:
The value of this attribute is used to determine whether or not the CDS server should advertise this clearinghouse via the solicitation or advertising protocol, and whether it is permitted to respond to look-up requests on directories it stores.
CDS_CHDirectories is a set-valued attribute which is present in every clearinghouse pseudo-directory entry. It contains one member for each directory replica stored in the clearinghouse. The attribute can also exist on clearinghouse objects which can be used when restoring damaged name spaces.
The contents of each member of the set consist of the UUID of a directory replica and its fully-qualified global name, which can be used to look up entries in the directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_ReplicaState is a single-valued attribute which determines whether a directory replica can be accessed. Its value describes the current state of the clearinghouse, and can be one of:
This attribute is read-only across the clerk-to-server RPC interface.
CDS_ReplicaType is a single-valued attribute which indicates whether a directory is a master or read-only replica.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_LastSkulk is a single-valued attribute which records the timestamp of the last skulk performed on this directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_LastUpdate is a single-valued attribute which records the timestamp of the most recent change to any attribute of the directory replica, or any change to an entry within the replica.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_RingPointer is a set-valued attribute which specifies the UUID of a clearinghouse containing another replica of this directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_Epoch is a single-valued attribute which identifies a particular instance of the directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_ReplicaVersion is a single-valued attribute which identifies the version of a replica of the directory.
This attribute is read-only across the clerk-to-server RPC interface.
CDS_NSCellname is a single-valued attribute which is present in every clearinghouse pseudo-directory entry. It contains the canonical string representation of the cell name for the clearinghouse.
CDS_GDAPointers is a set-valued attribute which is present and non-null in the cell root directory entry only. This attribute contains location information about the registered Global Directory Agents for that cell, in the same way as the CDS_Replicas attribute. The type field in replica pointers is always set to RT_gda.
This attribute also includes a timeout value which functions similarly to the timeout in CDS_ParentPointer.
CDS_CellAliases is a set-valued attribute which contains alias names for the cell. This is resident in the root directory when an alias name exists.
This attribute can be created, modified and deleted by resident
applications.
CDS_ParentCellPointers is a single-valued attribute which contains
GDA style pointers to the parent cell. This attribute is resident in the
root directory when the cell is a child in a hierarchical cell combination.
RPC_ClassVersion is a single-valued attribute which contains the current Name Service Interface (NSI) version. Ths attribute is created by the NSI but can be created, written, modified and deleted by resident applications.
RPC_ObjectUUIDs is a set-valued attribute which contains optional UUIDs of the referenced server objects. This attribute is created by the Name Service Interface but can be created, written, modified and deleted by resident applications.
RPC_Group is a set-valued attribute which contains server object names or service group names for this service group. This attribute is created by the Name Service Interface but can be created, written, modified and deleted by resident applications.
RPC_Profile is a set-valued attribute which contains server providers compromising the configuration profiles. This attribute is created by the Name Service Interface but can be created, written, modified and deleted by resident applications.
RPC_Codesets is a set-valued attribute which contains character code set information. This attribute is created by the Name Service Interface but can be created, written, modified and deleted by resident applications.
SEC_RepUUID is a set-valued attribute which contains the replica instance UUID. This is stored in the servers name space entry.
This attribute is read-only across the clerk-to-server RPC interface.
The sections that follow present abstract definitions of these service
primitives. The concrete specifications of these primitives, and how
they map to CDS directory operations that use the RPC interfaces, are
specified in
Every service primitive takes as an input parameter the fully-qualified global name of the directory service entry. The resolution of this name may provoke a series of steps (which may involve multiple remote operations) which is repeated until the target clearinghouse has been located. Partial results may be evaluated and lead to a completion of the operation.
Unless the underlying operations detect a failure (valid status codes
are listed in
These primitives can only operate on entries that already exist in the name space. The operations that manipulate the name space are specified in the appropriate subsections for object, directory and soft link entries.
Some attributes that are mandatory for CDS entries are precluded from
modification by these service primitives; these attributes are maintained
by CDS servers internally. Refer to
A valid CDS entry is specified to be one of the following:
Some service primitives support only a subset of the preceding list.
The following sections contain abstract descriptions of the CDS service primitives for manipulating attributes.
An Enumerate Attribute operation is initiated by a client. It returns a set containing the attribute identifiers of the specified entry.
This service primitive may incur multiple remote operations, depending on the length of the clerk's internal buffer.
The attribute identifiers are enumerated in the order of object identifiers.
A Modify Attribute operation is initiated by a client. It applies one update to one attribute of a specified entry. Attributes can be added or removed from an entry with this primitive.
Any successful modification to an entry also causes the CDS_UTS timestamp of that entry to be updated.
Note that certain directory attributes that are only maintained internally (by the CDS server) must not be modified by this operation; CDS servers should reject any attempts otherwise. Attempts to modify clearinghouse or soft link entries are illegal; none of their attributes are modifiable.
This service primitive can also initiate operations to remove an object entry from the name space, if the type of the attribute to be removed is defined as AT_none. Attempts to remove other entry types are illegal.
A Read Attribute operation is initiated by a client, and returns a set containing the values of the specified attribute. The values are encapsulated in discriminated unions, containing the syntax specifier and value pair.
The attribute values are enumerated in timestamp order of member creation. Those with the oldest timestamps are returned first.
This service primitive may incur multiple remote operations for set-valued attributes, depending on the length of the clerk's internal buffer.
A Test Attribute operation is initiated by a client, and returns a boolean value indicating whether the supplied value was one of the values of the specified attribute.
Service primitives for manipulating object entries invoke operations that create, delete or look up object entries in the name space.
Creation of an object entry implies the creation and initialization both of the mandatory attributes maintained by CDS servers, and of the optional operational attributes. The modification of these attributes (if permitted), and the creation, look-up and modification of application-defined attributes, is controlled by the service primitives that manipulate attributes.
The following sections contain abstract descriptions of the CDS service primitives for manipulating object entries.
A Create Object operation is initiated by the client, and creates the requested object entry.
The entry's CDS_CTS and CDS_UTS attributes are generated automatically by the CDS server. The entry's optional attributes CDS_Class, CDS_ClassVersion and CDS_ObjectUUID can be supplied by the caller. If CDS_Class is supplied, CDS_ClassVersion must also be supplied with the appropriate value.
This service primitive succeeds only if the name of the object is new in the name space (that is, if no entry with this name of any type exists in the name space). Furthermore, an object can be created only if its immediate parent directory already exists.
An Enumerate Object operation is initiated by a client, and returns a set containing the names and classes of objects in the specified directory. Only object names that match a supplied filter, consisting of an atomic name (possibly wildcarded) and (optionally) the object class, are returned. A NULL class matches a * (asterisk metacharacter) filter.
The objects are enumerated in lexical order, according to the ordering rules of the Portable Character Set (PCS). The ordering for extended character sets is not specified.
This service primitive may incur multiple remote operations, depending on the length of the clerk's internal buffer.
Service primitives for manipulating directory entries invoke operations that create, delete or look up directory entries in the name space. Included are services that modify child pointer entries.
Creation of a directory entry implies the creation and initialization of mandatory attributes maintained by CDS servers. The modification of these attributes (if permitted), and the creation, look-up and modification of application-defined attributes, is controlled by the services that manipulate attributes.
The following sections contain abstract descriptions of the CDS service primitives for manipulating directory entries.
A Create Directory operation is initiated by a client, and creates the requested directory entry in a specified or default clearinghouse.
This service primitive succeeds only if the name of the directory is new in the name space (that is, if no entry with this name of any type exists in the name space). Furthermore, a directory can be created only if its immediate parent directory already exists. This service primitive specifies the master clearinghouse.
Successful completion of the operation ensures the eventual consistency of the name space; in particular, the child pointers in the parent directory are appropriately created.
A Delete Directory operation is initiated by a client, and removes an existing directory from the name space.
Successful completion of the operation ensures the eventual consistency of the name space; in particular, the child pointers in the parent directory are appropriately updated.
An Enumerate Children operation is initiated by a client, and returns a set containing the names of child pointers in the specified directory. Only child pointers that match a supplied filter consisting of an atomic name (possibly wildcarded) are returned.
The child pointers are enumerated in lexical order, according to the ordering rules of the Portable Character Set (PCS). The ordering for extended character sets is not specified.
This service primitive may incur multiple remote operations, depending on the length of the clerk's internal buffer.
A Create Child operation is initiated by a server on a client's behalf, and creates a child pointer entry in the specified directory. It returns the value of the CDS_CTS attribute of the new child pointer entry.
This service primitive is performed if a client attempts to create a new directory (using Create Directory).
A Delete Child operation is initiated by a server on a client's behalf, and deletes the specified child pointer entry in the specified directory.
This service primitive is performed if a client attempts to delete a directory (using Delete Directory).
Service primitives for manipulating soft link entries invoke operations that create, delete or look up soft link entries in the name space.
Creation of a soft link entry implies the creation and initialization of mandatory attributes maintained by CDS servers. The modification of these attributes (if permitted), and the creation, look-up and modification of application-defined attributes, is controlled by the services that manipulate attributes.
The following sections contain abstract descriptions of the CDS service primitives for manipulating soft links.
A Create Soft Link operation is initiated by a client, and creates the specified soft link entry.
This service primitive can optionally specify the lifespan of the newly created soft link as being one of the following three:
The target of a soft link may not be in existence at the creation time of the soft link. The existence of the target is not verified by CDS servers.
A Delete Soft Link operation is initiated by a client, and removes the specified soft link entry from the name space.
An Enumerate Soft Links operation is initiated by a client, and returns a set containing the names of soft links in the specified directory.
Only soft links that match a supplied filter consisting of an atomic name (possibly wildcarded) are returned.
The soft links are enumerated in lexical order, according to the ordering rules of the Portable Character Set (PCS). The ordering for extended character sets is not specified.
This service primitive may incur multiple remote operations, depending on the length of the clerk's internal buffer.
A Resolve Name operation is initiated by a client, and returns the resolved fully-qualified global name of the target entry pointed to. It resolves the name by following a sequence of soft links as specified in the fully-qualified global name input parameter.
The service primitives for advertisement and solicitation perform operations that are necessary in order to provide CDS clerks with binding information to available clearinghouses in the cell.
The following sections contain abstract descriptions of the CDS service primitives for advertisement and solicitation.
An Advertise operation is initiated by a CDS server, and advertises the availability of the server's clearinghouses to a broadcast address, which is listened to by CDS clerks.
This service primitive is triggered either by a CDS server internal timer or a received solicitation request.
A Solicit operation is initiated by a clerk, and broadcasts a request to CDS servers which triggers their advertisements. No values are returned.
Please note that the html version of this specification may contain formatting aberrations. The definitive version is available as an electronic publication on CD-ROM from The Open Group.
| Contents | Next section | Index |