Cell Directory Service

Cell Directory Service (CDS) Cell Definition A cell consists of a collection of users, computers and resources that share a common set of DCE services. The cell is the primary unit of administration in DCE and is usually defined so that control centers around a common purpose, such as an organization within a company. At a minimum, the cell configuration must contain one Security Server and one Cell Directory Server. These servers may be contained in one or more machines. DCE currently provides support for multiple cell networks through a Global Directory Agent in the cell. The network topology may be quite varied within a single cell, ranging from a small Local Area Network (LAN) to an extensive set of LANs and Wide Area Networks (WANs). Cell Directory Service Overview The Cell Directory service looks up and manages names of resources in a cell. The names are specified in a hierarchical arrangement that defines the cell's namespace. A CDS directory appears very much like the familiar file system directory, particularly for UNIX users or like the OS/2 and DOS path name without the drive letter and ":" prefix. A directory resides on a CDS Server in a Clearinghouse. The clearinghouse can be thought of as a data base where the directory information is stored. There are essentially three kinds of entries in a CDS directory: a directory entry (also called a child pointer), an object entry and a soft link. The directory entry defines the hierarchical namespace with relative names separated by a "/" delimiter. A directory entry connects upper levels of a directory to another directory immediately beneath it in the cell namespace. An object entry represents a resource or entity of some sort. It is the end point, or leaf node, of the directory. A soft link is a pointer that provides an alternative name (alias) for a directory, an object or another soft link. Another kind of end point is a junction. A junction provides a connection to special services, such as Security and the Distributed File System, independent of the directory service. It is an object entry for the servers providing that service. The CDS Server responds to namespace requests from client applications, which includes the other DCE components: RPC, Security, DFS and DTS. DCE applications use CDS for locating servers and clients. Every client has a CDS Advertiser and at least one CDS clerk. A clerk initiates CDS operations and stores the directory data it retrieves in a local memory cache. The CDS Advertiser starts clerks as required, locates the CDS Servers in a cell and manages the cache. CDS server locations are cached for later use. Caching allows fast retrieval of previously acquired directory information avoiding repeated requests to the server. Periodically the cache is written to disk so that it can survive system crashes and re-boots. The cache is also written to disk when the CDS Advertiser is stopped. (A slim client configuration is also available which allows the CDS clerk to perform the responsibilities of both the CDS clerk and the CDS Advertiser.) CDS Performance Measurements The CDS Control Program (CDSCP) can be used by a cell administrator, or other users with the appropriate permissions, to manipulate and manage CDS directories. This tool is the basis for the CDS performance measurements. The measurement cases are defined as follows: •

Specific commands have been timed by repeated execution in a batch program. The times obtained are fairly representative of the response times obtained for a manual entry from the keyboard.

PRASHANT SHARMA : [email protected]

1

• • •

The CDSCP commands selected for measurement are SHOW and LIST. LIST simply lists the entries at a particular directory level. SHOW displays detailed information about the entity and its attributes. The commands are timed for both directory entries and for object entries. The commands are executed at high levels of the directory hierarchy.

Figure 5 shows the base set of measurements of the aforementioned CDSCP commands. List and Show perform similarly for both directories and objects.

Figure 5: CDS Control Program Base Commands The DCE control program, DCECP, can also be used to manipulate and manage CDS directories. The information contained in the output of the DCECP Directory commands is the same as CDSCP, but it is formatted differently. DCECP is the new single control program which contains all of the function of the previous control programs (rpccp, acl_edit, cdscp and rgy_edit) plus more function. Figure 6 compares the performance of CDSCP and DCECP commands. DCECP commands are slightly slower than their CDSCP counterparts. This is because DCECP has more overhead since it provides other functions such as shell command ability and TCL interpretation. Also, DCECP is larger in size and uses more DLLs, so the load time is longer than for CDSCP.

PRASHANT SHARMA : [email protected]

2

Figure 6: CDSCP vs. DCECP Tips and Techniques Although the CDS directory looks like a normal file system directory, it is much more than that and consequently the response time of directory lookups is significantly greater in CDS. Thus, CDS should be used for its primary purpose of providing resource location information and should not generally be used for data that is more suitable for a file or a data base. In particular, CDS is designed to be used for frequent reading of information that does not change often, so that the client-side caching capability is exploited. It is not designed to be used by applications that need to write data frequently. CDS has no mechanism for invalidating client caches. Applications specify how old the data may be. DFS uses a much stronger caching model with callbacks for cache invalidation and should be used by applications that need to write data frequently.

PRASHANT SHARMA : [email protected]

3