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.

The parameters must be the only means of communication between modules. FORTRAN common blocks will of course not work between two different machines. 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. In C language, this is the case with all parameters which are returned from the routine.
One should not needlessly pass large arrays of data. If a procedure is only going to reference a single element, that element should be passed explicitly, for efficiency.

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.

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 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 >> )