Techtribe· Techtribe team · Tutorials · 4 min read
Understanding Remote Procedure Call (RPC) in Distributed Systems
Learn the foundational principles of Remote Procedure Call (RPC), its characteristics, and how it differs from IPC in networked environments
Table of Contents
Remote Procedure Calls (RPC)
RPCs come into play when we need processes on different machines/systems, connected through a network, to communicate with each other.
So, think of a scenario where a process present on one system wants to communicate with another process physically located on a different system, and these **systems are connected by some type of network.In this case, we need RPC (remote procedure calls).
RPC is a protocol that allows us to establish a communication between processes on different machines without needing to understand the network details.
Characteristics of RPC:
It is similar in many aspects to IPC (internal procedure calls - calls between processes within the same machine).
However, because we are dealing with an environment where processes are running on separate systems, we need to use a message-based communication scheme to establish the remote service. We need to use this type of communication because, as we are dealing with different machines, they do not share a memory region, so we have to use this communication scheme, known as a message passing system schema.
Source: https://www.geeksforgeeks.org/message-passing-in-distributed-system/
Differences between RPC and IPC:
Unlike IPC, the messages exchanged in RPC communication are very well-structured and are not just data packets. In IPC, the messages are data packets, but since RPC is navigating through a network, the messages sent need to be very well-structured.
Each message (a process on one system communicating with another process on another system) is addressed to an RPC daemon (a daemon is a program that is always listening and waiting for some input/request), which will listen on a specific port on a remote system, and each of them (messages/functions) will have an identifier of the function to execute and the parameters to pass to that function. So, we can think of this “process” as a function, and we need to pass the parameters of this function; this function will then be executed in another process (function) on another machine.
The function (process) will be executed as requested (there may be schedulers, or it may be executed immediately), and any output is sent back to the requester (the machine that sent the process/request - the first process or client) in a separate message, so the message returned to the client will be sent in a separate message using the message passing system.
RPC Semantics
The semantics of RPCs allow a client to invoke a process on a remote host as if it were invoking a local process:
The RPC system hides any details that will allow the communication to happen. So, what happens is that the RPC will provide only a skeleton of the communication from the client.
Generally, a separate skeleton exists for each separate remote process.
When a client invokes (wants to obtain) a remote process from another system, the RPC system calls the appropriate communication skeleton, passing the correct parameters to the remote process. This communication skeleton will locate the port on the server and pass (marshal) the parameters. So, what happens is that on the server there will be different types of services/processes available, and each service will be identified by the port number, meaning when the communication skeleton passes the parameters, it will combine these parameters in a specific way.
Marshaling the parameters involves packaging the parameters in a way that they can be transmitted over a network. So, we receive all the necessary parameters to execute a function (the function is on the server side - it is the remote process we will invoke/call/request), and since these parameters will navigate through some type of network, they need to be packaged in a way that they can be transmitted over a network. Thus, parameter marshaling is packaging parameters in a way that they can be transmitted over a network.
The skeleton (on the client) will transmit the message to the server using the message passing system schema.
On the server side, there must be a similar skeleton, which will receive the message and invoke/call the correct process on the server side.
So, there must be a communication skeleton on both the client and server side, to correctly read the message we sent. Remember that in the message we sent there are parameters in it that must be sent to the function/process to be executed and called correctly. So, the parameters will call the correct function/process.
If necessary, the result of the message processing should return these values. In this case, the values will be passed back to the client using the same communication technique.
