A stub is a piece of code that translates parameters sent between the client and server during a remote procedure call in distributed computing. An RPC’s main purpose is to allow a local computer (client) to call procedures on another computer remotely (server) because the client and server utilize distinct address spaces. That is the reason parameters used in a function (procedure) call must be translated; otherwise, the values of those parameters would be useless because pointers to parameters in one computer memory would point to different data on the other computer.
In most cases, stub libraries are installed on both the client and the server. Client stubs transform (marshalling) parameters used in function calls and then reconvert the result returned by the server when the function is completed. On the other side, client arguments are reconverted by server stubs, and results are converted back after function execution.
Stub Generation:
Stubs can be created in two different ways:
- Manual Generation of Stub: In the manual generation of stubs, the RPC implementer provides a collection of translation functions from which a user can create their own stubs using this way. This method is easy to use and can handle a wide range of argument types.
- Automatic Generation of Stub: In the automatic generation of stubs, client and server interfaces are defined using Interface Definition Language (IDL). An interface specification, for example, contains information indicating whether each argument is input, output, or both; only input arguments must be passed from client to server, while only output elements must be copied from server to client. This is the most popular way of generating stubs.
- Import an Interface: A client program that calls procedures from an interface is said to import the interface.
- Export an Interface: A server program that implements a procedure in an interface is said to export the interface.
- Interface Definition Language (IDL): When building a distributed application, a programmer first creates an interface definition in IDL, then writes the client program that imports the interface and the server program that exports it. An IDL compiler is used to process the interface definition and generate components that may be coupled with client and server programs without requiring any changes to existing compilers. The compiler generates the required marshalling and unmarshalling operations in each stub procedure and a header file that supports the data types in the interface specification from an interface for each procedure in the interface. Both the client and server programs contain the header file, and the client stub procedures are compiled and linked with the client program, while the server stub procedures are compiled and linked with the server program. An IDL compiler can be programmed to interpret interface definitions for a variety of languages, allowing clients and servers written in different languages to communicate via Remote Procedure Calls (RPC).
To achieve semantic transparency, designers used the concept of stubs to make RPC (Remote Procedure Call) look like LPC (Local Procedure Call). Stubs mask the real RPC implementation from the applications that interface with the underlying RPC system.