Operating System - Remote Procedure Call (RPC)



A Remote Procedure Call (RPC) is an interprocess communication technique that is used for lient-server based applications. It is also known as a subroutine call or a function call. Read this chapter to know more about Remote Procedure Calls and how they work.

What Does a Remote Procedure Call Do?

A client has a request message that the RPC translates and sends to the server. This request may be a procedure or a function call to a remote server. When the server receives the request, it sends the required response back to the client. The client is blocked while the server is processing the call and only resumes its execution after the server is finished.

RPC allows a program to call a function that is located on another machine and it works as if the function is running locally on the same system. In RPC, all network communications such as data transfer (sending request and receiving responses) and protocol handling etc., are hidden from the user. That is why, RPC is a remote call the behaves like a local function call.

RPC is used in distributed systems and client-server communication, where one system/computer needs to run a function that exists on another computer which is connected through a network. The main purpose of RPC is to hide all information of network communication and make it easier for programs that exist in two different systems to communicate with each other.

Working Process of RPC

The following diagram shows an overview of how an RPC works −

Working Process of RPC

The sequence of events in a remote procedure call is given below −

  • Client Calls the Client Stub − The client stub (local procedure) is called by the client.
  • Client Stub Packs (Marshalling) the Parameters − The client stub makes a system call to send the message to the server and puts the parameters in the message.
  • Send to Server − The message is sent from the client to the server by the client’s operating system.
  • Server Receives Message − The message is passed to the server stub by the server operating system.
  • Stub Unpacks Parameters − The parameters are removed from the message by the server stub.
  • Server Runs the Procedure − Then, the server procedure is called by the server stub.

Note: A stub is a small piece of code that acts as an interface between the client and the server and handles all communication between them.

Types of RPC

There are multiple types of RPCs. In this section, let's learn in brief about some of the common types of RPCs.

Synchronous RPC

Also known as blocking RPC, here the client sends a request to the server and waits until the server responds. The client is blocked and cannot continue its task until the RPC completes.

Asynchronous RPC

The client sends a request to the server but does not wait for the server response and continues its task. It is fast and the client is free to continue its task. It is also known as non-blocking RPC.

Callback RPC

Callback RPC is a type of Remote Procedure Call where the communication works in both directions. The client first sends a request to the server, and after completing the task, the server makes another RPC call back to the client. Through this callback, the server notifies the client about results or updates without waiting for the client to check it.

Callback RPC is commonly used in real-time notifications, and applications where the server needs to send information back to the client.

Batch RPC

Batch RPC is a type of Remote Procedure Call where multiple RPC requests are grouped together and sent to the server in a single message. Instead of sending small requests one by one, the client sends them as a batch. It reduces the network overhead.

Batch RPC is useful when several remote calls need to be executed at the same time and the client does not immediately require the responses of its requests.

Broadcast RPC

Broadcast RPC is a type of Remote Procedure Call where a client sends a single request to all servers in the network at the same time. Instead of sending the request to one specific server, the request call is broadcasted, and every server that receives the request can decide whether to respond or ignore the client request.

Broadcast RPC is useful when the client does not know which server has the required information. For example, locating the resource in distributed systems. As, it broadcast the request, this type of RPC can create a lot of network traffic because the client request is sent to all servers at the same time.

Components of a Remote Procedure Call

Let's take a look at the major components of an RPC −

  • Client − The client is the program that requests for a service. It makes a function call, without having information that the function runs on another system.
  • Server − The server is the program that receives and executes the client function call.
  • Client Stub − The client stub works as an interface between the client and the server. It receives the function call from the client and converts that call into a request message and sends it to the server.
  • Server Stub − The server stub receives the request from the client and separate the required data from that request and calls the server function which execute the requested service. After completed the task, the response is sent back to the client.
  • RPC Runtime − It helps in managing the communication between the client and server.
  • Network − The network connects the client and server machines. It helps in transfer the request and response messages between client and server machine.
  • Binding − It helps the client to find the exact server name to determine the network address of the server that provides the requested service.

Issues in Using RPC

Local procedure calls fail only under extreme circumstances, whereas RPC can fail, or can be duplicated and executed more than once. So, it may cause network errors.

With standard procedure calls, some binding takes place during link, load and execution time so that a procedure call name is replaced by the memory address of the procedure call. RPC too needs a similar kind of binding of the client and server port. But how does a client know the port numbers on the server? This situation arises because no system has full information about the other systems as they do not share memory.

Now let's understand how to resolve these issues −

The operating system must ensure that messages are processed exactly once. Most local procedure calls have the "exactly once" functionality. But, in RPCs, it is more difficult to implement because messages visit over a network, so it can be lost or repeated.

The binding information may be predetermined, in the form of fixed port addresses. At compile time, an RPC call has a fixed port number asosciated with it. Once a program is compiled, the server cannot change the port number of the requested service. But this solution is not flexible because the port numbers have to be fixed and if we want to change the port number, we cannot do it.

Binding can be done dynamically by a rendezvous mechanism. In this, an operating system provides a rendezvous (matchmaker) daemon on a fixed RPC port. A client that sends a message containing the name of the RPC to the rendezvous daemon, requesting the port address of the RPC it needs to execute. The port number is returned and the RPC calls can be sent to that port until the process terminates or server crashes. Here, we do not need to fix the port numbers because the matchmaker will always find the port number of particular procedures name and it will return it to the client.

Pros and Cons of Using RPCs

RPCs offer the following advantages −

  • RPCs support process-oriented and thread-oriented models.
  • The internal message passing mechanism of RPC is hidden from the user.
  • The effort to rewrite and redevelop the code is minimum in RPCs.
  • RPCs can be used in distributed environment as well as the local environment.
  • Many of the protocol layers are omitted by RPC to improve performance.

Some of the disadvantages of RPC are as follows −

  • RPC is a concept that can be implemented in different ways. It is not a standard.
  • There is no flexibility in RPC for hardware architecture. It is only interaction based.

RPC vs REST

RPC and REST are two different ways to make computer programs interact with each other on the Internet. The following table highlights how an RPC is different from REST −

RPC (Remote Procedure Call) REST (Representational State Transfer)
RPC allows a program to call a function that is located on another machine and it works as if the function is running locally on the same system. REST allows a client to interact with data on server by using HTTP requests.
RPC is used to execute procedures or functions on a remote system. REST is used to access, create, update and delete the resources.
In RPC, communication done through function or method calls which is define by the server. In REST, communication done through URL and HTTP methods such as GET, POST, PUT and DELETE.
RPC, can use different data formats such as JSON, XML and binary formats. REST also use different data formats like JSON, XML to represent the data which sent between client and server.
RPC, can be used on different communication protocols such as TCP, HTTP, UDP, HTTP etc. But REST, can be only used on HTTP protocol.
RPC is used in internal systems and high-performance applications. REST is widely used for web APIs, mobile applications, and public services.

Conclusion

A Remote Procedure Call provides a way for programs running on different systems to communicate with each other over a network. It allows a program to call a function on a remote machine. It hides the procedure of network communication from the users. RPCs are widely used in distributed systems.

Advertisements