Remote Procedure Call (RPC) and Middleware: How Distributed Systems Call Functions Across Machines

TAKEAWAYS:

• RPC lets a client call a procedure on a remote server transparently, using stubs to marshal/unmarshal data between local and remote calls.
• Middleware acts as a glue layer between distributed components, handling communication, security, and transaction management.
• Virtualization in distributed systems isolates resources (CPU, storage) while sharing them efficiently, like cloud servers hosting multiple apps.
• RPC follows a request-reply cycle with error handling, timeouts, and retries to ensure reliability.
• Message-oriented middleware (e.g., Kafka, RabbitMQ) decouples senders and receivers using queues, unlike RPC’s synchronous calls.
• Exam tip: Compare RPC vs. message queues, explain the stub proxy mechanism, and relate middleware to real apps like eSewa’s payment processing.

---

1. Remote Procedure Call (RPC): The Illusion of Local Calls

RPC is a protocol that lets a program on one machine call a procedure on another machine as if it were local. The key idea: transparency—the client doesn’t know the server is remote.

How RPC Works: The Stub Proxy Mechanism

RPC relies on two critical components:

1. Stub (Client-Side Proxy):

   • Intercepts the procedure call from the client.
   • Marshaling: Converts local arguments into a network-friendly format (e.g., JSON, Protocol Buffers).
   • Sends the marshalled data to the server via a transport layer (TCP, UDP).

2. Skeleton (Server-Side Proxy):

   • Receives the marshalled data.
   • Unmarshaling: Converts the data back into local arguments.
   • Calls the actual procedure on the server.
   • Returns the result (or error) back to the client via the stub.

figure: RPC call flow

```mermaid
flowchart TD
    A["Client"] -->|Call procedure()| B["Stub (Marshaling)"]
    B -->|Send request| C["Network (TCP/UDP)"]
    C -->|Receive request| D["Skeleton (Unmarshaling)"]
    D -->|Call procedure()| E["Server"]
    E -->|Return result| D
    D -->|Send reply| C
    C -->|Receive reply| B
    B -->|Return result| A

RPC Message Format

RPC messages typically include:

• Request/Reply Type: Indicates if it’s a call or response.
• Procedure ID: Specifies which function to invoke.
• Arguments: Serialized client-side data.
• Return Value: Serialized result or error code.

figure: RPC message structure

```figure
{"type":"fields","width":64,"rows":[[{"label":"Message Type","bits":8,"value":"RPC_CALL"},{"label":"Procedure ID","bits":16,"value":"42"},{"label":"Argument Length","bits":32,"value":"..."}],[{"label":"Arguments","bits":32,"value":"{\"name\":\"Alice\", \"age\":25}"},{"label":"Padding","bits":16,"value":"..."}]],"caption":"Simplified RPC request message format (64-bit aligned)"}

Worked Example: eSewa’s Payment API

When you pay via eSewa, your phone (client) calls pay(amount, merchant_id) on eSewa’s server. Under the hood:

1. Your app’s stub marshals {"amount":500, "merchant_id":"123"} into JSON.
2. The request travels over the internet (TCP) to eSewa’s skeleton.
3. The server processes the payment, returns {"status":"success"}.
4. Your app’s stub unmarshalled the reply and shows "Payment confirmed!"

---

2. Message-Oriented Communication vs. RPC

While RPC is synchronous (client waits for reply), message-oriented middleware (MOM) decouples senders and receivers using queues.

figure: RPC vs. MOM comparison

mermaid
table TD
    | Feature               | RPC                          | MOM                          |
    |-----------------------|------------------------------|-------------------------------|
    | **Synchrony**         | Synchronous (blocking)       | Asynchronous (non-blocking)   |
    | **Decoupling**        | Client ↔ Server              | Producer ↔ Consumer (via queue) |
    | **Order Guarantee**   | FIFO per call                | Per-partition ordering        |
    | **Scalability**       | Limited by server threads    | Horizontal scaling (queues)    |
    | **Example**           | Bank transfer                | Social media notifications    |

---

3. Middleware: The Distributed System’s Glue

Middleware is a software layer that sits between distributed components, handling:

• Communication (RPC, messaging, gRPC).
• Security (authentication, encryption).
• Transactions (ACID compliance).
• Resource management (load balancing, caching).

Middleware Architectures

1. Peer-to-Peer (P2P):

   • No central server (e.g., BitTorrent).
   • Clients communicate directly.

2. Client-Server:

   • Centralized server (e.g., eSewa’s payment server).
   • Clients request services.

3. Brokered (Message-Oriented):

   • Middleware (e.g., RabbitMQ) routes messages.
   • Used in event-driven systems (e.g., Pathao’s ride updates).

4. Hybrid:

   • Combines RPC (for real-time) + messaging (for async tasks).

figure: Middleware architectures

```mermaid
classDiagram
    class Client {
        +request(service)
    }
    class Server {
        +provide(service)
    }
    class Middleware {
        <<abstract>>
        +route(request)
    }
    class Broker {
        +queue_messages()
    }
    class RPC_Middleware {
        +invoke_remote()
    }
    class Message_Broker {
        +publish_subscribe()
    }

    Client -->|RPC| RPC_Middleware : calls
    RPC_Middleware -->|gRPC/HTTP| Server : invokes
    Client -->|Async| Message_Broker : publishes
    Message_Broker -->|Queue| Server : delivers
    RPC_Middleware <|-- Broker : uses
    Message_Broker <|-- Broker : implements

Middleware architectures showing specialization

Real-World Example: Daraz’s Order Processing

Daraz uses middleware to:

1. RPC: Sync inventory when a user clicks "Buy."
2. Message Queue (Kafka): Decouple payment processing (async) from order confirmation.
3. Load Balancer (Middleware): Distribute orders across servers.

---

4. Virtualization in Distributed Systems

Virtualization abstracts physical resources (CPU, storage, networks) into logical units. Types:

1. Platform Virtualization:

   • Runs multiple OS instances on one machine (e.g., Docker containers).
   • Used by cloud providers (e.g., AWS EC2).

2. Storage Virtualization:

   • Combines physical storage into a single pool (e.g., NEPSE’s trading servers).

3. Network Virtualization:

   • Creates virtual networks (e.g., VPNs for remote workers).

figure: Virtualization layers

Example: NTC’s Network Virtualization

NTC uses virtualization to:

• Isolate traffic (e.g., business vs. residential users).
• Optimize bandwidth by dynamically allocating resources.

---

5. Advantages and Disadvantages of RPC

---

6. Exam Tip: How to Score Full Marks

1. Diagrams Are Mandatory:

   • Always draw the RPC stub-skeleton flow and message format.
   • Show a sequence diagram for RPC vs. message queues.

2. Compare and Contrast:

   • Link RPC to synchronous systems (e.g., bank transfers) vs. asynchronous (e.g., WhatsApp notifications).
   • Explain how middleware reduces coupling in Daraz’s order system.

3. Real-World Tie-Ins:

   • For virtualization, mention NTC’s network isolation.
   • For middleware, cite eSewa’s payment API or Pathao’s ride updates.

4. Avoid Vague Answers:

   • Don’t just say "RPC is a protocol"—explain the marshaling/unmarshaling steps.
   • Don’t list middleware types without examples (e.g., "RabbitMQ for async tasks").

---

7. In the Real World

1. eSewa’s Payment API (RPC + Middleware):

   • When you pay via eSewa, your phone uses RPC to call pay() on their server.
   • The middleware handles security (OAuth tokens) and transactions (ACID compliance).
   • If the payment fails, the middleware retries or notifies you via SMS (async queue).

2. Daraz’s Order Queue (Message-Oriented Middleware):

   • When you order a product, Daraz’s system uses RPC to check inventory.
   • The order is then placed in a message queue (e.g., Kafka) for async processing (packing, shipping).
   • This decouples the frontend (your phone) from backend tasks (warehouse systems).

3. Ncell’s Call Routing (Virtualization + RPC):

   • Ncell’s servers use virtualization to isolate traffic (e.g., voice vs. data).
   • When you call someone, the RPC layer routes your call to the correct base station.
   • Middleware ensures load balancing during peak hours (e.g., New Year’s Eve).

---

8. Worked Example: RPC Trace for a Bank Loan Approval

Scenario: A customer applies for a loan via a bank’s website.

1. Client Call:

   • User clicks "Apply for Loan" → browser stub marshals:

     {"loanAmount": 500000, "customerID": "12345", "creditScore": 750}
     

   • Sends over HTTPS (TCP) to the bank’s RPC endpoint.

2. Server Processing:

   • Bank’s skeleton unmarshalled the request.
   • Calls approveLoan() on the backend server.
   • Checks credit score (RPC to credit bureau) and collateral (RPC to property database).

3. Reply:

   • Server returns:

     {"status": "approved", "interestRate": 0.08, "tenure": 120}
     

   • Stub unmarshalled the reply → displays loan terms to the user.

figure: RPC trace for loan approval

```mermaid
sequenceDiagram
    participant Browser as Client
    participant Stub
    participant Network
    participant Skeleton
    participant LoanServer
    participant CreditBureau

    Browser->>Stub: pay(loanAmount=500000, customerID="12345")
    Stub->>Network: Marshal & Send {"loanAmount":500000, ...}
    Network->>Skeleton: Receive request
    Skeleton->>LoanServer: approveLoan()
    LoanServer->>CreditBureau: RPC: checkCreditScore()
    CreditBureau-->>LoanServer: {"score":750}
    LoanServer-->>Skeleton: {"status":"approved", "interestRate":0.08}
    Skeleton->>Network: Marshal & Send reply
    Network-->>Stub: Receive reply
    Stub-->>Browser: Display loan terms