Remote procedure call (RPC) – efficient com­mu­ni­ca­tion in client-server ar­chi­tec­tures

A remote procedure call is a central in­stru­ment for realizing op­er­a­tional and work-sharing struc­tures in networks and client-server ar­chi­tec­tures. You’ll find out below how the co­op­er­a­tion 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 com­mu­ni­ca­tion, i.e. the exchange of in­for­ma­tion between system processes. In 1984, computer sci­en­tists Andrew Birrell and Bruce Nelson defined RPC as a syn­chro­nous mechanism "which transfers control flow and data as a procedure call between two address spaces over a nar­row­band network." By exceeding an address space, processes can be started on a remote computer within the network and external instances can be op­er­a­tional­ly included in cal­cu­la­tion and data pro­cess­ing op­er­a­tions. The com­mu­ni­ca­tion process via RPC includes the transfer of pa­ra­me­ters and the return of a function value. In practice, it does not stop at one call, since several requests are processed in parallel.

Ul­ti­mate­ly, RPC aims to align pro­cess­ing levels: Ideally, it should make no dif­fer­ence to pro­gram­mers and users which procedure call is used. In principle, remote calls should be just as easy to implement as local procedure calls (trans­paren­cy principle). RPC calls stand for order-oriented, bidi­rec­tion­al com­mu­ni­ca­tion in networks and client-server ar­chi­tec­tures. They com­ple­ment the purely message-based com­mu­ni­ca­tion, 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 dis­trib­uted ap­pli­ca­tions 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 ap­pli­ca­tion are computer clusters (high-avail­abil­i­ty clusters), de­cen­tral­ized peer-to-peer networks, as well as blockchains (e.g. cryp­tocur­ren­cies), which often also work with RPC tech­nol­o­gy.

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 es­tab­lished network con­nec­tions use a system service referred to as a "remote procedure call."

The Network File System (NFS) developed by Sun Mi­crosys­tems plays an important role in the Unix and Linux world. It uses RPC calls between clients and servers to partially or com­plete­ly 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 in­di­vid­ual files on a remote computer as if they were on their own computer. Defined file per­mis­sions then regulate the read and write rights. The Network In­for­ma­tion System (NIS) also uses RPC and thereby manages UNIX and Linux systems centrally.

The RPC protocol handles inter-process com­mu­ni­ca­tion reliably and requires rel­a­tive­ly short pro­cess­ing times to do so. The pro­gram­ming of com­mu­ni­ca­tion processes of remote computers is made con­sid­er­ably 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 con­sis­tent mod­u­lar­iza­tion. Processes can be out­sourced, thereby relieving the burden on in­di­vid­ual computers. Networks and dis­trib­uted systems can work more ef­fi­cient­ly due to the dis­tri­b­u­tion of tasks by using spe­cial­ized platforms for special tasks (e.g. database servers). Here, the main par­tic­i­pants can be networked worldwide. Other ad­van­tages are the excellent scal­a­bil­i­ty of the realized client-server ar­chi­tec­tures as well as the pos­si­bil­i­ty of being able to work in a cloud-based manner.

The dis­ad­van­tages of RPC tech­nol­o­gy include the fact that there is no uniform standard for RPC calls. The various – mostly company-specific – im­ple­men­ta­tions (e.g. ONC-RPC from Sun) are usually not com­pat­i­ble with each other. In addition, the transfer and com­mu­ni­ca­tion levels of RPC-based systems entail certain speed re­duc­tions, which is not the case with purely local procedure calls. Since the client and server use different execution en­vi­ron­ments for their re­spec­tive routines, the use of resources (e.g. files) is also more complex. RPC systems are therefore not so well suited for trans­fer­ring large amounts of data.

By dividing it up into different pro­cess­ing instances, the error rate is increased. Messages can get lost in com­mu­ni­ca­tion (network errors, failure of a node in the network), and delays and in­ter­rup­tions may arise. Timing issues, redundant double ex­e­cu­tions (e.g. of process calls), or un­de­sir­able asyn­chronies in machine com­mu­ni­ca­tion are among the resulting com­pli­ca­tions. With syn­chro­nous 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 sus­cep­ti­bil­i­ty to errors can have a far-reaching impact, par­tic­u­lar­ly in large ar­chi­tec­tures with a high degree of task dis­tri­b­u­tion.

Due to possible sources of error, special RPC error semantics must also be taken into account, which makes pro­gram­ming rel­a­tive­ly complex. Pro­gram­mers and system de­vel­op­ers have to deal with the security aspects that dis­trib­uted systems and their com­mu­ni­ca­tion via RPC and UDP/IP or TCP/IP entail (network security, hacking, denial-of-service attacks etc.).