Remote Procedure Call

Remote Procedure Call

Interprocess communication (IPC) is a set of programming interfaces that allow a programmer to coordinate activities among different program processes that can run concurrently in an operating system. This allows a program to handle many user requests at the same time.

https://en.wikipedia.org/wiki/Remote_procedure_call

In computer science, a remote procedure call (RPC) is aninter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.^[1] That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question usesobject-oriented principles, RPC is called remote invocation orremote method invocation (RMI).

Many different (often incompatible) technologies have been used to implement the concept.

Sequence of events during an RPC

1. The client calls the client stub. The call is a local procedure call, with parameters pushed on to the stack in the normal way.
2. The client stub packs the parameters into a message and makes a system call to send the message. Packing the parameters is calledmarshalling.
3. The client's local operating system sends the message from the client machine to the server machine.
4. The local operating system on the server machine passes the incoming packets to the server stub.
5. The server stub unpacks the parameters from the message. Unpacking the parameters is calledunmarshalling.
6. Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction.

A very general mechanism for client-server applications is provided by RPC, theRemote Procedure Call package. RPC was developed by SunMicrsystems, and is a collection of tools and library functions.Important applications built on top of RPC are NFS, the NetworkFilesystem, and NIS, the Network Information System, both of which willbe introduced in later chapters.

An RPC server consists of a collection of procedures that client maycall by sending an RPC request to the server, along with the procedure parameters. The server will invoke the indicated procedure on behalf ofthe client, handing back the return value, if there is any. In order tobe machine-independent, all data exchanged between client and server isconverted to a so-calledExternal Data Representation format (XDR)by the sender, and converted back to the machine-local representation bythe receiver.

Sometimes, improvements to an RPC application introduce incompatiblechanges in the procedure call interface. Of course, simply changing theserver would crash all application that still expect the originalbehavior. Therefore, RPC programs have version numbers assigned tothem, usually starting with-1, and with each new version of the RPCinterface this counter will be bumped. Often, a server may offer severalversions simultaneously; clients then indicate by the version number intheir requests which implementation of the service they want to use.

The network communication between RPC servers and clients is somewhatpeculiar. An RPC server offers one or more collections of procedures;each set is being called aprogram, and is uniquely identifiedby a program number. A list mapping service names to program numbersis usually kept in /etc/rpc, an excerpt of which is reproduced belowin figure-.

Figure: A sample /etc/rpc file.

In TCP/IP networks, the authors of RPC were faced with the problem ofmapping program numbers to generic network services. Theychose to have each server provide both a TCP and a UDP port for eachprogram and each version. Generally, RPC applications will use UDP whensending data, and only fall back to TCP when the data to be transferreddoesn't fit into a single UDP datagram.

Of course, client programs have to have a way to find out which porta program number maps to. Using a configuration file for this would betoo inflexible; since RPC applications don't use reserved ports, there'sno guarantee that a port originally meant to be used by our databaseapplication hasn't been taken by some other process. Therefore, RPCapplications pick any port they can get, and register it with the so-calledportmapper daemon. The latter acts as a service broker for allRPC servers running on its machine: a client that wishes to contacta service with a given program number will first query the portmapperon the server's host which returns the TCP and UDP port numbers theservice can be reached at.

This method has the particular drawback that it introduces a single pointof failure, much like the inetd daemon does for the standardBerkeley services. However, this case is even a little worse, becausewhen the portmapper dies, all RPC port information is lost; thisusually means you have to restart all RPC servers manually, or rebootthe entire machine.

On , the portmapper is called rpc.portmap and residesin /usr/sbin. Other than making sure it is started formrc.inet2, the portmapper doesn't require any configuration work.