1. Why RPC Exists (Start from First Principles)
Distributed systems consist of multiple computers connected through a network. These machines cooperate to provide services, share resources, and perform computations.
At the lowest level, communication between machines happens through:
Messages
Network protocols
Sockets
Data serialization
Connection management
Suppose a client wants a server to perform a simple operation such as:
add(5, 10);
Without any abstraction, the programmer would need to:
Create a network connection
Format the request message
Convert data into network format
Send the message
Wait for the reply
Receive the response
Parse the result
Handle network failures
Even simple operations require substantial communication code.
The Fundamental Problem
Programmers should focus on business logic, not low-level networking details.
The Solution
RPC introduces an abstraction that allows a program to invoke a procedure on a remote machine almost as if it were a normal local function call.
2. What is Remote Procedure Call (RPC)?
Definition
Remote Procedure Call (RPC) is a communication mechanism that enables a program to execute a procedure located on another machine as if it were a local procedure call.
Instead of manually sending and receiving messages, the programmer simply calls a function.
Core Idea
Local Function Call Abstraction
↓
Network Communication
↓
Remote Procedure Execution
Example
Instead of writing:
Create Connection
Send Request
Wait for Reply
Parse Response
The programmer writes:
result = add(5, 10);
Even though:
add()
is actually executing on a remote server.
Key Insight
RPC hides the complexity of network communication behind a familiar procedure-call interface.
3. Why RPC is Necessary
Before RPC became popular, distributed applications relied heavily on explicit message passing.
This created several challenges:
Communication Complexity
Developers had to manually handle:
Socket programming
Protocol implementation
Request formatting
Response processing
Code Duplication
Every application repeatedly implemented similar networking logic.
Error-Prone Development
Network code introduces:
Connection failures
Message corruption
Timeout handling
Retry logic
Lack of Standardization
Different applications used different communication methods.
How RPC Solves These Problems
RPC simplifies distributed programming by:
Providing transparent remote invocation
Automating communication details
Standardizing interaction between distributed components
Reducing development complexity
Key Insight
RPC allows developers to think in terms of functions and procedures rather than messages and sockets.
4. Basic RPC Architecture
A typical RPC system consists of several components working together.
1. Client
The program requesting the service.
2. Client Stub
Acts as a local representative of the remote procedure.
3. RPC Runtime
Handles communication between machines.
4. Server Stub
Receives requests and prepares them for execution.
5. Server Procedure
The actual function that performs the requested operation.
Overall Architecture
Client
↓
Client Stub
↓
RPC Runtime
↓
Network
↓
RPC Runtime
↓
Server Stub
↓
Server Procedure
Key Insight
The client never directly communicates with the server procedure. Communication always passes through stubs and runtime components.
5. RPC Execution Flow (Most Important Section)
Consider the following remote procedure call:
multiply(4, 5);
Although it appears to be a simple function call, many operations occur internally.
Step 1: Client Invokes Procedure
The application calls:
multiply(4, 5);
The client believes it is invoking a local function.
Step 2: Client Stub Receives Call
Instead of contacting the server directly, the call is intercepted by the client stub.
The stub acts as a local proxy.
Step 3: Marshalling
The client stub converts parameters into a format suitable for transmission over the network.
Example:
(4, 5)
becomes
Serialized Network Message
This process is called:
Marshalling
Step 4: Request Transmission
The RPC runtime sends the serialized request to the server.
Step 5: Server Stub Receives Request
The server-side stub receives the incoming message.
Step 6: Unmarshalling
The server stub reconstructs the original parameters.
Example:
Serialized Message
↓
(4,5)
This process is called:
Unmarshalling
Step 7: Procedure Execution
The actual server procedure executes.
multiply(4,5)
Result:
20
Step 8: Response Transmission
The result follows the reverse path:
Marshall result
Send response
Unmarshall result
Return to client
Step 9: Client Continues
The client receives:
20
and execution proceeds normally.
Key Insight
The programmer sees a function call, but internally RPC performs serialization, communication, execution, and response handling.
6. Marshalling and Unmarshalling
These are among the most important concepts in RPC.
What is Marshalling?
Marshalling is the process of converting procedure parameters into a portable format suitable for network transmission.
Example:
(4, 5)
becomes
Binary Message
JSON
Protocol Buffer
XML
depending on the RPC framework.
What is Unmarshalling?
Unmarshalling is the reverse process.
The received message is converted back into usable parameters.
Network Message
↓
Original Data
Why Marshalling is Necessary
Different systems may have:
Different architectures
Different byte orders
Different data representations
Marshalling ensures interoperability.
Key Insight
Marshalling enables communication between heterogeneous systems.
7. Role of Stubs in RPC
Stubs are critical components that hide networking details from applications.
Client Stub
Acts as a local representative of the remote procedure.
Responsibilities
Accept procedure call
Marshall parameters
Send request
Receive response
Return result
Server Stub
Acts as an intermediary between the network and the server procedure.
Responsibilities
Receive request
Unmarshall parameters
Invoke procedure
Marshall response
Send result
Key Insight
Stubs make remote procedures appear like local procedures. They hide nearly all communication complexity from the programmer.
8. Transparency in RPC
One of the primary goals of RPC is transparency.
What is Transparency?
Transparency means that remote calls should appear similar to local procedure calls.
Ideally, the programmer should not need to know:
Network protocols
Message formats
Serialization mechanisms
Communication details
Why Complete Transparency is Impossible
A remote call fundamentally differs from a local call.
Remote communication involves:
Network latency
Packet loss
Server failures
Timeouts
Local function calls do not face these issues.
Key Insight
RPC simplifies distributed programming but cannot completely hide the realities of distributed systems.
9. Parameter Passing in RPC
Parameter passing becomes more complicated when memory is not shared.
Pass-by-Value
Data is copied and transmitted.
Example:
add(5,10)
Values are serialized and sent.
This works well in distributed systems.
Pass-by-Reference
Problem:
Remote machines do not share memory.
A memory address on one machine is meaningless on another.
Therefore most RPC systems primarily use:
Pass-by-Value Semantics
Key Insight
Shared-memory concepts do not naturally extend across network boundaries.
10. RPC Communication Models
10.1 Synchronous RPC
The client waits until the server responds.
Characteristics
Blocking
Simpler programming model
Easier reasoning
Flow
Send Request
↓
Wait
↓
Receive Response
10.2 Asynchronous RPC
The client continues execution immediately after sending the request.
Characteristics
Non-blocking
Better concurrency
Higher scalability
Flow
Send Request
↓
Continue Working
↓
Receive Response Later
Key Insight
Asynchronous RPC improves throughput but introduces additional complexity.
11. RPC Failures and Challenges
Distributed systems introduce many failure scenarios.
Client Failure
Client crashes after sending request.
Server Failure
Server crashes before completing execution.
Network Failure
Messages may be:
Lost
Delayed
Corrupted
Duplicate Requests
Retries may accidentally execute operations multiple times.
Key Insight
Unlike local procedure calls, remote calls must deal with partial failures.
12. RPC Execution Semantics
RPC systems define guarantees regarding procedure execution.
At Least Once
Procedure executes one or more times.
Duplicate execution is possible.
At Most Once
Procedure executes either:
Once
Not at all
Never more than once.
Exactly Once
Ideal guarantee.
Extremely difficult to implement in distributed systems.
Key Insight
Most practical systems approximate exactly-once behavior but cannot guarantee it under all failure conditions.
13. RPC vs Message Passing
| Feature | RPC | Message Passing |
|---|---|---|
| Abstraction Level | High | Low |
| Ease of Programming | Easy | Complex |
| Transparency | Better | Manual |
| Flexibility | Lower | Higher |
| Developer Effort | Less | More |
Key Insight
RPC trades flexibility for simplicity and developer productivity.
14. Modern RPC Frameworks
gRPC
Developed by Google.
Uses:
Protocol Buffers
HTTP/2
Provides:
High performance
Language independence
Streaming support
JSON-RPC
Uses JSON serialization.
Simple and lightweight.
XML-RPC
Uses XML encoding.
Older but widely used historically.
Apache Thrift
Cross-language RPC framework.
Supports multiple programming languages and transports.
Key Insight
Modern cloud and microservice architectures rely heavily on advanced RPC frameworks.
15. RPC in Modern Systems
RPC forms the foundation of:
Cloud Services
Distributed cloud components communicate through RPC-like interfaces.
Microservices
Services invoke each other through remote APIs.
Distributed Databases
Nodes coordinate through remote procedure invocations.
Web Services
Many APIs internally follow RPC principles.
Real-World Example
A banking application calls:
getBalance()
Internally:
Client
↓
RPC Request
↓
Server
↓
Database
↓
RPC Response
To the developer, it appears as a normal function call.
16. Advantages of RPC
Simplified Programming
Hides networking complexity.
Better Modularity
Supports distributed service architectures.
Transparency
Provides local-call abstraction.
Language Independence
Many frameworks support multiple languages.
Reusability
Services can be shared across systems.
17. Limitations of RPC
Network Dependency
Communication depends on network availability.
Latency
Remote calls are significantly slower than local calls.
Partial Failures
Client and server may fail independently.
Serialization Overhead
Complex objects require expensive marshalling.
Limited Transparency
Network realities cannot be fully hidden.
Key Insight
RPC makes distributed programming easier, but it cannot eliminate the fundamental costs and challenges of distributed communication.