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

A remote procedure call is a central in­stru­ment for realising op­er­a­tion­al and work-sharing struc­tures in networks and client-server ar­chi­tec­tures. You’ll find out below how the co­oper­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­nic­a­tion, i.e. the exchange of in­form­a­tion between system processes. In 1984, computer sci­ent­ists Andrew Birrell and Bruce Nelson defined RPC as a syn­chron­ous 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­tion­ally included in cal­cu­la­tion and data pro­cessing op­er­a­tions. The com­mu­nic­a­tion process via RPC includes the transfer of para­met­ers 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­mately, RPC aims to align pro­cessing 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­par­ency principle). RPC calls stand for order-oriented, bi­d­irec­tion­al com­mu­nic­a­tion in networks and client-server ar­chi­tec­tures. They com­ple­ment the purely message-based com­mu­nic­a­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­plic­a­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­plic­a­tion are computer clusters (high-avail­ab­il­ity clusters), de­cent­ral­ised peer-to-peer networks, as well as block­chains (e.g. crypto­cur­ren­cies), which often also work with RPC tech­no­logy.

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­pletely 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­vidu­al 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­form­a­tion System (NIS) also uses RPC and thereby manages UNIX and Linux systems centrally.

The RPC protocol handles inter-process com­mu­nic­a­tion reliably and requires re­l­at­ively short pro­cessing times to do so. The pro­gram­ming of com­mu­nic­a­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­sist­ent mod­u­lar­isa­tion. Processes can be out­sourced, thereby relieving the burden on in­di­vidu­al computers. Networks and dis­trib­uted systems can work more ef­fi­ciently due to the dis­tri­bu­tion of tasks by using spe­cial­ised platforms for special tasks (e.g. database servers). Here, the main par­ti­cipants can be networked worldwide. Other ad­vant­ages are the excellent scalab­il­ity of the realised client-server ar­chi­tec­tures as well as the pos­sib­il­ity of being able to work in a cloud-based manner.

The dis­ad­vant­ages of RPC tech­no­logy include the fact that there is no uniform standard for RPC calls. The various – mostly company-specific – im­ple­ment­a­tions (e.g. ONC-RPC from Sun) are usually not com­pat­ible with each other. In addition, the transfer and com­mu­nic­a­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­vir­on­ments for their re­spect­ive 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­cessing instances, the error rate is increased. Messages can get lost in com­mu­nic­a­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­desir­able asyn­chron­ies in machine com­mu­nic­a­tion are among the resulting com­plic­a­tions. With syn­chron­ous 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­cept­ib­il­ity to errors can have a far-reaching impact, par­tic­u­larly in large ar­chi­tec­tures with a high degree of task dis­tri­bu­tion.

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