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.
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.
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:
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.
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.
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.
Remote access to remote computer systems has always been a part of well-organized networks. Administrators can manage individual users as well as work on the move since it’s possible to access company data with a remote connection. One of the first protocols developed specifically for this purpose was Telnet. Read more here.
In the days of mainframe computers and the first smaller networks, terminals were a crucial building block for sharing hardware and software resources. It is no coincidence that terminal servers – the central administrative entity of such networks – are in demand decades later, now that applications are to be made available to multiple users.
Many companies have complex server infrastructures that are often managed by several administrators. Not only do the operating systems, but also software packages have to be installed, configured and maintained on a continuous basis. SaltStack allows all resources to be managed from a central computer. We show you what SaltStack can do and what makes it so special.
If the RPC server is unavailable, Windows will display the error code 0x800706BA. This means the network communication between the client and the server has been interrupted. The problem occurs fairly regularly in Windows 10. In this guide, we explain what the RPC server error message means and how you can fix it yourself without any expert network knowledge.
Remote procedure calls have long played a critical role in inter-machine communication when it comes to client-server architectures. For several years now, gRPC has proven to be a worthy successor. This framework uses powerful strategies to fulfill the increased demands of global networking and end-to-end digitization.
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
View packages
