The Developer Connection - Device Driver Kit for OS/2 3

home *** CD-ROM | disk | FTP | other *** search

/ The Developer Connection…ice Driver Kit for OS/2 3 / DEV3-D1.ISO / docs / euvcm000.inf (.txt) < prev next >

Wrap

OS/2 Help File | 1994-02-27 | 460.5 KB | 6,566 lines

ΓòÉΓòÉΓòÉ 1. Version Notice ΓòÉΓòÉΓòÉ 1993 Edition. Before using this publication in connection with the operation of IBM products, consult the latest edition of the applicable IBM system bibliography for current information on these products. Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address given below. Address your comments on this publication to: IBM Canada Ltd. Laboratory Information Development 21/986/844/TOR 844 Don Mills Road North York, Ontario, Canada. M3C 1V7 You can also send your comments by facsimile to (416) 448-4414 addressed to the attention of the RCF Coordinator. If you have access to Internet, you can send your comments electronically to torrcf@vnet.ibm.com; IBMLink, to toribm(torrcf); IBM/PROFS, to torolab4(torrcf); IBMMAIL, to ibmmail(caibmwt9). If you choose to respond through Internet, please include either your entire Internet network address, or a postal address. When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. (C) Copyright International Business Machines Corporation 1993. All rights reserved. Copyright as marked. Note to U.S. Government Users - Documentation related to restricted rights - Use, duplication, or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. IBM is a registered trademark of International Business Machines Corporation, Armonk, N.Y. The following statements are provided by the Open Software Foundation. The information contained within this document is subject to change without notice. OSF MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. OSF shall not be liable for errors contained herein, or for any direct or indirect, incidental, special or consequential damages in connection with the furnishing, performance, or use of this material. Copyright (C) 1993 Open Software Foundation, Inc. This documentation and the software to which it relates are derived in part from materials supplied by the following: o (C) Copyright 1990, 1991 Digital Equipment Corporation o (C) Copyright 1990, 1991 Hewlett-Packard Company o (C) Copyright 1989, 1990, 1991 Transarc Corporation o (C) Copyright 1990, 1991 Siemens Nixdorf Informationssysteme AG o (C) Copyright 1990, 1991 International Business Machines Corporation o (C) Copyright 1988, 1989 Massachusetts Institute of Technology o (C) Copyright 1988, 1989 The Regents of the University of California All Rights Reserved. Printed in the U.S.A. THIS DOCUMENT AND THE SOFTWARE DESCRIBED HEREIN ARE FURNISHED UNDER A LICENSE, AND MAY BE USED AND COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. TITLE TO AND OWNERSHIP OF THE DOCUMENT AND SOFTWARE REMAIN WITH OSF OR ITS LICENSORS. FOR U.S. GOVERNMENT CUSTOMERS REGARDING THIS DOCUMENTATION AND THE ASSOCIATED SOFTWARE These notices shall be marked on any reproduction of this data, in whole or in part. NOTICE Notwithstanding any other lease or license that may pertain to, or accompany the delivery of, this computer software, the rights of the Government regarding its use, reproduction and disclosure are as set forth in Section 52.227-19 of the FARS Computer Software-Restricted Rights clause. RESTRICTED RIGHTS NOTICE Use, duplication, or disclosure by the Government is subject to the restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 52.227-7013. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the Government is subject to restrictions as set forth in paragraph (b)(3)(B) of the rights in Technical Data and Computer Software clause in DAR 7-104.9(a). This computer software is submitted with "restricted rights." Use, duplication or disclosure is subject to the restrictions as set forth in NASA FAR SUP 18-52.227-79 (April 1985) "Commercial Computer Software-Restricted Rights (April 1985)." If the contract contains the Clause at 18-52.227-74 "Rights in Data General" then the "Alternate III" clause applies. US Government Users Restricted Rights-Use, duplication or disclosure restricted by GSA ADP Schedule Contract. Unpublished-All rights reserved under the Copyright Laws of the United States. This notice shall be marked on any reproduction of this data, in whole or in part. ΓòÉΓòÉΓòÉ 2. Notices ΓòÉΓòÉΓòÉ References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM licensed program in this publication is not intended to state or imply that only IBM's licensed program may be used. Any functionally equivalent product, program or service that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program, or service. Evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, is the user's responsibility. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Corporation, IBM Director of Licensing, 208 Harbor Drive, Stamford, Connecticut 06904. This publication contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. ΓòÉΓòÉΓòÉ 2.1. Trademarks and Service Marks ΓòÉΓòÉΓòÉ The following terms, denoted by an asterisk (*), used in this publication, are trademarks or service marks of IBM Corporation in the United States or other countries: AIX IBM The following terms, denoted by a double asterisk (**), used in this publication, are trademarks of other companies as follows: o Open Software Foundation, OSF, the OSF logo, OSF/1, OSF/Motif, and Motif are trademarks of the Open Software Foundation, Inc. o UNIX is a registered trademark of UNIX System Laboratories, Inc. in the U.S. and other countries. o DEC, DIGITAL, and ULTRIX are registered trademarks of Digital Equipment Corporation. o Apollo, Domain/OS, HP, Hewlett-Packard, and LaserJet are trademarks of Hewlett-Packard Company. o Network Computing System and PasswdEtc are registered trademarks of Hewlett-Packard Company. o AFS and Transarc are registered trademarks of the Transarc Corporation. o Episode is a trademark of the Transarc Corporation. o DIR-X is a trademark of Siemens Nixdorf Informationssysteme AG. o NFS, Network File System, SunOS and Sun Microsystems are trademarks of Sun Microsystems, Inc. o X/OPEN is a trademark of the X/Open Company Limited in the U.K. and other countries. o PostScript is a trademark of Adobe Systems Incorporated. ΓòÉΓòÉΓòÉ 3. About This Book ΓòÉΓòÉΓòÉ Distributed Computing Environment: Understanding the Concepts introduces you to the Open Software Foundation** (OSF**) Distributed Computing Environment (DCE) offering. It describes the technology components of DCE: from a high-level overview to discussion of individual components and their interdependencies. This book is derived in whole from the Introduction to OSF DCE book produced by the Open Software Foundation and published by Prentice-Hall. After reading this book, you will have a thorough understanding of OSF's Distributed Computing Environment. It contains many UNIX(**)-specific examples that may not be applicable to your particular operating system. For completeness, all components of OSF DCE are described. This does not necessarily mean that IBM supports, or intends to support, all of the same DCE components. Refer to the product documentation for DCE on your operating system to understand the implementation details. ΓòÉΓòÉΓòÉ 3.1. Who Should Use This Book ΓòÉΓòÉΓòÉ The content and intended audience of this book change from less technical to more technical as the book progresses. Chapter 1 is written for anyone interested in an overview of DCE, including managers, system administrators, and application programmers. Chapter 2 is intended for network managers and administrators. Chapters 3 and 4 are targeted primarily for administrators and programmers. ΓòÉΓòÉΓòÉ 3.2. How This Book Is Organized ΓòÉΓòÉΓòÉ o Overview of DCE. This overview of DCE describes distributed computing and its uses, and the client/server model of distributed computing, on which DCE is based. It summarizes the DCE architecture, and briefly describes each of the technology components that comprise DCE, and their integration with one another. o DCE Configuration. Chapter 2 explains the concept of a DCE cell and describes the DCE software configuration components and the configuration of different types of DCE systems. It then gives examples of different cell configurations, ranging from a simple DCE cell to cells with various combinations of DCE services. o DCE Technology Components. Chapter 3 describes each of the technology components that comprise DCE: DCE Threads, Remote Procedure Call, Directory Service, Distributed Time Service, Security Service, Distributed File Service, and Diskless Support Service. An example of a simple distributed application illustrates the use of these services. o Integration of DCE Technology Components. The DCE technologies are integrated with one another; that is, they use each other's services wherever appropriate. Chapter 4 describes the ways in which each of the DCE components uses the other technology components of DCE and the implications their integration has for porting, testing, configuring, and starting up DCE systems. ΓòÉΓòÉΓòÉ 4. Overview of DCE ΓòÉΓòÉΓòÉ The OSF Distributed Computing Environment provides services and tools that support the creation, use, and maintenance of distributed applications in a heterogeneous computing environment. This chapter first describes distributed computing and its benefits. It also describes three distributed computing models- client/server, remote procedure call (RPC), and data sharing. The final section gives an overview of DCE itself, describing its technology components, the organization of a DCE environment, and the relationship between DCE and the underlying computing system. ΓòÉΓòÉΓòÉ 4.1. Why Distributed Computing? ΓòÉΓòÉΓòÉ Distributed computing means computing that involves the cooperation of two or more machines communicating over a network (see A Potential DCE Network). The machines participating in the system can range from personal computers to supercomputers; the network can connect machines in one building or on different continents. A Potential DCE Network Why is enabling this type of cooperative computing important? One reason is historical: computing resources that used to operate independently now need to work together. For example, consider an office that acquired personal workstations for individual use. As the number of workstations in the office building grew, their users realized they needed to share data and resources among the individual computers. By connecting the workstations over a network, they accomplished this goal. A second reason is functional: if there is special-function hardware or software available over the network, it does not have to be duplicated on every computer system (or node). For example, an organization could make a typesetting service available over the network, allowing users throughout the organization to submit their jobs to be typeset. A third reason is economical: it may be more cost-effective to have many small computers working together than to have one large computer of equivalent power. In addition, having many units (large and small computers) connected to a network is the more flexible configuration-if more resources are needed, another unit can be added in place, without interference to the whole system. Finally, a distributed system can be more reliable and available than a centralized system. This is a result of the ability to replicate both data and functionality. For example, when a given file is copied on two different systems, if one machine is unavailable, the file can still be accessed on the other machine. Likewise, if several printers are attached to a network, and an administrator takes one printer offline for maintenance, users can still print their files using an alternative printer. Along with the advantages of distributed computing come new problems. Examples are keeping multiple copies of data consistent, and keeping the clocks on different machines in the system synchronized. A system that provides distributed computing support must address these new issues. ΓòÉΓòÉΓòÉ 4.1.1. Why DCE? ΓòÉΓòÉΓòÉ Why would an organization with a network such as the one in A Potential DCE Network benefit from using DCE to enable distributed computing? DCE's benefits can be categorized into its support of distributed applications, the integration of its components with each other, DCE's relationship to its platforms, its support for data sharing, and DCE's interaction with the world outside of DCE: o DCE provides tools and services that support distributed applications. DCE provides a high-level, coherent environment for developing and running applications on a distributed system. The DCE components fall into two categories: tools for developing distributed applications and services for running distributed applications. The tools, such as DCE Remote Procedure Call and DCE Threads, assist in the development of an application. The services, like the DCE Directory Service, Security Service, and Distributed Time Service, provide the support required in a distributed system that is analogous to the support an operating system provides in a centralized system. o DCE's set of services is integrated and comprehensive. A second benefit is the integration and comprehensiveness of the DCE components. Not only does DCE provide all the tools and services needed for developing and running distributed applications, but the DCE components themselves are well integrated. They use one another's services whenever possible, because many of the DCE components are themselves distributed applications. In addition to supporting the development of distributed applications, DCE includes services that address some of the new problems inherent in the distributed system itself, such as data consistency and clock synchronization. Finally, DCE includes management tools for administering all of the DCE services and many aspects of the distributed environment itself. o DCE provides interoperability and portability across heterogeneous platforms. Another benefit of DCE is its orientation toward heterogeneous rather than homogeneous systems. The DCE architecture allows for different operating systems and hardware platforms. Using DCE, a process running on one computer can interoperate with a process on a second computer, even when the two computers have different hardware or operating systems. DCE can accommodate a wide range of networks, especially networks needing distributed computing for the historical reasons previously listed. Applications that are built using DCE are portable to other hardware and operating systems that run DCE. o DCE supports data sharing. Another benefit is DCE's support of data sharing through its directory service and distributed file service. A user anywhere in the distributed system can share data by placing it in the namespace or in a file, whichever is appropriate for the application. The data is then accessible by authorized users throughout the system. o DCE participates in a global computing environment. One final benefit of DCE is the way it interacts with the outside world. In addition to supporting cooperation within and between themselves, DCE systems can also interoperate with computing environments outside of DCE. In particular, the DCE Directory Service can interoperate with two standard, global directory services-X.500 and Domain Name Service-allowing users from within DCE to access information about the outside world. In this way, DCE participates in a global directory service. One benefit of such participation can be seen in DCE's distributed file system: it looks like one global file system, and users anywhere in the world can address the same file using the same global name. ΓòÉΓòÉΓòÉ 4.1.2. Potential Users of DCE ΓòÉΓòÉΓòÉ In general, any computing organization wanting to take advantage of the benefits of a distributed computing environment-data and resource sharing, extensibility, availability, interoperability-can benefit from using DCE. For example: o An office with isolated computing resources can link the computers together in a network and use DCE for data and resource sharing. o An organization with multiple computing sites that are already interconnected by a network can use DCE to tie together and access resources across the different sites. The different sites can be in different countries or even on different continents. o Any computing organization comprising several cooperating hosts can benefit greatly from the administrative support afforded by a DCE environment. For example, in DCE the database of computer users and their associated information (such as passwords) can be administered centrally, removing the need for an administrator to update information on every single node in the network each time a new user is added. o Organizations that write distributed applications can use DCE as a platform for their software. Applications that are written on DCE can be readily ported to other software and hardware platforms that also support DCE. o Organizations wanting to use applications that run on DCE platforms. o Organizations that want to participate in networked computing on a global basis. Because DCE supports standard directory services that will be used throughout the world, a site that participates in DCE will be able to use that worldwide directory service database. It can access information about other sites around the world; in turn these other sites can access its information. o System vendors whose customers are in any of the preceding categories. o Organizations that would like to make a service available over the network on one system and have it accessible from other kinds of systems. ΓòÉΓòÉΓòÉ 4.2. Models of Distributed Computing ΓòÉΓòÉΓòÉ DCE is based on three distributed computing models: client/server, remote procedure call, and data sharing. The client/server model is a way of organizing a distributed application. The remote procedure call model is a way of communicating between parts of a distributed application. The data sharing model is a way of handling data in a distributed system. The following subsections briefly describe each model. ΓòÉΓòÉΓòÉ 4.2.1. The Client/Server Model ΓòÉΓòÉΓòÉ A useful model for implementing distributed applications is the client/server model. In this model, the distributed application is divided into two parts, one part residing on each of the two computers that will be communicating during the distributed computation (see The Client/Server Model). The Client/Server Model The client side of the application resides on the node that initiates the distributed request and receives the benefit of the service (for example, a workstation that requests that a file be printed). The server side of the application resides on the node that receives and executes the distributed request (for example, the node with the printer). Two different sets of code are produced: one that runs as a client, the other as a server. Communication Between the Print Client and Print Server shows a workstation running the client side of a distributed print program and a print server running the server side of the distributed program. Communication Between the Print Client and Print Server The terms client and server can be seen as relative roles rather than as absolutes. For example, in executing the print request, the print server may in turn become a client in a distributed communication. It may ask the file server to send it a copy of the file to be printed as shown in The Print Server Acting as a Client of the File Server. The Print Server Acting as a Client of the File Server The terms client and server are also used to refer to specific nodes. A given node, or even a given process, can act in both the client and server role. It is convenient, however, to use the term file server to refer to the node on which the server side of a distributed file system is running. The directory server is a node that contains a database with names in it, and answers requests for access to those names. When clarification is needed, we use the term machine to indicate the node rather than the role. For example, in The Print Server Acting as a Client of the File Server, the print server, which runs on the print server machine, is acting as a client to the file server. More than one server can run on a given node. For example, both a security server and a time server can run on the same node. In this case, it is both the security server machine and the time server machine (see Two Servers Running on One Node). Two Servers Running on One Node In general, the server nodes are specialized. They require software that is found only on that particular server (for example, the directory server). Client nodes are generalized. Client machines are typically configured to be many types of client (for example, a directory, security, and time service client). A Client Is General; Servers Are Specialized Client nodes are generalized because the client code is usually small compared to the code that implements a server. Typically, many nodes need to be able to run the client side of an application, whereas only one or two nodes may be equipped to run the server side of an application. One final distinction between client and server: the server is typically implemented as a continuous process (daemon), while the client is usually implemented as a library. In other words, the client side of an application consists of a call to a routine that executes (sending the request over the network and receiving the result) and then returns and goes on with whatever else it was doing. The server side of an application is a dedicated process that runs continuously, waiting for a request, executing it and returning the answer, then waiting for the next request, and so on. Client as a Library; Server as a Continuous Process illustrates this distinction. Client as a Library; Server as a Continuous Process DCE is based on the client/server model. The DCE services are themselves examples of distributed programs with a client and server side. The basic communications mechanism used in DCE, the remote procedure call (RPC), assumes the presence of a client and a server. Since DCE applications are built using remote procedure call, they are also based on the client/server model of distributed computation. ΓòÉΓòÉΓòÉ 4.2.2. The Remote Procedure Call Model ΓòÉΓòÉΓòÉ One way of implementing communications between the client and server sides of a distributed application is to use the procedure call model. In this model, the client makes what looks like a procedure call. The procedure call is translated into network communications by the underlying RPC mechanism. The server receives a request and executes the procedure, returning the results to the client. One of the DCE technology components, DCE RPC, is an implementation of this model. Most of the other DCE technology components use it for their network communications. (See DCE Remote Procedure Call for more information on remote procedure calls and DCE RPC.) ΓòÉΓòÉΓòÉ 4.2.3. The Data Sharing Model ΓòÉΓòÉΓòÉ Some of the DCE services are based on the data sharing model, in which data is shared by distributing it throughout the system. Like RPC, data sharing assumes the existence of clients and servers. Data sharing, however, focuses on distributed data rather than distributed execution. The server's data is sent to the client. For example, if a client wants to access a file, a copy of it is sent from the server to the client. The client then proceeds to access the file locally. Data sharing can be built on top of RPC, using RPC as the communications mechanism between the client and server, and as the means of transferring data. Data sharing usually entails having multiple copies of the same data; for example, a master copy of a file on a file server, and a copy of the file on one or more client machines. As a result, copies of data may diverge-a client may make changes to its copy making the client's copy inconsistent with the copy on the server. Distributed services based on the data sharing model usually include mechanisms for keeping copies of data consistent. In addition, services that implement data sharing must be able to synchronize multiple access to data. For example, two clients may each want to modify a given record in a database. The server that manages the database must either prevent them from making conflicting modifications or decide which modification takes precedence. Two DCE services are based on the data sharing model. The first is the Directory Service. Both DCE directory services, CDS and GDS, maintain caches on the client. The caches contain copies of data that users on the client have recently accessed. Subsequent access to the data can be made locally to the cache, rather than over the network to the server. The DCE Distributed File Service is also based on the data sharing model. A DFS client maintains a cache of files that have recently been accessed by a user on the system. DFS servers distribute and revoke tokens, which represent a client's capability to perform operations on files. Through careful token management, the DFS server can ensure that its clients do not perform conflicting operations on shared files, and that they do not see inconsistent copies of the same file. Data sharing, like RPC, enables users and programmers to communicate transparently in a distributed system. ΓòÉΓòÉΓòÉ 4.3. Architectural Overview of DCE ΓòÉΓòÉΓòÉ OSF's Distributed Computing Environment is a layer between the operating system and network, on the one hand, and the distributed application on the other. DCE provides the services that allow a distributed application to interact with a collection of heterogeneous computers, operating systems, and networks as if they were a single system. Layering of DCE and Related Software shows DCE in relation to operating systems, network communications software, and applications software. Layering of DCE and Related Software Several technology components work together to implement the DCE layer. Many of these components provide in a distributed environment what an operating system provides in a centralized (single-node) environment. DCE Architecture shows the DCE architecture and its technology components, along with their relationship to applications, underlying system support, and placeholders for future technologies. DCE Architecture ΓòÉΓòÉΓòÉ 4.3.1. Overview of DCE Technology Components ΓòÉΓòÉΓòÉ This section gives a short description of each of the DCE technology components. Detailed descriptions of each of these components are given in DCE Technology Components. DCE Threads supports the creation, management, and synchronization of multiple threads of control within a single process. This component is conceptually a part of the operating system layer, the layer below DCE. If the host operating system already supports threads, DCE can use that software and DCE Threads is not necessary. Because all operating systems do not provide a threads facility and DCE components require threads be present, this user-level threads package is included in DCE. The DCE Remote Procedure Call (RPC) facility consists of both a development tool and a runtime service. The development tool consists of a language (and its compiler) that supports the development of distributed applications following the client/server model. It automatically generates code that transforms procedure calls into network messages. The runtime service implements the network protocols by which the client and server sides of an application communicate. DCE RPC also includes software for generating unique identifiers, to identify service interfaces and other resources. The DCE Directory Service is a central repository for information about resources in the distributed system. Typical resources are users, machines, and RPC-based services. The information consists of the name of the resource and its associated attributes. Typical attributes could include a user's home directory, or the location of an RPC-based server. The DCE Directory Service consists of several parts: the Cell Directory Service (CDS), the Global Directory Service (GDS), the Global Directory Agent (GDA), and a directory service programming interface. The CDS manages a database of information about the resources in a group of machines called a DCE cell. (Cells are described in Organization of a Distributed Computing Environment.) The Global Directory Service implements an international standard directory service and provides a global namespace that connects the local DCE cells into one worldwide hierarchy. The (GDA) acts as a go-between for cell and global directory services. Both CDS and GDS are accessed using a single directory service application programming interface API, the X/OPEN(**) Directory Service (XDS). The DCE Distributed Time Service (DTS) provides synchronized time on the computers participating in a Distributed Computing Environment. DTS synchronizes a DCE host's time with Coordinated Universal Time (UTC), an international time standard. The DCE Security Service provides secure communications and controlled access to resources in the distributed system. There are three aspects to DCE security: authentication, secure communications, and authorization. They are implemented by several services and facilities that together comprise the DCE Security Service, including the Registry Service, the Authentication Service, the Privilege Service, the Access Control List (ACL) Facility, and the Login Facility. The identity of a DCE user or service is verified, or authenticated, by the Authentication Service. Communications are protected by the integration of DCE RPC with the Security Service-communication over the network can be checked for tampering or encrypted for privacy. Finally, access to resources is controlled by comparing the credentials conferred to a user by the Privilege Service with the rights to the resource, which are specified in the resource's Access Control List. The Login Facility initializes a user's security environment, and the Registry Service manages the information (such as user accounts) in the DCE Security database. The DCE Distributed File Service (DFS) allows users to access and share files stored on a File Server anywhere on the network, without having to know the physical location of the file. Files are part of a single, global namespace. A user anywhere on a network can access any file, just by knowing its name. The Distributed File Service achieves high performance, particularly through caching of file system data. Many users can access files that are located on a given File Server without a large amount of network traffic or delays. DCE DFS includes a physical file system, the DCE Local File System (LFS), which supports special features that are useful in a distributed environment. They include the ability to replicate data; to log file system data, enabling quick recovery after a crash; to simplify administration by dividing the file system into easily managed units called filesets; and to associate ACLs with files and directories. DCE also offers Diskless Support Service, which provides the tools that allow a diskless node to acquire an operating system over the network, obtain configuration information, connect to DFS to obtain the diskless node's root file system, and perform remote swapping. When these tools are incorporated into the client's operating system and hardware, the diskless node can operate in a DCE environment. The Management block shown in DCE Architecture is not a single component, but a cross section of the other components. Each DCE service contains an administrative component so it can be managed over the network. In addition, some of the DCE services themselves provide for management of the distributed system as a whole. For example, users are registered in the Security Service, and servers' network addresses are registered in the Directory Service. ΓòÉΓòÉΓòÉ 4.3.2. Organization of a Distributed Computing Environment ΓòÉΓòÉΓòÉ This section introduces the concept of a DCE cell, and gives a brief summary of how different machines participating in a Distributed Computing Environment are organized. A group of DCE machines that work together and are administered as a unit is called a cell. For example, imagine an organization consisting of several departments, each in a different building and each operating on its own budget. Each department in such an organization could have its own DCE cell. A Distributed Computing Environment, or DCE environment, is a group of one or more DCE cells that can communicate with each other. A cell becomes a part of a DCE environment when it obtains access to one or more global directory services where the other cells in the environment are registered. If the different departments' cells are a part of a DCE environment, then a user in one department's cell can access resources in another department's cell, although this access would typically be less frequent and more restricted than access to resources within the user's own cell. A DCE cell can be configured in many ways, depending on its users' requirements. A cell consists of a network connecting three kinds of nodes: DCE User Machines, DCE Administrator Machines, and DCE Server Machines. DCE User Machines are general-purpose, they contain software that enables them to act as clients to all of the DCE services. DCE Administrator Machines contain software that enables a DCE administrator to manage DCE system services remotely. The DCE Server Machines are equipped with special software to provide one or more of the DCE services. Every cell must have at least one each of the following servers: o Cell Directory Server o Security Server o Distributed Time Server. Other DCE servers may be present in a given DCE cell to provide additional functions. A Global Directory Agent may be present to enable the cell's directory server to communicate with other cells' directory servers. A Global Directory Server may be present to provide X.500 directory service, and Distributed File Servers may be present to provide storage of files, the special functions of the Local File System, and possibly Diskless Support Service. (DCE Configuration describes in detail DCE cell configuration.) ΓòÉΓòÉΓòÉ 4.3.3. Integration of the DCE Technology Components ΓòÉΓòÉΓòÉ One of the benefits of DCE is its coherence: although the components themselves are modular with well-defined interfaces, they are also well integrated; the various DCE components each make use of the services of the other components wherever possible. For example, the RPC facility uses the Directory Service to advertise and look up RPC-based servers and their characteristics; it uses the Security Service to ensure message integrity and privacy; and it uses DCE Threads to handle concurrent execution of multiple RPCs. The Distributed File Service uses Threads, RPC, Directory Service, Distributed Time Service, and Security Service in providing its file service. In general, the DCE components shown higher in the DCE Architecture (DCE Architecture) make use of the components shown lower in the architecture. For example, DCE Threads is used by most other DCE components, but does not itself use other components. This ordering is not strictly hierarchical; often two services depend on the other. For example, the Directory Service uses the Security Service, which in turn uses the Directory Service. The interdependence of DCE components is explained in more detail in Integration of DCE Technology Components. ΓòÉΓòÉΓòÉ 4.3.4. Relationship of DCE to Network and System Services ΓòÉΓòÉΓòÉ DCE is layered on top of local operating system and networking software. It requires some of the services provided by the underlying network and operating systems. ΓòÉΓòÉΓòÉ 4.3.4.1. Network Services ΓòÉΓòÉΓòÉ In general, DCE is layered over a transport level service, such as UDP (User Datagram Protocol), TCP (Transmission Control Protocol), or ISO TP0-TP4 transport protocols, which is accessed through a transport interface, such as sockets or XTI (X/Open Transport Interface). All nodes participating in the DCE environment are physically connected by a highly available network. The network can be a Local Area Network (LAN), a Wide Area Network (WAN), or a combination of both. The DCE architecture supports different types of network protocol families. For example, DCE could be ported to run over Open Systems Interconnection (OSI) protocols. (The OSF DCE reference implementation runs over the Internet Protocol (IP) family.) For DCE systems to communicate with one another they must have at least one set of network protocols in common. For example, DCE is not designed to enable a node running only IP protocols to communicate with a node running only OSI protocols. DCE can identify a node with a unique network address and can identify a process with a network endpoint address (for example, a port or T-selector). ΓòÉΓòÉΓòÉ 4.3.4.2. Operating System Services ΓòÉΓòÉΓòÉ Certain services must be available through the underlying operating system. o Multitasking o Timers o Local interprocess communications o Basic file system operations (VFS layer) o Memory management o Local security mechanisms (if appropriate) o Threads (or the ability to use DCE Threads) o General system utility functions (ANSI, XPG4, POSIX). ΓòÉΓòÉΓòÉ 5. DCE Configuration ΓòÉΓòÉΓòÉ This chapter gives an overview of DCE configuration. It describes the basic DCE software configuration components and their organization on different types of DCE machines. It then describes some typical DCE cell configurations. The DCE configuration description in this chapter is based on technical configuration considerations. The packaging of DCE software by OSF and other vendors will involve somewhat different configurations. ΓòÉΓòÉΓòÉ 5.1. Introduction to DCE Configuration ΓòÉΓòÉΓòÉ DCE consists of machines that communicate over a network and run DCE software. They serve different functions, and they run different configurations of DCE software. There are three basic types of machines in a DCE environment: o DCE User Machine A DCE User Machine contains DCE software that enables the machine to participate as a client in the DCE environment. A typical example is a user's workstation. o DCE Administrator Machine A DCE Administrator Machine contains DCE software that enables an administrator to control servers running in the environment. A typical example is the DCE system administrator's workstation. o DCE Server Machine A DCE server machine runs software that implements one or more of the DCE services. There can be different kinds of DCE server machines. Some examples are a DCE File Server machine and a DCE Security Server machine. Types of DCE Machines shows an example of a DCE environment containing the three different kinds of DCE machines. Types of DCE Machines The different types of DCE machines run different parts of the DCE software. The basic software necessary for any machine to participate in a DCE environment is the DCE User software. It runs on all three types of DCE machines. The software necessary for an administrator to control DCE servers remotely is the DCE Administrator software. It runs on DCE Administration Machines, along with DCE User software. Finally, some of the DCE software implements a particular DCE service, and is intended to run only on a machine acting as that particular server. For example, the DCE Security Server software only runs on a machine designated as a DCE Security Server machine. There are different kinds of DCE server machines. They run their server-specific software, plus the DCE User software. DCE Machines and Their Software summarizes the DCE software that runs on different kinds of DCE machines. DCE Machines and Their Software ΓòÉΓòÉΓòÉ 5.2. Basic Configuration Components ΓòÉΓòÉΓòÉ DCE software can be divided into several configuration components, that is, parts of the DCE software that are installed in various combinations on DCE machines. Different configuration components are installed on different machines in a DCE environment, depending on what the machine's intended use is. The following description is a model for dividing DCE services into configuration components. The way a service's implementation maps to this model varies from service to service. First, each DCE service can be divided into two general categories of functionality: user and administration. User functionality is the service provided to its users, for example, reading a file or searching a database. The administration functionality allows administrators to manage the server; for example, stopping and starting server programs or backing up data. Because the DCE services are based on the client/server model, the user and administration functions are divided into two parts, the client and server sides. In total, each DCE technology component can be conceptually divided into four configuration components: o User Client o User Server o Administration Client o Administration Server. As shown in Distributed Service Configuration Components, the User Client communicates over the network with the User Server, and the Administration Client communicates over the network with the Administration Server. Distributed Service Configuration Components The User Client component is typically installed on DCE users' workstations. The Administration Client might run only on the workstation used by the administrator of the service. Both the User Server and the Administration Server run on the server machine, because they require access to the resource (such as a database) that the server manages. The User Server and Administration Server may actually run in the same process or be implemented by several processes. As an example, consider the DCE Security Service. One part of the Security Service software is the Login Facility, which sets up a user's security environment. This is an example of a User Client. It communicates over the network with the Privilege Server, which runs on the Security Server machine. The Privilege Server is an example of a User Server. An example of an Administration Client in the Security Service is the rgy_edit program, which administrators use to modify data in the security database. It communicates over the network with the Registry Server, which runs on the Security Server machine. The Registry Server is an example of an Administration Server. The software for each of the DCE services, the Directory Service, the Distributed Time Service, the Security Service, the Distributed File Service, and the Diskless Support Service, can all be divided roughly into the four configuration components. DCE Threads and DCE RPC are separate configuration components. Because they help implement the communications between machines, they must be present on every DCE machine, whether it is a client or a server. ΓòÉΓòÉΓòÉ 5.3. DCE Machine Configuration Examples ΓòÉΓòÉΓòÉ DCE machine configurations fall into three general categories: client machines, administrator machines, and server machines. ΓòÉΓòÉΓòÉ 5.3.1. DCE User Machine Configuration ΓòÉΓòÉΓòÉ An example of a DCE User Machine is a user's workstation. This machine acts as a client to any of the DCE servers, but it does not act as a server itself (with one possible exception noted in the next paragraph). A DCE User Machine contains DCE Threads and DCE RPC software so it can communicate with other machines in the DCE environment. In addition, it contains the User Client configuration components of all the DCE services (see DCE User Machine Configuration). Part of this software may be present in the form of libraries linked with DCE application software. DCE User Machine Configuration A DCE User Machine may also contain DFS Server software, although this is not required. This enables the machine to access remote files through its DFS Client software, and to export its own file system to other machines through its DFS Server software. The software configuration of a typical DCE User Machine is called the DCE User software. In summary, it contains o DCE Threads and DCE RPC o User Client configuration components of each DCE service o DFS Server software (optional). ΓòÉΓòÉΓòÉ 5.3.2. DCE Administrator Machine Configuration ΓòÉΓòÉΓòÉ A DCE administrator's workstation is configured with the client sides of DCE administration programs to enable the administrator to control servers remotely. This configuration contains the Administration Client software for each of the DCE services. It also contains the DCE User software, because the Administrator Machines act as User Clients as well as Administration Clients (see DCE Administrator Machine Configuration). DCE Administrator Machine Configuration ΓòÉΓòÉΓòÉ 5.3.3. DCE Server Machine Configuration ΓòÉΓòÉΓòÉ Some machines in the DCE environment contain special-purpose server software. These are called DCE server machines. A DCE server machine is configured with the User Server and Administration Server components of a DCE service. It also contains the DCE User software. For example, a DTS Server machine contains the DCE User plus the DTS User Server and DTS Administration Server configuration components. It is not necessary to run one server per node; two or more types of servers can run on a single machine. DCE Server Machine Configuration Examples shows the configuration of a Distributed Time Server machine and the configuration of a second machine acting as both a CDS Server and a Security Server. DCE Server Machine Configuration Examples From now on, the term ``server'' will mean both the User Server and Administration Server software combined; for example, ``Security Server'' means the Security User Server and the Security Administration Server together. ΓòÉΓòÉΓòÉ 5.4. DCE Cell Configuration Examples ΓòÉΓòÉΓòÉ DCE cells consist of various combinations of DCE machines connected by a network. For DCE applications and the DCE services themselves to run, there must be at least one each of the Cell Directory, Security, and Distributed Time Servers in every DCE cell. In addition, a DCE cell can contain any combination of the remaining DCE servers, GDS, DFS, and Diskless Support Service, depending on the needs of the DCE users. The following subsections describe these typical DCE cell configurations: o Simple DCE Cell o DCE Cell with DFS File Server Machine o Connected DCE Cell o Multicell Configurations. ΓòÉΓòÉΓòÉ 5.4.1. Simple DCE Cell ΓòÉΓòÉΓòÉ Simple DCE Cell Configuration shows an example of a simple DCE cell. It contains seven nodes, each of them running the DCE User software. Four of the nodes are typical workstations; they are running only the DCE User software. One is an administrator's workstation; it runs the DCE Administrator software in addition to the DCE User software. The other two nodes are DCE server machines. One of the server machines is running a Security Server. The other, is running both a Cell Directory Server and a Distributed Time Server. This configuration is a complete, basic DCE cell. Simple DCE Cell Configuration DCE Application in Simple Cell shows the same simple DCE cell, this time with a DCE application running in it. Node C is offering the Bank Service, and Nodes A and B have the client code for accessing the Bank Service. The Bank Server has registered itself in the Cell Directory Service so the Bank Clients are able to locate it. DCE Application in Simple Cell ΓòÉΓòÉΓòÉ 5.4.2. DCE Cell with DFS File Server Machine ΓòÉΓòÉΓòÉ To have full Distributed File Service support, including DCE's Local File System, a DCE cell can contain one or more DFS File Server machines (as shown in Simple Cell Plus Distributed File Server). The DCE User is equipped to act as a DFS client, and may also export the client's local file system to other machines on the network, using the DFS Server software. The DFS File Server machine, however, is specially equipped with DCE LFS, a physical file system that supports distributed file system features such as file replication, online backup, and other advanced administrative support. Simple Cell Plus Distributed File Server ΓòÉΓòÉΓòÉ 5.4.3. Connected DCE Cell ΓòÉΓòÉΓòÉ An organization may want to communicate with other DCE cells or with systems outside of DCE. One way is through the DCE Global Directory Service (GDS), an implementation of the X.500 directory service standard. DCE also supports the use of the Domain Name Service (DNS) as a global directory service. The cell's CDS communicates with CDS servers in foreign cells with the help of an intermediary, the Global Directory Agent. When a Global Directory Agent machine is added to a DCE cell, the nodes in the cell can contact other systems using X.500 or DNS. Simple Cell Connected via Global Directory Agent shows the simple DCE cell with a Global Directory Agent added to it. Simple Cell Connected via Global Directory Agent Finally, if a cell contains a Global Directory Server, it can not only access the X.500 namespace through the GDA, but it can also own and administer a portion of that namespace in the GDS. For more information on the Global Directory Service and Cell Directory Service, see DCE Directory Service. ΓòÉΓòÉΓòÉ 5.4.4. Multicell Configurations ΓòÉΓòÉΓòÉ An organization may decide to have a DCE configuration that consists of more than one cell. The organization might consist of several departments, each wanting to have administrative control of its resources. Each department in the organization could administer its own cell. This grouping results in slightly more total administrative overhead than a single, large cell, but the local administrative control of each cell may be worth the trade-off. If the cells are connected through a global directory service, then the users of one cell can access the resources in another cell, with the proper authority. ΓòÉΓòÉΓòÉ 6. DCE Technology Components ΓòÉΓòÉΓòÉ The OSF Distributed Computing Environment comprises several technology components: o DCE Threads o DCE Remote Procedure Call o DCE Directory Service o DCE Distributed Time Service o DCE Security Service o DCE Distributed File Service o DCE Diskless Support Service. The DCE components fall into two general categories: distributed programming facilities and distributed services. The DCE Threads and RPC components are distributed programming facilities, which include libraries that implement Application Programming Interfaces (APIs) and program development tools. The remaining DCE components are distributed services. These components consist in part of a daemon, or server process, that runs continuously on a machine and responds to requests sent over the network. They are equipped with administrative subcomponents to manage the service. They also have APIs through which a programmer can access the server. In general, application programmers deal mostly with the distributed programming facilities, DCE Threads, and RPC. Although the distributed services also have APIs for accessing them, the programmer often uses distributed services only indirectly through the RPC facility, which in turn, uses the APIs of the distributed services. System administrators, on the other hand, deal mostly with the distributed services because they have significant management requirements. This chapter describes each of the technology components. Each section starts with an overview of its technology, and describes the pieces that comprise the components. The components are described from the perspective of different types of users: the end user, the programmer, and the administrator. Each section also explains how the components work and their important benefits or features. The last section of this chapter, Two DCE Application Examples, gives an example of a very simple distributed application, describing the process for developing, installing, and running it. ΓòÉΓòÉΓòÉ 6.1. DCE Threads ΓòÉΓòÉΓòÉ In a traditional computer program, there is only one thread of control. Execution of the program proceeds sequentially, and at any given time, there is only one point in the program that is currently executing. It is sometimes useful, however, to write a program that contains multiple threads of control. For example, some programs lend themselves to being structured as multiple flows of control, some programs show better performance when they are multithreaded, and multiple threads can be mapped to multiple processors when they are available. A distributed computing environment based on the client/server model and remote procedure call makes good use of the multiple threads of control. For example, when a client makes an RPC call, it is blocked until a response is returned from the server. If there are multiple threads of control in the client, work can continue in another thread while the thread waiting for the RPC response is blocked. On the server side, this same situation applies. In addition, servers often handle the requests of multiple clients. It is sometimes easier to write a well-structured program when each request can be handled by a separate thread of control. Often servers manage information, requiring input/output operations to a storage device. While one server thread is waiting for its input or output operation to finish, another server thread can continue working, improving overall performance. Using multiple threads puts new requirements on programmers: they must manage the threads, synchronize their access to global resources, and make choices about thread scheduling and priorities. A threads implementation must provide facilities for programmers to perform these tasks. Threads can be provided by a programming language, an operating system kernel, or a user-space library. DCE Threads is provided as a user-space library. ΓòÉΓòÉΓòÉ 6.1.1. What Is DCE Threads? ΓòÉΓòÉΓòÉ DCE Threads is a user-level (nonkernel) threads library based on the pthreads interface specified by POSIX in their 1003.4a standard (Draft 4). It consists of an API that gives programmers the ability to create and manipulate threads. The other technology components of OSF's Distributed Computing Environment depend on the availability of threads. DCE Threads is provided for use on operating systems that do not provide threads already; if a threads package is already available, then DCE Threads may not be needed. DCE Threads can be used as is, as a user-level threading facility, or it can be mapped to an existing threads facility provided by the host operating system. DCE Threads is designed for compatibility with existing operating systems that deal with processes rather than with threads and libraries that are not reentrant (that is, not written to handle multiple threads executing within them at the same time). This compatibility is provided through the use of jacket routines, which are used in conjunction with existing libraries, and modified operating system calls. Because messages from outside the cell (such as interrupts and signals) have traditionally been addressed to a process, rather than a specific thread in a process, this interaction must be modified as well. ΓòÉΓòÉΓòÉ 6.1.2. End User's Perspective ΓòÉΓòÉΓòÉ An end user is not aware of threads used in an application, except for a possible difference in performance. An application written with threads may run faster than a single-threaded version of the same application. ΓòÉΓòÉΓòÉ 6.1.3. Programming with DCE Threads ΓòÉΓòÉΓòÉ The distributed application programmer can use threads to help structure a program. Having multiple threads of control can introduce a higher level of complexity than programming with a single thread of control. Threads must be managed, scheduled, and allowed to communicate with one another in a controlled manner. ΓòÉΓòÉΓòÉ 6.1.3.1. Threads Management ΓòÉΓòÉΓòÉ In a traditional process, there is only one thread of control, and it is started and terminated implicitly. When there is more than one thread of control, the threads must be created and destroyed explicitly. DCE Threads provides the facilities for these tasks. ΓòÉΓòÉΓòÉ 6.1.3.2. Threads Scheduling ΓòÉΓòÉΓòÉ With multiple threads, if there are fewer available processors than the number of threads to be run, some decision must be made as to which thread runs first. This is analogous to the scheduling of processes by the operating system on a timesharing system, except that the threads scheduling is visible to and controlled by the application programmer. (Note that POSIX specifies that scheduling is optional, so systems using their own threads implementations may not include the functionality provided by DCE Threads that is described in this section.) DCE Threads scheduling is built on two basic, interacting mechanisms: scheduling priorities, and scheduling policies. Each thread has a scheduling priority associated with it. Threads with a higher priority have precedence over threads with a lower priority. The exact treatment of threads of different priorities depends on the scheduling policy under which they are running. DCE Threads offers three scheduling policies: o First-In, First-Out (FIFO) In FIFO scheduling, the thread in the highest priority category that has been waiting the longest to run is scheduled first. It runs until it is blocked, then again the thread that has been waiting the longest runs, and so on. Threads in the highest priority level are run in this first-in, first-out manner, and then the threads in the next highest priority level are run FIFO, and so on. o Round-Robin (RR) With round-robin scheduling, all of the threads at the highest priority level are given turns running by timeslicing. That is, one thread runs for a period of time, and then it is interrupted and another thread runs for a period of time, and so on, until all threads have had a chance. The process is repeated until all threads in that priority are finished or blocked. Then the threads in the next highest priority level are also run round-robin until they are all finished or blocked, and so on. o Default In the default scheduling, each thread is given turns running by timeslicing. Higher priority threads are given longer periods of time to run, but even the lowest priority thread eventually has a chance to run. This method contrasts with FIFO and round-robin scheduling, in which higher priority threads may prevent lower priority threads from running at all. ΓòÉΓòÉΓòÉ 6.1.3.3. Thread Communication and Synchronization ΓòÉΓòÉΓòÉ Threads communicate through shared variables: one thread sets a variable that another thread later reads. If multiple threads are accessing the same variable, incorrect results can occur because of the scheduling of threads and the race conditions. Therefore, access to shared variables must be synchronized. DCE Threads provides three facilities for synchronizing threads within a process: o Mutual exclusion objects (mutexes) o Condition variables o The join routine. The mutex object is used to synchronize access to a given resource, such as a shared variable, by multiple threads. Mutexes ensure that only one thread accesses the resource associated with the mutex at a time-thus the mutual exclusion or mutex name. The mutex works as follows. One mutex object is associated with each shared resource, for example, a shared variable. Before reading or writing the variable, a thread attempts to lock the variable's mutex. If it succeeds in locking the mutex, the thread proceeds to access the variable, and then it unlocks the mutex. If a second thread tries to access the object while the first thread is accessing it (the condition that can cause indeterminate results if the shared variable is not protected), the second thread is blocked when it tries to lock the mutex. When the first thread finishes with the variable and unlocks the mutex, the second thread is unblocked and gains the lock for the mutex. It can then proceed to access the shared variable. The mutex is a facility by which threads can ensure that their access to shared resources is synchronized. The threads may or may not be communicating through the shared data. The second method of thread synchronization, the condition variable, is used for explicit communications among threads. This is done through the use of a shared resource, the condition variable, and as a result requires the use of a mutex. For example, using a condition variable, Thread A can wait for Thread B to accomplish some task. Thread A waits on the condition variable until Thread B signals the condition variable, indicating that the particular task has been accomplished. Although the condition variable is used for explicit communications among threads, the communications is anonymous. For example, Thread B does not know that Thread A is waiting on the condition variable that Thread B signals, and Thread A does not know that it was Thread B that woke it up from its wait on the condition variable. There is another synchronization method that is not anonymous, the join routine. It allows a thread to wait for another, specific thread to complete its execution. When the second thread has finished, the first is thread unblocked and continues its execution. Unlike mutexes and condition variables, the join routine is not associated with any particular shared data. ΓòÉΓòÉΓòÉ 6.1.3.4. DCE Threads Exceptions ΓòÉΓòÉΓòÉ DCE Threads provides two ways to obtain information about the results of a threads call. One way is specified by the POSIX P1003.4a (pthreads) draft standard: status values are returned to the thread. DCE Threads also gives the programmer an alternative to status values: an exception-returning interface, which is an extension to the basic POSIX functionality. Exceptions enable routines to ignore status returns when other parts of the program are handling errors. ΓòÉΓòÉΓòÉ 6.1.4. DCE Threads Administration ΓòÉΓòÉΓòÉ No administrative tasks are associated with the DCE Threads component. ΓòÉΓòÉΓòÉ 6.2. DCE Remote Procedure Call ΓòÉΓòÉΓòÉ A distributed application based on the client/server model consists of two parts: the client side of the application, which runs on one machine and makes a request for service on behalf of a user, and the server side of the application, which runs on another machine on the network and fulfills the service request. The two pieces of code on two different machines need to be able to communicate across the network. One model for implementing communications between the client and server of an application is the remote procedure call (RPC). RPC gives programmers the ability to express an interaction between the client and server of a distributed application as if it were a procedure call: the programmer defines a calling interface and a procedure that implements it, makes a call to the procedure along with any arguments, and receives a return value through the argument list or as the procedure result. In RPC, control is passed from one code segment to another, and then returns to the original segment. In a local procedure call, the code segments are in the same address space on the same machine, while in a remote procedure call, the called procedure runs in a different address space, usually on a different machine than the calling procedure. As a result, arguments and results are passed differently for local and remote procedure calls. In local procedure calls, arguments and return values can be passed on the process's stack. In remote procedure calls, arguments and return values must be packed up into messages and sent to the peer machine over the network. The underlying RPC mechanism makes this look like a local procedure call to the programmer. An RPC facility shields the application programmer from the details of network communications between client and server nodes, such as: o Fragmentation and reassembly of messages o Handling different data formats (such as byte ordering) between different machines o Using a directory service to find message recipients o Using security services to ensure secure communications. Programmers using RPC do not need to rewrite applications to port them to different architectures, operating systems, communications protocols, or languages. RPC provides a high-level programming model to the distributed application programmer, hiding communications details and removing nonportable system and hardware dependencies. ΓòÉΓòÉΓòÉ 6.2.1. What is DCE RPC? ΓòÉΓòÉΓòÉ DCE RPC is a facility for calling a procedure on a remote machine as if it were a local procedure call. To the application programmer, a remote call looks (almost) like a local call. There are several RPC components that work together to implement this facility, including the Interface Definition Language (IDL) and its compiler, a Universal Unique Identifier (UUID) generator, and the RPC Runtime, which supports two RPC protocol implementations. One RPC protocol operates over connection-oriented transports such as the Transmission Control Protocol/Internet Protocol (TCP/IP) and the other RPC protocol operates over connectionless transports such as the User Datagram Protocol/Internet Protocol (UDP/IP). An end user does not see RPC at all, and the minimal amount of administration involved in RPC can usually be handled by the server-side application code, such as advertising an application server in the DCE Directory Service. The application programmer most comes into contact with the RPC component. Because many of the DCE components are themselves client/server applications, they use RPC as their basis for distributed communications. The components that comprise the DCE RPC are as follows: o The Interface Definition Language (IDL) and its Compiler An RPC interface is described in DCE IDL. The IDL file is compiled into object code using the IDL compiler. The object code is in two main parts-one for the client side of the application, and one for the server side. o The RPC Runtime Library It consists of a set of routines, linked with both the client and server sides of an application, which implement the communications between them. This involves the client finding the server in the distributed system, getting messages back and forth, managing any state that exists between requests, and processing any errors that occur. o Authenticated RPC DCE RPC is integrated with the DCE Security Service component to provide secure communications. Levels of security can be controlled by the RPC application programmer through the Authenticated RPC API. (Programming with DCE Security for more information on Authenticated RPC.) o Name Service Independent (NSI) API DCE RPC is integrated with the DCE Directory Service component to facilitate the location of RPC-based servers by their clients. The NSI routines allow a programmer to control the association, or binding, of a client to a server during RPC. o The RPC Daemon The RPC daemon (rpcd) is a program that runs on every DCE machine. It is an RPC-specific name server, which manages a database that maps RPC servers to the transport endpoints (in IP, the ports) that the server is listening for requests on. o The RPC Control Program The RPC control program (rpccp) is a tool for administering rpcd. It also allows an administrator to access RPC data in CDS. o UUID Facilities These are ancillary commands and routines for generating Universal Unique Identifiers (UUIDs), which uniquely identify an RPC interface or any other resource. The uuidgen program can optionally generate an IDL template for a service interface, along with a unique identifier for the interface. ΓòÉΓòÉΓòÉ 6.2.2. End User's Perspective ΓòÉΓòÉΓòÉ The end user does not come in direct contact with DCE RPC, but does see the end result, in the form of o the availability of distributed applications built using RPC. o the ability to use remote resources accessed via RPC. ΓòÉΓòÉΓòÉ 6.2.3. Programming with DCE RPC ΓòÉΓòÉΓòÉ This section provides a brief overview of how a programmer uses DCE RPC to write an application. For an example of how this process applies to a simple application, see Two DCE Application Examples. DCE RPC Programming Process shows an overview of the DCE RPC application development process. The dashed boxes indicate application code written by the DCE programmer. The other boxes indicate compiled code or code generated automatically for the programmer by DCE RPC. DCE RPC Programming Process ΓòÉΓòÉΓòÉ 6.2.3.1. The IDL File ΓòÉΓòÉΓòÉ First, the application programmer defines the RPC interface and associated data types, using the DCE Interface Definition Language (IDL). An interface is a group of operations that a server can perform. This grouping is similar to a module or library in a conventional programming language, a group of operations defined in a single file or unit. For example, a Bank Service might perform operations to debit, credit, or read the balance of an account. Each of those operations and their parameters must be defined in the IDL file. The collection of Bank Service operations debit, credit, read balance, together form the Bank Service interface. The process of defining RPC operations is similar to defining the input and output of a local procedure call, except in IDL only the calling interface is defined, not the implementation of the procedure. (An IDL interface definition is similar to an ANSI C prototype definition.) Next, the programmer compiles the IDL file using the IDL compiler. The compiler produces output either in a conventional programming language, which is the C language in the DCE offering, or in object code. The output of the compilation consists of a client stub, a server stub, and a header file. The client and server stubs are routines that make the remoteness of the operation transparent to the caller or callee of the operation. ΓòÉΓòÉΓòÉ 6.2.3.2. The Client Side ΓòÉΓòÉΓòÉ For the client side of the application, the programmer writes application code that makes calls to the operations in the IDL file. The client stub code is linked with this application code, and (along with the RPC Runtime code) performs the tasks that turn what looks like a procedure call into network communications with the server side of the application. Usually the client side of the application contains a relatively small amount of RPC code. ΓòÉΓòÉΓòÉ 6.2.3.3. The Server Side ΓòÉΓòÉΓòÉ For the server side, the programmer writes application routines that implement the operations defined in the IDL file. For example, in the banking application, a database lookup might implement the operation to read an account balance. The server stub, generated by the IDL compiler, is linked with the server application code. The server stub unpacks the arguments and makes the call to the application routine as if the client program had called it directly. The server side of the application contains the bulk of the RPC code that needs to be written by the distributed application programmer. ΓòÉΓòÉΓòÉ 6.2.3.4. Binding ΓòÉΓòÉΓòÉ For the client to send an RPC to the server, it must be able to find the server. This process is called binding. A client may have some direct way of knowing what server it needs to communicate with; for example, it may get this information from a file, a value hardcoded into its program, an environment variable, or a user. A more flexible way for a client to find a server is to take advantage of the way the DCE RPC uses of the DCE Directory Service. A client can find a server by asking the Directory Service for the location of a server that handles the interface in which the client is interested (in our example, a Bank Server). For the Directory Service to be able to give the client this information, a server must first advertise itself in the Directory Service. The server adds itself to the namespace, along with information about what interfaces it implements, what protocols it uses to communicate with, and where it is located. This way, a server can move, or there can be multiple servers implementing a given interface, without affecting the client. The client can still go to the Directory Service, a well-known central source of information, and find out where the server is located. The DCE programmer does not make calls directly to CDS; binding is supported by the Name Service Independent (NSI) API, an RPC-specific name service layer. Calls to this library are made by the client side of an application to look up binding information for a server based on various criteria, such as the type of service, the objects it manages, and the interfaces it supports. The server side of an application calls this library to advertise information about itself to the namespace where clients can find it. ΓòÉΓòÉΓòÉ 6.2.3.5. The RPC Daemon ΓòÉΓòÉΓòÉ There are two parts to a server's location: the address of the machine it resides on and the address of the process, which is the network endpoint (for example, a UNIX port). Because the machine location is fairly stable, its address can be entered into the Cell Directory Service. The network endpoint, however, can change each time the server process is started up. Instead of making frequent changes to CDS to update a server's endpoint address, DCE RPC uses a specialized type of directory service, the RPC daemon, or rpcd. When a server starts up, it registers its process address with rpcd. Every machine that runs an RPC server also runs an rpcd. Because the rpcd process always uses the same network endpoint, its process address is well known. Once a client knows what machine a server is running on, it can find the rpcd process running on that same machine. It can then ask the rpcd process for the network endpoint of the server process. This process is shown in Client Finds Server Using CDS and RPC Daemon (read the messages, shown in quotes, in clockwise order). Client Finds Server Using CDS and RPC Daemon ΓòÉΓòÉΓòÉ 6.2.4. DCE RPC Administration ΓòÉΓòÉΓòÉ A few administrative tasks must be performed when a distributed application is running using RPC. The application server executes most of these tasks when it first starts up. Nonautomated RPC administration is minimal. The administrator must ensure that each DCE server machine has an RPC daemon running on it. An administrator may be involved in registering servers in the namespace, but this can also be done from server code upon initialization. A management program, rpccp, allows an administrator to control the rpcd and administer RPC information in the namespace. An administrator may be involved in installing a new RPC-based application. In particular, the server side of the application must be started up before it can begin receiving and servicing requests. The administrator may arrange for the server process to be run each time the machine is started. ΓòÉΓòÉΓòÉ 6.2.5. How It Works ΓòÉΓòÉΓòÉ A short walk-through of what happens during an RPC call may help clarify the RPC concept and how it works. This section describes the RPC call shown in RPC Runtime Process. (This description is somewhat simplified. The use of rpcd is not shown.) RPC Runtime Process On the server side, the Bank Server process is started up. Before it begins its continuous cycle of receiving and servicing requests, the server process advertises its location in the Cell Directory Service (see 1 in RPC Runtime Process). In this way, when a client queries the Directory Service for a bank server, it can find it. After initialization, the server listens for a request to come in from a client over the network. This call to wait for client requests is a call to the RPC Runtime, because the Runtime handles network communications. Eventually, a user on the Bank Client machine invokes the bank application. The Bank Client initialization code calls the RPC Runtime to find a server offering the Bank Service (2). The Bank Client application code makes a call to a remote procedure, for example, a call to a procedure that credits a bank account (3). This results in a call to the client stub code. The stub transforms the arguments of the call into a network message (4). It then calls the client's RPC Runtime library, which sends the message to the server (5). Back on the server side, the RPC request is received by the RPC Runtime, which has been waiting for a client request (6). The Runtime passes control, and the received packet, to the server stub. The stub unpacks the arguments sent by the client (7) and passes them to the appropriate operation by making a procedure call to it. At this point, the server application code that implements the requested operation is called. The operation is performed, and the account is credited (8). The RPC reply (not shown in the figure) returns in the reverse direction. The Bank Server application procedure returns the results of the credit operation to the stub. The stub packs up the return parameters and passes the resulting message to the RPC Runtime to send off to the client over the network. The server then waits for the next client request to come in. The client Runtime receives the server's reply. The client stub then unpacks the received network message, arranging returned parameters so that when the client application call to RPC returns, it looks as if it has just performed a local procedure call. The mechanisms in both the client and server stubs and the Runtime library are transparent to the application programmer. The programmer writes the application calls to the RPC operations on the client side and provides implementations for those operations on the server side, but the network communications code is generated automatically. ΓòÉΓòÉΓòÉ 6.2.6. System Independence ΓòÉΓòÉΓòÉ There are several ways in which using DCE RPC frees a programmer from dependence on other parts of a system. It provides portability across programming languages, data transfer syntax mechanisms, transport and network protocols, and operating system and architecture platforms. ΓòÉΓòÉΓòÉ 6.2.6.1. Language Independence ΓòÉΓòÉΓòÉ DCE RPC is language independent in the sense that the stubs generated by the IDL compiler can be called by programs written in any traditional programming language, provided that the language follows the calling conventions that the stub expects. The DCE IDL compiler generates stubs that use the C language calling conventions. A client written in FORTRAN, for example, can call an IDL stub in the same way that it calls any local C procedure. It can then make a remote call to a server (possibly written in another language) that contains the server stub generated from the same IDL file as the client stub was generated from. ΓòÉΓòÉΓòÉ 6.2.6.2. Data Representation Independence ΓòÉΓòÉΓòÉ The default data representation format is the DCE Transfer Syntax, which is currently the Network Data Representation (NDR). It allows various representations for different types of data, including multiple encodings for characters, integers, and floating-point numbers. It is multi-canonical; that is, there are several canonical formats that can be used. The sender chooses one of these formats (in most cases, it will be the sender's native data representation), with information about what representation it has chosen. The receiver transforms data into its own format, if it is different from the format the data was sent in. This model optimizes for the case when both sender and receiver use the same data representation, a frequent occurrence. (Note that this data transfer is handled by the RPC software and is not visible to the application programmer.) The DCE RPC architecture allows the use of transfer syntaxes other than DCE Transfer Syntax (although the only transfer syntax currently provided in the OSF implementation is DCE Transfer Syntax). For example, data could be formatted according to the ISO ASN.1/BER specification and sent over the wire in that way. ΓòÉΓòÉΓòÉ 6.2.6.3. Protocol Independence ΓòÉΓòÉΓòÉ Independence of RPC, transport, and network protocols is achieved by two different RPC protocols. The first runs over connection-oriented transport protocols; the second over connectionless (datagram) transport protocols. The programmer can specify the underlying RPC protocol, but the semantics of RPC calls are the same whether the RPC is running over a connectionless or connection-oriented transport. Another RPC protocol could be used in place of these two DCE RPC protocols; for example, when ISO defines an RPC standard, it could be used transparently as a third RPC protocol under the DCE RPC interfaces. Servers identify themselves to the Directory Service according to the interface they support and the protocols they use. In this way, a client can look up a server that uses network protocols that are compatible with those that the client supports. ΓòÉΓòÉΓòÉ 6.2.6.4. Machine Independence ΓòÉΓòÉΓòÉ Because DCE RPC uses the DCE Transfer Syntax, distributed applications are machine independent. Machines can transfer data even when their native data representations are not the same. ΓòÉΓòÉΓòÉ 6.2.6.5. Operating System Independence ΓòÉΓòÉΓòÉ Finally, DCE RPC offers independence from the local operating system. The application programmer does not directly use the networking system calls provided by the local operating system. By being one level of abstraction up from this layer, the programmer is insulated from networking system calls that are specific to the operating system specific. ΓòÉΓòÉΓòÉ 6.3. DCE Directory Service ΓòÉΓòÉΓòÉ A distributed system may contain many users, machines, and other resources, along with large amounts of data, all geographically dispersed. The distributed system's attributes, such as the number of users, location of servers, and contents of data, are continuously changing. It is difficult to keep track of this large, geographically distributed, rapidly changing system. A directory service can help solve this problem. When a directory service is available, it is no longer necessary to maintain local copies of information, such as databases of users, hosts, and server locations, on each system. Instead, an application queries the directory service when it needs information. In a sense, the directory service is the most basic of all distributed system services, because it is used to find the information needed for accessing other services. The Directory Service Interfaces describes the Directory Service application programming interface. ΓòÉΓòÉΓòÉ 6.3.1. DCE Directory Service Architecture ΓòÉΓòÉΓòÉ The DCE Directory Service is a distributed, replicated database service. It is distributed because the information that forms the database is stored in different places-information about one group of users and resources might be stored in one directory server, while information about a second group of users and resources is stored in a different directory server. The Directory Service is replicated because information about a given name or group of names can be stored in more than one location, for higher availability. The Directory Service database consists of a hierarchical set of names, the namespace, which have associated attributes. Given a name, its associated attributes can be looked up in the Directory Service. For example, given the name of a print server, the Directory Service can return the printer's location. The Directory Service gives distributed system users a well-known, central place to store information, which can then be retrieved from anywhere in the distributed system. ΓòÉΓòÉΓòÉ 6.3.1.1. Overview of Directory Service Components ΓòÉΓòÉΓòÉ There are three components that together comprise the DCE Directory Service: o The DCE Cell Directory Service (CDS) o The DCE Global Directory Service (GDS) o The DCE Global Directory Agent (GDA). The X/Open Directory Service (XDS) application programming interface is used to access the Directory Service components. ΓòÉΓòÉΓòÉ 6.3.1.1.1. DCE Cell Directory Service ΓòÉΓòÉΓòÉ The Cell Directory Service stores names and attributes of resources located in a DCE cell. It is optimized for local access, because most directory service queries are for information about resources within the same cell as the originator of the query. CDS replication is important for a local directory service, because the directory service must be highly available. There must be at least one Cell Directory Server in each DCE cell. ΓòÉΓòÉΓòÉ 6.3.1.1.2. DCE Global Directory Service ΓòÉΓòÉΓòÉ The DCE Global Directory Service is a distributed, replicated directory service based on the CCITT X.500/ISO 9594 international standard. It is used for looking up a name outside of the local DCE cell. In particular, it acts as the high-level connector that allows independent cells to find out about and interact with one another. GDS interworks with other X.500 implementations, and can therefore participate in the worldwide X.500 directory service. Three One-Celled Organizations shows three organizations, each with its own DCE cell. Three One-Celled Organizations The Global Directory Service can act as a higher level directory service to connect cells, as shown in GDS and DNS Connect DCE Cell Namespaces. DCE supports the use of a second standard directory service, the Domain Name Service (DNS), which is widely used in the Internet community. It, too, can act as a higher level connector of DCE cells. GDS and DNS Connect DCE Cell Namespaces ΓòÉΓòÉΓòÉ 6.3.1.1.3. DCE Global Directory Agent ΓòÉΓòÉΓòÉ The Global Directory Agent is the intermediary between a cell's CDS and the rest of the world. It takes a name that cannot be found in the local cell and finds the foreign cell in which the name resides, using GDS or DNS, depending on where the foreign cell is registered. Use of Global Directory Agents gives a functional picture, including the use of GDAs, of the configuration shown in GDS and DNS Connect DCE Cell Namespaces. Use of Global Directory Agents ΓòÉΓòÉΓòÉ 6.3.1.1.4. DCE Directory Service Application Programming Interface ΓòÉΓòÉΓòÉ DCE programmers use the X/Open Directory Service (XDS) application programming interface to make all Directory Service calls. The XDS library knows, based on the format of the name to be looked up, whether to direct the calls it receives to GDS or to the CDS (see XDS: Interface to GDS and CDS). XDS uses the X/Open Object Management (XOM) application programming interface to define and manage its information. XDS: Interface to GDS and CDS ΓòÉΓòÉΓòÉ 6.3.1.2. The DCE Namespace ΓòÉΓòÉΓòÉ The DCE namespace is the set of names used by the DCE Directory Service. It is hierarchical, similar to the structure of a UNIX file system. Names can be typed or untyped, reflecting the different name formats supported by the two global directory services, GDS and DNS. Four Cells in DCE Global Namespace shows the root of the DCE namespace, indicated by the /... prefix, and four cell entries below it. The two cells on the left, /.../C=US/O=OSF/OU=DCE and /.../C=CA/O=B-College/OU=EE-Department, are in the X.500 namespace, while the two cells on the right, /.../company_b.com and /.../cs.univ.edu, are in the DNS namespace. Four Cells in DCE Global Namespace Top of a Typical DCE Cell Namespace shows the top of a typical DCE cell namespace. It contains an entry for security information, an entry for the cell's DFS file system, an entry for subsystems such as DCE services, an RPC Profile entry, and an entry for host names. Top of a Typical DCE Cell Namespace The following is a list of examples of typed and untyped names. /.../C=US/O=OSF/OU=DCE/sec/principals/snowpaws /.../C=US/O=OSF/OU=DCE/fs/usr/snowpaws /.../cs.univ.edu/sec/principals/ziggy /.../cs.univ.edu/fs/usr/ziggy The /... prefix indicates that the name is a global name. The first two names are typed names using X.500 syntax, and the second two names are untyped names using DNS syntax. The first name in each set indicates the name of a user in an authentication database; the second name in each set is the user's home directory in a file system. In each of the name examples, there is a global component and a local component. The global component consists of a cell name, which is registered in a global directory service. In one case, the cell is an entry in the X.500 namespace: /.../C=US/O=OSF/OU=DCE. In the other case, the cell is an entry in the DNS namespace: /.../cs.univ.edu. The remainder of the name is an entry in the cell's namespace; for example, /fs/usr/snowpaws. The names listed above reside in the DCE cell namespace, but it is also possible to maintain names in the X.500 namespace by using GDS. An example of this kind of name is /.../C=US/O=OSF/OU=DCE/CN=SIG-DCE. This name could be used, for example, for an electronic mail list. ΓòÉΓòÉΓòÉ 6.3.1.3. Viewpoints on the Directory Service ΓòÉΓòÉΓòÉ The DCE Directory Service looks very different to the end user, programmer, and administrator. ΓòÉΓòÉΓòÉ 6.3.1.3.1. End User's Perspective ΓòÉΓòÉΓòÉ The DCE Directory Service is one of the few DCE technologies that is visible to the end user. An end user can use the CDS Browser to look through the cell's namespace. ΓòÉΓòÉΓòÉ 6.3.1.3.2. Application Programmer's Perspective ΓòÉΓòÉΓòÉ DCE application programmers do not necessarily need to work directly with the Directory Service, because a frequent use of the Directory Service to look up the location of a server can be done automatically by DCE RPC. Programmers who do use the Directory Service interact with it through the X/Open Directory Service interface. XDS provides facilities for adding, deleting, modifying, and looking up names and their attributes. Programmers use XDS for accessing both DCE directory services-CDS and GDS. The programmer needs to understand the different types of names used for different namespaces, and be aware of some XDS calls that are not available when CDS is being used. An example is the search query, which is possible in GDS, but not in CDS. ΓòÉΓòÉΓòÉ 6.3.1.3.3. Administrator's Perspective ΓòÉΓòÉΓòÉ Unlike the end user and application programmer, the Directory Service administrator is aware of the cell's directory service configuration, because the two directory services are administered separately. The administrator manages the CDS server, the Global Directory Agent, and the GDS server, if the cell has one. ΓòÉΓòÉΓòÉ 6.3.1.4. Related Services: Registration and Lookup Path ΓòÉΓòÉΓòÉ There are two services in DCE that are distinct from, but related to, the DCE Directory Service. The first is registration. In naming an object in a distributed system, it is useful to have a unique name for the object. DCE provides a facility for generating Universal Unique Identifiers (UUIDs), which are used to name DCE objects such as RPC interfaces, users, and computing resources. A second service that is related to directory service is the ability to specify a path through the directory service for looking up names. In DCE, this capability is provided by RPC profiles. They can be used, for example, to look up names relative to a certain location. If a user wants to look up a printer based on the printer's proximity to the user, for example, a profile may specify that a directory service lookup for a printer begin in the local cell, then if a printer is not found, look in the two neighboring cells, and so on. ΓòÉΓòÉΓòÉ 6.3.1.5. Specialized Naming Services ΓòÉΓòÉΓòÉ The DCE namespace is not contained entirely in the DCE Directory Service. Other system services contain parts of the namespace which supplement the DCE Directory Service. Some of them require their own specialized naming services. These include: o The Security Service Database The Security Service keeps a database of DCE principals (users and servers) and information related to them such as their passwords. An example of a name in the security part of the DCE namespace is /.../cs.univ.edu/sec/principal/ziggy. o The DFS Fileset Location Server Database The Fileset Location Server maintains a database that maps DFS filesets to the DFS File Server machines they are kept on. An example of a name in the DFS part of the DCE namespace is /.../cs.univ.edu/fs/usr/ziggy. ΓòÉΓòÉΓòÉ 6.3.2. DCE Cell Directory Service ΓòÉΓòÉΓòÉ One of the two directory services underlying the XDS API is the DCE Cell Directory Service (CDS). The following subsections describe CDS in terms of the data elements that it deals with and the components that implement it. They then describe how CDS handles replication, caching, and data consistency. Finally, they describe CDS from the end-user, programmer, and administrator perspectives. ΓòÉΓòÉΓòÉ 6.3.2.1. What Is CDS? ΓòÉΓòÉΓòÉ The DCE Cell Directory Service is made up of several components, including the CDS Server, CDS Clerk, and CDS Administration Programs. o CDS Server The CDS Server runs on a node containing a database of directory information. It responds to queries from clients by accessing the database. (A CDS database is called a clearinghouse.) o CDS Clerk The CDS Clerk runs on the client node and serves as an intermediary between client applications and CDS Servers. One of the Clerk's most important functions is to maintain a cache of information acquired through directory queries. The Clerk stores the response to a query in its cache so that the next time a related query is made, the information is already available on the client node, and no network communications with the CDS Server are necessary. The cache is written to disk periodically, so it persists even if the Clerk process dies or the client node is terminated. o CDS Administration Programs Two administrative programs are included in the CDS technology. The CDS Namespace Browser and the CDS Control Program. The CDS Namespace Browser, which is used by CDS administrators as well as end users, is a CDS client application that allows the user to look at the cell's namespace. The CDS Control Program, cdscp, enables administrators to control CDS Servers. ΓòÉΓòÉΓòÉ 6.3.2.2. The CDS Database ΓòÉΓòÉΓòÉ CDS information is contained in three types of data elements-directory entries, directories, and clearinghouses. o Directory Entries A directory entry consists of a name and its attributes. One example is the name of an application server, whose attributes include the interface it exports and its location on the network. o Directories A CDS directory is a logical grouping of CDS information. It is a collection of directory entries. The directory is the administrative unit for replication. There can be one or more copies, or replicas, of a given directory. CDS directories are in a hierarchical relationship to one another; each directory has a parent directory and may also have child directories. o Clearinghouses A clearinghouse is a physical CDS database it is a collection of directory replicas. The clearinghouse is the database on a CDS Server machine that the CDS Server accesses in order to respond to its requests. As an example of how the different types of CDS data elements relate to one another, imagine a directory P, which contains all the information about the printers in a given cell. This directory contains one directory entry per printer. The administrator of the cell may decide that the information contained in the P directory is important enough that it needs to be replicated on more than one CDS Server, so if one server goes down, the P information can still be found on the other server. To that end, replicas of the P directory might be kept in two clearinghouses: one replica in Clearinghouse A; the other in Clearinghouse B. ΓòÉΓòÉΓòÉ 6.3.2.3. Replication and Data Consistency in CDS ΓòÉΓòÉΓòÉ A directory service must be highly available, because other services depend on it. It must also be fast. CDS achieves these two goals through the replication of directories and caching of directory entries. It also provides mechanisms for keeping various degrees of consistency among copies of data. There are two types of directory replicas in CDS: Master Replica and Read-Only Replica. There is exactly one master replica of a given directory, and any kind of operation can be performed on it. The only operations that can be performed on a read-only replica are those limited to read access to the directory; no updates can be made to this type of directory replica. There can be zero or more read-only replicas. CDS provides two methods for maintaining data consistency among replicas of a directory: Immediate Propagation and Skulking. In immediate propagation, a change made to one copy is immediately made to other copies of the same data. Immediate propagation is used when it is important for all copies of a directory to be consistent at all times. In some cases, copies do not have to be updated immediately. Sometimes it is not even possible, because a server holding a copy may be unavailable to receive updates. In these cases, the other consistency mechanism, skulking, can be used. A skulk happens periodically (for example, every 24 hours), and is done on a per-directory basis. All changes made to the given directory are collected and propagated in bulk to all clearinghouses that contain replicas of the directory. If a skulk cannot complete, that is, if one or more of the nodes containing a replica to be updated is down, then an administrator is notified and the skulk is attempted again later. Caching is also a form of replication, and therefore leads to the problem of keeping multiple copies of information consistent (or in this case, dealing with the fact that cached information may be out of date). CDS allows the client application to bypass the Clerk's cache and go directly to the CDS Server for information, when the application wants to make sure it has the latest information. ΓòÉΓòÉΓòÉ 6.3.2.4. End User's Perspective ΓòÉΓòÉΓòÉ An end user may be interested in looking at the cell namespace to look for information contained in CDS. This can be done using the CDS Namespace Browser. ΓòÉΓòÉΓòÉ 6.3.2.5. Programming with CDS ΓòÉΓòÉΓòÉ Programmers can access CDS through XDS. (See The Directory Service Interfaces). They also use CDS indirectly when they use the Name Service routines of the RPC API. ΓòÉΓòÉΓòÉ 6.3.2.6. CDS Administration ΓòÉΓòÉΓòÉ CDS administrators use the CDS Control Program to administer CDS and the CDS Namespace Browser to inspect its data. Some administrative tasks include determining the number of CDS Servers in the cell and specifying replication and update of CDS data. ΓòÉΓòÉΓòÉ 6.3.3. DCE Global Directory Service ΓòÉΓòÉΓòÉ The DCE Global Directory Service (GDS) is a directory service implementation based on the international standard CCITT X.500/ISO 9594. When present in a DCE cell, the GDS can serve two basic functions. First, it can participate in a high level, possibly worldwide directory service tying together independent DCE cells. Second, it can be used as an additional directory service to CDS for storing object names and attributes in a central place. Like the Cell Directory Service, GDS is a replicated, distributed database. The GDS database contains information that can be distributed over several GDS servers. In addition, copies of information can be stored in multiple GDS servers, and the information can also be cached. The unit of replication in GDS is the directory entry (whole subtrees can also be specified). The GDS directory is structured differently from CDS, and names are also different in that they are typed, as described later. Programmers can access both DCE Directory Services, however, using the X/Open Directory Service API (see The Directory Service Interfaces for a description of XDS). ΓòÉΓòÉΓòÉ 6.3.3.1. What Is GDS? ΓòÉΓòÉΓòÉ Several components work together to provide the DCE Global Directory Service: o The Directory System Agent (DSA) This process runs on the GDS Server machine and manages the GDS database. It is the server side of GDS. To handle simultaneous requests from different users, the GDS Server machine can run several DSA processes. o The Directory User Agent (DUA) The DUA is a library that implements the GDS client; this library is present on all GDS client machines. o The Directory User Agent Cache This process keeps a cache of information obtained from DSAs. One DUA Cache runs on each client machine and is used by all the users on that machine. The DUA Cache contains copies of recently accessed object entries and information about DSAs. The programmer specifies which information should be cached, and the DUA Cache can be bypassed to obtain information directly from a DSA. This is desirable, for example, when the user wants to make sure the information obtained is up-to-date. o The C-Stub and S-Stub The C-Stub process runs on each client machine and manages communications with DSAs. It implements the upper layers of the ISO protocol stack. (See GDS Relation to Standards.) Its function is similar to the RPC Runtime. (GDS uses OSI protocols instead of DCE RPC.) The S-Stub is similar to the C-Stub, except it runs on the server machine and manages its communications with DUAs and other DSAs. o The Shadow Update and Cache Update Processes Unlike the processes listed previously, which run continuously, the processes for updating replicas in DSAs and DUA Caches run as needed and then are terminated. The shadow update process runs on the GDS server machine; the cache update process runs on GDS client machines. o The GDS Administration Programs DCE GDS provides programs for administering its service. One, gdssysadm, supports administration of the local GDS installation, such as configuration, server activation, and backup. The gdsditadm program supports remote administration of the contents of a GDS database. Finally, the gdscacheadm program supports the administration of the contents of the local DUA cache. GDS Components shows the interaction between the Directory Service application, the XDS interface, and the GDS client and server. The GDS client and server use the Directory Access Protocol (DAP) to communicate. The GDS servers use the Directory System Protocol (DSP) to communicate with one another. DAP and DSP perform functions similar to the function that the DCE RPC protocols perform in other DCE services. The DAP and DSP protocols are defined in the X.500 standard, enabling worldwide interoperability among directory services. GDS Components ΓòÉΓòÉΓòÉ 6.3.3.2. GDS Configurations ΓòÉΓòÉΓòÉ A GDS machine can be configured in two ways: o Client Only A node can contain only the client side of GDS. This node can access remote DSAs and cache some information in the DUA cache. o Client/Server A machine can be configured with both the GDS client and server. This is the typical configuration for a machine acting as a GDS server. This configuration can be useful even if a node acts mainly as a client because the DSA can be used as a larger, more permanent cache of information contained in remote DSAs. ΓòÉΓòÉΓòÉ 6.3.3.3. The GDS Database ΓòÉΓòÉΓòÉ The GDS database is a hierarchical, object-oriented database. The OSF DCE reference implementation of GDS uses the C-ISAM database software. The information comprising the Global Directory Service takes the following forms: o Object Entry An object entry is an entry in the database that names and describes an object, such as a person, machine, or server. It consists of one or more attributes, and each of the attributes has a type and a value. For example, an attribute type might be COMMON NAME (or CN) and the value might be snowpaws; another attribute might be type MACHINE ADDRESS and the value might be 100.100.1.177. Some attributes may have more than one value. Each object entry has an attribute of type OBJECT CLASS, and its value specifies what the object's class is, which determines what other attributes the object entry has. The name of an entry consists of one or more of its attributes. (See GDS Object Entry.) GDS Object Entry o Relative Distinguished Name (RDN) The name attribute of an object contains the object's Relative Distinguished Name (RDN). An RDN contains both the type and value of the naming attribute; for example, ``CN = snowpaws'' or ``MACHINE NAME = MachineA.'' (In DCE Directory Service notation, the type and value of an attribute are separated by an equal sign.) o Distinguished Name (DN) The Distinguished Name is the concatenation of the object's RDN and the RDNs of all its ancestors in the GDS naming hierarchy, like a full pathname for a file in a UNIX file system. An example of a DN might be /.../C=US/O=OSF/OU=DCE/CN=snowpaws. (In DCE Directory Service notation, the RDNs are separated by slashes.) o Directory Information Base (DIB) The Directory Information Base consists of all the object entries in all the Directory Service Agents in GDS. o Directory Information Tree (DIT) The Directory Information Tree is the structure of the GDS namespace; it determines the hierarchy of GDS names. For example, the DIT might specify that the only entries that can come directly under the DIT root are entries describing countries, such as /.../C=US or /.../C=JP. o Directory Schema The Directory Schema contains structuring rules for the GDS information. This includes object classes, their attributes, and their syntax. o GDS Access Control Lists Security in GDS is not integrated with the DCE Security Service. It is based on Access Control Lists, but GDS ACLs are different from other DCE ACLs. Each object entry has an ACL associated with it. It specifies permission to access the object's attributes. The attributes can be classified as PUBLIC, STANDARD, or SENSITIVE. The object's ACL grants a user or group of users five different types of permission: modify PUBLIC attributes, read or modify STANDARD attributes, read or modify SENSITIVE attributes. When a new object entry is created in the GDS directory, it inherits the security characteristics of its parent entry by default. An object entry's ACLs are attributes of the object entry. ΓòÉΓòÉΓòÉ 6.3.3.4. How GDS Works ΓòÉΓòÉΓòÉ When an application program makes a Global Directory Service call using the XDS API, the call is handed to the DUA library. The DUA first looks in the DUA Cache (if specified) to see if the requested information is already available on the local node. If it is not, the DUA queries a Directory Service Agent. The DSA may have the requested information, and if it does, it returns the results to the DUA. If it does not, the query can proceed in one of two ways. Either the DSA can query a different DSA on behalf of the DUA, or the DSA can return information that the DUA can query a second DSA itself. The first method is called chaining, and the second method is called referral. In either case, different DSAs are queried until the information is found. It is cached (if specified) in the DUA Cache, and the results are returned to the GDS application program. ΓòÉΓòÉΓòÉ 6.3.3.5. GDS and Network Services ΓòÉΓòÉΓòÉ The X.500 Directory Service standard was written to run on top of the Open Systems Interconnection (OSI) communications protocols. The OSI protocols are divided into seven layers: the Physical, Data Link, Network, Transport, Session, Presentation, and Application Layers (see The OSI Protocol Layers.) The upper three layers are usually implemented as libraries that are linked together with the application process. The lower layers are part of the operating system, and their services are made available to the upper layers through a transport interface. The transport interface is the double line in The OSI Protocol Layers. The OSI Protocol Layers The Directory Service is an Application Layer protocol. Its specification requires the use of two other application layer service elements: ACSE (Association Control Service Element) and ROSE (Remote Operation Service Element), and of the underlying layers. ROSE and ACSE of Layer 7, and the Presentation Service of Layer 6, are implemented in GDS by the Remote Operation Service (ROS) library. The OSI Session Service (Layer 5) is implemented in GDS by the OSI Session Service (OSS) library. These layers are equivalent to the communications support supplied by the DCE RPC Runtime system, which also fills in the gap between an application and the underlying transport communications. Although GDS supplies support for these upper OSI layers, they are used only for the Directory Service and are not made available for application programmers. DCE requires that the system it runs on provide support for transport layer communications (either OSI transport or IP transport). The OSI protocols running above the transport layer were originally designed to run over OSI transport protocols. Many DCE systems run TCP/IP, so GDS provides the capability for running over the TCP/IP transport protocol as specified in RFC 1006. The GDS software includes a compiler and a runtime library called MAVROS. The compiler takes specifications written in the Abstract Syntax Notation (ASN.1) and compiles them into C language code for header files and encoding/decoding routines, much as the RPC IDL compiler takes an IDL specification and compiles it into a header file and client and server stubs. MAVROS is used to encode and decode the DAP and DSP protocols and their data values. ΓòÉΓòÉΓòÉ 6.3.3.6. GDS Relation to Standards ΓòÉΓòÉΓòÉ The OSI software provided in DCE is based on the following ISO standards: o X.500/ISO 9594 The CCITT 1988 version (Blue Book), which shares the same text as ISO Directory Standard 9594 (v1) published in 1990. o ROSE/ACSE/Presentation/Session ISO 9072 (v1:1989), 8650 (v1:1988), 8649, 8823 (v1:1988), and 8327 (v2:1988) Protocol International Standards. The implementation follows EWOS agreements. o ASN.1/BER The ASN.1 compiler accepts ASN.1 syntax conformant to ISO 8824 and generates routines to encode/decode data conformant to ISO 8825 Basic Encoding Rules. The GDS software provides functional extensions to the standards in the following areas: o Replication o Knowledge Information Modelling and Administration o Schema Modelling and Administration o Subtree Administration o Caching o Remote Administration o Security (Access Control). ΓòÉΓòÉΓòÉ 6.3.4. DCE Global Directory Agent ΓòÉΓòÉΓòÉ The DCE Global Directory Agent (GDA) is the third major component of the DCE Directory Service. It acts as an intermediary between the local cell's directory service and the global directory services. In particular, the GDA handles CDS calls that are directed to foreign cells. The foreign cells must be registered with one of the two global directory services that DCE supports-the X.500 Directory Service or the Domain Name Service. ΓòÉΓòÉΓòÉ 6.3.4.1. What Is GDA? ΓòÉΓòÉΓòÉ The DCE Global Directory Agent is a process that acts as an interface between CDS and GDS or the Domain Name Service. The GDA is not visible to the end user. Programmers access the GDA indirectly through the XDS API. GDA administration consists simply of starting and stopping the GDA process. At least one GDA must be present in a DCE cell for that cell to acquire directory service information from other DCE cells. ΓòÉΓòÉΓòÉ 6.3.4.2. GDA and Other Directory Service Components ΓòÉΓòÉΓòÉ GDA and Other Directory Service Components shows how the GDA relates to other Directory Service components. GDA and Other Directory Service Components The application uses XDS to make a Directory Service call. If the name to be accessed is a typed name, such as /.../C=US/O=OSF/OU=DCE/CN=SIG-DCE, then the query is passed to the Global Directory Service. If the name to be accessed is an untyped name, such as /.../cs.univ.edu/fs/usr/ziggy, or a partially typed name, such as /.../C=US/O=OSF/OU=DCE/fs/usr/snowpaws, then the query is passed to the Cell Directory Service. If the name is a local name, contained in the local CDS, then the query is handled by the local CDS server. If it is a name that resides in a foreign cell, it is passed to the GDA. The GDA determines whether the foreign cell is registered in X.500 or DNS, based on the format of the name. It then contacts a GDS server or DNS server to find the foreign cell. Once the foreign cell is found, information about that cell is cached so that subsequent lookups of names in that cell do not require the involvement of a global directory server. Finally, the CDS server in the foreign cell is contacted to handle the query about the name. ΓòÉΓòÉΓòÉ 6.3.5. The Directory Service Interfaces ΓòÉΓòÉΓòÉ The X/Open Directory Service (XDS) and X/Open Object Management (XOM) APIs provided by the DCE Directory Service are based on X/Open specifications. APIs are not really separate components (every DCE component includes APIs to access it), but we call them out separately in this case because programmers use the Directory Service APIs to access both DCE directory services-CDS and GDS. ΓòÉΓòÉΓòÉ 6.3.5.1. The XOM Application Programming Interface ΓòÉΓòÉΓòÉ XOM is an interface for creating, deleting, and accessing objects containing information. It is an object-oriented architecture: each object belongs to a particular class, and classes can be derived from other classes, inheriting the characteristics of the original class. The representation of the object is transparent to the programmer; the object can only be manipulated through the XOM interface, not directly. XOM is used to create the objects that make up the Directory Service. XOM defines basic data types, such as Boolean, string, object, and so on. It defines an information architecture, including concepts such as objects, their attributes, and their classes. It also provides definitions of routines for manipulating objects. ΓòÉΓòÉΓòÉ 6.3.5.2. The XDS Interface ΓòÉΓòÉΓòÉ The X/Open Directory Service (XDS) API is used by DCE programmers for accessing information in the DCE Directory Service, whether the information is managed by CDS or GDS. It uses the XOM interface for defining and handling the information objects that comprise the directory. These objects are passed as parameters and as return values to the XDS routines. The XDS API contains routines for managing connections with a Directory Server: reading, comparing, adding, removing, and modifying entries; listing directories; and searching for entries. Some extensions to the X/Open standard that the DCE XDS API provides include provisions for security and cache management. ΓòÉΓòÉΓòÉ 6.4. DCE Distributed Time Service ΓòÉΓòÉΓòÉ A distributed computing system has many advantages, but also brings with it new problems. One of them is keeping the clocks on different nodes synchronized. In a single system, one clock provides the time of day to all applications. Computer hardware clocks are not completely accurate, but there is always one consistent idea of what time it is for all processes running on the system. In a distributed system, however, each node has its own clock. Even if it were possible to set all of the clocks in the distributed system to one consistent time at some point, those clocks would drift away from that time at different rates. As a result, the different nodes of a distributed system have different ideas of what time it is. This is a problem, for example, for distributed applications that care about the ordering of events. It is difficult to determine whether Event A on Node X occurred before Event B on Node Y because different nodes have different notions of the current time. The DCE Distributed Time Service (DTS) addresses this problem in two ways: 1. DTS provides a way to periodically synchronize the clocks on the different hosts in a distributed system. 2. DTS also provides a way of keeping that synchronized notion of time reasonably close to the correct time. (In DTS, correct time is considered to be Coordinated Universal Time (UTC), an international standard.) These services together allow cooperating nodes to have the same notion of what time it is, and to also have that time be meaningful in the rest of the world. Distributed time is inherently more complex than time originating from a single source. Because clocks cannot be continuously synchronizing, there is always some discrepancy in their ideas of the current time as they drift between synchronizations. In addition, indeterminacy is introduced in the communications necessary for synchronization. Clocks synchronize by sending messages about the time back and forth, but that message passing itself takes a certain (unpredictable) amount of time. In addition to being able to express the time of day, a distributed notion of time must also include an inaccuracy factor. How close the timestamp is to the real time. As a result, keeping time in a distributed environment requires not only new synchronization mechanisms, but also a new form of expression of time, one that includes the inaccuracy of the given time. In DTS, distributed time is expressed as a range, or interval, rather than as a single point. ΓòÉΓòÉΓòÉ 6.4.1. What Is DTS? ΓòÉΓòÉΓòÉ There are several different components that comprise the DCE Distributed Time Service: o Time Clerk o Time Servers - Local Time Server - Global Time Server - Courier Time Server - Backup Courier Time Server o DTS Application Programming Interface o Time Provider Interface (TPI) o Time format, which includes inaccuracy. The active components are the Time Clerk and different kinds of Time Servers. There are two interfaces: a programming interface (DTS API) and an interface (TPI) to an External Time Provider. Finally, DTS defines a new format for expressing time. ΓòÉΓòÉΓòÉ 6.4.1.1. Time Clerk ΓòÉΓòÉΓòÉ The Time Clerk is the client side of DTS. It runs on a client machine, such as a workstation, and keeps the machine's local time synchronized by asking Time Servers for the correct time and adjusting the local time accordingly. The Time Clerk is configured to know the limit of the local system's hardware clock. When enough time has passed that the system's time is above a certain inaccuracy threshold (that is, the clock may have drifted far enough away from the correct time), the Time Clerk issues a synchronization. It queries various Time Servers for their opinion of the correct time of day, calculates the probable correct time and its inaccuracy based on the answers it receives, and updates the local system's time. The update can be gradual or abrupt. If an abrupt update is made, the software register holding the current time is modified to reflect the new time. Usually, however, it is desirable to update the clock gradually, and in this case the tick increment is modified until the correct time is reached. In other words, if a clock is normally incremented 10 milliseconds at each clock interrupt, and the clock is behind, then the clock register will instead be incremented 11 milliseconds at each clock tick until it catches up. DTS Time Clerks and Servers shows a LAN with two Time Clerks (C) and three Time Servers (S). Each of the Time Clerks queries two of the Time Servers when synchronizing. The Time Servers all query each other. DTS Time Clerks and Servers ΓòÉΓòÉΓòÉ 6.4.1.2. Time Server ΓòÉΓòÉΓòÉ The Time Server is a node that is designated to answer queries about the time. The number of Time Servers in a DCE cell is configurable; three per LAN is the minimum number. Time Clerks query these Time Servers for the time, and the Time Servers query one another, computing the new system time and adjusting their own clocks as appropriate. One or more of the Time Servers can be attached to an External Time Provider. A distinction is made between Local Time Servers (Time Servers on a given LAN) and Global Time Servers. They are located differently by their clients. A client may need to contact a Global Time Server if, for example, the client wants to get time from three servers, but only two servers are available on the LAN. In addition, it may be desirable to configure a DTS system to have two LAN servers and one Global Time Server synchronizing with each other, rather than just having time servers within the LAN synchronizing with each other. This condition requires Couriers. A Courier Time Server is a Time Server that synchronizes with a Global Time Server. That is, a Time Server outside the Courier's LAN. It thus imports an outside time to the LAN by synchronizing with the outside Time Server. Other Time Servers in the LAN can be designated as Backup Courier Time Servers. If the Courier is not available, then one of the Backup Couriers serves in its place. Local, Courier, and Global Time Servers shows two LANs (LAN A and LAN B) and their Time Servers (S). In each LAN, one of the Time Servers acts as a Courier Time Server (Co) by querying a Global Time Server (G) (that is, a Time Server outside of either LAN) for the current time. Local, Courier, and Global Time Servers ΓòÉΓòÉΓòÉ 6.4.1.3. DTS Application Programming Interface ΓòÉΓòÉΓòÉ DTS provides an API library that allows programmers to manipulate timestamps. For example, programmers can obtain a timestamp representing the current time, translate timestamps to different formats, and compare two timestamps. ΓòÉΓòÉΓòÉ 6.4.1.4. Time Provider Interface ΓòÉΓòÉΓòÉ So far, all the components described are those supporting the synchronization of a distributed system's clocks. There must also be a way to ensure they are synchronized to the correct time. The notion of the correct time must come from an outside source, the External Time Provider. This may be a hardware device such as one that receives time from radio or telephone sources. This external time is given to a Time Server, which then communicates it to other servers. Such an External Time Provider can be very accurate. If no such device is available, the external time source can be the system administrator, who consults a trustworthy time source and enters it into the system. This method cannot, of course, be as accurate as an automatic time source, but it may be sufficient in some cases. DTS supports the ability to work with an External Time Provider through the Time Provider Interface. The External Time Provider itself, however, is a hardware device (or a person), and is therefore outside the scope of DCE. ΓòÉΓòÉΓòÉ 6.4.1.5. DTS Time Format ΓòÉΓòÉΓòÉ The time format used in DTS is a standard one: UTC, which notes the time since October 15, 1582, the beginning of the Gregorian calendar. This time is interpreted using the Time Differential Factor (TDF) for use in different time zones. For example, the TDF in New York City is -5 hours. The TDF for Greenwich, England is 0. ΓòÉΓòÉΓòÉ 6.4.2. End User's Perspective ΓòÉΓòÉΓòÉ From a user's point of view, the advantage of having a distributed time service is that more applications work as expected in a distributed environment. For example, the UNIX make program compiles new binary files if it discovers that the source file has been changed since the last time the binary was compiled. In a distributed system, this change may not work properly if the source is on one machine and the binary is on another, and the two machines have different ideas of what time it is (and of what time it was when their files were updated). Having DTS means that the nodes have roughly the same notion of time, and the make program works as expected. ΓòÉΓòÉΓòÉ 6.4.3. Programming with DTS ΓòÉΓòÉΓòÉ There are two ways a programmer can be affected by the presence of DTS in a system. An application can retrieve the time from the system in the same way as before DTS was introduced. But with DTS, the system's time is more correct, and is synchronized with the clocks of other nodes in the distributed system. The programmer can also use the DTS API to directly deal with distributed time. Because DTS time is represented differently than single-node time-it includes inaccuracy-new routines are provided for comparing times and for converting from DTS time format to the native system's time format. The API also includes routines for retrieving the current time, performing calculations on times, and handling time zone information. If programmers choose to use DTS directly, they must handle a new contingency when comparing times. When asking the question "Which time is earlier, Time A or Time B?", it is possible to get the answer "We do not know.". When the two time intervals overlap, there is no way of determining which occurred first. Programmers can handle this problem in two ways: they can ignore the inaccuracy and compare the two median times; or (the safer alternative) they can acknowledge that either time could have been first, and take the more conservative action. For example, if it cannot be determined, when the make program is running, whether the source or the executable was modified last, the compilation can be rerun, just in case the source was modified after the executable was generated. ΓòÉΓòÉΓòÉ 6.4.4. DTS Administration ΓòÉΓòÉΓòÉ Administering a distributed time service is more involved than administering the time in a single node. In a single node, time administration typically consists of setting the time and date when a system is first started up, and then updating the time occasionally to compensate for clock drift. DTS requires more setup and configuration work for the administrator, although once it is up and running, the administrative maintenance tasks are infrequent. ΓòÉΓòÉΓòÉ 6.4.5. Interaction with the Network Time Protocol ΓòÉΓòÉΓòÉ The Network Time Protocol (NTP), an Internet recommended standard that is widely used in the Internet, is another method of synchronizing time in a distributed environment. It is possible for NTP servers to provide time to a DTS system, and for DTS servers to provide time to an NTP system. ΓòÉΓòÉΓòÉ 6.5. DCE Security Service ΓòÉΓòÉΓòÉ A distributed computing environment brings with it new security requirements beyond those found in a nondistributed system. In a nondistributed system, the operating system can be trusted to protect resources from unauthorized access. This is not the case in open distributed systems, however. Communications take place over an accessible network, where messages between machines can be observed or forged. A new security system is required to control access to resources in a distributed environment. In DCE, resource protection is provided by the DCE Security Service. ΓòÉΓòÉΓòÉ 6.5.1. What Is the DCE Security Service? ΓòÉΓòÉΓòÉ The DCE Security Service consists of several parts, including the Authentication Service, the Privilege Service, the Registry Service, the Access Control List Facility, and the Login Facility. o The Authentication Service The Authentication Service enables two processes on different machines to be certain of one another's identity, or to be authenticated. On a timesharing system, this is provided in part by the operating system kernel. Because a local host's operating system cannot necessarily be trusted in a distributed system, an authentication service is necessary in a distributed computing environment. o The Privilege Service Once a server has verified the identity of the user who is making a request, it still needs to determine whether the user should be authorized, or granted the requested access to a resource that the server controls. This function is provided by the DCE authorization service, called the Privilege Service. It forwards in a secure way the information that a server needs to know to determine what permissions it should grant to the user. Both the DCE Authentication Service and the DCE Privilege Service are used in conjunction with DCE RPC and the Login Facility. The typical application programmer does not interact with them directly, but instead uses Authenticated RPC. o The Registry Service The DCE Registry Service is a replicated service that manages the cell's Security database. The Security database contains entries for security entities, which are called principals. A principal can be a user or a server, for example. The database also contains information associated with each principal, for example, encryption keys, which are used in authentication, authorization, and encryption of messages. The Registry Service enables administrators to access and modify the database of DCE users. o The Access Control List Facility DCE Access Control Lists (ACLs) are lists of users who are authorized to access a given resource. For example, a user can put a colleague on an ACL for a certain file, thereby granting the colleague permission to read and write the file. DCE ACLs are associated with many DCE resources: files, entries in the Directory Service, and entries in the Security Service. DCE ACLs are based on the POSIX 1003.6/Draft 3 specification. An ACL API allows programmers to manipulate ACLs, and the acl_edit command allows users to modify ACLs associated with resources they own. o The Login Facility The DCE Login Facility initializes a user's DCE security environment. It authenticates the user to the Security Service by means of the user's password. The Security Service returns security credentials, which are then used to authenticate the user to distributed services that are accessed during the user's session, such as the Distributed File Service or other applications. ΓòÉΓòÉΓòÉ 6.5.2. How DCE Security Works ΓòÉΓòÉΓòÉ The DCE security services and facilities interact to provide a secure distributed computing environment. DCE Security Interactions shows this process. The presentation in this section is a simplified view of the transactions that actually take place. DCE Security Interactions When a DCE cell is first created, the DCE security administrator runs a program to create an initial DCE security database. The administrator then starts up a DCE Security Server, called secd, on the same machine as the database. Using the rgy_edit command, the administrator creates user accounts in the security database. After the administrator has created an account for a user, the user can participate in a secure DCE system. Typically, a user logs in at the beginning of a session. The Login Facility interacts with the Privilege Server to send a request for authentication credentials to the Authentication Server. The Authentication Server sends back the authentication credentials, called a Ticket. The reply is encrypted using the user's password, so if the user can supply the right password, the reply can be decrypted and the Ticket can be accessed. Tickets are used by clients to authenticate themselves to servers; that is, to prove that clients are really who they say they are. Next, the Login Facility sends the Ticket to the Privilege Server. It returns authorization credentials, called a Privilege Attribute Certificate (PAC). It contains authorization information specific to the user, such as the groups to which the user belongs. PACs are used to authorize users; that is, to help a server decide whether users should be granted access to resources that the server manages. When the Login Facility has finished running, the user has a security environment and can communicate in a secure way with application servers. For example, if the user runs an application client, the application client can use Authenticated RPC to communicate with the application server. The application server receives the RPC-based request, which includes the user's PAC. The server inspects the user's authorization credentials and compares them with the information in the Access Control List associated with the resource the user wants to access. If, for example, the ACL says that any user in the group friends can access the resource, and the user's PAC shows that the user is in the friends group, then the server will give the user access to the resource. The authentication and authorization information that is sent over the network is encrypted so that only the intended recipients can decrypt and read the messages. The application data can be encrypted as well to prevent any unauthorized user from reading the data that is sent over the network. The encryption used in DCE is secret key encryption, in which two parties share a secret: the encryption key. Using that key, they can encrypt and decrypt each other's messages. ΓòÉΓòÉΓòÉ 6.5.3. End User's Perspective ΓòÉΓòÉΓòÉ Much of the DCE Security mechanism occurs without the knowledge of users; for example, secure communications take place without the user's intervention. There are several ways, however, in which users do come in contact with DCE Security. One instance is users typing in their passwords to authenticate themselves to DCE, usually at login time. Another case is changing access to resources they own. Finally, a user notices the Security Service in action when he or she is denied unauthorized access to resources. ΓòÉΓòÉΓòÉ 6.5.4. Programming with DCE Security ΓòÉΓòÉΓòÉ Typically, a DCE programmer uses DCE RPC to implement a distributed application. Because DCE Security is integrated with RPC, in some cases the programmer does not need to access security services directly. Programming interfaces to the Security Service are available to the programmer who needs them. They include the ACL, Login, and Registry APIs, along with the API for Authenticated RPC. ΓòÉΓòÉΓòÉ 6.5.4.1. Authenticated RPC ΓòÉΓòÉΓòÉ DCE RPC and DCE Security cooperate to provide authentication, authorization, and secure communications. To use Authenticated RPC, the client must already have a security environment, such as that set up by the Login Facility. The server side of the application registers its name and the type of authentication service it supports. In DCE, two types of authentication service are supported-secret key authentication, which is based on Kerberos or no authentication. The client makes a call to indicate the authentication service, protection level, and authorization service it wants to use for RPC communications with a given server. The authentication service can be either secret key authentication or no authentication. The protection level ranges from authentication at the beginning of an RPC session, to authenticating each message or packet, to ensuring that a packet has not been modified in transit, to encrypting all user data. In general, the more secure the protection level, the higher the price paid in terms of performance, because the security mechanisms involve encrypting and decrypting data, which take up processor time. The authorization service chosen by the client can be either uncertified or certified. In uncertified authorization, the authorization information sent to a server consists only of the client's name. In certified authorization, the authorization information consists of the UUIDs of the client's name and groups. The certified authorization information is in a PAC. In both the certified and uncertified authorization service, the authorization information is sent securely. The server uses the authentication and authorization information about the client to determine whether it should be granted the access to the resource that it has requested. The server knows the identity of the client and the authorization groups the client belongs to. The server compares the client's credentials against information in the ACLs to determine whether a client should be given the access it is requesting. ΓòÉΓòÉΓòÉ 6.5.4.2. Access Control Lists ΓòÉΓòÉΓòÉ If a distributed application uses ACLs to control access to its resources, the distributed application programmer needs to write an ACL Manager to handle access to the resources. The ACL Manager is part of the server side of the application. Typically, one Access Control List is associated with each resource that the server manages. The ACL contains one or more entries specifying a user or group and the operations the user or group is permitted to perform on the resource (for example, read, write, or execute permission). The ACL Manager takes the authorization information supplied by the application client during an RPC, and compares it to the ACL for the requested resource. The ACL Manager indicates whether the client is or is not allowed the requested access to the resource. DCE ACL Example shows a simple DCE ACL. Every DCE ACL contains a field indicating its type. The ACL type in this case is sp_data_acl. Each DCE ACL also contains a field indicating what the default for the entries in the ACL. In the example, the default cell is /.../C=US/O=OSF/OU=DCE. The rest of the ACL consists of ACL entries. DCE ACL Example ACL entries can be of several types. The example shows three types of ACL entries: user, group, and foreign_user. The cell to which the user and group entries belongs is the default cell listed in the ACL. The cell to which the foreign_user entry belongs is specified in the entry. Each entry includes a list of permissions. The different possible permissions are determined by the ACL type (in this example, sp_data_acl). There are two types of permissions in the ACL example: r for read permission, and w for write permission. Based on this ACL, the sp_data_acl ACL Manager will give the principal snowpawsin the cell /.../C=US/O=OSF/OU=DCE read and write permission to the object, the members of the friends group in the /.../C=US/O=OSF/OU=DCE cell read permission to the object, and the principal ziggy in the foreign cell /.../cs.univ.edu read permission. ΓòÉΓòÉΓòÉ 6.5.5. DCE Security Service Administration ΓòÉΓòÉΓòÉ There are two types of DCE Security administration: local and cellwide. The administrator of a DCE machine controls the local passwd_override file. This file determines some security aspects that are specific to the local machine, such as which principals may use the machine and the password for a local account (such as root). The local security administrator also controls the local file that contains user and password information, if it exists. (This file may contain a copy of information from the security database to be used in case the security server cannot be reached or for already existing applications that expect such a local file.) The cell-wide security administrator manages the cell's Security Servers. This task includes managing the secd process, which provides security services on the security server machine, creating and editing the security database, and controlling replication of security data. The cell-wide security administrator is also involved in cross-cell authentication because clients in one cell read to communicate securely with servers in another cell. The security administrators in the two cells must register each other's Authentication Service in their Registry. Clients in one cell can then authenticate servers in another cell, and authorized clients in one cell can access services in a foreign cell. ΓòÉΓòÉΓòÉ 6.5.6. DCE Security and Kerberos ΓòÉΓòÉΓòÉ The DCE Authentication Service is based on MIT Project Athena's Kerberos Network Authentication Service, Version 5. The Kerberos Key Distribution Center (KDC) server is a part of the DCE Security server, secd. The Kerberos API is used internally by DCE Security, but is not exposed for use by the application programmer. Instead, DCE application programmers use the Authenticated RPC API. ΓòÉΓòÉΓòÉ 6.6. DCE Distributed File Service ΓòÉΓòÉΓòÉ Distributed systems can provide many advantages over centralized systems, such as higher availability of data and resources, the ability to share information throughout a very large (even worldwide) system, and efficient use of special computing functionality. A distributed file system is an example of an application that can take advantage of all of these aspects of a distributed system. It can make files highly available through replication, making it possible to access a copy of a file even if one of the machines on which the file is not available. A distributed file system can provide access to files from anywhere in the world, allowing cooperation among geographically dispersed users. The distributed file system can also give users on machines with little storage space the ability to access and store data on machines with much more disk space available. The DCE Distributed File Service (DFS) is a distributed client/server application, built on the underlying DCE services. It takes full advantage of both the lower-level DCE services (such as RPC, Security, and Directory) and the distributed computing system itself. ΓòÉΓòÉΓòÉ 6.6.1. What Is DFS? ΓòÉΓòÉΓòÉ DFS is a distributed application that manages information in the form of a file system. ΓòÉΓòÉΓòÉ 6.6.1.1. DFS Data Organization ΓòÉΓòÉΓòÉ DFS data is organized at three levels as shown in (see Files, Directories, Filesets, and Aggregates). Files, Directories, Filesets, and Aggregates The three levels of DFS data are, from smallest to largest: o Files and Directories The file is the unit of user data. Directories organize files (and other directories) into a hierarchical tree structure. o Filesets The fileset is the unit of administration. A fileset is a subtree of files and directories, no larger than a disk or partition (or logical volume if supported). The fileset is a convenient grouping of files for administrative purposes; for example, the subtree of files pertaining to a particular project can be grouped on the same fileset. o Aggregates The aggregate is the unit of disk storage, similar to a disk partition. It is also the unit of fileset exporting. It can contain one or more filesets. ΓòÉΓòÉΓòÉ 6.6.1.2. DFS Components ΓòÉΓòÉΓòÉ DFS is implemented by several components; this section briefly describes each of them. ΓòÉΓòÉΓòÉ 6.6.1.2.1. Cache Manager ΓòÉΓòÉΓòÉ The Cache Manager is the client side of DFS, which runs on any machine acting as a DFS client. It takes a user's file system request and looks in a cache to see if a copy of the data is already on the local system. If not, the Cache Manager sends a request to the File Server machine for the data and caches it locally. Because files are cached on the client, a local copy of the file can subsequently be accessed instead of the remote copy on the File Server machine. As a result, network traffic to the File Server machine, as well as File Server machine load, is much lighter than if the client has to go to the server each time it need to access the file. ΓòÉΓòÉΓòÉ 6.6.1.2.2. File Exporter ΓòÉΓòÉΓòÉ The File Exporter is the server side of DFS. It runs on a DFS File Server machine, where it handles requests from remote clients for the files that it manages. The File Exporter receives an RPC call and accesses its own local file system, which can be the DCE Local File System or another file system such as a UNIX File System (UFS), to service the request. Using the Token Manager, it handles the synchronization of different clients, which may be concurrently accessing the same file, and returns the requested information to the client. ΓòÉΓòÉΓòÉ 6.6.1.2.3. DCE Local File System ΓòÉΓòÉΓòÉ The DCE Local File System (DCE LFS) is the physical file system provided with DCE. It manages the storage of files on a disk. The scope of DCE LFS is a single computer, and LFS is analogous to a UNIX file system. However, LFS is more powerful than most UNIX local file systems. It includes more features than a distributed file service based on a traditional UNIX file system. They include the ability to use more flexible authorization in the form of DCE Access Control Lists (ACLs); the ability to replicate, back up, and even move different parts of the file system without interruption in service; and fast recovery after a crash, made possible through logging (in contrast to UNIX file systems, which must execute the time-consuming fsck command). DCE LFS includes support for DCE cells; for example, the owner of a file or name in an Access Control List can be a name in a foreign cell. A UNIX File System (UFS) can be used as the File Server machine's physical file system as an alternative to LFS. DFS can export UFS, issue synchronization tokens for files in UFS, and perform fileset operations such as dump and restore on UFS. There is only one fileset UFS partition, resulting in large filesets that are not convenient to move. Also, UFS filesets cannot be replicated. A File Server machine using LFS will have more function than a File Server machine using UFS, although UFS systems can be supported in DFS. ΓòÉΓòÉΓòÉ 6.6.1.2.4. Token Manager ΓòÉΓòÉΓòÉ The Token Manager runs on the File Server machine and synchronizes access to files by multiple clients. It issues tokens, to DFS clients carry various access rights, usually read or write. There are four different kinds of tokens: data tokens for access to file and directory data, status tokens for access to file and directory status, lock tokens for locking a portion of a file, and open tokens for opening a file. The Token Manager on the server side cooperates with the Token Management Layer in the Cache Manager (on the client side) to manage tokens. If a client requests an operation that conflicts with a token that another client holds, the conflicting token is revoked before the requested operation can proceed. ΓòÉΓòÉΓòÉ 6.6.1.2.5. Fileset Server ΓòÉΓòÉΓòÉ The Fileset Server allows administrators to create, delete, move, and perform other operations on filesets. For example, an administrator can use the Fileset Server to move a fileset from one File Server machine to another for load balancing. (If DCE LFS is not being used as the physical file system, then an entire partition is treated as a single fileset, and some fileset operations may not be supported.) ΓòÉΓòÉΓòÉ 6.6.1.2.6. Basic OverSeer Server ΓòÉΓòÉΓòÉ The Basic OverSeer Server, (BOS Server), monitors the DFS processes that run on a server and restarts them when needed. It maintains information about those processes and responds to administrative requests for that information. ΓòÉΓòÉΓòÉ 6.6.1.2.7. Replication Server ΓòÉΓòÉΓòÉ The Replication Server is an administrative server that replicates filesets. For example, an administrator can create a copy of a fileset on a second File Server machine. The Replication Server will update the replica at a specified interval (every 30 minutes, for example). Even if the file's master File Server machine is unavailable, a copy of the file is still available online through the secondary copy on the alternative File Server machine. ΓòÉΓòÉΓòÉ 6.6.1.2.8. Update Server ΓòÉΓòÉΓòÉ The Update Server distributes binary files or administration information to nodes in the DFS system. The Update Server consists of an upclient and an upserver. The upclient software runs on a machine that receives new versions of the binary files or administration information. The upserver program runs on a master machine and automatically propagates any changes to binaries or administration information to the machines running the upclient software. ΓòÉΓòÉΓòÉ 6.6.1.2.9. Scout ΓòÉΓòÉΓòÉ The Scout administrative tool collects and displays information about the File Exporters running on File Server machines, so a system administrator to monitor the DFS system. ΓòÉΓòÉΓòÉ 6.6.1.2.10. Backup Server ΓòÉΓòÉΓòÉ The Backup Server is a facility for backing up File Server data. It maintains backup records in the Backup Database. It schedules file system backups and makes incremental dumps. The unit for backup is the fileset. ΓòÉΓòÉΓòÉ 6.6.1.2.11. Fileset Location Server ΓòÉΓòÉΓòÉ The Fileset Location Server is a replicated directory service, which keeps track of the filesets and where they can be found on File Server machines. It provides lookup service analogous to the service CDS provides, except the Fileset Location Server is specialized for DFS. The location of the fileset is hidden; it can be accessed simply by its name. As a result, a fileset can be moved and its location updated in the Fileset Location Database without users and applications having to know about the move. Some DFS components run in the host machine's kernel. These are the Cache Manager and Token Management Layer on DFS client machines; the File Exporter, Token Manager, and DCE Local File System on File Server machines; and parts of the Fileset Location Server. ΓòÉΓòÉΓòÉ 6.6.1.3. Features of DCE DFS ΓòÉΓòÉΓòÉ The DCE Distributed File Service has the following features: o Uniform File Access DFS is based on a global namespace. A DFS file is accessed by the same name no matter where in the distributed system it is accessed from. Users do not need to know the network address or name of the File Server machines where a file is located to name and access the file. o Intracell Location Transparency Data can move from one location to another within a cell without affecting a user or programmer. An administrator can move a fileset from one File Server machine to another for load balancing, for example, without disturbing users. o Performance DFS is a high-performance file service. Fast response is achieved in part through the caching of file and directory data on the DFS client machine. This reduces the time it takes for a user to access a file, and it also reduces traffic on the network and the load on the File Server machine. The first time a user on a machine accesses a file, the Cache Manager gets a copy of the file from the File Server machine, and caches it on the client machine. Subsequent accesses to the file are then made to the copy on the client machine rather than to the File Server machine. o Availability DFS makes its service and data highly available in several ways. One way is through replication: a copy of a file can be stored on more than one File Server machine. If the file's main File Server machine is unavailable, a copy of the file may still be available (although possibly not up-to-date) on another File Server machine. This replication is especially useful for files that are accessed by many users and change infrequently (for example, binary files). Another way DFS achieves high availability is through caching. Copies of files are cached on DFS clients. If a client is temporarily disconnected from the network a user may be able to access a file since a copy may reside in the local cache. DFS administration can occur while users continue to access DFS files, another means of providing high availability. Both backups and relocation of DFS files can be done without making the files unavailable to users. The physical file system portion of DFS, called the DCE Local File System, is designed for fast recovery (yielding higher availability) after failures. This is possible because DCE LFS is a log-based file system; that is, LFS keeps a record of actions taken that affect the file system structure. In the case of a system crash, the record can be replayed to bring the file system to a consistent state. o Support for Distributed Application Programming DFS is itself a distributed application; but it in turn, supports the development of other distributed applications. Programmers can use DFS to share data or to communicate in a distributed application. DFS takes care of the network communications and movement, synchronization, and storage of shared data. o Ease of Administration and Scalability DFS files are grouped into units called filesets, which are convenient to administer. The processes that implement DFS, such as the File Exporter and backup processes, are monitored and maintained automatically by the BOS, resulting in less work for a DFS administrator and a more scalable system. Because of the high performance mentioned previously, DFS has a high client-to-server ratio. This leads to a scalable system: clients can be added with little effect on other clients and the rest of the system. Finally, DFS includes tools such as the Backup Server and Update Server, that automate time-consuming administrative tasks. o Integration DFS is fully integrated with other DCE components, including RPC, Security, Directory Service, and Threads. o Interoperation DFS interoperates with other file systems; for example, a UFS file system can be exported using DFS. o Standards DFS maintains POSIX single-site read/write semantics. The DCE Local File System is POSIX 1003.1 conformant. ΓòÉΓòÉΓòÉ 6.6.2. DFS Configuration ΓòÉΓòÉΓòÉ This section describes those DFS components that run on the different types of DFS machines: DFS client machines, DFS File Server machines, and other DFS server machines. The Cache Manager runs on every machine that acts as a DFS client. It communicates with File Server machines to provide DFS service (see DFS Client and File Server Machines). DFS Client and File Server Machines Several processes run on DFS File Server machines: the File Exporter (which includes a Token Manager), the BOS, the Replication Server, the Fileset Server, and the client side of the Update Server. Also present on the File Server machine is a physical file system, either DCE LFS or UFS. Finally, some processes must run on a machine that contains the database they access (usually the DFS File Server machine). See Other DFS Servers. Other DFS Servers These processes are the server side of the Update Server (which runs both on machines containing master copies of configuration files and machines containing master copies of binary files), the Fileset Location Server (which runs on the machine where the Fileset Location Database is located), and the Backup Server (co-located with the Backup Database). ΓòÉΓòÉΓòÉ 6.6.3. End User's Perspective ΓòÉΓòÉΓòÉ Users are usually not aware that some of the files that they access are stored on their local computer, some on their cell's File Server, and some in another cell. To a user, there is one large, worldwide file system. Users will notice a few differences between working on a distributed file system and working on a local file system. For example, DFS users are issued quotas for file storage and can run commands for information about these quotas. There are also commands for determining the location of a file, and other information that is specific to a distributed file system. ΓòÉΓòÉΓòÉ 6.6.4. Programming with DFS ΓòÉΓòÉΓòÉ Application programmers typically use DFS transparently by making POSIX 1003.1 file system calls. Additional DFS interfaces provide administrative capabilities, such as calls for administering filesets. The fact that programmers can use a distributed file system through a familiar interface means that DFS enables distributed applications programming without special programming expertise. Through the use of the Distributed File Service, programmers can write distributed applications without the use of RPC and the client/server model, if the DFS data sharing model is appropriate to the application. ΓòÉΓòÉΓòÉ 6.6.5. DFS Administration ΓòÉΓòÉΓòÉ Administration of DFS is a significant task, because several processes that implement DFS need to be set up and maintained. Administrative tools are provided to aid in this task. DFS configuration is varied and flexible. A DFS administrator has the additional task of designing and evolving a configuration of DFS servers and clients that best suits the needs of the system's users. DFS day-to-day administration includes fileset administration, such as making filesets available, backing them up, and moving them. ΓòÉΓòÉΓòÉ 6.7. DCE Diskless Support Service ΓòÉΓòÉΓòÉ The DCE Diskless Support Service enables nodes without disks to participate in a DCE environment. A diskless node has no disk on which to store a local file system. Diskless support means providing facilities over the network to replace the facilities that would usually be on the local disk. The four areas that must be supported are as follows: o Starting a kernel o Obtaining configuration information o Remote file system support o Remote swapping support. At start up, a traditional machine looks for a binary image of its operating system in a well-known file on its local disk (such as /vmunix on many UNIX machines). A diskless system, because it has no local disk on which to store its kernel, must be able to start by some other method. In DCE, a kernel is obtained over the network. Once a diskless client is started, it needs some information before it can be fully operational. Because it cannot read that information from the root file system (it does not have one yet), it has to get it from another source. The diskless node obtains this information from a Diskless Configuration (DLC) Server. One of the main functions of a local disk is the permanent storage of user and system files. A diskless system needs a place to store its files, because it cannot store them locally. Diskless machines can use a remote file server to store and retrieve their files. Another typical use of local disks on traditional machines is for swapping. When a process is blocked and the CPU needs more space in main memory to run the next process, the disk can be used to temporarily store the blocked process. When it is time for the blocked process to run again, it is brought back into main memory from the disk. A diskless node needs another way to swap processes in and out of its memory. It uses a remote swap server; that is, the disk on another machine on the network is used for the diskless machine's swap space. (Depending on the diskless machine's operating system, this facility may be used for paging as well as swapping.) For diskless machines using DFS, paging can be done to files instead of through the Swap Server. ΓòÉΓòÉΓòÉ 6.7.1. What Is DCE Diskless Support Service? ΓòÉΓòÉΓòÉ DCE diskless configurations involve four types of machines (see Diskless Client and Related Servers): o Diskless Client (BOOTP and TFTP clients) o Boot Server (bootpd and tftpd) o Configuration Server o Swap Server (optional) o DFS File Server. Some of these servers can be located together; for example, the Boot Server and Configuration Server can run on a Distributed File Server machine. (The Boot Server and Configuration Server must run on the same machine.) Diskless Client and Related Servers ΓòÉΓòÉΓòÉ 6.7.2. Booting Support for Diskless Operation ΓòÉΓòÉΓòÉ Booting support consists of code that resides in the Read-Only Memory (ROM) in the diskless client machine because that is the only place on a diskless node that is available for permanent storage. The code contains the client sides of the BOOTP and Trivial File Transfer Protocol (TFTP) protocols. Because DCE is limited to offering software, not hardware, the actual supplied code runs in user mode and demonstrates the ability to get a kernel over the network using these two protocols. During the boot process, the diskless client uses BOOTP to obtain its own network address and the address of its Boot Server. It then uses TFTP to obtain the kernel file to be booted. ΓòÉΓòÉΓòÉ 6.7.3. The Diskless Configuration Process ΓòÉΓòÉΓòÉ A diskless node needs configuration information before the root file system is available; it is obtained from the Diskless Configuration Server. This server supplies the diskless node with information about: o The Client's Swap Server (if needed) o The Client's root file system location and server o DFS Cache Manager configuration parameters. Using these configuration values, the diskless node starts the DFS Cache Manager and mounts the appropriate root file system from the DFS File Server machine. ΓòÉΓòÉΓòÉ 6.7.4. File Service Support for Diskless Operation ΓòÉΓòÉΓòÉ DCE Diskless Support Service provides the ability for a diskless machine to use a remote file service. This facility is based on the DCE Distributed File Service (see DCE Distributed File Service). It has several aspects: o Diskless Cache Manager o Machine-Specific Files o Device Files. When DFS is used on a machine with a local disk, the DFS Cache Manager (the client side of DFS) uses storage on the disk to keep a cache of recently accessed files. This greatly reduces network traffic to the File Server machine, and increases performance. On a diskless machine the Cache Manager uses an in-memory cache. Because DCE supports interoperation among heterogeneous systems, a File Server machine may have clients with different kinds of systems. A mechanism is needed to distinguish between, for example, binary files intended for one platform, and binaries for a second platform. When a diskless client needs to execute the binary file, it gets the right version for its system. DFS provides a mechanism for making this distinction in the file system. The machine-specific file mechanism consists of two special filenames: @host and @sys. The @host file name is replaced with the host name of the client. This special file name is used for files that are specific to the individual client machine, for example, an /etc/rc file or equivalent. The @sys file name is replaced with the client's system name. For example, the diskless server may have copies of executable files for various platforms. The file name is replaced with the specific client's platform, so the client can access the appropriate executables for its operating system/hardware configuration. Finally, some of the files in a DCE file system are actually devices (that is, /dev files). They are interpreted as devices on the client machine, but not on the server machine. ΓòÉΓòÉΓòÉ 6.7.5. Swapping Support for Diskless Operation ΓòÉΓòÉΓòÉ DCE provides diskless swapping support for systems that swap or page to devices; systems that page to files do not need this support. The diskless swapping support has the following components: o Swap Server On the Swap Server machine, the diskless swap server daemon, runs in user mode. It maintains a database of information about its clients, swap files, and swap devices, and accepts administrative requests to modify that information. It also accepts requests from users to access swap space, which it keeps on disk. o Client Swap Driver On the diskless node, the Swap Client runs in kernel mode. It looks like a device driver to the diskless node's operating system. It takes swap requests from the client's kernel and forwards them across the network to the Swap Server. o Swap Administration Program The diskless swap administration program, allows an administrator to control the Swap Server remotely. It makes requests to the Swap Server to modify the Swap Server's database. Requests modify client information and information about files and devices to be used for swapping. Swap Process From Application To Server shows the interaction among an application on the diskless machine, its operating system and swap driver, and the Swap Server and swap store on the Swap Server machine. Swap Process From Application To Server ΓòÉΓòÉΓòÉ 6.8. Two DCE Application Examples ΓòÉΓòÉΓòÉ This section presents two implementations of a very simple distributed application, called greet. You should have some familiarity with UNIX systems and the C programming language. The greet application is implemented in two different ways: one using DCE RPC, the other using DCE DFS. ΓòÉΓòÉΓòÉ 6.8.1. The greet Application: An Implementation Using DCE RPC ΓòÉΓòÉΓòÉ This first implementation of the greet application is an example of a simple DCE RPC-based application. The client side of the application sends a greeting to the server side of the application. The server prints the client's greeting and sends a return greeting back to the client. The client prints the server's reply and terminates. ΓòÉΓòÉΓòÉ 6.8.1.1. Steps in Developing a DCE RPC Application ΓòÉΓòÉΓòÉ This section provides a step-by-step description of the development of the greet application. 1. Generate an IDL template. The first step is to run the uuidgen program, which creates a Unique Universal Identifier for uniquely labelling the application's interface. It also creates a template for an IDL file. The following command: uuidgen -i > greet.idl creates the file greet.idl. It contains the following: [ uuid(3d6ead56-06e3-11ca-8dd1-826901beabcd), version(1.0) ] interface INTERFACENAME { } 2. Name the interface. Replace the string INTERFACENAME in the IDL file with the name of the application interface, in this case, greetif. [ uuid(3d6ead56-06e3-11ca-8dd1-826901beabcd), version(1.0) ] interface greetif { } 3. Define the interface operations. Within the braces, write definitions of the operations comprising the interface. In this example, there is only one operation, called greet. /* * greet.idl * * The "greet" interface. */ [uuid(3d6ead56-06e3-11ca-8dd1-826901beabcd), version(1.0)] interface greetif { const long int REPLY_SIZE = 100; void greet( [in] handle_t h, [in, string] char client_greeting[], [out, string] char server_reply[REPLY_SIZE] ); } The first line of the operation definition gives the name of the operation, greet, and indicates by the void declaration that it has no meaningful return value. The next three lines specify the arguments to the operation, namely h, client_greeting, and server_reply. The first argument is a handle containing binding information for the server. The second is a string that is passed from the client to the server (the client's greeting). The third argument is a string returned from the server back to the client (the server's reply). 4. Run the IDL compiler. The following command runs the IDL compiler: idl greet.idl (Some of the commands in this section are somewhat simplified. See Makefile for greet Application for the complete command.) Three new files are created automatically as a result of this command: o greet.h o greet_cstub.o o greet_sstub.o 5. Write the client application code greet_client.c. In general, the DCE RPC application programmer writes three application code files: o The Client code o The Server initialization code o The Server operation code. The following is the client code for the greet application, a file called greet_client.c. /* * greet_client.c * * Client of "greet" interface. */ #include <stdio.h> #include <dce/nbase.h> #include <dce/rpc.h> #include "greet.h" #include "util.h" int main( int argc, char *argv[] ) { rpc_ns_handle_t import_context; handle_t binding_h; error_status_t status; idl_char reply[REPLY_SIZE]; if (argc < 2) { fprintf(stderr, "usage: greet_client <CDS pathname>\n"); exit(1); } /* * Start importing servers using the name specified * on the command line. */ rpc_ns_binding_import_begin( rpc_c_ns_syntax_default, (unsigned_char_p_t) argv[1], greetif_v1_0_c_ifspec, NULL, &import_context, &status); ERROR_CHECK(status, "Can't begin import"); /* * Import the first server (we could interate here, * but we'll just take the first one). */ rpc_ns_binding_import_next(import_context, &binding_h, &status); ERROR_CHECK(status, "Can't import"); /* * Make the remote call. */ greet(binding_h, (idl_char *) "hello, server", reply); printf("The Greet Server said: %s\n", reply); } In this routine, the client makes two calls to the RPC runtime to acquire binding information needed to communicate with the server. The client then calls the greet remote procedure, supplying a greeting to be sent to the server. The client prints the reply received by the server. 6. Write the server initialization code greet_server.c. The second file that the DCE RPC application programmer must write is the server initialization code. This is boilerplate code; that is, it is largely the same for any RPC application. The greet_server.c file contains the server initialization code for the greet application. /* * greet_server.c * * Main program (initialization) for "greet" server. */ #include <stdio.h> #include <dce/dce_error.h> #include <dce/rpc.h> #include "greet.h" #include "util.h" int main( int argc, char *argv[] ) { unsigned32 status; rpc_binding_vector_t *binding_vector; if (argc < 2) { fprintf(stderr, "usage: greet_server <CDS pathname>\n"); exit(1); } /* * Register interface with RPC runtime. */ rpc_server_register_if(greetif_v1_0_s_ifspec, NULL, NULL, &status); ERROR_CHECK(status, "Can't register interface"); /* * Use all protocol sequences that are available. */ rpc_server_use_all_protseqs(rpc_c_protseq_max_reqs_default, &status); ERROR_CHECK(status, "Can't use protocol sequences"); /* * Get the binding handles generated by the runtime. */ rpc_server_inq_bindings(&binding_vector, &status); ERROR_CHECK(status, "Can't get bindings for server"); /* * Register assigned endpoints with endpoint mapper (RPCD). */ rpc_ep_register( greetif_v1_0_s_ifspec, binding_vector, NULL, (unsigned_char_p_t) "greet server version 1.0", &status); ERROR_CHECK(status, "Can't register with endpoint map"); /* * Export ourselves into the CDS namespace. */ rpc_ns_binding_export( rpc_c_ns_syntax_default, (unsigned_char_p_t) argv[1], greetif_v1_0_s_ifspec, binding_vector, NULL, &status); ERROR_CHECK(status, "Can't export into CDS namespace"); /* * Start listening for calls. */ printf("Listening...\n"); rpc_server_listen(rpc_c_listen_max_calls_default, &status); ERROR_CHECK(status, "Can't start listening for calls"); /* * Unregister from endpoint mapper. */ rpc_ep_unregister( greetif_v1_0_s_ifspec, binding_vector, NULL, &status); ERROR_CHECK(status, "Can't unregister from endpoint map"); } In this file, the server registers its interface with the RPC runtime. It then retrieves the binding information assigned to it by the runtime. It registers its binding information with the RPC endpoint mapper, and then with the Cell Directory Service. It then is ready to service requests. Before exiting, the server unregisters its information in the endpoint map. 7. Write the server operation code greet_manager.c. The third file that an RPC programmer writes is the code that implements the operations defined in the IDL file. In this case, there is only one operation, greet. The greet_manager.c file implements this operation. /* * greet_manager.c * * Implementation of "greet" interface. */ #include <stdio.h> #include "greet.h" void greet( handle_t h, idl_char *client_greeting, idl_char *server_reply ) { printf("The client says: %s\n", client_greeting); strcpy(server_reply, "Hi, client!"); } The server prints the message it received from the client, then puts its own message in the reply parameter to be sent back to the client. 8. Write any utility code. In addition to the three standard RPC application code files, greet_client.c, greet_server.c, and greet_manager.c, the greet application contains a utility file for handling errors. This file is called util.c. /* * util.c * * Utility routine(s) shared by "greet" client and server programs. */ #include <stdio.h> #include <dce/nbase.h> #include <dce/dce_error.h> void error_exit( error_status_t status, char *text ) { unsigned char error_text[100]; int dummy; dce_error_inq_text(status, error_text, &dummy); fprintf(stderr, "Error: %s - %s\n", text, error_text); exit(1); } The util.c file comes with a header file called util.h. /* * util.h * * Declarations of utility routine(s) shared by "greet" client * and server programs. */ #define ERROR_CHECK(status, text) \ if (status != error_status_ok) error_exit(status, text) void error_exit( error_status_t status, char *text ); 9. Compile the client and server programs. The greet_client and greet_server programs can now be compiled. The client side of the application is compiled using the following command (again, somewhat simplified): cc -o greet_client greet_client.c greet_cstub.o util.o -ldce The server side of the application is compiled as follows: cc -o greet_server greet_server.c greet_manager.c greet_sstub.o util.o -ldce ΓòÉΓòÉΓòÉ 6.8.1.2. Installing and Running the greet Application ΓòÉΓòÉΓòÉ This section describes the process for an administrator who is installing and starting up the greet application, and a user who is running it. o Installing the Client and Server Programs An administrator installs the greet_client program on machines on which users will run the greet application. The administrator also installs the greet_server program on one or more machines that will execute the server part of the greet application. o Starting the Greet Server To start up the Greet Server, the administrator enters the following command on a machine that has the Greet Server installed: greet_server /.../my_cell/subsys/my_company/greet_server o Running the greet Application To run the greet application, a user types the following command on any Greet Client machine: greet_client /.../my_cell/subsys/my_company/greet_server The Greet Server will print the message it received from the Greet Client. Then the Greet Client prints the reply that the Greet Server sent back to it. ΓòÉΓòÉΓòÉ 6.8.1.3. Makefile for greet Application ΓòÉΓòÉΓòÉ The commands given in the preceding description for building the greet application have been simplified. Following is the actual Makefile, containing the complete commands for generating the application. DCEROOT = /opt/dcelocal CC = /bin/cc IDL = idl LIBDIRS = -L${DCEROOT}/usr/lib LIBS = -ldce LIBALL = ${LIBDIRS} ${LIBS} INCDIRS = -I. -I${DCEROOT}/usr/include CFLAGS = -g ${INCDIRS} IDLFLAGS = -v ${INCDIRS} -cc_cmd "${CC} ${CFLAGS} -c" all: greet_client greet_server greet.h greet_cstub.o greet_sstub.o: greet.idl ${IDL} ${IDLFLAGS} greet.idl greet_client: greet.h greet_client.o util.o greet_cstub.o ${CC} -o greet_client greet_client.o greet_cstub.o \ util.o ${LIBALL} greet_server: greet.h greet_server.o greet_manager.o util.o \ greet_sstub.o ${CC} -o greet_server greet_server.o greet_manager.o \ greet_sstub.o util.o ${LIBALL} greet_client.c greet_server.c util.c: util.h greet_manager.c greet_client.c greet_server.c: greet.h ΓòÉΓòÉΓòÉ 6.8.2. The greet Application: An Implementation Using DCE DFS ΓòÉΓòÉΓòÉ This section describes an implementation of the greet application using the DCE Distributed File Service. In this version, the client and server use well-known files in the DCE filespace to communicate with each other. This application looks just like an application using a local file system, except for the names of the files in the DCE filespace. The communication (using RPC) is done by DFS, and is not visible to the programmer. (Please note that this example is intended to be simple, not necessarily to model good programming. For example, a real application would check return values for errors, and would be likely to use the lock system call to synchronize client and server access to files, rather than waking up every few seconds to check if a file had been created.) The application contains three files: dfs_greet.h, dfs_greet_client.c, and dfs_greet_server.c. 1. The dfs_greet.h File This file gives the well-known filenames that the client and server communicate through. /* * DCE Program Example Using DFS * * dfs_greet.h */ #define C_GREET_FILE "/...my_cell/fs/opt/my_company/greet/client" #define S_GREET_FILE "/...my_cell/fs/opt/my_company/greet/server" 2. The dfs_greet_client.c File This is the client side of the application. /* * DCE Program Example Using DFS * dfs_greet_client.c * * The client writes a message for the server into * a well-known file. It waits until the server has * created its own well-known file, then reads the * server's message from the file, prints it, and * deletes the file. */ #include <stdio.h> #include "dfs_greet.h" #define C_GREET_TEXT "Hi, server!" main() { FILE *f; size_t ret; char s[BUFSIZ]; f = fopen(C_GREET_FILE, "w"); ret = fwrite(C_GREET_TEXT, sizeof(C_GREET_TEXT), 1, f); fclose(f); while ((f = fopen(S_GREET_FILE, "r")) == NULL) sleep(3); ret = fread(s, sizeof(char), BUFSIZ, f); fclose(f); printf("Server says: %s", s); unlink(S_GREET_FILE); } 3. The dfs_greet_server.c File This file contains the server side of the greet application. /* * DCE Example Program Using DFS * dfs_greet_server.c * * The server waits until the client has created a * well-known file, then reads the client's message * from the file, prints the message, and removed the * file. The server then writes a message for the * client into another well-known file. */ #include <stdio.h> #include "dfs_greet.h" #define S_GREET_TEXT "Hi, client!" main() { FILE *f; size_t ret; char s[BUFSIZ]; while ((f = fopen(C_GREET_FILE, "r")) == NULL) sleep(3); ret = fread(s, sizeof(char), BUFSIZ, f); fclose(f); printf("Client says: %s", s); unlink(C_GREET_FILE); f = fopen(S_GREET_FILE, "w"); ret = fwrite(S_GREET_TEXT, sizeof(S_GREET_TEXT), 1, f); fclose(f); } The Makefile for creating the client and server programs is as follows: # Makefile for DCE Program Example Using DFS all: dfs_greet_client dfs_greet_server dfs_greet_client: dfs_greet.h dfs_greet_client.c cc -o dfs_greet_client dfs_greet_client.c dfs_greet_server: dfs_greet.h dfs_greet_server.c cc -o dfs_greet_server dfs_greet_server.c The Greet Client and Server are installed as in the RPC application. They are run in the same way, except they do not take a <servername> argument. ΓòÉΓòÉΓòÉ 7. Integration of DCE Technology Components ΓòÉΓòÉΓòÉ One of the advantages of the OSF Distributed Computing Environment is the integration of its component technologies with one another. Wherever appropriate, DCE technologies make use of other DCE technologies to accomplish their tasks. For example, the Cell Directory Service uses many of the other DCE components, such as Threads, RPC, DTS, and Security, in providing its service. Because the DCE technologies are well integrated, they also depend on one another for correct functioning. For example, CDS needs a running DCE Security Server to provide its directory service in a secure manner. These dependencies among technology components have implications for DCE activities such as porting, planning, and bringing up a DCE cell. This chapter describes how DCE components are integrated and the implications of their resulting interdependencies. ΓòÉΓòÉΓòÉ 7.1. Integration Matrix ΓòÉΓòÉΓòÉ DCE Component Integration shows which DCE components are used by each of the other DCE components. The components listed in the leftmost column are the technology consumers. The components listed in the top row are the technology providers. For example, in the box (row RPC, column Threads), the X indicates that RPC makes use of the Threads technology. The abbreviation NA (for Not Applicable) in a box shows the intersection of a technology with itself. A blank box indicates that the consuming technology does not use the providing technology. The following sections include discussions of technology integration, including reasons why certain technologies do not use other technologies. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé DCE Component Integration Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé THREADS Γöé RPC Γöé CDS Γöé DTS Γöé SECURITY Γöé GDS Γöé DFS Γöé DISKLESS Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé THREADS Γöé NA Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RPC Γöé X Γöé NA Γöé X Γöé Γöé X Γöé Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé CDS Γöé X Γöé X Γöé NA Γöé X Γöé X Γöé X Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé DTS Γöé X Γöé X Γöé X Γöé NA Γöé X Γöé Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé SECURITY Γöé X Γöé X Γöé X Γöé X Γöé NA Γöé Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé GDS Γöé Γöé Γöé Γöé Γöé Γöé NA Γöé Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé DFS Γöé X Γöé X Γöé X Γöé X Γöé X Γöé Γöé NA Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé DISKLESS Γöé X Γöé X Γöé X Γöé Γöé Γöé Γöé X Γöé NA Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The DCE components support distributed applications, and in accomplishing that task, they also use each other's services, as shown in the matrix. The use of a given DCE component by another DCE component can provide an example for the application programmer. Note that many of the boxes are filled in, especially those representing the five most basic components (Threads, RPC, CDS, DTS, and Security). As a result, some pairs of components have mutual dependencies, for example, the Security and CDS components. The Security Service uses information from the Cell Directory Service, while CDS uses the Security Service to control access to its information. The implications of these mutual dependencies are discussed in Implications of Mutual Dependencies. ΓòÉΓòÉΓòÉ 7.2. Integration by Technology Component ΓòÉΓòÉΓòÉ This section takes each of the DCE technology components in turn and describes its use of other technology components. o DCE Threads Integration The DCE Threads component does not involve distribution across nodes and therefore does not use any other DCE component. o DCE RPC Integration RPC uses Threads, CDS, and the Security Service. Threads are used to allow clients and servers to deal with multiple simultaneous RPCs. As a result of the use of threads by RPC, any component that uses DCE RPC also uses threads. RPC uses CDS to look up servers that support a given interface or object to discover the locations of those servers and the protocols that they use. GDS can be used indirectly by RPC. If an RPC server is located in a foreign cell that is registered in the X.500 namespace, GDS is accessed via CDS to find the given RPC server. RPC uses a notion of time, for example, how long to wait for a reply to a message. This involves only the time on the local node, such as comparing the time when a message was sent with the current time to see if a time-out has expired. As a result, RPC does not use DTS timestamps directly. RPC does, however, depend on DTS to help ensure that clocks on different machines run at approximately the same rate. The DCE Security Service is used to authenticate the RPC client and server to one another, and to pass authorization information about the client for the server to check against its ACLs. o DCE CDS Integration CDS makes use of several DCE technology components. It uses DCE Threads to allow the CDS server and the CDS clerk to handle multiple requests concurrently. It uses RPC in communications between CDS clerks and CDS servers, as well as in communications between CDS servers, such as for keeping replicated information consistent. CDS relies on DTS to maintain synchronized clocks in the network for use in the sequencing of updates to the namespace and for use in replication. CDS uses GDS (via the GDA) to find foreign cells registered in GDS. And finally, CDS uses DCE Security's Access Control Lists and authenticated RPC to ensure authorized access to directory data and administrative functions. o DCE DTS Integration DTS uses RPC in the communications between DTS clients and DTS servers. It also uses RPC in the protocol between a Time Server and a Time Provider. Because DTS is based on DCE RPC, which uses DCE Threads, DTS also uses Threads. DTS depends on CDS to find Time Servers and their locations. GDS may be used indirectly if a Global Time Server is registered in a foreign cell that is registered in the X.500 namespace. DTS uses the DCE Security Service to authenticate its interactions. o DCE Security Service Integration The DCE Security Server, like all DCE RPC-based applications, uses DCE Threads. The Security Server communicates with its clients using DCE RPC. CDS is used to find Security Servers. GDS may be used indirectly in accessing a Security Server that is in a foreign cell registered in the X.500 namespace. The Security Service uses a notion of time for the expiration of credentials and for detecting replays of authentication information. It assumes reasonable synchronization of the clocks in the network, which is accomplished in DCE by the Distributed Time Service. The Security Service does not use DTS timestamps in this version of DCE. o DCE GDS Integration The GDS server does not use DCE Threads; instead, it uses multiple processes to handle multiple requests. Because GDS is based on the X.500 standard, which is specified to run over ISO protocols, GDS does not use DCE RPC. GDS does not use CDS. Because GDS is at a higher level in the global namespace hierarchy, CDS refers to GDS but GDS does not refer to CDS. GDS has a separate security mechanism and ACLs from the DCE Security Service. Again, this is in order for GDS to comply with the international directory service standard. o DCE DFS Integration The DFS servers that run in user space (for example, the Backup, Fileset Location, and Fileset Servers) all use DCE Threads to handle multiple requests. Because the DFS File Exporter and Cache Manager run in the kernel, they do not use DCE Threads. DCE Threads is a user-space, not kernel, threads implementation. DFS uses DCE RPC for all remote interaction between the DFS clients (for example, the Cache Manager and Scout) and servers (for example, the File Exporter, Fileset Location Server, and Backup Server). Because the Cache Manager and File Exporter run in the kernel, they use a kernel version of RPC. DFS uses CDS to locate Fileset Location Servers. DFS may use GDS indirectly (via CDS) to locate Fileset Location Servers in foreign cells registered in the X.500 namespace. DFS uses authenticated RPC and DCE ACLs to protect its resources. DFS relies on DTS to maintain clock synchronization in the network. o DCE Diskless Support Service Integration The Swap Server component of the Diskless Support Service uses DCE Threads for concurrency. The Diskless Support Service uses RPC for its interactions with CDS and between the Swap Client and Server. The Diskless Cache Manager also uses RPC to communicate with the DFS File Exporter. It does not use RPC for startup, however, because it requires very small, simple network services. Diskless Support uses CDS to find its configuration information. Diskless Support Service includes instructions on how to modify the diskless node's kernel to use the DFS Cache Manager (DFS client) to mount the client's root file system. For diskless operation to be secure, it would require hardware support, which is outside the scope of DCE. ΓòÉΓòÉΓòÉ 7.3. Implications of Mutual Dependencies ΓòÉΓòÉΓòÉ Mutual dependencies among DCE technology components result in restrictions in areas such as the startup of a cell. For example, because the Security Service depends on CDS to find the location of a Security Server, and CDS depends on the Security Service to verify the authenticity of a CDS server, how can a DCE system ever get started? This section identifies the implications of mutual dependencies in the areas of DCE system startup, porting and testing of DCE, and planning for DCE configuration. o Implications for Startup Mutual dependencies in DCE technologies dictate the order in which some steps must be taken in bringing up a DCE client machine, a DCE server machine, and a DCE cell. In particular, a DCE cell's servers must be started up in a particular order. The Security Server is started first, because its dependency on CDS can be circumvented through the use of a local file to find Security Servers. Then the CDS Server is started. o Implications for Porting and Testing The interdependencies among DCE technologies constrain the order in which technologies can be ported. DCE Threads can be ported first, because other technologies use it, and it has no dependencies. Many of the other technologies have mutual dependencies, however. A porting effort can proceed by first porting the libraries of all the components, and then going on to port and test the servers. GDS can be ported independently, because it has no dependencies on other DCE components. o Implications for Configuration DCE technology interdependencies also have implications for configuration. The servers that other servers depend on are the servers that are the highest priority for replication, in environments where high availability is important. CDS and Security Servers should be replicated, because other DCE servers depend on them in order to operate. Among the various DFS servers, the Fileset Location Server is the highest priority for replication. o Implications for Application Programmers Because DCE RPC is integrated with DCE Threads, programmers writing RPC-based applications need to be aware of the implications of using multiple threads of control. ΓòÉΓòÉΓòÉ 8. List of Abbreviations ΓòÉΓòÉΓòÉ ACF Attribute Configuration File ACL Access Control List ACSE Association Control Service Element AES Application Environment Specification API Application Program Interface ASN.1 Abstract Syntax Notation-1 AVA Attribute Value Assertion BER Basic Encoding Rules BOS Basic Overseer Server C Country C-ISAM C-language Indexed Sequential Access Method CCITT International Telegraph & Telephone Consultative Committee CDS Cell Directory Service CDSPI Cell Directory Service Portable Interface CPU Central Processing Unit DAP Directory Access Protocol DB Database DCE Distributed Computing Environment DFS Distributed File Service DIB Directory Information Base DIT Directory Information Tree DLC Diskless Configuration Service DN Distinguished Name DNS Domain Name Service DSA Directory System Agent DSP Directory System Protocol DTS Distributed Time Service DUA Directory User Agent FIFO First In, First Out GDA Global Directory Agent GDS Global Directory Service IDL Interface Definition Language IP Internet Protocol ISO International Organization for Standardization LAN Local Area Network LFS Local File System LRU Least Recently Used MS-DOS Microsoft Disk Operating System NA Not Applicable NetBIOS Network Version of Basic Input/Output System NSI Name Service Independent NTP Network Time Protocol O Organization OS Operating System OS/2 Operating System/2 OSF Open Software Foundation OSI Open Systems Interconnection OSS OSI Session Service OU Organizational Unit RDN Relative Distinguished Name ROM Read-Only Memory ROS Remote Operation Service ROSE Remote Operation Service Elements RPC Remote Procedure Call RR Resource Record (DNS) RR Round Robin (scheduling) TCP/IP Transmission Control Protocol/Internet Protocol TDF Time Differential Factor TFTP Trivial File Transfer Protocol TLI Transport Layer Interface TPI Time Provider Interface UDP/IP User Datagram Protocol/Internet Protocol UFS UNIX File System UTC Coordinated Universal Time UUID Universal Unique Identifier VFS Virtual File System WAN Wide Area Network XOM X/Open Object Management XDS X/Open Directory Service XTI X/Open Transport Interface ΓòÉΓòÉΓòÉ 9. Glossary of Terms and Abbreviations ΓòÉΓòÉΓòÉ This glossary defines all DCE terms and abbreviations used in this book. If you do not find the term you are looking for, refer to the Index or to the Dictionary of Computing, SC20-1699. ΓòÉΓòÉΓòÉ 9.1. References ΓòÉΓòÉΓòÉ The following cross references are used in this glossary: ΓòÉΓòÉΓòÉ 9.1.1. Contrast with ΓòÉΓòÉΓòÉ This refers to a term that has an opposed or substantively different meaning. ΓòÉΓòÉΓòÉ 9.1.2. Synonym for ΓòÉΓòÉΓòÉ This indicates that the term has the same meaning as a preferred term, which is defined in its proper place in the dictionary. ΓòÉΓòÉΓòÉ 9.1.3. Synonymous with ΓòÉΓòÉΓòÉ This is a backward reference from a defined term to all other terms that have the same meaning. ΓòÉΓòÉΓòÉ 9.1.4. See ΓòÉΓòÉΓòÉ This refers the reader to multiple-word terms that have the same last word. ΓòÉΓòÉΓòÉ 9.1.5. See also ΓòÉΓòÉΓòÉ This refers the reader to related terms that have a related, but not synonymous, meaning. ΓòÉΓòÉΓòÉ 9.2. Prefixes ΓòÉΓòÉΓòÉ The following prefixes are provided in this glossary as references to the related DCE services: CDS Cell Directory Service DTS Distributed Time Service GDS Global Directory Service RPC Remote Procedure Call Security Security Service Threads Threads Service XDS X/Open Directory Service XOM X/Open Object Management ΓòÉΓòÉΓòÉ 9.3. A ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.3.1. abstract syntax notation one (ASN.1) ΓòÉΓòÉΓòÉ abstract syntax notation one (ASN.1) See ASN.1. ΓòÉΓòÉΓòÉ 9.3.2. access control list (ACL) ΓòÉΓòÉΓòÉ access control list (ACL) 1. Security: Data that controls access to a protected object. An access control list specifies the privilege attributes needed to access the object and the permissions that may be granted, with respect to the protected object, to principals that possess such privilege attributes. 2. GDS: Specifies the users with their access rights to an object. ΓòÉΓòÉΓòÉ 9.3.3. access control list facility ΓòÉΓòÉΓòÉ access control list facility A Security Service feature that checks a principal's access to an object. This facility determines access rights by comparing the principal's privileges to entries in an access control list (ACL) of an object. ΓòÉΓòÉΓòÉ 9.3.4. access right ΓòÉΓòÉΓòÉ access right Synonym for permission. ΓòÉΓòÉΓòÉ 9.3.5. accessible ΓòÉΓòÉΓòÉ accessible Pertaining to an object whose client possesses a valid designator or handle. ΓòÉΓòÉΓòÉ 9.3.6. account ΓòÉΓòÉΓòÉ account Data in the Registry database that allows a principal to log in. It is a registry object that relates to a principal. ΓòÉΓòÉΓòÉ 9.3.7. ACL ΓòÉΓòÉΓòÉ ACL See access control list. ΓòÉΓòÉΓòÉ 9.3.8. address ΓòÉΓòÉΓòÉ address An unambiguous name, label, or number that identifies the location of a particular entity or service. See presentation address. ΓòÉΓòÉΓòÉ 9.3.9. address family ΓòÉΓòÉΓòÉ address family A set of related communications protocols that use a common addressing mechanism to identify end points; for example, the U.S. Department of Defense Internet Protocols. Synonymous with protocol family. ΓòÉΓòÉΓòÉ 9.3.10. API ΓòÉΓòÉΓòÉ API See application program interface. ΓòÉΓòÉΓòÉ 9.3.11. application program interface (API) ΓòÉΓòÉΓòÉ application program interface (API) A functional interface supplied by the operating system or by a separately orderable licensed program that allows an application program written in a high-level language to use specific data or functions of the operating system or the licensed program. ΓòÉΓòÉΓòÉ 9.3.12. architecture ΓòÉΓòÉΓòÉ architecture 1. The organizational structure of a computer system, including the interrelationships among its hardware and software. 2. The logical structure and operating principles of a computer network. The operating principles of a network include those of services, functions, and protocols. ΓòÉΓòÉΓòÉ 9.3.13. ASN.1 ΓòÉΓòÉΓòÉ ASN.1 Abstract syntax notation one. A data representation scheme that enables complicated types to be defined and enables values of these types to be specified. ΓòÉΓòÉΓòÉ 9.3.14. attribute ΓòÉΓòÉΓòÉ attribute 1. RPC: An interface definition language (IDL) or attribute configuration file (ACF) that conveys information about an interface, type, field, parameter, or operation. 2. DTS: A qualifier used with DTS commands. DTS has four attribute categories: characteristics, counters, identifiers, and status. 3. XDS: Information of a particular type concerning an object and appearing in an entry that describes the object in the directory information base (DIB). It denotes the attribute's type and a sequence of one or more attribute values, each accompanied by an integer denoting the value's syntax. ΓòÉΓòÉΓòÉ 9.3.15. attribute configuration file (ACF) ΓòÉΓòÉΓòÉ attribute configuration file (ACF) RPC: An optional companion to an interface definition file that modifies how the Interface Definition Language (IDL) compiler locally interprets the interface definition. See also interface definition and Interface Definition Language. ΓòÉΓòÉΓòÉ 9.3.16. attribute syntax ΓòÉΓòÉΓòÉ attribute syntax GDS: A definition of the set of values that an attribute may assume. It includes the data type, in ASN.1, and usually one or more matching rules by which values may be compared. ΓòÉΓòÉΓòÉ 9.3.17. attribute type ΓòÉΓòÉΓòÉ attribute type 1. XDS: The component of an attribute that indicates the type of information given by that attribute. Because it is an object identifier, it is unique among other attribute types. 2. XOM: Any of various categories into which the client dynamically groups values on the basis of their semantics. It is an integer unique only within the package. ΓòÉΓòÉΓòÉ 9.3.18. attribute value ΓòÉΓòÉΓòÉ attribute value XDS, XOM: A particular instance of the type of information indicated by an attribute type. ΓòÉΓòÉΓòÉ 9.3.19. attribute value assertion (AVA) ΓòÉΓòÉΓòÉ attribute value assertion (AVA) GDS: An attribute type and attribute value pair. A relative distinguished name is comprised of one or more AVAs. ΓòÉΓòÉΓòÉ 9.3.20. authentication ΓòÉΓòÉΓòÉ authentication In computer security, a method used to verify the identity of a principal. ΓòÉΓòÉΓòÉ 9.3.21. authentication level ΓòÉΓòÉΓòÉ authentication level Synonym for protection level. ΓòÉΓòÉΓòÉ 9.3.22. Authentication Service ΓòÉΓòÉΓòÉ Authentication Service One of three services provided by the Security Service: it verifies principals according to a specified authentication protocol. The other Security services are the Privilege Service and the Registry Service. ΓòÉΓòÉΓòÉ 9.3.23. authorization ΓòÉΓòÉΓòÉ authorization 1. The determination of a principal's permissions with respect to a protected object. 2. The approval of a permission sought by a principal with respect to a protected object. ΓòÉΓòÉΓòÉ 9.3.24. authorization service ΓòÉΓòÉΓòÉ authorization service RPC: An implementation of an authorization protocol. ΓòÉΓòÉΓòÉ 9.4. B ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.4.1. Basic Encoding Rules (BER) ΓòÉΓòÉΓòÉ Basic Encoding Rules (BER) A set of rules used to encode ASN.1 values as strings of octets. ΓòÉΓòÉΓòÉ 9.4.2. BER ΓòÉΓòÉΓòÉ BER See Basic Encoding Rules. ΓòÉΓòÉΓòÉ 9.4.3. binding ΓòÉΓòÉΓòÉ binding RPC: A relationship between a client and a server involved in a remote procedure call. ΓòÉΓòÉΓòÉ 9.4.4. binding handle ΓòÉΓòÉΓòÉ binding handle RPC: A reference to a binding. See binding information. ΓòÉΓòÉΓòÉ 9.4.5. binding information ΓòÉΓòÉΓòÉ binding information RPC: Information about one or more potential bindings, including an RPC protocol sequence, a network address, an endpoint, at least one transfer syntax, and an RPC protocol version number. See binding. See also endpoint, network address, RPC protocol, RPC protocol sequence, and transfer syntax. ΓòÉΓòÉΓòÉ 9.4.6. Browser ΓòÉΓòÉΓòÉ Browser CDS: A Motif-based program that lets users view the contents and structure of a cell namespace. ΓòÉΓòÉΓòÉ 9.5. C ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.5.1. cache ΓòÉΓòÉΓòÉ cache 1. CDS: The information that a CDS clerk stores locally to optimize name lookups. The cache contains attribute values resulting from previous lookups, as well as information about other clearinghouses and namespaces. 2. Security: Contains the credentials of a principal after the DCE login. 3. GDS: See DUA cache. ΓòÉΓòÉΓòÉ 9.5.2. CDS ΓòÉΓòÉΓòÉ CDS See Cell Directory Service. ΓòÉΓòÉΓòÉ 9.5.3. CDS control program (CDSCP) ΓòÉΓòÉΓòÉ CDS control program (CDSCP) A command interface that CDS administrators use to control CDS servers and clerks and manage the namespace and its contents. See also manager. ΓòÉΓòÉΓòÉ 9.5.4. CDSCP ΓòÉΓòÉΓòÉ CDSCP See CDS control program. ΓòÉΓòÉΓòÉ 9.5.5. cell ΓòÉΓòÉΓòÉ cell The basic unit of operation in the distributed computing environment. A cell is a group of users, systems, and resources that are grouped around a common purpose and that share common DCE services. ΓòÉΓòÉΓòÉ 9.5.6. Cell Directory Service (CDS) ΓòÉΓòÉΓòÉ Cell Directory Service (CDS) A DCE component. It manages a database of information about the resources within a cell. ΓòÉΓòÉΓòÉ 9.5.7. cell-relative name ΓòÉΓòÉΓòÉ cell-relative name Synonym for local name. ΓòÉΓòÉΓòÉ 9.5.8. chaining ΓòÉΓòÉΓòÉ chaining GDS, XDS: A mode of interaction optionally used by a directory system agent (DSA) that cannot perform an operation itself. The DSA chains by invoking the operation in another DSA and then relaying the outcome to the original requester. ΓòÉΓòÉΓòÉ 9.5.9. child pointer ΓòÉΓòÉΓòÉ child pointer CDS: A pointer that connects a directory to a directory immediately below it in a namespace. You do not explicitly create child pointers; CDS creates them for you when you create a new directory. CDS stores the child pointer in the directory that is the parent of the new directory. ΓòÉΓòÉΓòÉ 9.5.10. class ΓòÉΓòÉΓòÉ class A category into which objects are placed on the basis of their purpose and internal structure. ΓòÉΓòÉΓòÉ 9.5.11. clearinghouse ΓòÉΓòÉΓòÉ clearinghouse CDS: A collection of directory replicas on one CDS server. A clearinghouse takes the form of a database file. It can exist only on a CDS server node; it cannot exist on a node running only CDS clerk software. Usually only one clearinghouse exists on a server node. ΓòÉΓòÉΓòÉ 9.5.12. clerk ΓòÉΓòÉΓòÉ clerk 1. DTS: A software component that synchronizes the clock for its client system by requesting time values from servers, computing a new time from the values, and supplying the computed time to client applications. 2. CDS: A software component that receives CDS requests from a client application, ascertains an appropriate CDS server to process the requests, and returns the results of the requests to the client application. ΓòÉΓòÉΓòÉ 9.5.13. client ΓòÉΓòÉΓòÉ client A computer or process that accesses the data, services, or resources of another computer or process on the network. Contrast with server. ΓòÉΓòÉΓòÉ 9.5.14. client context ΓòÉΓòÉΓòÉ client context RPC: The state within an RPC server generated by a set of remote procedures and maintained across a series of calls for a particular client. See context handle. See also manager. ΓòÉΓòÉΓòÉ 9.5.15. client stub ΓòÉΓòÉΓòÉ client stub RPC: The surrogate code for an RPC interface that is linked with and called by the client application code. In addition to general operations such as marshalling data, a client stub calls the RPC runtime to perform remote procedure calls and, optionally, to manage bindings. See server stub. ΓòÉΓòÉΓòÉ 9.5.16. client/server model ΓòÉΓòÉΓòÉ client/server model A form of computing where one system, the client, requests something, and another system, the server, responds. ΓòÉΓòÉΓòÉ 9.5.17. clock ΓòÉΓòÉΓòÉ clock The combined hardware interrupt timer and software register that maintains the system time. ΓòÉΓòÉΓòÉ 9.5.18. condition variable ΓòÉΓòÉΓòÉ condition variable Threads: A synchronization object used in conjunction with a mutex. It allows a thread to suspend its execution until some condition is true. ΓòÉΓòÉΓòÉ 9.5.19. context handle ΓòÉΓòÉΓòÉ context handle RPC: A reference to state (client context) maintained across remote procedure calls by a server on behalf of a client. See client context. ΓòÉΓòÉΓòÉ 9.5.20. control access ΓòÉΓòÉΓòÉ control access CDS: An access right that grants users the ability to change the access control on a name and to perform other powerful management tasks, such as replicate a directory or move a clearinghouse. ΓòÉΓòÉΓòÉ 9.5.21. Coordinated Universal Time (UTC) ΓòÉΓòÉΓòÉ Coordinated Universal Time (UTC) An international time standard that DTS uses. The zero hour of Coordinated Universal Time is based on the zero hour of Greenwich (England) Mean Time. ΓòÉΓòÉΓòÉ 9.5.22. copy ΓòÉΓòÉΓòÉ copy GDS, XDS: Either a copy of an entry stored in other DSAs through bilateral agreement or a locally and dynamically stored copy of an entry resulting from a request (a cache copy). ΓòÉΓòÉΓòÉ 9.5.23. courier ΓòÉΓòÉΓòÉ courier DTS: A local server that requests a time value from a randomly selected global server each time the courier synchronizes. ΓòÉΓòÉΓòÉ 9.5.24. C-stub ΓòÉΓòÉΓòÉ C-stub The part of the directory user agent (DUA) that implements the connection with the communications network. ΓòÉΓòÉΓòÉ 9.6. D ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.6.1. daemon ΓòÉΓòÉΓòÉ daemon A DCE server process. ΓòÉΓòÉΓòÉ 9.6.2. datagram ΓòÉΓòÉΓòÉ datagram RPC: A network data packet that is independent of all other packets and does not guarantee delivery or sequentiality. ΓòÉΓòÉΓòÉ 9.6.3. datagram protocol ΓòÉΓòÉΓòÉ datagram protocol RPC: A datagram-based transport protocol, such as User Datagram Protocol (UDP), that runs over a connectionless transport protocol. ΓòÉΓòÉΓòÉ 9.6.4. DCE ΓòÉΓòÉΓòÉ DCE See Distributed Computing Environment. ΓòÉΓòÉΓòÉ 9.6.5. decrypt ΓòÉΓòÉΓòÉ decrypt Security: To decipher data. ΓòÉΓòÉΓòÉ 9.6.6. DFS ΓòÉΓòÉΓòÉ DFS See Distributed File Service. ΓòÉΓòÉΓòÉ 9.6.7. directory ΓòÉΓòÉΓòÉ directory 1. A logical unit for storing entries under one name in a namespace. You can copy, delete, and control access to a directory. Each physical instance of a directory is called a replica. 2. A collection of open systems that cooperates to hold a logical database of information about a set of objects in the real world. ΓòÉΓòÉΓòÉ 9.6.8. directory access protocol (DAP) ΓòÉΓòÉΓòÉ directory access protocol (DAP) GDS: The protocol used by a DUA to access a DSA. ΓòÉΓòÉΓòÉ 9.6.9. directory information base (DIB) ΓòÉΓòÉΓòÉ directory information base (DIB) GDS: The complete set of information to which the directory provides access, which includes all of the pieces of information that can be read or manipulated using the operations of the directory. ΓòÉΓòÉΓòÉ 9.6.10. directory information tree (DIT) ΓòÉΓòÉΓòÉ directory information tree (DIT) GDS: The directory information base (DIB) considered as a tree, whose vertices (other than the root) are the directory entries. ΓòÉΓòÉΓòÉ 9.6.11. directory schema ΓòÉΓòÉΓòÉ directory schema GDS: The set of rules and constraints concerning directory information tree (DIT) structure, object class definitions, attribute types, and syntaxes that characterize the directory information base (DIB). ΓòÉΓòÉΓòÉ 9.6.12. Directory Service ΓòÉΓòÉΓòÉ Directory Service A DCE component. The Directory Service is a central repository for information about resources in a distributed system. See Cell Directory Service and Global Directory Service. ΓòÉΓòÉΓòÉ 9.6.13. directory system ΓòÉΓòÉΓòÉ directory system GDS: A system for managing a directory, consisting of one or more DSAs. Each DSA manages part of the DIB. ΓòÉΓòÉΓòÉ 9.6.14. directory system agent (DSA) ΓòÉΓòÉΓòÉ directory system agent (DSA) GDS: An open systems interconnect (OSI) application process that is part of the directory. ΓòÉΓòÉΓòÉ 9.6.15. directory system protocol (DSP) ΓòÉΓòÉΓòÉ directory system protocol (DSP) GDS: The protocol used by a directory system agent (DSA) to access another DSA. ΓòÉΓòÉΓòÉ 9.6.16. directory user agent (DUA) ΓòÉΓòÉΓòÉ directory user agent (DUA) GDS: An open systems interconnect (OSI) application process that represents a user accessing the directory. ΓòÉΓòÉΓòÉ 9.6.17. distinguished name ΓòÉΓòÉΓòÉ distinguished name GDS: One of the names of an object, formed from the sequence of RDNs of its object entry and each of its superior entries. ΓòÉΓòÉΓòÉ 9.6.18. distributed computing ΓòÉΓòÉΓòÉ distributed computing A type of computing that allows computers with different hardware and software to be combined on a network to function as a single computer to share the task of processing application programs. ΓòÉΓòÉΓòÉ 9.6.19. Distributed Computing Environment (DCE) ΓòÉΓòÉΓòÉ Distributed Computing Environment (DCE) The emerging industry standard for implementing distributed computing. ΓòÉΓòÉΓòÉ 9.6.20. Distributed File Service (DFS) ΓòÉΓòÉΓòÉ Distributed File Service (DFS) A DCE component. It provides a file service that joins the local file systems of several File Server machines, making the files equally available to all DFS client machines. ΓòÉΓòÉΓòÉ 9.6.21. distributed service ΓòÉΓòÉΓòÉ distributed service A DCE service that is used mainly by administrators to manage a distributed environment. These services include DTS, Security, and Directory. ΓòÉΓòÉΓòÉ 9.6.22. Distributed Time Service (DTS) ΓòÉΓòÉΓòÉ Distributed Time Service (DTS) A DCE component. It provides a way to synchronize the times on different hosts in a distributed system. ΓòÉΓòÉΓòÉ 9.6.23. drift ΓòÉΓòÉΓòÉ drift DTS: The change in a clock's error rate over a specified period of time. ΓòÉΓòÉΓòÉ 9.6.24. DTS ΓòÉΓòÉΓòÉ DTS See Distributed Time Service. ΓòÉΓòÉΓòÉ 9.6.25. DUA cache ΓòÉΓòÉΓòÉ DUA cache GDS: The part of the DUA that stores information to optimize name lookups. The cache contains objects from previous lookups as well as information about DSAs in the directory. ΓòÉΓòÉΓòÉ 9.7. E ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.7.1. element ΓòÉΓòÉΓòÉ element RPC: Any of the bits of a bit string, the octets of an octet string, or the octets by means of which the characters of a character string are represented. ΓòÉΓòÉΓòÉ 9.7.2. encrypt ΓòÉΓòÉΓòÉ encrypt To encipher data. ΓòÉΓòÉΓòÉ 9.7.3. encryption key ΓòÉΓòÉΓòÉ encryption key A value used to encrypt data so that only possessors of the encryption key can decipher it. ΓòÉΓòÉΓòÉ 9.7.4. endpoint ΓòÉΓòÉΓòÉ endpoint RPC: An address of a specific server instance on a host. ΓòÉΓòÉΓòÉ 9.7.5. endpoint map ΓòÉΓòÉΓòÉ endpoint map RPC: A database local to a node where local RPC servers register binding information associated with their interface identifiers and object identifiers. The endpoint map is maintained by the endpoint map service of the RPC daemon. See endpoint map service. See also RPC daemon. ΓòÉΓòÉΓòÉ 9.7.6. endpoint map service ΓòÉΓòÉΓòÉ endpoint map service RPC: A service provided by the RPC daemon that maintains a system's endpoint map for local RPC servers. When an RPC client makes a remote procedure call using a partially bound binding handle, the endpoint map service looks up the endpoint of a compatible local server. See endpoint map. See also partially bound binding handle and RPC daemon. ΓòÉΓòÉΓòÉ 9.7.7. entry ΓòÉΓòÉΓòÉ entry GDS, XDS: The part of the DIB that contains information relating to a single directory object. Each entry consists of directory attributes. ΓòÉΓòÉΓòÉ 9.7.8. export ΓòÉΓòÉΓòÉ export 1. RPC: To place the server binding information associated with an RPC interface or a list of object UUIDs or both into an entry in a name service database. 2. To provide access information for an RPC interface. Contrast with unexport. ΓòÉΓòÉΓòÉ 9.8. F ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.8.1. foreign cell ΓòÉΓòÉΓòÉ foreign cell A cell other than the one to which the local machine belongs. A foreign cell and its binding information are stored in either GDS or the Domain Name System (DNS). The act of contacting a foreign cell is called intercell. Contrast with local cell. ΓòÉΓòÉΓòÉ 9.8.2. fully bound binding handle ΓòÉΓòÉΓòÉ fully bound binding handle RPC: A server binding handle that contains a complete server address including an endpoint. Contrast with partially bound binding handle. ΓòÉΓòÉΓòÉ 9.9. G ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.9.1. GDA ΓòÉΓòÉΓòÉ GDA See global directory agent. ΓòÉΓòÉΓòÉ 9.9.2. GDS ΓòÉΓòÉΓòÉ GDS See Global Directory Service. ΓòÉΓòÉΓòÉ 9.9.3. global directory agent (GDA) ΓòÉΓòÉΓòÉ global directory agent (GDA) A DCE component that makes it possible for the local CDS to access names in foreign cells. The GDA helps CDS find binding information to foreign cells through either the GDS or the Domain Name System (DNS). ΓòÉΓòÉΓòÉ 9.9.4. Global Directory Service (GDS) ΓòÉΓòÉΓòÉ Global Directory Service (GDS) A DCE component. It provides a global namespace that connects DCE cells in a worldwide hierarchy. It is an implementation of the X.500 directory standard. ΓòÉΓòÉΓòÉ 9.9.5. global name ΓòÉΓòÉΓòÉ global name A name that is universally meaningful and usable from anywhere in the DCE naming environment. The prefix /... indicates that a name is global. ΓòÉΓòÉΓòÉ 9.9.6. group ΓòÉΓòÉΓòÉ group 1. RPC: A name service entry that corresponds to one or more RPC servers that offer common RPC interfaces, RPC objects, or both. A group contains the names of the server entries, other groups, or both that are members of the group. See NSI group attribute. 2. Security: Data that associates a named set of principals that can be granted common access rights. See subject identifier. ΓòÉΓòÉΓòÉ 9.10. H ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.10.1. handle ΓòÉΓòÉΓòÉ handle RPC: An opaque reference to information. See binding handle, context handle, interface handle, name service handle, and thread handle. ΓòÉΓòÉΓòÉ 9.10.2. heterogeneous ΓòÉΓòÉΓòÉ heterogeneous A collection of dissimilar host computers such as those from different manufacturers. Contrast with homogeneous. ΓòÉΓòÉΓòÉ 9.10.3. home cell ΓòÉΓòÉΓòÉ home cell Synonym for local cell. ΓòÉΓòÉΓòÉ 9.10.4. homogeneous ΓòÉΓòÉΓòÉ homogeneous A collection of similar host computers such as those of one model of one manufacturer. Contrast with heterogeneous. ΓòÉΓòÉΓòÉ 9.10.5. host ID ΓòÉΓòÉΓòÉ host ID Synonym for network address. ΓòÉΓòÉΓòÉ 9.11. I ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.11.1. IDL ΓòÉΓòÉΓòÉ IDL See Interface Definition Language. ΓòÉΓòÉΓòÉ 9.11.2. IDL compiler ΓòÉΓòÉΓòÉ IDL compiler RPC: A compiler that processes an RPC interface definition and an optional attribute configuration file (ACF) to generate client and server stubs, header files, and auxiliary files. See Interface Definition Language. ΓòÉΓòÉΓòÉ 9.11.3. import ΓòÉΓòÉΓòÉ import 1. RPC: To obtain binding information from a name service database about a server that offers a given RPC interface by calling the RPC NSI import operation. 2. RPC: To incorporate constant, type, and import declarations from one RPC interface definition into another RPC interface definition by means of the IDL import statement. ΓòÉΓòÉΓòÉ 9.11.4. inaccuracy ΓòÉΓòÉΓòÉ inaccuracy DTS: The bounded uncertainty of a clock value as compared to a standard reference. ΓòÉΓòÉΓòÉ 9.11.5. information architecture ΓòÉΓòÉΓòÉ information architecture GDS: The representation of the information stored in object management (OM) objects and the hierarchical relationships between different classes of OM objects. ΓòÉΓòÉΓòÉ 9.11.6. instance ΓòÉΓòÉΓòÉ instance XOM: An object in the category represented by a class. ΓòÉΓòÉΓòÉ 9.11.7. integrity ΓòÉΓòÉΓòÉ integrity RPC: A protection level that may be specified in secure RPC communications that ensures that data transferred between two principals has not been modified in transit. ΓòÉΓòÉΓòÉ 9.11.8. interface ΓòÉΓòÉΓòÉ interface RPC: A shared boundary between two or more functional units, defined by functional characteristics, signal characteristics, or other characteristics, as appropriate. The concept includes the specification of the connection of two devices having different functions. See RPC interface. ΓòÉΓòÉΓòÉ 9.11.9. interface definition ΓòÉΓòÉΓòÉ interface definition RPC: A description of an RPC interface written in the DCE Interface Definition Language (IDL). See RPC interface. ΓòÉΓòÉΓòÉ 9.11.10. Interface Definition Language (IDL) ΓòÉΓòÉΓòÉ Interface Definition Language (IDL) A high-level declarative language that provides syntax for interface definitions. ΓòÉΓòÉΓòÉ 9.11.11. interface handle ΓòÉΓòÉΓòÉ interface handle RPC: A reference in code to an interface specification. See binding handle and interface specification. ΓòÉΓòÉΓòÉ 9.11.12. interface identifier ΓòÉΓòÉΓòÉ interface identifier RPC: A string containing the interface universal unique identifier (UUID) and major and minor version numbers of a given RPC interface. See RPC interface. ΓòÉΓòÉΓòÉ 9.11.13. interface specification ΓòÉΓòÉΓòÉ interface specification RPC: An opaque data structure that is generated by the DCE IDL compiler from an interface definition. It contains identifying and descriptive information about an RPC interface. See interface definition, interface handle, and RPC interface. ΓòÉΓòÉΓòÉ 9.11.14. interface UUID ΓòÉΓòÉΓòÉ interface UUID RPC: The universal unique identifier generated for an RPC interface definition using the UUID generator (uuidgen). See interface definition and RPC interface. ΓòÉΓòÉΓòÉ 9.11.15. interval ΓòÉΓòÉΓòÉ interval DTS: The combination of a time value and the inaccuracy associated with it; the range of values represented by a combined time and inaccuracy notation. As an example, the interval 08:00.00I00:00 (eight o'clock, plus or minus five minutes) contains the time 07:57.00. ΓòÉΓòÉΓòÉ 9.12. K ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.12.1. Kerberos ΓòÉΓòÉΓòÉ Kerberos The authentication protocol used to implement DCE private key authentication. Kerberos was developed at the Massachusetts Institute of Technology. ΓòÉΓòÉΓòÉ 9.12.2. key ΓòÉΓòÉΓòÉ key A value used to encrypt and decrypt data. ΓòÉΓòÉΓòÉ 9.12.3. Key Management Facility ΓòÉΓòÉΓòÉ Key Management Facility A Security Service facility that enables noninteractive principals to manage their secret keys. ΓòÉΓòÉΓòÉ 9.13. L ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.13.1. LAN ΓòÉΓòÉΓòÉ LAN Local area network. A data network located on the user's premises in which serial transmission is used for direct data communication among data stations. ΓòÉΓòÉΓòÉ 9.13.2. layer ΓòÉΓòÉΓòÉ layer In network architecture, a group of services, functions, and protocols that is complete from a conceptual point of view, that is one out of a set of hierarchically arranged groups, and that extends across all systems that conform to the network architecture. ΓòÉΓòÉΓòÉ 9.13.3. local ΓòÉΓòÉΓòÉ local 1. Pertaining to a device directly connected to your system without the use of a communication line. 2. Pertaining to devices that have a direct, physical connection. Contrast with remote. ΓòÉΓòÉΓòÉ 9.13.4. local area network ΓòÉΓòÉΓòÉ local area network See LAN. ΓòÉΓòÉΓòÉ 9.13.5. local cell ΓòÉΓòÉΓòÉ local cell The cell to which the local machine belongs. Synonymous with home cell. Contrast with foreign cell. ΓòÉΓòÉΓòÉ 9.13.6. local name ΓòÉΓòÉΓòÉ local name A name that is meaningful and usable only within the cell where an entry exists. The local name is a shortened form of a global name. Local names begin with the prefix /.: and do not contain a cell name. Synonymous with cell-relative name. ΓòÉΓòÉΓòÉ 9.13.7. local server ΓòÉΓòÉΓòÉ local server DTS: A server that synchronizes with its peers and provides its clock value to other servers and clerks in the same network. ΓòÉΓòÉΓòÉ 9.13.8. Login Facility ΓòÉΓòÉΓòÉ Login Facility A Security Service facility that enables a principal to establish its identity. ΓòÉΓòÉΓòÉ 9.14. M ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.14.1. manager ΓòÉΓòÉΓòÉ manager RPC: A set of remote procedures that implement the operations of an RPC interface and that can be dedicated to a given type of object. See also object and RPC interface. ΓòÉΓòÉΓòÉ 9.14.2. master replica ΓòÉΓòÉΓòÉ master replica CDS: The first instance of a specific directory in the namespace. Once copies of the directory have been made, a different replica can be designated as the master, but only one master replica of a directory can exist at a time. CDS can create, update, and delete object entries and soft links in a master replica. ΓòÉΓòÉΓòÉ 9.14.3. mutex ΓòÉΓòÉΓòÉ mutex A synchronization object that is used to allow multiple threads to serialize their access to shared data. The name is derived from the capability it provides, namely, mutual exclusion. ΓòÉΓòÉΓòÉ 9.15. N ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.15.1. name ΓòÉΓòÉΓòÉ name GDS, CDS: A construct that singles out a particular (directory) object from all other objects. A name must be unambiguous (that is, denote just one object); however, it need not be unique (that is, be the only name that unambiguously denotes the object). ΓòÉΓòÉΓòÉ 9.15.2. name service handle ΓòÉΓòÉΓòÉ name service handle RPC: An opaque reference to the context used by the series of next operations called during a specific name service interface (NSI) search or inquiry. ΓòÉΓòÉΓòÉ 9.15.3. name service interface (NSI) ΓòÉΓòÉΓòÉ name service interface (NSI) RPC: A part of the application program interface (API) of the RPC runtime. NSI routines access a name service, such as CDS, for RPC applications. ΓòÉΓòÉΓòÉ 9.15.4. namespace ΓòÉΓòÉΓòÉ namespace CDS: A complete set of CDS names that one or more CDS servers look up, manage, and share. These names can include directories, object entries, and soft links. ΓòÉΓòÉΓòÉ 9.15.5. naming attribute ΓòÉΓòÉΓòÉ naming attribute GDS: An attribute used to form the relative distinguished name (RDN) of an entry. ΓòÉΓòÉΓòÉ 9.15.6. network ΓòÉΓòÉΓòÉ network A configuration of data processing devices and software connected for information interchange. ΓòÉΓòÉΓòÉ 9.15.7. network address ΓòÉΓòÉΓòÉ network address An address that identifies a specific host on a network. Synonymous with host ID. ΓòÉΓòÉΓòÉ 9.15.8. network data ΓòÉΓòÉΓòÉ network data RPC: Data represented in a format defined by a transfer syntax. See also transfer syntax. ΓòÉΓòÉΓòÉ 9.15.9. Network Data Representation (NDR) ΓòÉΓòÉΓòÉ Network Data Representation (NDR) RPC: The transfer syntax defined by the Network Computing Architecture. See transfer syntax. ΓòÉΓòÉΓòÉ 9.15.10. network protocol ΓòÉΓòÉΓòÉ network protocol A communications protocol from the Network Layer of the Open systems interconnect (OSI) network architecture, such as the Internet Protocol (IP). ΓòÉΓòÉΓòÉ 9.15.11. Network Time Protocol (NTP) ΓòÉΓòÉΓòÉ Network Time Protocol (NTP) A clock synchronization protocol commonly used on an internet. ΓòÉΓòÉΓòÉ 9.15.12. node ΓòÉΓòÉΓòÉ node In network topology, the point at an end of a branch. It is usually a physical machine. ΓòÉΓòÉΓòÉ 9.15.13. NSI ΓòÉΓòÉΓòÉ NSI See name service interface. ΓòÉΓòÉΓòÉ 9.15.14. NSI binding attribute ΓòÉΓòÉΓòÉ NSI binding attribute RPC: An RPC-defined attribute (NSI attribute) of a name service entry; the binding attribute stores binding information for one or more interface identifiers offered by an RPC server and identifies the entry as an RPC server entry. See binding information and NSI object attribute. See also server entry. ΓòÉΓòÉΓòÉ 9.15.15. NSI group attribute ΓòÉΓòÉΓòÉ NSI group attribute RPC: An RPC-defined attribute (NSI attribute) of a name service entry that stores the entry names of the members of an RPC group and identifies the entry as an RPC group. See group. ΓòÉΓòÉΓòÉ 9.15.16. NSI object attribute ΓòÉΓòÉΓòÉ NSI object attribute RPC: An RPC-defined attribute (NSI attribute) of a name service entry that stores the object UUIDs of a set of RPC objects. See object. ΓòÉΓòÉΓòÉ 9.15.17. NSI profile attribute ΓòÉΓòÉΓòÉ NSI profile attribute RPC: An RPC-defined attribute (NSI attribute) of a name service entry that stores a collection of RPC profile elements and identifies the entry as an RPC profile. See profile. ΓòÉΓòÉΓòÉ 9.15.18. NTP ΓòÉΓòÉΓòÉ NTP See Network Time Protocol. ΓòÉΓòÉΓòÉ 9.15.19. NULL ΓòÉΓòÉΓòÉ NULL The value of a pointer that indicates that the pointer does not point to data. ΓòÉΓòÉΓòÉ 9.16. O ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.16.1. object ΓòÉΓòÉΓòÉ object 1. A data structure that implements some feature and has an associated set of operations. 2. RPC: For RPC applications, an object can be anything that an RPC server defines and identifies to its clients using an object universal unique identifier (UUID). An RPC object is often a physical computing resource such as a database, directory, device, or processor. Alternatively, an RPC object can be an abstraction that is meaningful to an application, such as a service or the location of a server. See object UUID. 3. XDS: Anything in the world of telecommunications and information processing that can be named and for which the directory information base (DIB) contains information. 4. XOM: Any of the complex information objects created, examined, modified, or destroyed by means of the interface. ΓòÉΓòÉΓòÉ 9.16.2. object class ΓòÉΓòÉΓòÉ object class CDS, GDS: An identified family of objects that share certain characteristics. An object class can be specific to one application or shared among a group of applications. An application interprets and uses an entry's class-specific attributes based on the class of the object that the entry describes. ΓòÉΓòÉΓòÉ 9.16.3. object entry ΓòÉΓòÉΓòÉ object entry CDS: The name of a resource (such as a node, disk, or application) and its associated attributes, as stored by CDS. CDS administrators, client application users, or the client applications themselves can give a resource an object name. CDS supplies some attribute information (such as a creation timestamp) to become part of the object, and the client application may supply more information for CDS to store as other attributes. See entry. ΓòÉΓòÉΓòÉ 9.16.4. object management (OM) ΓòÉΓòÉΓòÉ object management (OM) The creation, examination, modification, and deletion of potentially complex information objects. ΓòÉΓòÉΓòÉ 9.16.5. object UUID ΓòÉΓòÉΓòÉ object UUID RPC: The universal unique identifier (UUID) that identifies a particular RPC object. A server specifies a distinct object UUID for each of its RPC objects. To access a particular RPC object, a client uses the object UUID to find the server that offers the object. See object. ΓòÉΓòÉΓòÉ 9.16.6. Open Software Foundation (OSF) ΓòÉΓòÉΓòÉ Open Software Foundation (OSF) Pertaining to a nonprofit research and development organization set up to encourage the development of solutions that allow computers from different vendors to work together in a true, open system, computing environment. ΓòÉΓòÉΓòÉ 9.16.7. operation ΓòÉΓòÉΓòÉ operation 1. RPC: The task performed by a routine or procedure that is requested by a remote procedure call. 2. GDS: Processing performed within the directory to provide a service, such as a read operation. ΓòÉΓòÉΓòÉ 9.16.8. organization ΓòÉΓòÉΓòÉ organization Security: Data that associates a named set of users that is associated with a common administrative policy. ΓòÉΓòÉΓòÉ 9.16.9. OSF ΓòÉΓòÉΓòÉ OSF See Open Software Foundation. ΓòÉΓòÉΓòÉ 9.17. P ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.17.1. package ΓòÉΓòÉΓòÉ package XOM: A specified group of related object management (OM) classes, denoted by an object identifier. ΓòÉΓòÉΓòÉ 9.17.2. parent directory ΓòÉΓòÉΓòÉ parent directory CDS: Any directory that has one or more levels of directories beneath it in a cell namespace. A directory is the parent of any directory immediately beneath it in the hierarchy. ΓòÉΓòÉΓòÉ 9.17.3. partially bound binding handle ΓòÉΓòÉΓòÉ partially bound binding handle RPC: A server binding handle that contains an incomplete server address lacking an endpoint. Contrast with fully bound binding handle. ΓòÉΓòÉΓòÉ 9.17.4. password ΓòÉΓòÉΓòÉ password A secret string of characters shared between a computer system and a user. The user must specify the character string to gain access to the system. ΓòÉΓòÉΓòÉ 9.17.5. permission ΓòÉΓòÉΓòÉ permission 1. The modes of access to a protected object. The number and meaning of permissions with respect to an object are defined by the access control list (ACL) Manager of the object. 2. GDS: One of five groups that assigns modes of access to users: MODIFY PUBLIC, READ STANDARD, MODIFY STANDARD, READ SENSITIVE, or MODIFY SENSITIVE. Synonymous with access right. See also access control list. ΓòÉΓòÉΓòÉ 9.17.6. person ΓòÉΓòÉΓòÉ person See principal. ΓòÉΓòÉΓòÉ 9.17.7. platform ΓòÉΓòÉΓòÉ platform The operating system environment in which a program runs. ΓòÉΓòÉΓòÉ 9.17.8. port ΓòÉΓòÉΓòÉ port 1. Part of an IP address specifying an endpoint. 2. To make the programming changes necessary to allow a program that runs on one type of computer to run on another type of computer. ΓòÉΓòÉΓòÉ 9.17.9. position (within a string) ΓòÉΓòÉΓòÉ position (within a string) XOM: The ordinal position of one element of a string relative to another. ΓòÉΓòÉΓòÉ 9.17.10. position (within an attribute) ΓòÉΓòÉΓòÉ position (within an attribute) XOM: The ordinal position of one value relative to another. ΓòÉΓòÉΓòÉ 9.17.11. presentation address ΓòÉΓòÉΓòÉ presentation address An unambiguous name that is used to identify a set of presentation service access points. Loosely, it is the network address of an open systems interconnect (OSI) service. ΓòÉΓòÉΓòÉ 9.17.12. principal ΓòÉΓòÉΓòÉ principal Security: An entity that can communicate securely with another entity. In the DCE, principals are represented as entries in the Registry database and include users, servers, computers, and authentication surrogates. ΓòÉΓòÉΓòÉ 9.17.13. privacy ΓòÉΓòÉΓòÉ privacy RPC: A protection level that may be specified in secure RPC communications and that encrypts RPC argument values. ΓòÉΓòÉΓòÉ 9.17.14. private key ΓòÉΓòÉΓòÉ private key See secret key. ΓòÉΓòÉΓòÉ 9.17.15. privilege attribute ΓòÉΓòÉΓòÉ privilege attribute Security: An attribute of a principal that may be associated with a set of permissions. DCE privilege attributes are identity-based and include the principal's name, group memberships, and native cell. ΓòÉΓòÉΓòÉ 9.17.16. privilege attribute certificate (PAC) ΓòÉΓòÉΓòÉ privilege attribute certificate (PAC) Security: Data describing a principal's privilege attributes that has been certified by an authority. In the DCE, the Privilege Service is the certifying authority; it seals the privilege attribute data in a ticket. The authorization protocol, DCE Authorization, determines the permissions granted to principals by comparing the privilege attributes in PACs with entries in an access control list. ΓòÉΓòÉΓòÉ 9.17.17. Privilege Service ΓòÉΓòÉΓòÉ Privilege Service Security: One of three services provided by the Security Service; the Privilege Service certifies a principal's privileges. The other services are the Registry Service and the Authentication Service. ΓòÉΓòÉΓòÉ 9.17.18. profile ΓòÉΓòÉΓòÉ profile RPC: An entry in a name service database that contains a collection of elements from which name service interface (NSI) search operations construct search paths for the database. Each search path is composed of one or more elements that refer to name service entries corresponding to a given RPC interface and, optionally, to an object. See NSI profile attribute and profile element. ΓòÉΓòÉΓòÉ 9.17.19. profile element ΓòÉΓòÉΓòÉ profile element RPC: A record in an RPC profile that maps an RPC interface identifier to a profile member (a server entry, group, or profile in a name service database). See profile. See also group, interface identifier and server entry. ΓòÉΓòÉΓòÉ 9.17.20. protection level ΓòÉΓòÉΓòÉ protection level The degree to which secure network communications are protected. Synonymous with authentication level. ΓòÉΓòÉΓòÉ 9.17.21. protocol ΓòÉΓòÉΓòÉ protocol A set of semantic and syntactic rules that determines the behavior of functional units in achieving communication. ΓòÉΓòÉΓòÉ 9.17.22. protocol family ΓòÉΓòÉΓòÉ protocol family Synonym for address family. ΓòÉΓòÉΓòÉ 9.17.23. protocol sequence ΓòÉΓòÉΓòÉ protocol sequence Synonym for RPC protocol sequence. ΓòÉΓòÉΓòÉ 9.18. R ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.18.1. read access ΓòÉΓòÉΓòÉ read access CDS: An access right that grants the ability to view data. ΓòÉΓòÉΓòÉ 9.18.2. read-only replica ΓòÉΓòÉΓòÉ read-only replica 1. CDS: A copy of a CDS directory in which applications cannot make changes. Although applications can look up information (read) from it, they cannot create, modify, or delete entries in a read-only replica. Read-only replicas become consistent with other, modifiable replicas of the same directory during skulks and routine propagation of updates. 2. Security: A slave Registry server. ΓòÉΓòÉΓòÉ 9.18.3. realm ΓòÉΓòÉΓòÉ realm Security: A cell, considered exclusively from the point of view of Security; this term is used in Kerberos specifications. The term cell designates the basic unit of DCE configuration and administration and incorporates the notion of a realm. ΓòÉΓòÉΓòÉ 9.18.4. referral ΓòÉΓòÉΓòÉ referral GDS: An outcome that can be returned by a DSA that cannot perform an operation itself. The referral identifies one or more other DSAs more able to perform the operation. ΓòÉΓòÉΓòÉ 9.18.5. register ΓòÉΓòÉΓòÉ register 1. RPC: To list an RPC interface with the RPC runtime. 2. To place server-addressing information into the local endpoint map. 3. To insert authorization and authentication information into binding information. See endpoint map and RPC interface. ΓòÉΓòÉΓòÉ 9.18.6. Registry Service ΓòÉΓòÉΓòÉ Registry Service Security: One of three services provided by the Security Service; the Registry Service manages information about principals, accounts, and security policies. The other services are the Privilege Service and the Authentication Service. ΓòÉΓòÉΓòÉ 9.18.7. relative distinguished name (RDN) ΓòÉΓòÉΓòÉ relative distinguished name (RDN) GDS, XDS: A set of Attribute Value Assertions (AVAs). ΓòÉΓòÉΓòÉ 9.18.8. remote ΓòÉΓòÉΓòÉ remote Pertaining to a device, file or system that is accessed by your system through a communications line. Contrast with local. ΓòÉΓòÉΓòÉ 9.18.9. remote procedure ΓòÉΓòÉΓòÉ remote procedure RPC: An application procedure located in a separate address space from calling code. See remote procedure call. ΓòÉΓòÉΓòÉ 9.18.10. remote procedure call ΓòÉΓòÉΓòÉ remote procedure call RPC: A client request to a service provider located anywhere in the network. ΓòÉΓòÉΓòÉ 9.18.11. Remote Procedure Call (RPC) ΓòÉΓòÉΓòÉ Remote Procedure Call (RPC) A DCE component. It allows requests from a client program to access a procedure located anywhere in the network. ΓòÉΓòÉΓòÉ 9.18.12. replica ΓòÉΓòÉΓòÉ replica CDS: A directory in the CDS namespace. The first instance of a directory in the namespace is the master replica. When CDS managers make copies of the master replica to store in other clearinghouses, all of the copies, including the master replica, become part of the directory's replica set. ΓòÉΓòÉΓòÉ 9.18.13. replication ΓòÉΓòÉΓòÉ replication The making of a shadow of a database to be used by another node. Replication can improve availability and load-sharing. ΓòÉΓòÉΓòÉ 9.18.14. request ΓòÉΓòÉΓòÉ request A command sent to a server over a connection. ΓòÉΓòÉΓòÉ 9.18.15. resource ΓòÉΓòÉΓòÉ resource Items such as printers, plotters, data storage, or a computer service. Each has a unique identifier associated with it for naming purposes. ΓòÉΓòÉΓòÉ 9.18.16. return value ΓòÉΓòÉΓòÉ return value A function result that is returned in addition to the values of any output or input/output arguments. ΓòÉΓòÉΓòÉ 9.18.17. RPC ΓòÉΓòÉΓòÉ RPC See Remote Procedure Call. ΓòÉΓòÉΓòÉ 9.18.18. RPC daemon (RPCD) ΓòÉΓòÉΓòÉ RPC daemon (RPCD) The process that provides the endpoint map service for a system. See also endpoint map and endpoint map service. ΓòÉΓòÉΓòÉ 9.18.19. RPC interface ΓòÉΓòÉΓòÉ RPC interface A logical group of operations, data types, and constant declarations that serves as a network contract for a client to request a procedure in a server. See also interface definition and operation. ΓòÉΓòÉΓòÉ 9.18.20. RPC protocol ΓòÉΓòÉΓòÉ RPC protocol An RPC-specific communications protocol that supports the semantics of the DCE RPC API and runs over either connectionless or connection-oriented communications protocols. ΓòÉΓòÉΓòÉ 9.18.21. RPC protocol sequence ΓòÉΓòÉΓòÉ RPC protocol sequence A valid combination of communications protocols represented by a character string. Each RPC protocol sequence typically includes three protocols: a network protocol, a transport protocol, and an RPC protocol that works with those network and transport protocols. See network protocol, RPC protocol. Synonymous with protocol sequence. ΓòÉΓòÉΓòÉ 9.18.22. RPC runtime ΓòÉΓòÉΓòÉ RPC runtime A set of operations that manages communications, provides access to the name service database, and performs other tasks, such as managing servers and accessing security information, for RPC applications. See RPC runtime library. ΓòÉΓòÉΓòÉ 9.18.23. RPCD ΓòÉΓòÉΓòÉ RPCD See RPC daemon. ΓòÉΓòÉΓòÉ 9.19. S ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.19.1. scalability ΓòÉΓòÉΓòÉ scalability The ability of a distributed system to expand in size without changes to the system structure, to applications, or to the way users deal with the system. ΓòÉΓòÉΓòÉ 9.19.2. schema ΓòÉΓòÉΓòÉ schema See directory schema. ΓòÉΓòÉΓòÉ 9.19.3. secret key ΓòÉΓòÉΓòÉ secret key Security: A long-lived encryption key shared between a principal and the Authentication Service. ΓòÉΓòÉΓòÉ 9.19.4. Security Service ΓòÉΓòÉΓòÉ Security Service A DCE component. It provides trustworthy identification of users, secure communications, and controlled access to resources in a distributed system. ΓòÉΓòÉΓòÉ 9.19.5. segment ΓòÉΓòÉΓòÉ segment One or more contiguous elements of a string. ΓòÉΓòÉΓòÉ 9.19.6. server ΓòÉΓòÉΓòÉ server 1. On a network, the computer that contains programs, data, or provides the facilities that other computers on the network can access. 2. The party that receives remote procedure calls. Contrast with client. ΓòÉΓòÉΓòÉ 9.19.7. server entry ΓòÉΓòÉΓòÉ server entry RPC: A name service entry that stores the binding information associated with the RPC interfaces of a particular RPC server and object universal unique identifiers (UUIDs) for any objects offered by the server. See also binding information, NSI binding attribute, NSI object attribute, object and RPC interface. ΓòÉΓòÉΓòÉ 9.19.8. server stub ΓòÉΓòÉΓòÉ server stub RPC: The surrogate calling code for an RPC interface that is linked with server application code containing one or more sets of remote procedures (managers) that implement the interface. See client stub. See also manager. ΓòÉΓòÉΓòÉ 9.19.9. service ΓòÉΓòÉΓòÉ service In network architecture, the capabilities that the layers closer to the physical media provide to the layers closer to the end user. ΓòÉΓòÉΓòÉ 9.19.10. session ΓòÉΓòÉΓòÉ session GDS: A sequence of directory operations requested by a particular user of a particular directory user agent (DUA) using the same session object management (OM) object. ΓòÉΓòÉΓòÉ 9.19.11. skulk ΓòÉΓòÉΓòÉ skulk CDS: A process by which CDS makes the data consistent in all replicas of a particular directory. CDS collects all changes made to the master replica since the last skulk was completed, and disseminates the changes from the up-to-date replica to all other existing replicas of the directory. All replicas of a directory must be available for a skulk to be considered successful. If a skulk fails, CDS reports the replicas that it could not reach. ΓòÉΓòÉΓòÉ 9.19.12. soft link ΓòÉΓòÉΓòÉ soft link CDS: A pointer that provides an alternative name for an object entry, directory, or other soft link in the namespace. A soft link can be permanent or it can expire after a specific period of time. The CDS server also can delete it automatically after the name that the link points to is deleted. ΓòÉΓòÉΓòÉ 9.19.13. specific ΓòÉΓòÉΓòÉ specific XOM: The attribute types that can appear in an instance of a given class, but not in an instance of its superclasses. ΓòÉΓòÉΓòÉ 9.19.14. S-stub ΓòÉΓòÉΓòÉ S-stub GDS: The part of the directory system agent (DSA) that establishes the connection to the communications network. ΓòÉΓòÉΓòÉ 9.19.15. standard ΓòÉΓòÉΓòÉ standard A model that is established and widely used. ΓòÉΓòÉΓòÉ 9.19.16. string ΓòÉΓòÉΓòÉ string An ordered sequence of bits, octets, or characters, accompanied by the string's length. ΓòÉΓòÉΓòÉ 9.19.17. stub ΓòÉΓòÉΓòÉ stub RPC: A code module specific to an RPC interface that is generated by the Network Interface Definition Language (NIDL) compiler to support remote procedure calls for the interface. RPC stubs are linked with client and server applications and hide the intricacies of remote procedure calls from the application code. See client stub, server stub, and extended server stub. ΓòÉΓòÉΓòÉ 9.19.18. subject identifier (SID) ΓòÉΓòÉΓòÉ subject identifier (SID) A string that identifies a user or set of users. Each SID consists of three fields in the form person.group.organization. In an account, each field must have a specific value; in an access control list (ACL) entry, one or more fields may use a wildcard. ΓòÉΓòÉΓòÉ 9.19.19. synchronization ΓòÉΓòÉΓòÉ synchronization DTS: The process by which a Distributed Time Service entity requests clock values from other systems, computes a new time from the values, and adjusts its system clock to the new time. ΓòÉΓòÉΓòÉ 9.19.20. syntax ΓòÉΓòÉΓòÉ syntax 1. XOM: An object management (OM) syntax is any of the various categories into which the OM specification statically groups values on the basis of their form. These categories are additional to the OM type of the value. 2. A category into which an attribute value is placed on the basis of its form. See attribute syntax. ΓòÉΓòÉΓòÉ 9.19.21. system time ΓòÉΓòÉΓòÉ system time The time value maintained and used by the operating system. ΓòÉΓòÉΓòÉ 9.20. T ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.20.1. thread ΓòÉΓòÉΓòÉ thread A single sequential flow of control within a process. ΓòÉΓòÉΓòÉ 9.20.2. thread handle ΓòÉΓòÉΓòÉ thread handle RPC: A data item that enables threads to share a memory management environment. ΓòÉΓòÉΓòÉ 9.20.3. ticket ΓòÉΓòÉΓòÉ ticket Security: An application-transparent mechanism that transmits the identity of an initiating principal to its target. A simple ticket contains the principal's identity, a session key, a timestamp and other information, sealed using the target's secret key. A privilege ticket contains the same information as a simple ticket, and also includes a privilege attribute certificate. A ticket-granting ticket is a ticket to the ticket-granting service. A service ticket is a ticket for a specified service other than the ticket-granting service. ΓòÉΓòÉΓòÉ 9.20.4. time differential factor (TDF) ΓòÉΓòÉΓòÉ time differential factor (TDF) DTS: The difference between coordinated universal time (UTC) and the time in a particular time zone. ΓòÉΓòÉΓòÉ 9.20.5. time provider (TP) ΓòÉΓòÉΓòÉ time provider (TP) DTS: A process that queries coordinated universal time (UTC) from a hardware device and provides it to the server. ΓòÉΓòÉΓòÉ 9.20.6. time provider interface (TPI) ΓòÉΓòÉΓòÉ time provider interface (TPI) An interface between the DTS server and external time provider process. The DTS server uses the interface to communicate with the time provider and to obtain timestamps from an external time source. ΓòÉΓòÉΓòÉ 9.20.7. timeslicing ΓòÉΓòÉΓòÉ timeslicing A mechanism by which running threads are preempted at fixed intervals. This ensures that every thread is allowed time to be executed. ΓòÉΓòÉΓòÉ 9.20.8. transfer syntax ΓòÉΓòÉΓòÉ transfer syntax RPC: A set of encoding rules used for transmitting data over a network and for converting application data to and from different local data representations. See also Network Data Representation. ΓòÉΓòÉΓòÉ 9.20.9. Transmission Control Protocol ΓòÉΓòÉΓòÉ Transmission Control Protocol A transport protocol of the Internet Protocol (IP) family for connection-oriented communication. ΓòÉΓòÉΓòÉ 9.20.10. Transmission Control Protocol/Internet Protocol (TCP/IP) ΓòÉΓòÉΓòÉ Transmission Control Protocol/Internet Protocol (TCP/IP) A network protocol that connects to other systems that support TCP/IP. It allows a user to send and receive mail, transfer files across a network, print files, run commands on remote systems, and log in to remote systems. ΓòÉΓòÉΓòÉ 9.20.11. transport layer ΓòÉΓòÉΓòÉ transport layer A network service that provides end-to-end communications between two parties, while hiding the details of the communications network. The Transmission Control Protocol (TCP) and International Organization for Standardization (ISO) TP4 transport protocols provide full-duplex virtual circuits on which delivery is reliable, error free, sequenced, and duplicate free. User Datagram Protocol (UDP) provides no guarantees. The connectionless RPC protocol provides some guarantees on top of UDP. ΓòÉΓòÉΓòÉ 9.20.12. transport protocol ΓòÉΓòÉΓòÉ transport protocol A communications protocol, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). ΓòÉΓòÉΓòÉ 9.20.13. type ΓòÉΓòÉΓòÉ type XOM: A category into which attribute values are placed on the basis of their purpose. See attribute type. ΓòÉΓòÉΓòÉ 9.20.14. type UUID ΓòÉΓòÉΓòÉ type UUID RPC: The universal unique identifier (UUID) that identifies a particular type of object and an associated manager. See also manager and object. ΓòÉΓòÉΓòÉ 9.21. U ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.21.1. unexport ΓòÉΓòÉΓòÉ unexport RPC: To remove binding information from a server entry in a name service database. Contrast with export. ΓòÉΓòÉΓòÉ 9.21.2. universal unique identifier (UUID) ΓòÉΓòÉΓòÉ universal unique identifier (UUID) RPC: An identifier that is immutable and unique across time and space. A UUID can uniquely identify an entity such as an object or an RPC interface. See interface UUID, object UUID, and type UUID. ΓòÉΓòÉΓòÉ 9.21.3. user ΓòÉΓòÉΓòÉ user A person who requires the services of a computing system. ΓòÉΓòÉΓòÉ 9.21.4. User Datagram Protocol (UDP) ΓòÉΓòÉΓòÉ User Datagram Protocol (UDP) A protocol of the Internet Protocol (IP) family. ΓòÉΓòÉΓòÉ 9.21.5. UTC ΓòÉΓòÉΓòÉ UTC See Coordinated Universal Time. ΓòÉΓòÉΓòÉ 9.22. V ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.22.1. value ΓòÉΓòÉΓòÉ value XOM: An arbitrary and complex information item that can be viewed as a characteristic or property of an object. See attribute value. ΓòÉΓòÉΓòÉ 9.22.2. vector ΓòÉΓòÉΓòÉ vector RPC: An array of references to other structures. ΓòÉΓòÉΓòÉ 9.23. W ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.23.1. WAN ΓòÉΓòÉΓòÉ WAN Wide area network. A network that provides communication services to a geographic area larger than that served by a local area network (LAN). ΓòÉΓòÉΓòÉ 9.23.2. wide area network ΓòÉΓòÉΓòÉ wide area network See WAN. ΓòÉΓòÉΓòÉ 9.23.3. workstation ΓòÉΓòÉΓòÉ workstation A terminal or microcomputer, usually one that is connected to a host or to a network, at which a user can execute applications. ΓòÉΓòÉΓòÉ 9.24. X ΓòÉΓòÉΓòÉ ΓòÉΓòÉΓòÉ 9.24.1. XDS ΓòÉΓòÉΓòÉ XDS The X/Open Directory Service application program interface (API). ΓòÉΓòÉΓòÉ 9.24.2. XOM ΓòÉΓòÉΓòÉ XOM The X/Open Object Management application program interface (API).