A stub in distributed computing is a piece of code that converts parameters passed between client and server during a remote procedure call. The main idea of an RPC is to allow a local computer to remotely call procedures on a different computer. The client and server use different address spaces, so parameters used in a function call have to be converted, otherwise the values of those parameters could not be used, because pointers to parameters in one computer's memory would point to different data on the other computer. The client and server may also use different data representations, even for simple parameters. Stubs perform the conversion of the parameters, so a remote procedure call looks like a local function call for the remote computer. Stub libraries must be installed on both the client and server side. A client stub is responsible for conversion of parameters used in a function call and deconversion of results passed from the server after execution of the function. A server skeleton, the stub on the server side, is responsible for deconversion of parameters passed by the client and conversion of the results after the execution of the function. Stubs can be generated in one of two ways:
Manually: In this method, the RPC implementer provides a set of translation functions from which a user can construct his or her own stubs. This method is simple to implement and can handle very complex parameter types.
Automatically: This is the more commonly used method for stub generation. It uses an interface description language to define the interface between client and server. For example, an interface definition has information to indicate whether each argument is input, output or both; only input arguments need to be copied from client to server and only output elements need to be copied from server to client.
A server program that implements a procedure in an interface is said to export the interface and a client program that calls procedures from an interface is said to import the interface. When writing a distributed application, a programmer first writes an interface definition using the IDL, then programmers can write the client program that imports the interface and the server program that exports the interface. The interface definition is processed using an IDL compiler to generate components that can be combined with client and server programs, without making any changes to the existing compilers. In particular, from an interface for each procedure in the interface, the compiler generates the appropriate marshalling and unmarshalling operations in each stub procedure and a header file that supports the data types in the interface definition. The header file is included in the source files of both the client and server programs, the client stub procedures are compiled and linked with the client program, and the server stub procedures are compiled and linked with the server program. An IDL compiler can be designed to process interface definitions for use with different languages, enabling clients and servers written in different languages to communicate using remote procedure calls. To achieve the goal of semantics transparency, designers have made RPC look like LPC using the concept of stubs that hide the actual RPC implementation from the programs the interface to the underlying RPC system.
