TCP/IP Tutorial and Technical Overview - IBM Redbooks

An application written using DCE RPCs has a client portion, which usually issues
RPC requests, and a server portion, which receives RPC requests, processes
them, and returns the results to the client. RPCs have three main components:
► The Interface Definition Language (IDL) and its associated compiler. From
the specification file, it generates the header file, the client stub, and the
server stub. This allows an application to issue a Remote Procedure Call in
the same manner as it issues a local procedure call.
► The network data representation, which defines the format for passing data,
such as input and output parameters. This ensures that the bit-ordering and
platform-specific data representation can be converted properly after it arrives
at the target system. This process of preparing data for an RPC call is called
marshalling.
► The runtime library, which shields the application from the details of network
communications between client and server nodes.
The application programmer can choose to use multiple threads when making
RPC calls. This is because an RPC is synchronous; that is, when an RPC call is
made, the thread that issued the call is blocked from further processing until a
response is received.
Remote Procedure Calls can be used to build applications that make use of other
DCE facilities, such as the Cell Directory Service (CDS) and the security service.
The CDS can be used to find servers or to advertise a server's address for client
access. The security service might be used to make authenticated RPCs that
enable various levels of data integrity and encryption using the commercial data
masking facility (CDMF), data encryption standard (DES), and other functions
such as authorization.
13.3.4 Distributed Time Service
Keeping the clocks on different hosts synchronized is a difficult task because the
hardware clocks do not typically run at the same rates. This presents problems
for distributed applications that depend on the ordering of events that happen
during their execution. For example, let us say that a programmer is compiling
some code on a workstation and some files are also located on a server. If the
workstation and the server do not have their time synchronized, it is possible that
the compiler might not process a file, because the date is older than an existing
one on the server. In reality, the file is newer, but the clock on the workstation is
slow. As a result, the compiled code will not reflect the latest source code
changes. This problem becomes more acute in a large cell where servers are
distributed across multiple time zones.
The DCE Distributed Time Service (DTS) provides standard software
mechanisms to synchronize clocks on the different hosts in a distributed
Chapter 13. Remote execution and distributed computing 507