In computing, I know of 4 contexts where the word stub has a well-established meaning:
- Web Sites: A stub is a web page in progress, i.e., a page which provides minimal information and is intended for later development. For instance, a Wikipedia stub is a short article in need of expansion.
- Coding: During development, we sometimes use a “skeleton” function (or procedure, or method) to simulate some intended (but not yet implemented) functionality. For instance, the function may stand in for a complex algorithm to be developed later, or simulate a procedure running on a remote host. Such placeholder function is called a stub function. Stub functions come in handy for quick prototyping and testing.
- Distributed Systems: In distributed systems, a service interface defines the services available to programs. These services are distributed among several networked machines. In distributed systems, a program in machine A may request a service by calling a procedure. However, the procedure may be offered by a remote host, say, machine B. Remote Procedure Calls (RPC) are a paradigm of distributed systems aimed at abstracting the communication between hosts in a network. The goal of RPCs is to hide the details of the remote call. The remote call should look like a local one, i.e., the program in machine A would invoke the procedure in machine B as it would invoke a procedure locally. Under the hood, though, it’s obvious that we have to transmit information from the client (caller) to the server (callee), and in the other direction. Now, how to hide the fact that we are calling a procedure located in other machine? This is the basic idea of RPCs:
- In the address space of the client, we represent the server procedure by means of a local procedure called client stub. Likewise, the server is also linked to a server stub, which will receive the message from the client stub.
- When machine A requests a service which is provided by machine B, a call is made to the client stub (which has the same name as the procedure in B). As the client stub lies in the same address space of the caller, the invocation is handled locally, and the program sees this invocation as a local one. However, the client stub marshalls the received parameters and sends them, throught the network, to the server stub. In turn, the server stub unmarshalls the parameters and perform the call to the real procedure in the server. When the server procedure finishes, results or exception data travels back, from server to client. By the way, marshalling is the process of taking a collection of data items (such as the procedure name and its arguments) and grouping them according to some predefined representation, suitable for transmission over the network. The server should know and conform to this representation in order to unmarshall the received data and recover the transmitted information.
Albeit conceptually simple, there are some interesting (nasty) problems for implementing RPCs, such as passing pointer arguments (remember that client and server have different address spaces).
- Computer Networking: A stub network is a network or part of network with only one communication path to external networks (non-local hosts). For instance, if we connect to our Internet Service Provider using only one router, our local network is a stub network with respect to our provider.
There is other related context for stubs: in electronics, we identify Stub sections, which are mostly used for impedance matching in transmission lines. But I’m not too familiar with this “stub” meaning.