Glossary of RPC Terms

Foreign Function Interface

Many programming environments allow a project to incorporate object code from many different languages, at the least allowing the incorporation of objects produced from C source. Languages like C and C++ typically require that the system linker make the final links to objects from other languages, while others provide more active mediation. LISP and Prolog are languages which typically require this: the loosely typed nature of the languages require that special type checking be inserted in the LISP or Prolog program to allow C functions to be called. The foreign function interface provides a mechanism for the programmer to define the details of the interface needed from a system like LISP to call C functions.

Interface Definition Language

For an interface to be defined consistently on each end of the RPC connection, there needs to be a way to specify the parameters and return types in a way that is independent of the implementation languages used for the applications and servers. This is generally done using a language designed to specify module interfaces in some language-neutral manner. Automated tools are used to translate the specifications into definitions in each language which the interface will be used from, as well as the implementation language. A widely used interface definition language is IDL, developed by the Object Management Group.

Marshalling

This is the process of packing data into a flattened form which can be re-structured later, and is used for transmitting structured information across a network or placing it in a persistent store. The format of the data used by a marshalling procedure is defined carefully to allow complete reconstruction. An example is the specification for the External Data Representation from Sun.

Reliability

The concept of reliability refers to the network transport layer. A transport protocol is said to be reliable if there is some guarantee that a packet will be received so long as delivery is possible. Explicit acknowledgement of receipt is not required of the recipient, but may be useful in some applications. A protocol is unreliable if no such guarantee is made. This reduces overhead in the protocol, but explicit or implicit acknowledgement of receipt is usually appropriate. RPC systems often use an unreliable transport protocol since much can be inferred about the connection based on the continued exchange of calls and returns.

Stub

Using a remote procedure call mechanism transparently requires an actual procedure call be made to activate the RPC system. This call is made to a stub function generated from the interface definition. The stub provides marshalling of the arguments and calls the RPC runtime support to make the actual call. On return from the runtime, the stub re-structures the marshalled result and returns to the caller. It is typically generated from a specification written in an interface definition language.

Transport Protocol

This is the network protocol that simply moves packets across the network. Examples include the Internet Protocol (IP) and Ethernet (ETH).

Go Back to the Operating Systems page.

Go Back to the RPC page.