Remote Procedure Call (RPC)

What is Remote Procedure Call (RPC)?

A Remote Procedure Call (RPC) is a software communication protocol that one program uses to request a service from another program located on a different computer and network, without having to understand the network's details. Specifically, RPC is used to call other processes on remote systems as if the process were a local system. A procedure call is also sometimes known as a function call or a subroutine call.

RPC acts like a low-level transport protocol for carrying data packets between communicating programs. It does this using a client-server model. The requesting program is called a client, while the service-providing program is called the server. Like a local procedure call, an RPC is a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or threads that share the same address space enables multiple RPCs to be performed concurrently.

Interface definition language (IDL) -- the specification language used to describe a software component's application programming interface (API) -- is commonly used in Remote Procedure Call software. In this case, IDL provides a bridge between the machines at either end of the link that might be using different operating systems (OSes) and computer languages. This means that RPC is usable on operating systems such as Windows, Unix and macOS.

What does RPC do?

RPC is commonly used to build and interact with distributed systems. RPC enables a program to call a subroutine on a different computer without it knowing it's remote. Even though RPC acts like a transport protocol, it's actually an inter-process communications procedure.

When a program statement or instruction that uses the RPC framework is compiled into an executable program, a stub is included. A stub is a piece of code that's used to convert parameters that are passed between a client and a server. The stub acts as a representative of the remote procedure code. When the program is run and the procedure call is issued, the stub receives the request and forwards it to a client runtime program on the local computer. The first time the client stub is invoked, it contacts a name server to determine the transport address where the server resides.

The client runtime program knows how to address the remote computer and server application and sends the message across the network that requests the remote procedure. Similarly, the server includes a runtime program and stub that interfaces with the remote procedure itself. Response-request protocols are returned the same way.

How does RPC work?

When a remote procedure call is invoked, the calling environment is first suspended. Procedure parameters are then transferred across the network to the device where the procedure is planned to execute. Following this, the procedure begins executing in that environment.

When the procedure is complete, data is transferred back to the calling environment, where program execution continues -- as if it had returned from a normal procedure call.

The following steps occur during an RPC:

1. The client calls the client stub. The call is a local procedure call with parameters pushed onto the stack in the usual way.
2. The client stub packs the procedure parameters into a message and makes a system call to send the message. The packing of the procedure parameters is called marshaling.
3. The client's local OS sends the message from the client device to the remote server device.
4. The server OS's transport layer passes the incoming packets to the server stub.
5. The server stub unpacks the parameters -- called unmarshaling -- from the message.
6. When the server procedure is finished, it returns to the server stub, marshaling the return values in a message. The server stub then sends the message to the transport layer.
7. The transport layer sends the message to the client transport layer, which then returns the message to the client stub.
8. The client stub unmarshalls the return parameters and the execution returns to the caller.

RPC can also be modified to work effectively in other environments, such as in microservices.

Types of RPC

There are several RPC models and distributed computing implementations. One popular model and implementation is the Open Software Foundation's Distributed Computing Environment. The Institute of Electrical and Electronics Engineers defines RPC in its ISO Remote Procedure Call Specification, "ISO/IEC 11578:1996."

Examples of RPC configurations include the following:

• Synchronous. This is the standard method of RPC. The client makes a call and waits for a reply from the server.
• Nonblocking. The client makes a call, but instead of waiting for a reply, it continues with its own processing.
• Batch-mode. A client sends multiple nonblocking calls in a group.
• Broadcast. A client sends a message to multiple servers and then receives all the resulting replies.
• Callback. A client makes a nonblocking client-server call.

Alternative methods for client-server communication include message queueing, IBM's Advanced Program-to-Program Communication and Representational State Transfer (REST).

Pros and cons of RPC

RPC provides the following benefits to developers and application managers:

• Helps clients communicate with servers through the traditional use of procedure calls in different languages.
• Can be used in local and distributed environments.
• Supports process-oriented and thread-oriented models.
• Hides the internal message-passing mechanism from the user, providing abstraction.
• Omits many of the protocol layers to improve performance.

Though RPC boasts a wide range of benefits, users should also be aware of the following pitfalls:

• The client and server use different execution environments for their respective routines, and the use of resources is more complex. Consequently, RPC systems aren't always suited for transferring large amounts of data.
• RPC is vulnerable to failure because it involves a communication system, another machine and another process.
• RPC isn't as flexible as other APIs such as REST.

RPC vs. REST

REST is an architectural style for distributed systems, commonly used in software development for web services and systems that can easily communicate with one another. Systems, service interfaces and APIs that comply with REST are known as RESTful APIs.

REST and RPC protocols share similar qualities. For example, both protocols are used for communicating over a distributed system. However, they still have different underlying structures and use cases. While RPC enables remote call functions as if they were local, REST APIs enable users to perform data operations on remote servers.

REST must be stateless, but RPC systems can be stateful or stateless. REST also enables greater flexibility, as it can send data in multiple formats -- like JavaScript Object Notation or Extensible Markup Language -- in one API, while RPC uses a fixed data format.

RPCs are typically used to call remote functions to a server, while REST is commonly used to perform standard operations like creating, reading or deleting records on a server.

Although RPC and REST APIs have similar functions, they also have different use cases and design practices. Learn more about REST API design best practices.