Remote Procedure Call

The Remote Procedure Call (RPC) protocol is designed for network programming, allowing a program to make a subroutine call on a remote machine. In other words, it sends a carefully crafted message that let a remote machine provides the service.

Key features of RPC:

• Request-reply

  RPC is a request-reply protocol having typical the “ping-pong” behavior of such protocol. Though it is not fundamental to RPC’s design, most program will design blocking function awaiting the reply.

• UDP or TCP transport

  RPC/UDP is a connection-less, stateless protocol. RPC/TCP is a reliable, stateful protocol.

• Standardized data representation

  RPC uses the eXternal Data Representation (XDR) protocol to standardize the format of integers, floating point numbers, and strings.

• Authentication

  RPC provides support for authenticating the calling program on one machine to the target subroutine on the author. Authentication can operate in several different modes. For example, NFS’s authentication relies on UNIX user and group IDs to the file server for permission checking.

Both TCP and UDP rely on specific port numbers to perform service rendezvous. RPC divorce services from being tied to a given port number by using a specific service called PORTMAP or RPCBIND. The service itself uses port 111, and other RPC services can register themselves using an RPC call to port 111. The portmapper offers other RPC calls to permit service lookup. Such architecture requires the portmapper must be the first RPC program started, and must remain in constant operation.

Each remote procedure call has two sides: an active client side that makes the call to a server, which sends back a reply.

RPC uses a typical client-server design. A remote machine implements one or more remote procedures that clients can hit via exposed endpoints. The terms client and server only apply to a particular transaction; a particular host or program could operate in both roles at different times.

Few important ways in which RPC differ from local procedure calls:

• Error handling

  Failure of the remote server or network must be handled when using RPC

• Global variables and side-effects

  Since the server does not have access to the client’s address space, hidden arguments cannot be passed as global variables or returned as side effects.

• Performance

  Remote procedures usually operate one or more orders of magnitude slower than local procedure calls.

• Authentication

  Since RPC can be transported over unsecured networks, authentication may be necessary. Authentication prevents one entity from masquerading as some other entity.

Reference:

• https://www.freesoft.org/CIE/RFC/1831/index.htm
• https://www.freesoft.org/CIE/Topics/86.htm