Remote Procedure Call

Remote Procedure Call is exactly what it sounds like. A procedure with some piece of program on some processor (i.e. in another address space) is made available to other processes in some way, and may be called (invoked) exactly as if it were local to the callers process. The pioneers of the Remote Procedure Call idea are Birrell and Nelson[#BaNRPC##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>.

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:

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>):
  1. 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.
  2. The client program reaches a remote procedure call (i.e. it calls its 'stub').
  3. The stub code marshals the arguments, and uses the communications subsystem to send them to the appropriate server.
  4. 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.
  5. 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.
  6. 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.

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.