Remote Procedure Call (RPC) is a protocol or architecture which is used to run programs and code located in another system in a computer network. Normally processes can call each other in the same local systems. RPC is used to call other processes on the remote systems like a local system.
RPC is Distributed
RPC architecture is distributed where we can run single applications in multiple systems in a synchronized way. We can use all of the system resources of the multiple systems as a single big system.
RPC is Client-Server Based
RPC uses the client-server model. The requesting program is called a client and the service-providing program or system is called a server. Client and server are interchangeable according to the requesting and responding system.
In order to call a procedure or function on the remote system program, we need to provide some data like function name, parameters, program data, etc. In order to provide these data, a stub is included in the compiled code as representative of the remote procedure code. When Stub will interface as a remote procedure call and manage the transmission of the data, function, parameters, etc to the remote procedure.
As a client-server architecture RPC is a request and reply protocol that can be named ping-pong. This is not an obligation for RCP applications but most of the RPC applications send a single request/procedure call and waits for the response. Without getting a response they do not send a second request/procedure call.
UDP and TCP Transport
RPC can operate over UDP or TCP without any restriction. But in general, UDP is preferred by the RCP applications which provide faster and simples implementation. RCP/RCP s slower but provides reliable transmission if we need stability or the network is not stable as expected.
Standardized Data Representation
RPC marshals the data to make a procedure call with a function name, parameter, and data. The marshaled data will be structured as an eXternal Data Representation (XDR) protocol which is documented in RFC 1832. The XDR format supports data types like integers, floating-point numbers, strings, and different types to enhance data transmission seamlessly.
RPC also supports authentication of the calling applications from one system to the target function on the other system. Authentication can run in several models. As an example, NFS operations authentication is done with the Linux user and group IDs for file server permission and authorization.
RPC Work Flow
In this part, we will examine a standard RPC request for different components on the client and server system.
- Client programs or applications call the client function.
- Client function call redirected to the Client stab which is responsible to make the remote procedure call.
- Client stub will use ready to use RPC Runtime as an interface to the server
- Client RPC Runtime will redirect the message to the server RPC runtime.
- Server RPC Runtime will popup the client message to the Server Stub.
- Server Stub will call the Server function in order to execute the given method, parameters, and data requested by the client.
- After the Server Function execution ended the function result will be returned to the Server Stub
- Server Stub will redirect to the RPC Runtime as a response
- Server RPC Runtime will transmission result to the Client RPC Runtime
- RPC Runtime will popup to the Client Stub
- Client Stub will push the method call result to the Client Function.
As a popular protocol the RPC provides some advantages over other related protocols.
- Remote procedure calls can use process-oriented and thread oriented models
- RPC provides an abstraction for running remote methods and procedures with simplicity
- Code development efforts will be minimum with RPC
- RPC can be used in a distributed manner as well as local systems
- RPC performance is good according to other alternative protocols
Here we will list some disadvantages of the RPC.
- Some RPC implementations are standard
- There is an increase in the cost of a remote procedure call