Remote procedure call (RPC) – efficient communication in client-server architectures

A remote procedure call is a central instrument for realising operational and work-sharing structures in networks and client-server architectures. You’ll find out below how the cooperation between spatially-separated computers works via an RPC call, at which levels it takes place, and where RPC concepts are used today.

The term remote procedure call denotes a concept that regulates inter-process communication, i.e. the exchange of information between system processes. In 1984, computer scientists Andrew Birrell and Bruce Nelson defined RPC as a synchronous mechanism "which transfers control flow and data as a procedure call between two address spaces over a narrowband network". By exceeding an address space, processes can be started on a remote computer within the network and external instances can be operationally included in calculation and data processing operations. The communication process via RPC includes the transfer of parameters and the return of a function value. In practice, it does not stop at one call, since several requests are processed in parallel.

Ultimately, RPC aims to align processing levels: Ideally, it should make no difference to programmers and users which procedure call is used. In principle, remote calls should be just as easy to implement as local procedure calls (transparency principle). RPC calls stand for order-oriented, bidirectional communication in networks and client-server architectures. They complement the purely message-based communication, which follows the paradigm of input and output (use of I/O functions).

RPC calls are used in many areas today. They serve as a building block for web services (e.g. in the form of the XML-RPC protocol for remote function calls via HTTP) and enable distributed applications in which different computing machines share existing resources and arising tasks. These include, among others, cloud computing services, banking and booking systems in the travel industry, as well as databases. Other areas of application are computer clusters (high-availability clusters), decentralised peer-to-peer networks, as well as blockchains (e.g. cryptocurrencies), which often also work with RPC technology.

Remote procedure calls are also essential for today's operating systems. With their help, Windows can, for example, perform routine tasks. For example, the fax service, the printer queue, or established network connections use a system service referred to as a "remote procedure call."

The Network File System (NFS) developed by Sun Microsystems plays an important role in the Unix and Linux world. It uses RPC calls between clients and servers to partially or completely mount the file system of a remote computer on a local computer, i.e. to make it available. Through the procedure, the user can work with individual files on a remote computer as if they were on their own computer. Defined file permissions then regulate the read and write rights. The Network Information System (NIS) also uses RPC and thereby manages UNIX and Linux systems centrally.

The RPC protocol handles inter-process communication reliably and requires relatively short processing times to do so. The programming of communication processes of remote computers is made considerably easier as, for example, there is no need to take the complex details of the network used into account. In addition, the RPC concept allows a consistent modularisation. Processes can be outsourced, thereby relieving the burden on individual computers. Networks and distributed systems can work more efficiently due to the distribution of tasks by using specialised platforms for special tasks (e.g. database servers). Here, the main participants can be networked worldwide. Other advantages are the excellent scalability of the realised client-server architectures as well as the possibility of being able to work in a cloud-based manner.

The disadvantages of RPC technology include the fact that there is no uniform standard for RPC calls. The various – mostly company-specific – implementations (e.g. ONC-RPC from Sun) are usually not compatible with each other. In addition, the transfer and communication levels of RPC-based systems entail certain speed reductions, which is not the case with purely local procedure calls. Since the client and server use different execution environments for their respective routines, the use of resources (e.g. files) is also more complex. RPC systems are therefore not so well suited for transferring large amounts of data.

By dividing it up into different processing instances, the error rate is increased. Messages can get lost in communication (network errors, failure of a node in the network), and delays and interruptions may arise. Timing issues, redundant double executions (e.g. of process calls), or undesirable asynchronies in machine communication are among the resulting complications. With synchronous RPC, a server problem (e.g. a crash) can affect the client if the calling process waits in vain for the return value. On the other hand, the server is slowed down if the client’s response is delayed or does not arrive at all. This susceptibility to errors can have a far-reaching impact, particularly in large architectures with a high degree of task distribution.

Due to possible sources of error, special RPC error semantics must also be taken into account, which makes programming relatively complex. Programmers and system developers have to deal with the security aspects that distributed systems and their communication via RPC and UDP/IP or TCP/IP entail (network security, hacking, denial-of-service attacks etc.).