Logo
RPC: Remote Procedure Call
Overview

RPC: Remote Procedure Call

Rachel Park Rachel Park
September 25, 2025
3 min read
dicl research rpc

RPC (Remote Procedure Call) is a communication method that allows programs to execute procedures on a remote server as if they were local function calls. It abstracts the complexities of network communication, enabling seamless interaction between distributed systems.

This is a form of inter-process communication (IPC) where a client sends a request to a server to execute a specific procedure and waits for the server to return the result.

Components of RPC

  1. Interface
    • Define what functions are available
  2. Marshalling & Serialization
    • Converting function arguments into a network message format. (ex: JSON, XML, Protocol Buffers)
    • Converting the response back into a usable format
  3. Transport
    • The underlying network channel: TCP/UDP sockets, HTTP/2, gRPC, etc
  4. Stubs
    • Client Stub: Acts as a proxy for the client, handling marshalling and sending requests.
    • Server Stub: Receives requests, unmarshals them, and invokes the actual procedure on the server.
Definition

Stub is piece of code that acts as a proxy for the real function.

  • On the client side, the stub pretends to be the actual function. It takes the args, serializes them, and sends them over the network. Then, it waits for the response, deserializes it, and returns it to the caller.
  • On the server side, the stub receives network requests, unpacks them, and calls the actual function.

You never call the networking directly; you call the stub, which handles all the network communication for you.

How RPC Works

RPC

  1. Client calls the remote procedure using a stub.
  2. The stub marshals the request and sends it over the network.
  3. The server receives the request, unmarshals it, and invokes the actual procedure.
  4. The server sends the response back to the client stub.
  5. The client stub unmarshals the response and returns it to the caller.

Why use RPC in distributed systems?

In distributed systems, RPC is used for various reasons:

  1. Abstraction of Network Complexities: RPC hides the underlying network complexities, allowing developers to focus on application logic.
  2. Scalability: Services can be split among multiple machines and scaled horizontally.
  3. Consistency of Communication: RPC enforces a consistent communication pattern across different services.
  4. High Performance: Modern RPC frameworks (like gRPC) use efficient binary serialization and multiplexing, reducing latency and improving throughput.

Synchronous vs. Asynchronous RPC

  • Synchronous RPC
    • Client blocks until the server responds.
    • Simple but can waste time waiting.
  • Asynchronous RPC
    • Client sends request, continues working, and later receives the response (via callback or future).
    • Useful for high-performance systems, e.g., parallel block transfers.

gRPC (Google Remote Procedure Call)

It is an open-source RPC framework developed by Google. Built on top of HTTP/2, it uses Protocol Buffers (protobuf) for efficient serialization. gRPC supports multiple programming languages and provides features like authentication, load balancing, and bidirectional streaming.

Limitations

  • Network Reliability: RPC relies on network communication, which can be unreliable. Network failures can lead to lost requests or responses.
  • Latency: Remote calls are inherently slower than local calls due to network overhead.
  • Complexity: Implementing and managing RPC systems can add complexity to the application architecture
  • Transparency Trade-offs: Because RPC aims to make remote calls appear like local ones, developers may overlook the differences in latency, failure modes, and error handling.