The OSF DCE comprises several technology components:
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 distributed services' APIs. System administrators, on the other hand, deal mostly with the distributed services since they have significant management requirements.
There are also facilities that do not fall under a specific component, but perform services common to multiple components. Among these facilities are the following:
This chapter contains sections devoted to each of the technology components (Sections 3.1 through 3.6). Each of these sections starts with an overview of its technology, along with a description of the pieces that constitute the technology. The sections then describe their technologies from the perspective of different types of users such as the end user's viewpoint, how the programmer develops an application with the technology, and how the administrator manages the technology. Finally, the sections each explain how their technology works, and they describe important benefits or features of the particular technology.
Section 3.7 gives an overview of the cross-technology facilities. Section 3.8 describes the DCE administrative control program (dcecp).
The last section of this chapter, Section 3.9, gives an example of a very simple distributed application, describing the process for developing, installing, and running it.
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 can make good use of the capability for multiple threads of control. For example, when a client makes an RPC call, it blocks until a response is returned from the server. If there are multiple threads of control in the client, then work can continue in another thread while the thread waiting for the RPC response is blocked. On the server side, this same situation applies, since a server may itself issue an RPC. 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 threads' 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; this has implications for its interaction with other software on the system, such as an operating system that delivers signals to or blocks a whole process, rather than just a thread, and pre-existing library calls that were not originally written for a multithreaded environment.
The following subsections give an overview of the DCE Threads technology component. They describe the different kinds of functions provided by the technology, and how DCE Threads is seen from the end user's, programmer's, and administrator's perspective, focusing particularly on programming with DCE Threads, since the application programmer is the main consumer of this technology.
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, as described in Section 3.1.3. The other technology components of OSF's Distributed Computing Environment assume the availability of threads support. 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 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. Since messages from the outside world (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. For further information on the way DCE Threads interacts with other software, see the chapters on threads in the OSF DCE Application Development Guide.
An end user is not aware whether or not threads are being 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.
The distributed application programmer can use threads to help structure a program. However, 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.
In a traditional process, there is only one thread of control, and it is started and terminated implicitly. However, when it is possible to have more than one thread of control, the threads must be created and destroyed explicitly. DCE Threads provides the facilities for doing this.
DCE Threads scheduling is built on two basic, interacting mechanisms:
Each thread has a scheduling priority associated with it. Threads with a higher priority have precedence over threads with a lower priority when scheduling decisions are made. The exact treatment of threads of different priorities depends on the scheduling policy they are running under.
DCE Threads offers three scheduling policies:
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 blocks, 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, then the threads in the next highest priority level are run FIFO, and so on.
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, 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.
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 is in contrast to FIFO and round-robin scheduling, in which it is possible for higher priority threads to prevent lower priority threads from running at all.
Threads communicate through shared variables -- one thread sets a variable that another thread later reads. However, if multiple threads are accessing the same variable, incorrect results can occur due to scheduling of threads and race conditions. To resolve this problem, access to shared variables must be synchronized. DCE Threads provides three facilities for synchronizing threads within a process:
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. To do this, Thread A waits on the condition variable until Thread B signals the condition variable, indicating that the particular task has been accomplished.
Note that although the condition variable is used for explicit communications among threads, the communications are anonymous. For example, Thread B does not necessarily 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. This allows a thread to wait for another, specific thread to complete its execution. When the second thread has finished, the first thread unblocks and continues its execution. Unlike mutexes and condition variables, the join routine is not associated with any particular shared data.
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. This is provided by the 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.
There are no administrative tasks associated with the DCE Threads component.
For additional information on DCE Threads, see the following:
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, as in a traditional local procedure call, control is passed from one code segment to another, and then returns to the original segment. However, in a local procedure call, the code segments are in the same address space on the same machine; whereas 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 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:
Programmers using RPC do not need to rewrite applications in order 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.
The following subsections give an overview of the DCE Remote Procedure Call technology component. They describe the components that comprise the technology, and how DCE RPC is seen from the end user's, programmer's, and administrator's perspective, focusing primarily on programming with RPC, since the application programmer is the main consumer of this technology. The subsections also describe the steps involved in the execution of a remote procedure call. They describe the ways in which DCE RPC frees the programmer from system software and hardware dependencies, and then list additional sources of information on 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, but 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. It is the application programmer who most comes into contact with the RPC component. Since 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:
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.
This library 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.
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. (See Section 3.5.4 for more information on Authenticated RPC.)
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.
The DCE Host daemon (dced) is a program that runs on every DCE machine. It includes (among other things) an RPC-specific name server called the endpoint mapper service, which manages a database that maps RPC servers to the transport endpoints (in IP, the ports) that the server is listening for requests on.
The DCE control program (dcecp) is a tool for administering DCE.
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.
The end user does not come in direct contact with DCE RPC, but does see the end result, in the form of
An end user who is browsing through the namespace may also notice the names of RPC-based servers, since these servers advertise themselves to their clients through the DCE Directory Service.
This section provides a brief overview of the process a programmer goes through in using DCE RPC to write an application. For an example of how this process applies to a simple application, see Section 3.8 of this manual. For a more detailed description of the DCE RPC programming process, see the introductory chapters and the RPC chapters of the OSF DCE Application Development Guide.
Figure 3-1 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.
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 in a conventional programming language, which is the C language in the DCE offering and then calls the appropriate compiler to produce 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.
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.
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.
In order 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 DCE RPC's use 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 that the client is interested in (in our example, a Bank Server). In order 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 in order 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.
Every machine that runs an RPC server also runs a dced. The dced process always uses the same network endpoint, so its process address is well known. Therefore, once a client knows what machine a server is running on, it can find the Endpoint Mapper running on that same machine. It can then ask the Endpoint Mapper for the network endpoint of the server process. This process is shown in Figure 3-2 (read the messages, shown in quotes, in clockwise order).
A few administrative tasks must be performed when running a distributed application using RPC. The application server executes most of these tasks when it first starts. As described in the previous section, the server registers its (dynamically assigned) listening endpoint with dced. The server also advertises information about itself and the interfaces it supports in the DCE Directory Service.
Nonautomated RPC administration is minimal. The administrator must ensure that each DCE machine has a DCE Host 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 as just described. Usually, an administrator will be needed to change the ACL on the directory where the server will register so that the server has write permission. A management program, dcecp, allows an administrator to (among many things) control the dced 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 before it can begin receiving and servicing requests. The administrator may arrange for the server process to be started each time the machine is booted, for example.
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 Figure 3-3. (This description is somewhat simplified. The use of dced is not shown.)
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 Point 1 in Figure 3-3). In this way, when a client queries the Directory Service for a bank server, it will be able to 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, since 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 (see Point 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 -- 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's Runtime receives the server's reply. The client stub then unpacks the received network message, arranging returned parameters such that when the client application call to RPC returns, it looks like 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.
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.
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.
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 ``multicanonical;'' 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.
Independence of RPC, transport, and network protocols is achieved as follows. The DCE RPC offering includes two different RPC protocols. The first runs over connection-oriented transport protocols; the second runs 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.
Because DCE RPC uses the DCE Transfer Syntax, distributed applications are machine independent. DCE Transfer Syntax allows machines to transfer data even when their native data representations are not the same.
Finally, DCE RPC offers independence from the local operating system. The application programmer is not directly using 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 operating system specific.
For additional information on DCE RPC, see the following:
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 potentially 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, since it is used to find the information needed for accessing other services.
The next section gives an overview of the DCE Directory Service architecture. Sections 3.3.2 and 3.3.3 describe the DCE Directory Service components -- the Cell Directory Service, and the Global Directory Agent. Section 3.3.4. describes the Directory Service application programming interface.
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.
There are three components that together comprise the DCE Directory Service:
The X/Open Directory Service (XDS) application programming interface is used to access the Directory Service components. A brief overview of the Directory Service components and interface is given in this section; subsequent sections in this chapter describe them in more detail.
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, since most directory service queries are for information about resources within the same cell as the originator of the query. CDS is replicated -- this is important for a local directory service, since the directory service must be highly available. There must be at least one Cell Directory Server in each DCE cell. Figure 3-4 shows three organizations, each with its own DCE cell.
CDS can be used to connect independent cells into a ``hierarchical'' cell configuration, as shown in Figure 3-5. In this configuration, one cell's CDS acts as a higher-level directory service to connect other independent cells. The cell whose CDS acts as the higher-level directory service is known as the ``parent'' cell, while the cells connected through the parent's CDS are known as ``child'' cells.
DCE Global Directory Service. The Global Directory Service is a distributed, replicated directory service based on the CCITT X.500/ISO international standard. GDS interworks with other X.500 implementations, and can therefore participate in the worldwide X.500 directory service.
The Global Directory Service can act as a higher level directory service to connect cells, as shown in Figure 3-5. 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.
Note: GDS support is not provided with the product, but is mentioned here for completeness.
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, DNS, or CDS, depending on where the foreign cell is registered. Figure 3-6 gives a functional picture, including the use of GDAs, of the configuration shown in Figure 3-5.
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 the Global Directory Service or to the Cell Directory Service (see Figure 3-7). XDS uses the X/Open Object Management (XOM) application programming interface to define and manage its information.
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. GDS names are typed, that is, they consist of a type and a value separated by an = (equal sign). A name such as /C=US/O=ABCcompany, names an object that exists in GDS. An untyped name consists only of values such as abc.com; DNS names use this format.
Figure 3-8 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.
Figure 3-9 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 hostnames. (See the Transarc DCE Administration Guide--Introduction for more information on the 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 DCE Directory Service looks very different to the end user, programmer, and administrator. This section takes a brief look at the Directory Service from each of these three perspectives.
End User's Perspective. The DCE Directory Service is one of the few DCE technologies that is visible to the end user. A frequent use of the namespace is in referencing the file system. The pathname for a file in a foreign cell is partially a pathname in the Directory Service, as in the example /.../cs.univ.edu/fs/usr/ziggy given previously.
Application Programmer's Perspective. DCE application programmers do not necessarily need to interface directly with the Directory Service, since 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. However, 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.
Administrator's Perspective: Two Directory Services and an Intermediary. Unlike the end user and application programmer, the Directory Service administrator is aware of the cell's directory service configuration, since the two directory services are administered separately. The administrator manages the CDS server and the Global Directory Agent.
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. More information on UUIDs is contained in the RPC chapters of the OSF DCE Application Development Guide.
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. Profiles 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. For more information on RPC Profiles, see the RPC chapters of the OSF DCE Application Development Guide.
The DCE namespace is not contained entirely in the DCE Directory Service. Other system services contain parts of the namespace and some of them require their own specialized naming services, which supplement the DCE Directory Service. These include:
The DCE Host Daemon (dced) maintains a database of local data that is essential for operating in a DCE environment, such as the host's cell name. It also keeps a database of server configuration information that it uses to manage DCE server operation on a host, for example, starting or stopping a DCE server. An example of a name in the DCE host daemon part of the namespace is /.../cs.univ.edu/hosts/gunther/config/srvrconf/video_clip, where video_clip is the name of a DCE application server.
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.
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.
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.
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.)
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 crashes.
Administrators can use the DCE Control Program dcecp to carry out the majority of CDS administrative tasks. There is also an administrative program included in the CDS technology -- the CDS Control Program. The CDS Control Program, cdscp, enables administrators to control CDS Servers and data.
Figure 3-10 shows a client application that sends a request to the CDS clerk, which in turn communicates with the CDS Server. The server performs a database lookup or update, depending on the request. The response is then sent back to the client application.
CDS information is contained in three types of data elements -- directory entries, directories, and clearinghouses.
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.
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.
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, and the other in Clearinghouse B.
A directory service must be highly available, since 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:
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:
With 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, it is not necessary for copies to be updated immediately. Sometimes it is not even possible, since 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). As mentioned previously, the CDS Clerk caches directory information so that information will be available on the local node rather than having to repeatedly query directory servers. 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.
An end user may be interested in perusing the cell namespace to look for information contained in CDS.
Programmers can access CDS through XDS (see Section 3.3.4). They also use CDS indirectly when they use the Name Service routines of the RPC API.
In general, CDS administrators use dcecp to administer CDS; They can also use cdscp in the few cases where dcecp does not provide the necessary administrative function. CDS administrative tasks include monitoring CDS servers, managing access control on CDS directories, and specifying replication and update of CDS data.
For additional information on CDS, see the following:
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.
The DCE Global Directory Agent is a process that interfaces 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 in order for that cell to acquire directory service information from other DCE cells.
Figure 3-11 shows how the GDA relates to 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.
For additional information on DCE GDA, see the GDA sections of the Transarc DCE Administration Guide.
The X/Open Directory Service (XDS) and X/Open Object Management (XOM) application programming interfaces 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.
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.
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.
For additional information on the XDS and XOM interfaces, see the following:
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, there is one clock that 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:
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 -- since 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. So 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 therefore expressed as a range, or interval, rather than as a single point.
There are several different components that comprise the DCE Distributed Time Service:
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.
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 milliseconds at each clock tick until it catches up.
Figure 3-12 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.
Time Servers. A 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 a typical 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 (described later in this section).
A distinction is made between Local Time Servers (Time Servers on a given LAN) and Global Time Servers. This is because 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 is where Couriers are needed.
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.
Figure 3-13 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.
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.
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 cannot, of course, be as accurate as an automatic time source, but it may be sufficient in some cases.
DTS supports the ability to interface 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.
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
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 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.
There are two ways a programmer can be affected by the presence of DTS in a system. It is possible for an application to 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 other nodes' clocks in the distributed system.
It is also possible for the programmer to use the DTS API to directly deal with distributed time. Since 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 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 running the make program, 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.
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 set-up and configuration work for the administrator, although once it is up and running, the administrative maintenance tasks are infrequent.
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. See the chapter on NTP in the Transarc DCE Administration Guide for additional information.
For additional information on the DCE Distributed Time Service, see the following:
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 in order to control access to resources in a distributed environment. In DCE, resource protection is provided by the DCE Security Service or, alternatively, the Generic Security Service (GSS).
The DCE Security Service comprises several parts, including the Authentication Service, the Privilege Service, the Registry Service, the Access Control List Facility, the Login Facility, and the Audit Service.
The Authentication Service enables two processes on different machines to be certain of one another's identity, or authenticated. On a timesharing system, this functionality is provided in part by the operating system kernel. However, since a local host's operating system cannot necessarily be trusted in a distributed system, an authentication service is necessary in a distributed computing environment.
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 functionality 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 in order 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, so the typical application programmer does not interact with them directly, but instead uses Authenticated RPC.
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.
The Extended Registry Attribute interface allows the Registry schema to be modified so that user-defined attributes can be associated with registry objects.
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 dcecp command allows users to modify ACLs associated with resources they own.
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.
The Audit Service detects and records the execution of DCE server operations that are relevant to the maintenance of a secure distributed computing environment. The Audit Service records the ``event'' in a log file called an ``audit trail file''. DCE application programmers build auditing into their DCE servers by designating security-relevant operations as ``code points'' for which auditing is required, and using an audit API to establish auditing of those operations. The DCE Security Service and the DCE Distributed Time Service also use the Audit Service to track and record the use of their security-critical operations. Administrators can use the Audit Service ``event class'' and ``filter'' mechanisms to organize and tailor the recording of events into audit trail files.
This section gives an overview of how the DCE security services and facilities interact to provide a secure distributed computing environment. Figure 3-14 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 dcecp program, 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 into the account at the beginning of a session. The Login Facility interacts with both the Authentication Server and the Privilege Server. It sends a request for authentication credentials to the Authentication Server. The Authentication Server sends back the authentication credentials, called a Ticket. The Authentication Server's 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. The Privilege Server returns authorization credentials, called an EPAC (Extended Privilege Attribute Certificate). The EPAC contains authorization information specific to the user, such as which groups the user belongs to. EPACs 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 EPAC. The server inspects the user's authorization credentials and 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 EPAC 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 all encrypted so that only the intended recipients are able to decrypt and read the messages. If desired, the application data can be encrypted as well. This prevents any unauthorized user from being able to read 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. (For information on the generation, transfer, and use of encryption keys in DCE Security, see the Security chapters of the OSF DCE Application Development Guide--Introduction and Style Guide and OSF DCE Application Development Guide--Core Components.
Finally, although it is not shown in Figure 3-14, all of the Security Service events just discussed -- creating a user, logging in, obtaining a ticket, and so on -- are recorded and logged in an audit trail file by the Audit Service daemon, auditd. In addition, if the application server has been designed to use the Audit Service, and the operation that the application client is requesting has been designated an audit code point, then the Audit Service logs the execution of the server operation on behalf of the requesting client.
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 when users type in their passwords to authenticate themselves to DCE, usually at login time. Another case is when they change access to resources they own, using the dcecp program. Finally, a user notices the Security Service in action when he or she is denied unauthorized access to resources.
Typically, a DCE programmer uses DCE RPC to implement a distributed application. DCE Security is integrated with RPC, so in some cases the programmer does not need to access security services directly. However, programming interfaces to the Security Service are available to the programmer who needs them. They include the ACL, Audit, Login, Extended Registry Attribute, Security Credentials, and Registry APIs, along with the API for Authenticated RPC. This section gives an overview of programming with Authenticated RPC and DCE ACLs.
Authenticated RPC. DCE RPC and DCE Security cooperate to provide authentication, authorization, and secure communications. In order 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 (see Section 3.5.6), or no authentication.
The client makes a call to indicate which 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, since the security mechanisms involve encrypting and decrypting data, which take up CPU 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 the form of an Extended Privilege Attributes Certificate (EPAC), which is produced by the Privilege Service. In both the certified and uncertified authorization service, the authorization information is sent securely.
The authentication and authorization information about the client are used by the server to determine whether the client should be granted the access to the resource that it has requested. The server knows for certain the identity of the client, and what authorization groups the client belongs to. The server can therefore compare the client's credentials against information in Access Control Lists and determine whether a client should be given the access it is requesting.
Access Control Lists. If a distributed application uses ACLs to control access to its resources, then 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, there is one Access Control List associated with each resource that the server manages. The ACL contains one or more entries specifying a user or group and what 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.
Figure 3-15 shows a simple DCE ACL. Every DCE ACL contains a field indicating what type of ACL it is. The ACL type in this case is sp_data_acl. Each DCE ACL also contains a field indicating what the default cell is 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.
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 snowpaws in 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.
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, the password for a local account (such as root), and so forth. 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.) If the machine runs DCE servers that use the Audit Service (application servers, the DTS server, or the Security server) the local security administrator also manages the audit daemon (auditd).
The cell-wide security administrator manages the cell's Security Server(s). This includes managing the secd process, which provides security services on the security server machine, creating and editing the security database using dcecp, and controlling replication of security data. The cell-wide security administrator can also carry out remote administration of the Audit daemons running on hosts in the cell. The cell-wide security administrator is also responsible for administering Audit Service event numbers and event class numbers to ensure that unique numbers are being issued.
The cell-wide security administrator is also involved in cross-cell authentication. It is possible for clients in one cell to communicate securely with servers in another cell. In order for this to happen, the security administrators in the two cells must register each other's Authentication Service in their Registry. This enables clients in one cell to authenticate to servers in another cell. In this way, it is possible for authorized clients in one cell to access services in a foreign cell.
A note on the relationship between the DCE Security Service and Kerberos, for those who are already familiar with Kerberos: The DCE Authentication Service is based on MIT Project Athena's Kerberos Network Authentication Service, Version The Kerberos Key Distribution Center (KDC) server is a part of the DCE Security server, secd. The authorization information that is created by the DCE Privilege server is passed in the Kerberos Version 5 Ticket's authorization data field.
The Kerberos user commands kinit, klist, and kdestroy are used in DCE Security. 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.
The Generic Security Service (GSS) provides an alternate way of securing distributed applications that handle network communications by themselves. With GSSAPI, applications that establish the secure connection are like a DCE RPC client. Applications that accept the secure connection are like a DCE RPC server.
The GSS available with DCE includes the Standard GSSAPI routines (defined in the Internet RFC 1509), as well as OSF DCE extensions to the GSSAPI routines. These extensions are additional routines that enable an application to use DCE security services.
The GSSAPI combines authentication and authorization under a single security mechanism type. The security mechanism provides applications a choice of either authenticated Kerberos security or authenticated PAC authorization under DCE Security.
Although an application that uses GSSAPI may not make explicit calls to RPC routines, the GSSAPI implementation itself uses DCE RPC to communicate with the DCE registry
For additional information on the DCE Security Service and the GSSAPI, see the following:
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 stored goes down. A distributed file system can provide access to files from anywhere in the world, allowing cooperation among geographically dispersed users. A distributed file system can also give users on machines with very 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 the lower-level DCE components (such as RPC, the Security Service, and the Directory Service). The following subsections describe DFS and the configuration of its components, and they provide various user perspectives on DFS.
DFS data is organized at three levels. (See Figure 3-16.)
The three levels of DFS data are, from smallest to largest:
The file is the unit of user data. Directories organize files (and other directories) into a hierarchical tree structure.
The fileset is the unit of administration. A fileset is a subtree of files and directories that is 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 in the same fileset.
The aggregate is the unit of disk storage, similar to a disk partition. It is also the unit of fileset exporting, which makes the data in filesets available to users of DFS. It can contain one or more filesets.
DFS consists of several components. This section briefly describes each of these components, discussing the software that runs on DCE client machines (the Cache Manager), then the software that runs on DCE File Server machines (the File Exporter, Token Manager, and DCE Local File System), and finally the administrative server processes, which typically run on DFS File Server machines (the Fileset Server, Basic OverSeer Server, Replication Server, Update Server, Fileset Location Server, and Backup Server). It also briefly describes the administrative tools used to monitor DFS use and activity (Scout and the dfstrace utility), and it describes the DFS/NFS Secure Gateway, which provides authenticated access to DFS from NFS clients.
Because files are cached on the client, a local copy of a cached 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 had to go to the server each time it needed to access 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 Token Manager must revoke the existing token and grant a new token before the requested operation can proceed.
A UNIX File System (UFS) can be used as a File Server machine's physical file system as an alternative or complement to DCE LFS. DFS can export a UFS, issue synchronization tokens for files in a UFS, and perform fileset operations such as dump and restore on a UFS. However, there is only one fileset per UFS partition, which results in large filesets, and unlike DCE LFS filesets, UFS filesets cannot be replicated or moved. Although UFS systems are supported in DFS, a File Server machine that uses DCE LFS has more functionality than a File Server machine that uses only UFS.
Some DFS components run in the host machine's kernel. These are the Cache Manager and Token Management Layer on DFS client machines; and the File Exporter, Token Manager, and DCE Local File System on File Server machines.
The DCE Distributed File Service has the following features:
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 machine on which the file is located to name and access the file. For example, the file /.../cs.univ.edu/fs/usr/ziggy/thesis can be addressed by that name from anywhere in DCE, including from foreign cells.
Data can move from one location to another within a cell without a user or programmer being affected by the move. Because of this transparency, an administrator can move a fileset from one File Server machine to another for load balancing, for example, without disturbing users.
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 the 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 access to the file can then be made to the copy on the client machine rather than to the copy on the File Server machine.
DFS makes its services and data highly available in several ways. One way is through replication -- a read-only copy of a file can be stored on more than one File Server machine. This way, if the File Server machine that houses one copy of the file is down, another copy of the file may still be available on another File Server machine. DFS replication is especially useful for files that are accessed by many users but change infrequently (for example, binary files).
Another way DFS achieves high availability is through caching. Copies of files are cached on DFS clients. Even if a client is temporarily disconnected from the network, users of the client may be able to access copies of files that reside in the local cache.
DFS administration can occur while users continue to access DFS files, which is another means of providing high availability. Both backups and relocation of DFS filesets can be done without making the data in the filesets unavailable to users.
The physical file system portion of DFS, the DCE Local File System, is designed for fast recovery (yielding high availability) after failures. DCE LFS is a log-based file system; that is, LFS keeps a record of actions taken that affect the file system structure so that in the case of a system crash, the record can be replayed to bring the file system to a consistent state.
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 network communications and the movement, synchronization, and storage of shared data.
DFS files are grouped into units called filesets, which are convenient to administer. The processes that implement DFS, such as the Fileset Location Server and the Backup Server, are monitored and maintained automatically by the Basic OverSeer Server, resulting in less work and a more scalable system for a DFS administrator. 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 low impact on other clients and the rest of the system. Finally, DFS includes tools such as the Update Server to automate time-consuming administrative tasks.
DFS is fully integrated with other DCE components, including RPC, the Security Service, the Directory Service, and Threads.
DFS interoperates with other file systems; for example, a UFS file system can be exported to users of DFS.
DFS maintains POSIX single-site read/write semantics. The DCE Local File System adheres to POSIX
This section describes which of the DFS components 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 Figure 3-17.)
Several processes run on DFS File Server machines: the File Exporter (which includes the Token Manager), the Basic OverSeer Server, 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, DCE LFS, UFS, or both.
Some DFS processes must run on a machine that contains the files or database they access. These processes usually run on DFS File Server machines. (See Figure 3-18.)
These processes are the server side of the Update Server (which runs both on machines that contain master copies of configuration files and on machines that contain master copies of binary files), the Fileset Location Server (which runs on machines on which the Fileset Location Database is located), and the Backup Server (which runs on machines on which the Backup Database resides).
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 machines, and some in another cell -- to a user, the DCE Distributed File Service presents one large, worldwide file system. Users do 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, which they can use DFS commands to examine. DFS also includes commands for determining the location of a file and other information that is unique to a distributed file system.
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 distributed programming expertise. Through the use of DFS, programmers can write distributed applications without the use of RPC and the client/server model, assuming the DFS data sharing model is appropriate to the application.
Administration of DFS is a significant task because several processes that implement DFS need to be set up and maintained. However, administrative tools are provided to aid in this task. DFS configuration is varied and flexible, so 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.
For additional information about the DCE Distributed File Service, see the chapters and reference pages in the Transarc DCE DFS Administration Guide and the Transarc DCE DFS Administration Reference.
For most applications, multiple DCE components work in concert. Several services are dedicated to facilitating interaction among components and are described separately from the components themselves in the following subsections.
A Security Validation Service maintains a login context for host identification and certifies for application programs that the DCE Security Daemon (secd) is legitimate.
The Key Table Management Service enables remote management of server key tables. A server uses private keys rather than human-readable passwords for authentication. This service can be used to add, remove, and change keys and entire key tables.
The Endpoint Mapper Service maintains a local database (an endpoint map) associating port addresses that locate servers on a host with servers, interfaces, and objects. Remote procedure calls use this service via the RPC runtime to resolve bindings between clients and servers. The data can be remotely perused, and even changed, although changes to the database are usually performed automatically by dced and the RPC runtime.
These cross-component facilities are described in detail in the OSF DCE Application Development Guide--Core Components.
The core services (especially the Cell Directory Service and the Security Service) for large cells can be complex, with some services being replicated or even partitioned across differing systems. The Host Services described in the previous section will exist on every computer in the cell. An administrative interface is needed that provides consistent and uniform access to DCE administration functions, wherever they reside, from any and every point in the cell. Administrative commands must work consistently and predictably regardless of the platform on which they execute.
The DCE Control Program (dcecp) available with DCE Version was developed to provide consistent, portable, extensible, and secure access to nearly all DCE administration functions from any point in a DCE cell. The dcecp program implements most of the operations previously performed by using various component control programs (for instance rpccp, cdscp, rgy_edit, acl_edit, dtscp, and sec_admin). Where before administrators needed multiple control programs with different syntaxes to perform certain operations such as adding a host to a cell, now only dcecp is required. Furthermore, these complex operations can be done now using a single "task script" that walks administrators through the pertinent commands prompting for input as necessary.
To do this, dcecp is able to manipulate data (for instance, directories, entries, groups, principals, accounts, and ACL's) stored in the various databases (for instance, the registry, clearinghouses, and ACL managers). It can also perform certain management operations like user create, server disable, and registry synchronize.
The DCE control program is built on a portable command language called Tcl (pronounced "tickle"), which stands for Tool Command Language. Tcl is a platform-independent command language that runs on every system where DCE Version 1.1 is installed. The Tcl command interpreter is provided along with dcecp. Together, these enable administrators to use variables, if statements, looping functions, and other programming operations to enhance the command set. Administrators can share scripts, moving them to other platforms without change. A common cell environment can be developed by propagating scripts.
The DCE control program uses an object-operation syntax, in which an object comes first, followed by an operation. The object-operation order makes it easy to add new objects and operations to DCE.
In summary, dcecp is an interactive command line interface used to manage most aspects of the DCE core components. Only a few infrequently performed control operations have not been replaced by dcecp.
This section presents two implementations of a very simple distributed application, called greet. This section assumes some familiarity with UNIX systems and the C programming language. The greet application is implemented two different ways -- one using DCE RPC, the other using DCE DFS. For a more extensive application example, which uses many more DCE services and facilities, see the timop example in Part 1 of the OSF DCE Application Development Guide.
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.
This section provides a step-by-step description of the development of the greet application.
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.idlcreates the file greet.idl. It contains the following:
[
uuid(3d6ead56-06e3-11ca-8dd1-826901beabcd),
version(1.0)
]
interface INTERFACENAME
{
}
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
{
}
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).
The following command runs the IDL compiler:
idl greet.idl(Some of the commands in this section are somewhat simplified. See the Makefile in Section 3.9.1.3 for the complete command.) Three new files are created automatically as a result of this command:
In general, the DCE RPC application programmer writes three application code files:
The following is the client code for the greet application, a file called greet_client.c.
/* * greet_client.c * * Client of "greet" interface. */ #include#include #include #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 \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.
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. */ #includeIn 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.#include #include #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 \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. */ 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"); }
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#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.
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#include #include 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
);
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
This section describes the process for an administrator who is installing and starting up the greet application, and a user who is running it.
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.
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
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.
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
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.
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"
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#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\n", s); unlink(S_GREET_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#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\n", 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