Designing a distributed system

Distributed design using RPC starts with the design of a modular program. It is wise (as in any system) to define the interfaces between the modules before writing each module.

Design Rules

In order that, in the final version, the modules can run on different machines, various rules must be followed:

Control is not passed between modules except as a procedure call
No data is to be passed between modules except explicitly In fact, mechanisms exist to have implicitly passed data (such as FORTRAN COMMON blocks) transferred as well. See the "PRAGMA external_marshalling" for techniques for having information passed implicitly along with the parameters to procedures.
It is better, for efficency, to make a few calls to a remote module rather than lots of calls transfering a little data each time.
Also for efficiency reasons, it is a bad idea to pass large arrays unnecessarily.

The calling conventions used for remote procedures may be selected to be either FORTRAN, C, Pascal or PILS compatible, when the system is generated.

Basically the RPC system can be easily used with most high level languages. There are some limitations imposed on data types: variant records ("unions" in C) are not handled by the compiler, for instance. You can handle them using the "External Marshalling" (q.v.) feature. FORTRAN and PILS have their own inherent limitations on data types if used. If pointers are passed from one machine to another, they may either be passed as integers, so that they retain their value but not their usefulness, or data structure to which they point can be transferred automatically, in which case they retain their meaning but not their literal value. Linked records may be passed so long as they are not recursive. (See the full list of supported data types).

Component parts

Some of the code necessary to connect the local and remote parts of the programs are already written, and are contained in a run&hyphen.time library. This includes an interface to the various communications systems used.

The remaining parts are the "stub" modules. These are generated specially for each application by an RPC compiler (RPCC). On the calling machine, there is a stub module which emulates the called procedure, and on the called machine there is a stub module which emulates the calling program.

For ease of handling, related procedures are grouped into units called "packages" . The package is the unit of compilation of stub modules, and a unit of addressing in the run&hyphen.time system. For example, a graphics package might contain all the procedures for graphics handling. For each package, the designer must write a definition file, described below.

For each package, any module which calls the procedures is referred to as a "client" , and the module which is called is referred to as a "server" .

(diagram ommitted: The software components of a remote call.)