Remote Procedure Call (RPC)

What is Remote Procedure Call (RPC)?

RPC is a technique that allows a program to execute a procedure (a block of code) in remote machine look like calling a local function. The goal is to hide the details of networking (marshalling, transport, retries, etc.) so application developers can focus on business logic.

What is a Remote Procedure?

A remote procedure is a block of code or function located in a different address space or on a remote system that can be invoked and executed by a program or process residing elsewhere, often referred to as the client.

Components of RPC

1 Client Stub

A local representation of the remote function.

When your application calls:

user = getUser(42)

Here we are actually calling the client stub.

This stub hides the complexity of:

• serialization
• networking
• waiting for server response
• deserialization

Responsibilities:

• Accept parameters from caller
• Serialize (marshal) them into binary/JSON/XML
• Send the request to the RPC runtime
• Wait for the server's response
• Deserialize the return value
• Return it to the caller as if it were a normal function

2 Server Stub (Skelton Server)

A server-side proxy that receives requests from clients.

Responsibilities:

• Receive the serialized request
• Deserialize it to actual function arguments
• Call the real function/method on the server
• Take the real return value
• Serialize it back into protocol format
• Send it back to the client

3 RPC Runtime/ Transport Layer

This is the communication engine, responsible for moving requests/responses between client and server.

Responsibilities:

• Manage connections (TCP, HTTP, QUIC, etc.)
• Send requests to correct server
• Handle timeouts, retries
• Deliver responses in order
• Handle network errors, partial failures
• Optional: manage load balancing

The runtime may handle:

• message framing
• multiplexing streams
• connection pooling
• compression

In older RPC systems:

• Java RMI uses JRMP (Java Remote Method Protocol)
• XML-RPC / JSON-RPC uses HTTP
• Thrift and gRPC use their own optimized transports

4 Serialization and Deserialization Layer (Marshalling / Unmarshalling)

RPC must convert structured data into bytes.

Serialization responsibilities:

• Convert arguments -> binary or text
• Make it platform-neutral (e.g., different endian formats, CPU architectures)

Deserialization responsibilities:

• Convert bytes -> native data bytes
• Validate format
• Handle unknown fields gracefully

Common serialization options in RPC:

• JSON (JSON-RPC)
• XML (XML-RPC)
• Protobuf (gRPC, Thrift optional)
• Apache Avro
• MessagePack
• Custom binary formats

5 Interface Definition / Contract Definition

RPC generally requires a contract to define:

• function name
• input parameters
• output parameters
• data structures
• exceptions returned

Examples:

• IDL (Interface Definition Language) in Thrift, CORBA, gRPC
• WSDL in SOAP
• Interfaces in Java RMI

Why Needed:

To generate client/server stubs and ensure cross-language compatibility.

6 Binder / Service Registry (Optional but Common)

Used to locate the remote service.

In classical RPC:

• Java RMI Registry
• CORBA naming service

In modern microservices:

• Consul
• Eureka
• Etcd
• Kubernetes service discovery

Purpose:

• Map service name -> server addres
• Allow clients to find the service

Example:

UserService → 10.2.4.7:50051

7 Protocol Definition Layer

Every RPC system defines:

• How messages are structured (headers + body)
• How errors are represented
• How metadata is attached
• How versioning works
• How streaming works (if supported)

Examples:

• gRPC protocol spec
• Thrift protocol spec
• JSON-RPC spec
• XML-RPC spec

8 Error Handling & Exceptions

RPC must handle:

• Network timeouts
• Server-side exceptions
• Serialization errors
• Version mismatch
• Connection drops

RPC frameworks define:

• errors codes
• retry rules
• deadline/timeout handling
• cancelation protocols

Example in gRPC:

UNAVAILABLE – retry
INVALID_ARGUMENT – client error
INTERNAL – server crash

9 Security Layer (Optional Depending on RPC)

RPC may support:

• TLS encryption
• Mutual TLS (client + server certificates)
• Authentication tokens
• Request signing
• ACLs

Modern RPC systems like gRPC support:

• mTLS
• JWT
• OAuth2-based access

Legacy RPC often had:

• weak or no security

10 Middleware / Interceptors (Modern RPC Feature)

Used to add these behaviors:

• logging
• rate limiting
• metrics
• tracing
• authentication

This is popular in:

• gRPC interceptors
• Thrift middleware
• JSON-RPC middleware patterns

How All Components Fit Together (Flow)

1. Client Side:
   1. Caller invokes function
   2. Client stub takes over
   3. Stub serializes args
   4. Runtime sends requests over network
2. Server Side:
   1. Server runtime receives request
   2. Server stub deserializes it
   3. Actual method is executed
   4. Response is serialized
   5. Sent back to client
   6. Client stub deserializes
   7. Return value given to caller

To the caller -> looks like a normal function.