#1#].
Remote Procedure Call systems follow the Client Server model very
closely.
A server implements the procedure. A client calls it.
Usually, the distributed applications programmer starts by defining
some procedure or set of procedures in an <#414#> Interface Definition
language<#414#> (IDL).
The interface defines the procedures and their parameters together
with associated type information.The procedure is written to conform to this interface.
Then a number clients can be written to call this interface.
There are several levels of software necessary to support this system,
above the normal communications systems. These are illustrated in
#fnrpc#415>.
#figure416#
Figure: RPC Layers
The appropriate communications semantics vary between different RPC
systems, but are always request/response in pattern. Some systems
demand different levels of reliability, such as exactly once semantics,
others are at least once. Some systems limit the size or number or
types of procedure parameters; others have no practical limits.
The ;SPM_quot;Stubs;SPM_quot; at each end have three functions:
-
They mimic the missing code: The Client stub mimics
the procedure, and the Server Stub mimics a caller.
-
They <#422#> marshall<#422#> and <#423#> unmarshall<#423#> the arguments to a procedure. This means
that the Stub code must accumulate the arguments (typically
from the stack) and wrap them in an appropriate format to send over
the network.
-
The Server Stub must dispatch incoming calls to the appropriate
procedure when more than one is supported. In some systems, the server
may queue incoming calls, while in others, it may rely on the caller
to retry.
Different RPC systems allow concurrent threads of procedures to be
executing. The server stub is effectively executed in parallel to any
of the procedures, dispatching calls and replies as they happen and
not blocking.
The sequence of events for a typical remote procedure call is as
follows (see figure #fnrpcts#425>):
-
If this is the first call (to this instance of the server)
the client program locates the server (perhaps by making a call to a
well known server which provides the instance-to-location mapping
service). There are a number of other mechanisms possible here.
-
The client program reaches a remote procedure call (i.e. it calls its
'stub').
-
The stub code marshals the arguments, and uses the communications
subsystem to send them to the appropriate server.
-
The client program is then blocked from further execution, awaiting
a reply. Some systems permit the client to continue and collect the reply later.
This is called non-blocking RPC.
-
The server stub then performs the reverse processing,
calls the procedure as if it were the client. If the procedure has OUT
parameters or return values, these are then marshaled by the server
stub, transmitted back to the client and unmarshaled there.
-
The client program then continues as if an ordinary procedure call
had returned.
How does this relate to the Object Oriented approach outlined in
Chapter 1? The server is an instance of an Object, implementing some
class. The set of procedures are the implementation of the methods for
that class.
#figure428#
Figure: Time Sequence Diagram for A Remote Procedure Call
Some RPC systems are not restrictive about which processes are clients
or servers. Many allow a client to be a server and vice versa
at different points in their execution. Some allow RPC calls to a client that
is awaiting a reply. This is sometimes restricted to calls back from
the server that has been called. This is on the basis that this ;SPM_quot;callback;SPM_quot;
is essentially mutual recursion, and a fully transparent RPC system should
allow all normal procedural patterns.