Distributed OS: RPC, Amoeba, Cloud OS, Process Management & Security

Core Concepts & Definitions

What is a Distributed Operating System (DOS)?

A Distributed Operating System (DOS) is an OS that manages a collection of independent computers as a single coherent system, hiding the physical distribution of resources. Unlike traditional OSes, DOS provides:

• Transparency (users see a unified system).
• Resource sharing (CPU, memory, files across nodes).
• Fault tolerance (system continues if one node fails).
• Scalability (easy to add/remove nodes).

stateDiagram-v2
    [*] --> CentralizedOS: ["Single OS controls all nodes"]
    [*] --> DistributedOS: ["No single OS; nodes share control"]
    [*] --> ClientServer: ["Clients request services from servers"]
    [*] --> PeerToPeer: ["All nodes equal; no dedicated server"]
    CentralizedOS --> "Single Point of Failure"
    DistributedOS --> "High Fault Tolerance"
    ClientServer --> "Load Balancing"
    PeerToPeer --> "Decentralized Control"
    note left of CentralizedOS: "Centralized"
    note left of DistributedOS: "Distributed"
    note left of ClientServer: "Client-Server"
    note left of PeerToPeer: "Peer-to-Peer"

Key Technologies in Distributed OS

1. Remote Procedure Call (RPC)

RPC allows a program to call a procedure (function) on a remote system as if it were local. It works in 4 steps:

1. Client marshals (serializes) arguments into a message.
2. Client stub sends the message over the network.
3. Server stub receives the message and unmarshals (deserializes) it.
4. Server executes the procedure and sends the result back.

sequenceDiagram
    participant Client
    participant ClientStub
    participant Network
    participant ServerStub
    participant Server

    Client->>ClientStub: Call remote_func(arg1, arg2)
    ClientStub->>Network: Marshal & Send (func_name, arg1, arg2)
    Network-->>ServerStub: Receive (func_name, arg1, arg2)
    ServerStub->>Server: Unmarshal & Call func(arg1, arg2)
    Server-->>ServerStub: Return result
    ServerStub->>Network: Marshal & Send result
    Network-->>ClientStub: Receive result
    ClientStub-->>Client: Return result

Real-World Example: WhatsApp Messages

• When you send a message, WhatsApp’s client stub (on your phone) sends a serialized request to WhatsApp’s server stub (on their servers).
• The server processes it (e.g., stores in a database) and sends back an acknowledgment.
• Why RPC? Because WhatsApp needs to call functions (e.g., save_message(), notify_recipient()) on remote servers without exposing internal details.

2. Amoeba System Architecture

Amoeba is a distributed OS designed at the Vrije Universiteit Amsterdam. It uses:

• Microkernel architecture (minimal kernel, most services in user space).
• Capability-based addressing (each resource has a unique capability token).
• Process groups (processes can migrate between nodes).

Why Amoeba?

• Used in early distributed file systems (similar to modern cloud storage).
• Inspired Google’s Borg (container orchestration system).

3. Cloud Operating System (Cloud OS)

A Cloud OS is an OS designed to run virtualized workloads in a cloud environment. Examples:

• Microsoft Azure
• Amazon Linux
• Google Compute Engine OS

Characteristics of Cloud OS

Advantages of Cloud OS

✅ Cost-efficient (pay-as-you-go). ✅ Scalability (add/remove servers instantly). ✅ High availability (redundancy across data centers). ✅ Disaster recovery (backups in multiple regions).

Real-World Example: eSewa Payments

• When you pay a bill via eSewa, the system uses a cloud OS (likely AWS or Azure) to:
  1. Scale dynamically (handles thousands of transactions per second).
  2. Isolate user data (multi-tenancy ensures your transaction is secure).
  3. Auto-recover if a server fails (fault tolerance).

Process Management in Distributed Systems

In DOS, processes can migrate, communicate, and synchronize across nodes.

How Processes Communicate?

1. Message Passing (synchronous/asynchronous).
2. Remote Procedure Call (RPC) (as discussed).
3. Shared Memory (with synchronization mechanisms like semaphores).

Process Migration in Amoeba

• A process can move from one node to another while maintaining its state.
• Used in load balancing (e.g., if Node A is overloaded, processes move to Node B).

sequenceDiagram
    participant ProcessA
    participant NodeA
    participant NodeB

    ProcessA->>NodeA: Request migration (due to high load)
    NodeA->>NodeB: Send process state (code, data, registers)
    NodeB-->>NodeA: Acknowledge
    NodeA->>ProcessA: Resume on NodeB
    ProcessA->>NodeB: Execute

Real-World Example: Pathao Driver App

• When a Pathao driver logs in, their process state (location, active rides) is managed by Pathao’s distributed cloud OS.
• If a server goes down, the system migrates the process to another node to keep the app running.

Security in Distributed OS

Distributed systems face unique security challenges:

• Unauthorized access (hackers exploiting RPC).
• Data integrity (man-in-the-middle attacks).
• Denial-of-Service (DoS) (overloading nodes).

Security Mechanisms

Real-World Example: Ncell’s Mobile Banking

• When you log in to Ncell’s app, it uses:
  • RPC over HTTPS (secure communication).
  • Token-based authentication (JWT) to verify your identity.
  • Load balancers to distribute requests across servers (preventing DoS).

Comparison: Distributed OS vs. Traditional OS

Worked Example: RPC in a Bank Loan System

Scenario: A bank’s loan approval system uses RPC to check credit scores from a remote database.

1. Client (Loan Officer’s PC) calls check_credit_score(customer_id).
2. Client stub serializes the request and sends it over the network.
3. Server stub (on the bank’s credit server) receives the request.
4. Server queries the database and returns {"score": 750, "approved": true}.
5. Client stub sends the result back to the loan officer.

sequenceDiagram
    participant LoanOfficer
    participant ClientStub
    participant Network
    participant ServerStub
    participant CreditDB

    LoanOfficer->>ClientStub: check_credit_score(12345)
    ClientStub->>Network: Marshal & Send
    Network->>ServerStub: Receive
    ServerStub->>CreditDB: Query DB
    CreditDB-->>ServerStub: {"score": 750, "approved": true}
    ServerStub->>Network: Marshal & Send
    Network->>ClientStub: Receive
    ClientStub-->>LoanOfficer: Return result

Why RPC?

• The loan officer doesn’t need to know where the credit database is located.
• The bank can scale by adding more credit servers without changing the client app.

Exam Tip: How to Score Full Marks

1. Define Clearly

   • Always start with a precise definition (e.g., "A Distributed OS is an OS that manages a collection of independent computers as a single system...").
   • Example: "RPC is a protocol that allows a program to execute a procedure on a remote system as if it were local."

2. Use Diagrams

   • Sequence diagrams for RPC, process migration.
   • Class diagrams for Amoeba architecture.
   • State diagrams for process states in distributed systems.

3. Relate to Real-World Examples

   • eSewa → Cloud OS scalability.
   • WhatsApp → RPC for messaging.
   • Pathao → Process migration for load balancing.

4. Compare & Contrast

   • Distributed OS vs. Traditional OS (table format).
   • RPC vs. Message Passing (explain when to use each).

5. Explain Trade-offs

   • "While RPC simplifies remote calls, it adds network latency. Message passing is more flexible but complex."

6. Common Exam Questions & Answers

   Question Type	Key Points to Include
   Define RPC	Steps (marshal, send, unmarshal, execute), client/server stubs, transparency.
   Amoeba Architecture	Microkernel, capabilities, process groups, migration.
   Cloud OS Advantages	Virtualization, auto-scaling, multi-tenancy, fault tolerance.
   Security in Distributed OS	Authentication, encryption, firewalls, intrusion detection.
   Process Migration	State transfer, load balancing, fault tolerance.

Summary Table: Key Concepts