DCE/RPC Facility

The following components are provided by DCE to assist the development and execution of the RPC programs related to DCE:

Remote procedure call runtime library,

Network Interface Definition Language (NIDL) compiler, and Location Broker.

The RPC runtime library provides the system calls that enable a local program to execute procedures on remote hosts. The Location Broker then provides the information of remote (and local, of course) servers. The NIDL compiler is a tool for developing DCE applications.

7.2.1.1 DCE Application Development

The process of a typical DCE application development might be as follows. At first, the programmer uses the NIDL language to write an interface definition file which defines all of the remote service interfaces (procedures). The programmer then compiles this definition using the NIDL compiler. In general, there are four output files for an interface definition, where two of them are client stubs (one is called a client stub and the other a client switch. We will describe them more fully later), one is a server stub, and the last one is an include file for the use of both client and server programs. The programmer then builds the server program, which implements the remote interfaces described in the interface definition, and the client program, which makes use of the remote procedures and other application functions (as well as providing a user interface). The formats for the remote procedure calls in the client program are defined in the interface definition. Finally, the server program is linked with the server stub and the client program is linked with the client stubs.

Now the server program can run on a remote host and the client program running on a local host can execute the remote procedures in the same way as it requests local procedures.

The above process is for developing “non-replicated” client/server programs, that is, only one server is responsible for managing an object (eg, a database file). If we want to replicate a very important object in several locations, we need to develop

“replicated” servers to manage these replicated objects. As these replicated servers need to communicate with each other to maintain the consistency of the replicated objects, a replicated server will have the function of both a server and a client program. That is, a replicated server needs to be linked with stub files provided for both server and client programs. This will cause naming conflicts between stub

routines because the same procedure (service interface) names are defined in both server and client stub files.

The method used in DCE to solve this problem is to use two client stub files, one is called the client stub and the other the client switch [Kong 1990]. The client switch contains “public” procedure names (the same names defined in the interface definition file and can be referenced by client programs), while the client stub contains only “private” procedure names (these procedures have the same function as the public procedures) that are not visible outside the stub program.

To build an ordinary (non-replicated) client, both the client stub and client switch files are linked with the client program. An RPC call in the client program will then go to the client stub, the client switch, and then to the particular procedure. To build a replicated server, only the client stub (of course, the server stub as well) needs to be linked with the server program. An RPC call in the server program will then go to the client stub directly, and then to the particular procedure.

7.2.1.2 Location Broker

Note that we did not mention the Location Broker above. A small and specific application needn’t have recourse to the Location Broker because the client program knows where the remote services are located. The Location Broker is very useful in general, however. Usually, a server program must register all of its services with the Location Broker. The client program can then find the service through the Location Broker. After the client finds the location of the service, it then calls the service directly. This is called unbound (or allocated) calling. DCE also supports other calling semantics, such as bound-to-host and fully bound calls [Kong 1990].

There are two kinds of location brokers, one called the Global Location Broker (GLB) and the other called the Local Location Broker (LLB), respectively. The LLB provides the services information for its local host, and the GLB provides the services information for the whole network. When the difference between these location brokers is not important, we will use the term Location Broker (LB) to refer to them. There are some system calls provided by DCE to manage the location brokers. Because there may be many services registered in a Location Broker, a unique naming facility called the Universal Unique Identifier (UUID) is employed.

Each service has to be assigned a UUID before it is registered with the LB. These UUIDs are used by DCE to distinguish one service from another.

7.2.1.3 RPC Handle

In DCE, an object is an entity manipulated by well-defined operations. Each object is identified by an object UUID. On the other hand, the RPC runtime library is implemented on the basis of sockets. When a client makes a remote procedure call, requesting that a particular operation be performed on a particular object, the RPC runtime library needs some information about the object and server. This information is represented by an RPC handle. DCE provides several system calls to

create and manage handles. After a handle is bound to a server, the client can use this handle to access the server. An RPC handle can be in three states:

Unbound (or allocated).

Bound-to-host.

Bound-to-server (or fully bound).

If a client knows an object’s UUID (and, of course, its interface operations), but does not know its location, an unbound handle can be used. When the client uses this handle to make a remote procedure call to request a particular operation on the object, the runtime library broadcasts a message to all hosts on the local network.

Any host which supports the operation on the object may respond to the request.

The caller runtime library then accepts the first response as the one it requested.

After that, the handle becomes fully bound to that server.

If a client knows an object’s UUID and the host on which it is located, a bound-to-host handle can be used. When the client uses this handle to make a remote procedure call, the runtime library sends a message to the host’s Location Broker. If the requested interface is registered on the Location Broker, the proper server will get this message and respond to the client. Again, the handle becomes fully bound after this call.

If a client knows an object’s UUID, its host, and its server address, then a fully bound handle can be used. When the client uses this handle to make a remote procedure call, the runtime library sends a message directly to the socket address of the handle.

7.2.1.4 Concurrent Programming Support

In addition to the RPC runtime library, NIDL compiler, and Location Broker, the Apollo also provides a Concurrent Programming Support (CPS) software tool to support the execution of DCE. This tool consists of four classes of system calls:

Task programming calls that create and manage multitasking environments.

Eventcount system calls that create and manage eventcounts for synchronising programming events.

Mutex programming calls that provide applications with mutual exclusion, resource-sharing and synchronisation

Pfm programming calls that control signals, faults, and exceptions for faults.

A distributed program in DCE can be functionally divided into two parts: the server part and the client part. Each part can be located on any host in the network.

Usually, a server part manages an object, and a client part accesses the object by using the remote procedures provided by the server. An RPC-oriented program (in short, an RPC program) may consist of several servers and clients, and all these

parts of the program work together concurrently on the programmer’s task. A server or client can fork to several processes if necessary.

After a programmer compiles his interface definition with the NIDL compiler, the source code for the server and client stubs are generated, and their object files linked with the server and client programs respectively. When a remote procedure call is issued in the client program, it actually goes to the client stub, which then communicates with the server stub (if the server’s address is known). Then the procedure implementing the required service is called by the server stub, and the return data are transferred through the server and client stubs back to the client program. The RPC runtime library contains the routines, tables, and data that support the communication of remote procedure calls between server and client stubs.