Remote procedure call (RPC) – efficient communication in client-server architectures
A remote procedure call is a central instrument for realizing 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.
What is a remote procedure call (RPC)?
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).
The specialty of RPC calls is communication between different computers, but they can also contribute to communication between different processes within a connected system.
Client stub meets server stub – this is how RPC works
RPC calls always run according to a certain pattern: A client contacts, for example, a central database server when searching for a spare part. The remote server then checks the database and sends the result back to the client. The latter processes the data received and shows, for example, a list with the inventory data in administration software.
Special instances are involved in the implementation of a remote procedure call on the sender and receiver side, which are called “stubs.” The client stub acts on the client-side as a proxy for the remote server procedure. The server stub is the server-side proxy of the calling client code. The stubs operationally simulate a functional local unit by concealing the “distance” of the code on the respective other side. At the same time, they act as procedure interfaces. The typical sequence of an RPC call is characterized by the following steps:
- The client code retrieves a stub procedure (local client stub).
- The client stub generates a transmittable message from the transferred parameters of the procedure call that adheres to the RPC protocol. Serialization takes place during the transfer, in which structured data is transferred in a sequential form. This translation process is also known as marshaling.
- The client stub then contacts the communication system of the local computer, which often uses TCP/IP or UDP/IP for the subsequent message exchange between client and server.
- After the sent message arrives at the recipient, the server stub executes the so-called de- or unmarshaling by unpacking the parameters contained in the message (using the RPC protocol as a basis).
- The server stub transfers the decoded parameters and therefore provides the local call of a server procedure.
- The resulting function value is communicated to the server stub.
- Now, the process takes place in the opposite direction: Generation of a transmittable message pursuant to the RPC protocol, message exchange between server and client, then the return value is transported to the waiting client code. The application is continued on the source computer.
Cloud computing and computer clusters – areas of application for RPC calls
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), decentralized 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.
What are the advantages of RPC?
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 modularization. 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 specialized platforms for special tasks (e.g. database servers). Here, the main participants can be networked worldwide. Other advantages are the excellent scalability of the realized client-server architectures as well as the possibility of being able to work in a cloud-based manner.
What are the disadvantages of RPC?
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.).
Some problems that result from a general synchronicity of client and server can be solved with asynchronous RPC concepts. With this method, the client doesn’t have to wait for a response from the server. It may continue the program flow and perform other operations after a call. The server's response is then processed by the client at a later time. However, the special programming of asynchronous RPC calls is very complex and time-consuming.