Introduction to Remote Procedure Call

By Loyd Charles

What is Remote Procedure Call?

Remote procedure call is method for building distributed systems. It allows a program on one machine to call a subroutine on another machine without knowing that the subroutine is on a different machine. Remote procedure call is not a protocol like TCP/IP, but it’s a method for using existing transport protocols. It’s translucent so, other programs won’t know about its usage.

Since application software does not contain any communication code, it is independent of

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.

How does it work?

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:

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

Designing the system

The following constraints required by the use of RPC are mostly those imposed by the rules of good software design.

Generating the Code for RPC

Basic steps involved for most RPC implementations are as follows.

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.

Running the System: Naming and Addressing

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.

Example Applications that use RPC

In this section we discuss a few examples of applications in which Remote Procedure Call has been used

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:

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.


  1. B.J. Nelson, "Remote Procedure Call", XEROX PARC CSL-81-9, May 1981

  2. Sun Microsystems, External Data Representation Reference Manual. Sun Microsystems, Jan.J1985.

  3. Power Programming with RPC, John Bloomer, O’Reilly & Associates.