How to Use RPC

The steps necessary to create an application system using RPC are outlined below. The more sophisticated techniques available are not discussed here, but are described in [7,8]

Designing the system

The constraints imposed by the use of RPC are mostly those imposed by the rules of good software design. In addition, there will be extra constraints specific to the implementation of RPC in use. Our particular implementation imposes restrictions on the data types which the RPC compiler can handle, and, under certain circumstances, on the total number of bytes transferred in any call.

Generating the software

The basic steps involved, for most RPC implementations, are as follows. In some cases, the application code has to be modified to add a few lines to initialise the run-time system and the stubs. This depends on whether the local operating system is suficiently sophisticated to do this automatically. Apart from that initialisation 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 (this would be too constraining in a real system). Therefore, the RTS has to take the logical name of the service required, and use it to find a suitable server.

In our current implementation, local tables on each machine are normally used to give the addresses of the remote servers. Some other systems [9, 10] use central name servers to store this information; others rely on the address being compiled into the stubs or provided by the user program.

Experience shows that many methods of address resolution must be available. A full discussion of this is, however, outside the scope of this introductory paper.

(Back) (To Summary) (More >> )