Remote Procedure Call (RPC) is a message-passing programming technology developed by Sun Microsystems and extended by the Open Software Foundation (OSF) that allows an application to execute procedures and interact with services on a remote computer on the network.
Remote procedure calls (RPCs) are the preferred method of enabling client/server processing on the Microsoft Windows Server platforms, an Microsoft’s implementation of RPC functionality is compatible with that of other implementations, such as those for the IBM AIX, HP-UX, and Sun Solaris operating systems.
Remote Procedure Call (RPC) vs Local Procedure Call (LPC)
You use RPCs to pass messages between components of a distributed application that are located on different computers on a network. While local procedure calls (LPCs) provide a mechanism for enabling different parts of an application located on a single computer to communicate with each other, RPCs involve communication between different computers. RPCs actually use a variety of other interprocess communication (IPC) mechanisms such as named pipes, mailslots, Windows Sockets, and NetBIOS to establish connections between the RPC client and RPC server components on different machines.
How Remote Procedure Call works
A Remote Procedure Call is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. The figure above shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications.
A remote procedure is uniquely identified by program number, version number and procedure number. The program number identifies a group of related remote procedures, each of which has a unique procedure number. A program may consist of one or more versions. Each version consists of a collection of procedures which are available to be called remotely. Version numbers enable multiple versions of an RPC protocol to be available simultaneously. Each version contains a number of procedures that can be called remotely. Each procedure has a procedure number.
Layers of Remote Procedure Calls
The RPC interface can be seen as being divided into three layers.
The Highest Layer: The highest layer is totally transparent to the operating system, machine and network upon which is run. It’s probably best to think of this level as a way of using RPC, rather than as a part of RPC proper. Programmers who write RPC routines should (almost) always make this layer available to others by way of a simple C front end that entirely hides the networking.
To illustrate, at this level a program can simply make a call to rnusers(), a C routine which returns the number of users on a remote machine. The user is not explicitly aware of using RPC – they simply call a procedure, just as they would call malloc().
The Middle Layer: The middle layer is really “RPC proper.” Here, the user doesn’t need to consider details about sockets, the UNIX system, or other low-level implementation mechanisms. They simply make remote procedure calls to routines on other machines. The selling point here is simplicity. It’s this layer that allows RPC to pass the “hello world” test – simple things should be simple. The middle-layer routines are used for most applications.
RPC calls are made with the system routines registerrpc() callrpc() and svc_run(). The first two of these are the most fundamental: registerrpc() obtains a unique system-wide procedure-identification number, and callrpc() actually executes a remote procedure call. At the middle level, a call to rnusers() is implemented by way of these two routines.
The middle layer is unfortunately rarely used in serious programming due to its inflexibility (simplicity). It does not allow timeout specifications or the choice of transport. It allows no UNIX process control or flexibility in case of errors. It doesn’t support multiple kinds of call authentication. The programmer rarely needs all these kinds of control, but one or two of them is often necessary.
The Lowest Layer: The lowest layer does allow these details to be controlled by the programmer, and for that reason, it is often necessary. Programs written at this level are also most efficient, but this is rarely a real issue – since RPC clients and servers rarely generate heavy network loads.
Although this document only discusses the interface to C, remote procedure calls can be made from any language. Even though this document discusses RPC when it is used to communicate between processes on different machines, it works just as well for communication between different processes on the same machine.
