The Role of RPC

DCE RPC is based on the Apollo’s Network Computing System (NCA/RPC). RPC fits very naturally into the client-server model. The components of DCE RPC can be split into the following two groups according to the stage of their usage:

Used in development. They include IDL (Interface Definition Language) and the idl compiler. The IDL is a language used to define data types and operations applicable to each interface in a platform independent manner. The idl compiler is a tool used to translate IDL definitions into code (usually in C) which can be used in distributed applications;

Used in runtime. They include RPC runtime library, rpcd (RPC daemon), and rpccp (RPC control program).

To build a basic DCE application, the application developer has to supply the following three files:

The interface definition file. It defines the interfaces (data structures, procedure names, and parameters) of the remote procedures that are offered by the server;

The client program. It defines the user interfaces, the calls to the remote procedures of the server, and the client side processing functions;

The server program. It implements the calls offered by the server.

The first step for building a DCE application is to compile the interface definition file using the idl compiler to produce the interface header file, and the client and the server stubs. Then the client program and server program are compiled with their related stub files and the interface header. Finally, the client and server executables are generated by linking these object files with the RPC runtime library. Figure 7.2 shows these operations.

Figure 7.2: Build a DCE application

DCE uses threads to improve the efficiency of RPCs. A thread is a ‘lightweight’

process that executes a portion of a program, cooperating with other threads concurrently executing in the same address space of a process. Most of the information that is a part of a process can then be shared by all threads executing within the process’ address space. By sharing common information, the overhead incurred in creating and maintaining the information, and the amount of information

Figure 7.3: Using threads in a client-server application 7.1.3 The DCE Services

All the high-level DCE services, such as directory services, security services, time services, and distributed file services, are provided by relevant servers. This section briefly discusses these services and servers.

that needs to be saved when switching between threads of the same program is reduced significantly.

The thread facility can be provided by the operating system or DCE, but in both cases DCE specifies an application programming interface (API) to access thread services from applications. The API routines allow programmers to create and terminate threads, have one thread waiting for another to complete, and perform thread synchronisation. To provide a service, for example, a separate server can be used to interface with a group of clients and a separate thread within a particular server can be used to process an RPC from a client (Figure 7.3(a)). In this case, a server can serve many clients from many groups simultaneously. Within a client, a separate thread can be used to perform an RPC, allowing several RPCs to be executed at the same time (Figure 7.3(b)).

7.1.3.1 Directory Services

The main job of the directory services is to help clients find the locations of appropriate servers. To let clients access the services offered by a server, the server has to place some binding information into a directory. As mentioned in Chapter 2, to access the services of a server, a client needs to acquire that server’s binding information from the directory and to bind the information with the client. The client can then access the server directly.

A directory is a hierarchically structured database that stores dynamic system configuration information. The directory is a realisation of the naming system. Each name has attributes associated with it, which can be obtained via a query using the name.

Each cell in a DCE distributed computing system has its own directory service, called the Cell Directory Service (CDS), which stores the directory service information for a cell [Bond 1995]. It is optimised for intra-cell access, since most clients communicate with servers in the same cell. Each CDS consists of CDS servers and CDS clerks. A CDS server runs on a node containing a database of directory information (called the clearinghouse). Each clearinghouse contains some number of directories, similar to (but not the same as) directories in a file system.

Each directory, in turn, can logically contain other directories, object entries, or soft links (an alias that points to something else in CDS). Figure 7.4 shows the directory hierarchy of a clearinghouse.

Each cell may have multiple CDS servers. Nodes which do not run a CDS server must run a CDS clerk. A CDS clerk acts as an intermediary between a distributed application and the CDS server on a node not running a CDS server.

When a server wishes to make its binding information available to clients, it exports that information on one of its cell’s CDS servers. When a client wishes to locate a server within its own cell, it imports that information from the appropriate CDS server by calling on the CDS clerk on its node.

Figure 7.4: The CDS directory hierarchy

DCE uses the Domain Name System (DNS) or Global Directory Service (GDS, based on the X.500 standard) to enable clients to access servers in foreign cells. To access a server in a foreign cell, a client gives the cell’s name and the name of the desired server in that cell. A CDS component called a Global Directory Agent (GDA) extracts the location of the named cell’s CDS server from DNS or GDS, then a query is sent directly to this foreign server. Figure 7.5 shows the components of the DCE directory service.

Figure 7.5: Components of the DCE directory service

CDS supports replication of its information. Replication is done at the directory level, so any directory and the objects it contains can be copied by a cell administrator and kept in two or more CDS servers running concurrently within a cell. There are two types of directory replicas: master replicas and read-only replicas. Master replicas can accept any directory service operations (such as read and update operations) whereas read-only replicas can only accept read operations.

All the update operations happen on a master replica [Rosenberg et al. 1992], [Bond 1995]. There are two methods for maintaining data consistency between a master replica and its read-only replicas: immediate propagation and skulking. With immediate propagation, a change to the master replica causes the change to be immediately applied to all of its read-only replicas. However, if read-only replica is not available during the propagation, the change is simply not made to that replica.

With skulking, the changes are carried out on a periodical basis. The skulking operation ensures that when a failed replica restarts its information will be consistent with other replicas.

7.1.3.2 Security Services

DCE provides the following four security services:

Authentication. When a client requests some service from a server, it must identify itself and must provide some information to prove its true identity;

Authorisation. Once a client’s identity has been authenticated, the next question is whether the client has the right to perform the service it is requesting;

Data integrity. This service guards against the alteration of data during the transmission of the data. It allows a recipient of a message to determine whether the data has been tampered with;

Data privacy. It ensures that data sent between clients and servers cannot be read by anyone but the parties involved in the communication.

A security server (it may be replicated) is responsible for providing these services within a cell. The security server has the following three components:

Registry service is a database of principal (a user of the cell), group, and organisation accounts, their associated secret keys and administration policies.

Key distribution service provides tickets to clients. A ticket is a specially encrypted object that contains a conversation key and an identifier that can be presented by one principal to another as a proof of identity.

Privilege service supplies the privileges of a particular principal. It is used in authorisation.

The security server must run on a secure computer, since the registry on which it relies contains a secret key, generated from a password, for every principal in the cell.

DCE security services are based on the Kerberos V5.0, created by the MIT/Project Athena [MIT 1994], and DCE extends Kerberos version 5 by providing authorisation services [Chappell 1994].

7.1.3.3 Time Services

Distributed time service (DTS) of DCE is designed to keep a set of clocks on different computers synchronised. DTS uses the usual client-server structure: DTS clients, daemon processes called clerks, request the correct time from some number of servers, receive responses, and then reset their clocks as necessary to reflect this new knowledge. How often a clerk resynchronises, and thus how accurate that system’s clock will be, is configured by the system administrator.

Time in DTS is expressed as an interval (a time plus or minus an inaccuracy). A new time interval is calculated as the intersection of all the received intervals. For example, as shown in Figure 7.6, if a clerk receives four time intervals from time server 1, 2, 3, and 4, then the time synchronisation of the clerk is performed (the value returned by time server 3 is regarded to be faulty since it does not intersect with the majority, and is ignored). As a result, the clerk’s time is set to be the intersection of time intervals from time server 1,2, and 4.

There are several components that comprise the DCE DTS:

Time clerk is the client side of DTS. It runs on a client computer and keeps the computer’s local time synchronised by asking a time server for the correct time and adjusting the local time accordingly.

Figure 7.6: Time synchronisation using intervals

Time servers are of three types. The local time server maintains the time synchronisation of a given LAN. The global time server and courier time servers are used to synchronise time among interconnected LANs. A time server synchronises with other time servers by asking these time servers for correct times and adjusts its time accordingly.

DTS API provides an interface where application programs can access time information provided by the DTS.

Figure 7.7 shows the time synchronisation among time servers and clerks within a cell with multiple LANs. Within LAN 3, the time clerk synchronises its time by receiving (the dashed lines) time intervals from three time servers (time servers on computer 1, computer 2 and computer 3). The new time interval of the time clerk is then calculated from these received time intervals. Time synchronisation between the interconnected LANs (LAN 1, LAN 2 and LAN 3) are carried out by the global time servers within each LAN (the solid lines). An application (in Computer 4) accesses time information through the API provided by the DTS.

7.1.3.4 Distributed File Services

DCE uses its distributed file services (DFSs) to join the file systems of individual computers within a cell into a single file space. A uniform and transparent interface is provided for applications to accessing files located in the network. DFS is derived from the Andrew File System (AFS) [Satyanarayanan 1989]. It uses RPC for client-server communication, uses threads to enhance parallelism, relies on the DCE directory to locate servers, and uses DCE security services to protect from attackers.

DFS uses the client-server model. DFS clients, called cache managers, communicate with DFS servers using RPC on behalf of user applications. There are two types of DFS servers:

Figure 7.7: Time synchronisation within a multi-LAN cell

A fileset location server which stores the locations of system and user files in DFS;

A file server which manages files.

When a file is first accessed by an application from a computer, that computer’s cache manager copies the file’s first chunk (the default size is 64K bytes, so many files will be copied in their entirety) to its local disk (cache). Applications on that computer are then free to read and write the data on the cache. If multiple computers are caching the same chunk of a file, a somewhat elaborate token mechanism is used to maintain consistency among their caches.

A typical interaction between various components of DFS is shown in Figure 7.8, where the number represents steps:

Step 1: At first, the application issues a file request call to the cache manager in its computer;

Step 2: If the requested file is located in the local cache, the request is served using the local copy of the file. Otherwise, the cache manager locates the fileset location server through the CDS server (cell directory service, see Section 7.1.1);

Step 3: The location of the file server that stores the requested file is found through the fileset location server;

Step 4: Finally, the cache manager calls the file server and the file data is accessed.

Figure 7.8: Interactions between DFS components 7.2 The DCE/RPC

In an application developed using DCE/RPC, a user accesses a distributed application program by interacting with a client program and the client program interacts with a server program (probably through the underlying structure) to perform the user’s tasks. Usually a client program may have direct access to network brokers and server support tools, but may have no direct access to the underlying basic heterogeneous interconnect. A dashed line is used to mark the interaction between client programs and the basic heterogeneous interconnect.

The server programs are designed to perform specific functions and they can be located in any of the hosts of a computer network. Similar to a client program, a server program usually has direct access to network brokers and server support tools, but may have no direct access to the underlying basic heterogeneous interconnect.

The network brokers are used for locating server locations. At the beginning of a server program’s execution, the server usually registers itself with location brokers.

A client program then uses the location brokers to locate a server that it needs to communicate with. By using these location brokers, it is possible that server locations are transparent to user (client) programs.

The server support tools provide some facilities for simplifying distributed application programming and the heterogeneous interconnect provides the basic interconnection between heterogeneous computing systems.