By Loyd Charles
Since application software does not contain any communication code, it is independent of
The particular communications hardware and protocols used
The operating system used
The calling sequence needed to use the underlying communications software
This means that application software can be written before these choices are made. Because it takes care of any data reformatting needed, RPC makes byte ordering and differences in data representation (real number formats, etc) transparent.
The following introduces and describes the parts involved in a remote procedure call. As shown in the figure below, the calling program is known as the client, and subroutine it calls is known as the server.
When the client calls the server, the RPC system takes care of the following things:
Taking all the parameters which are passed to the subroutine and transferring them to the remote machine;
Having the subroutine executed on the remote machine
Transferring back all the parameters, which are returned to the calling routine.
The most common method of doing this is by the use of stub modules. The client program is linked to a client stub module. This is a subroutine, which looks from the outside in every aspect like the remote subroutine. On the inside, it is almost empty; all it does is takes the values of the parameters which are passed to it, then put that in a message. This is called marshalling.
The client stub then uses a routine in the RPC Run-Time System (RTS) to send the message off and waits for a reply message. When the reply arrives, the stub unmarshals the parameters that were returned in the reply message, putting their values into the variables of the calling program. The client stub then returns to the calling program just like a normal subroutine.
The server stub is located on the remote machine. It is called by the RPC run-time system when the message arrives from the client. Server stub performs the operations complementary to those of the client stub. Unmarshals the parameters passed to the subroutine, calling the subroutine, and marshalling the return parameters.
All communication details were handled by the RPC run-time system, so the stubs contain only the code, which is specific to the application involved in the process. Each stub handles a specific set of procedures known as a package.
In order to produce stub modules, the following things are needed
The names of the procedures in the package
The number of parameters which they take
The data type of each parameter
The direction in which each parameter is transferred.
The following constraints required by the use of RPC are mostly those imposed by the rules of good software design.
The parameters must be the only means of communication between modules. This is not likely to arise with a new application, but must be checked if an existing application is to be split into a distributed one.
Pointers may not be passed between modules. In general, a pointer will not have any significance except on the machine on which it originated. If a package works by returning pointers to large data structures, then it must be modified before it can be used remotely. In some cases, a pointer is passed when in fact the significant thing is the data to which it points, not the actual value of the pointer. In this case, the RPC system can copy the data, and make a new pointer on the remote side.
Large arrays of data should not be needlessly passed around. If a procedure is only going to reference a single element, that element should be passed explicitly, for efficiency.
Basic steps involved for most RPC implementations are as follows.
Write the package definition file to define the software interface.
Run the RPC compiler to produce the stub code.
Link together the client modules (program, stub, RTS) to make the client module.
Link the server modules (a standard main program, the server stub, the server routines themselves, and the RTS)
In some situations, the application code has to be modified to add a few lines to initialize the run-time system and the stubs. This depends on whether the local operating system is sufficiently sophisticated to do this automatically. Apart from that initializations code, the package definition is the only software, which needs to be written to make an application run remotely.
When the client program is run, the client stub must be connected, via the RTS to the server stub. Normally, the client stub will not be aware of the physical address of the server. Therefore, the RTS has to take the logical name of the service required, and use it to find a suitable server. Some other systems use central name servers to store this information; others rely on the address being compiled into the stubs or provided by the user program.
In this section we discuss a few examples of applications in which Remote Procedure Call has been used
Remote software task management Load/Start/Control
Remote FASTBUS access
Submission of operating system commands from embedded microprocessors
It is important to realize that the client-server relationship only applies to one call. In fact a program, which is a server from one point of view may also be a client of another facility. A client may call back routines within the client it is serving.
Remote Procedure Call is a technique, which is widely used today, with the excess of distributed processing power. Tools are available for programmers to use in developing RPC applications over a wide variety of platforms, including Windows, Macintosh, 26 variants of UNIX, OS/2, NetWare, and VMS.
RPC implementations are nominally incompatible with other RPC implementations, although some are compatible. Using a single implementation of a RPC in a system will most likely result in a dependence on the RPC vendor for maintenance support and future enhancements. This could have a highly negative impact on a system's flexibility, maintainability, portability, and interoperability.
Because there is no single standard for implementing an RPC, different features may be offered by individual RPC implementations. Features that may affect the design and cost of a RPC-based application include the following:
support of synchronous and/or asynchronous processing
support of different networking protocols
support for different file systems
whether the RPC mechanism can be obtained individually, or only bundled with a server operating system
Because of the complexity of the synchronous mechanism of RPC and the proprietary and unique nature of RPC implementations, training is essential even for the experienced programmer.
B.J. Nelson, "Remote Procedure Call", XEROX PARC CSL-81-9, May 1981
Sun Microsystems, External Data Representation Reference Manual. Sun Microsystems, Jan.J1985.
Power Programming with RPC, John Bloomer, O’Reilly & Associates.
http://www12.w3.org/History/1992/nfs_dxcern_mirror/rpc/doc/Introduction/HowItWorks.html