DC CHAPTER 4 RPC

🌐 Interprocess Communication (IPC)

Definition:
Interprocess Communication ek mechanism hai jisme two or more independent processes ek
distributed environment mein data exchange karte hain. Internet par IPC dono tarah ka
communication support karta hai:

 Datagram communication (message-based, connectionless)

 Stream communication (continuous data flow, connection-oriented)

Example:
Google search engine apne servers ko enquiry bhejta hai unke current load & queue status ke
liye. Phir request ko least loaded node par bheja jaata hai ya queue mein daala jaata hai.
Distributed system ko aise enquiry ke liye IPC mechanism provide karna padta hai.

⚡ Characteristics of IPC
1. Synchronous System Calls
o Sender aur receiver dono blocking calls use karte hain.
o Sender wait karega jab tak acknowledgment na aaye.
o Receiver wait karega jab tak message na receive ho.
o Example: File transfer jaha sender ko confirmation chahiye ki data successfully
gaya.
2. Asynchronous System Calls
o Sender aur receiver dono non-blocking calls use karte hain.
o Sender ko receiver ke acknowledgment ka wait nahi karna padta.
o Example: Email sending jaha sender turant apna kaam continue kar sakta hai.
3. Message Destination
o Local port ek message destination hota hai (integer value).
o Ek port ka exactly one receiver hota hai but multiple senders ho sakte hain.
o Agar kisi process ko port number pata hai, wo us port par message bhej sakta hai.
4. Reliability
o Validity: Guarantee ki message deliver hoga, lost nahi hoga.
o Integrity: Message bina corruption aur duplication ke destination tak pahunchna
chahiye.

💡 Diagram Idea:
  Ek sender aur ek receiver ke beech arrows dikhana.
 Synchronous mein arrow ke saath “wait” label.
 Asynchronous mein arrow ke saath “no wait” label.

📚 Layered Protocols
Distributed systems mein shared memory absent hoti hai, isliye communication message
sending/receiving se hota hai.

Process Flow:

 Process A (Machine 1) → Process B (Machine 2).

 Message application layer ko diya jaata hai.
 Har layer apna header/trailer add karti hai.
 Physical layer finally message ko transmission medium par bhej deti hai.

Layer Example:

 Application Layer → Presentation Layer → Session Layer → Transport Layer →

Network Layer → Data Link Layer → Physical Layer.

💡 Diagram Idea:

 Ek layered stack bana ke har layer ka header/trailer show karna.

 Bottom mein physical medium (cable/wireless).
🔗 Remote Procedure Call (RPC)
Definition:
RPC ek technique hai jisme ek process dusre machine par procedure call kar sakta hai jaise local
procedure call hota hai.

Working:

 Caller (Machine A) procedure call karta hai.

 Caller suspend hota hai, callee (Machine B) execute karta hai.
 Parameters caller se callee ko jaate hain, result wapas aata hai.
 Programmer ko message passing dikhai nahi deta.

Features:

1. Simple syntax (local procedure call jaisa).

2. Easy to use, efficient, general.
3. IPC ke liye use ho sakta hai (same machine ya different machine).
4. Caller aur callee ke address space alag hote hain.

Execution Steps:

 Caller arguments ko ek specified location mein rakhta hai.

 Control procedure body ko transfer hota hai.
 Procedure execute hota hai aur result return hota hai.
 RPC internally message-passing scheme use karta hai.

Parallelism:

 Caller block hona zaroori nahi.

 RPC asynchronous bhi ho sakta hai → client apna kaam continue kar sakta hai jab tak
reply aaye.
 Server ek thread create karke multiple requests handle kar sakta hai.

💡 Diagram Ideas:

1. RPC Flow Diagram:

o Caller (Machine A) → Request Message → Server (Machine B) → Execute
Procedure → Reply Message → Caller.
2. Parallel RPC:
o Server multiple threads handle kar raha hai.
o Client asynchronous call kar raha hai.
📊 Comparison Table: IPC vs RPC
Aspect IPC (Message Passing) RPC (Remote Procedure Call)
Communication Style Explicit message send/receive Procedure call syntax (like local call)
Programmer View Message handling visible Message passing hidden
Blocking Behavior Can be synchronous/asynchronous Can be synchronous/asynchronous
Address Space Processes may share/disjoint Caller & callee always disjoint
Ease of Use More complex (manual handling) Easier (local call style)
Example Google server load enquiry Client calling server function remotely

RPC Working and RPC

Call Semantics
🔗 Remote Procedure Call (RPC) – Detailed
Working

📌 Stepwise Flow of RPC

1. Client Stub Invocation

o Client apne address space mein ek client stub procedure invoke karta hai.
o Parameters normal procedure call ki tarah pass kiye jaate hain.
 2. Marshalling (Packing)
o Client stub parameters ko ek message mein pack karta hai.
o Marshalling ka matlab hai parameters ko ek standard format mein convert karna aur
message mein copy karna.

3. Transport Layer Send

o Client stub message ko transport layer ko deta hai.
o Transport layer message ko remote server machine tak bhejta hai.

4. Server Stub Unmarshalling

o Server par transport layer message ko server stub ko pass karta hai.
o Server stub parameters ko unpack (unmarshall) karta hai aur desired server routine ko
call karta hai.

5. Server Procedure Execution

o Server procedure execute hota hai aur result server stub ko return karta hai.
o Server stub result values ko ek message mein marshall karta hai aur transport layer ko
deta hai.

6. Return Message to Client

o Transport layer result message ko client transport layer tak bhejta hai.
o Client transport layer message ko client stub ko pass karta hai.

7. Unmarshalling at Client
o Client stub return parameters ko unpack karta hai.
o Execution caller ko return hota hai.

💡 Diagram Idea:

 Ek flowchart jisme arrows dikhaye jaaye:

Client → Client Stub → Transport Layer → Server Transport → Server Stub → Server Procedure
→ Server Stub → Transport Layer → Client Stub → Client.

⚡ RPC Call Semantics

RPC mein caller aur callee different nodes par hote hain. Dono independently fail ho sakte hain
aur restart bhi ho sakte hain.
Is wajah se RPC execution disturb ho sakta hai → call ya response message lost ho sakta hai, ya
node crash ho sakta hai.
Isliye RPC runtime system mein fault handling code hona zaroori hai.

Call semantics define karte hain ki fault conditions mein remote procedure kitni baar execute
hota hai.
1️⃣ Possibly / May-be Call Semantics
 Sabse weak semantics.
 Caller ek timeout period wait karta hai aur phir apna execution continue kar deta hai.
 Koi guarantee nahi hoti ki call message deliver hua ya procedure execute hua.
 Useful jab response caller ke liye important nahi hai.

👉 Example: IoT Temperature Monitoring

 Sensor har 10 sec mein server ko temperature bhejta hai.

 Agar ek packet lost ho gaya toh server simply next update ka wait karega.

💡 Diagram Idea:

 Sensor → Server (arrow with “may-be delivered”).

2️⃣ Least-One Call Semantics

 Call message retransmit hota hai timeout ke baad, jab tak caller ko response na mil jaaye.
 Caller → RPC call → Callee execute → Caller result receive.
 Ye repeat hota hai jab tak result milta hai.
 Problem: Orphan calls (caller crash ho gaya, par callee abhi bhi execute kar raha hai).
 Isse unwanted computation aur resource wastage hota hai.

👉 Example: “Pay Now” option on e-commerce platform.

  Agar caller crash ho gaya toh bhi callee payment process kar sakta hai → double charge risk.

💡 Diagram Idea:

 Caller crash → orphan call executing on server.

3️⃣ Least-of-Many Call Semantics

 Orphan calls avoid karne ke liye unique call ID assign hota hai.
 Repeated calls ke liye new call IDs generate hote hain.
 Client response tab accept karta hai jab call ID match kare.
 Agar mismatch hai toh response ignore kar diya jaata hai.

👉 Example: Online Movie Ticket Booking System.

 Agar multiple retries ho jaaye toh bhi ek hi valid booking confirm hoti hai.

💡 Diagram Idea:

 Multiple calls with IDs → only latest ID response accepted.

4️⃣ At-Least-Once Call Semantics

 Call ek ya zyada baar execute hota hai.
 Caller ko specify nahi hota ki kaunsa result milega.
 Ye semantics idempotent operations ke liye useful hai (same operation multiple times → same
result).

👉 Examples:

 Account enquiry (same balance result).

 Email sending service (duplicate email acceptable).

💡 Diagram Idea:

 Caller → multiple executions → same result returned.

5️⃣ Exactly-Once Call Semantics

  Strongest aur most desirable semantics.
 Chahe caller kitni baar retransmit kare, procedure sirf ek baar execute hota hai.
 Guarantee: No duplication, no corruption.

👉 Example: Online Bank Fund Transfer.

 Agar transfer request multiple times bheja gaya toh bhi sirf ek transaction execute hoga.

💡 Diagram Idea:

 Caller retries → Server ensures only one execution.

📊 Summary Table – RPC Call Semantics

Semantics Guarantee Level Example Use Case

Possibly / May-be Weakest, no guarantee IoT sensor data

Least-One Retransmit until response E-commerce “Pay Now”

Least-of-Many Uses Call ID to avoid orphan calls Movie ticket booking

At-Least-Once Executes ≥1 times, idempotent ops Account enquiry, Email

Exactly-Once Executes only once, strongest Bank fund transfer

RMI (Remote Method

Innvocation)

🔗 Remote Method Invocation (RMI)

Definition:
RMI ek mechanism hai jo distributed system mein ek process (Java Virtual Machine – JVM)
mein chal raha object ko allow karta hai ki wo dusre process (jo alag JVM aur alag physical
machine par ho sakta hai) ke object ke methods invoke kare.
👉 Ye basically object-oriented equivalent of RPC (Remote Procedure Call) hai.
⚙️Components of RMI
1. Stub and Skeleton

 Stub (Client-side proxy):

o Client ke paas ek local representative hota hai jo remote object ka proxy hota hai.
o Jab client stub par method call hota hai, wo remote JVM ke saath connection establish
karta hai.
o Parameters ko marshalling (serialization) karke ek message mein convert karta hai aur
network par bhejta hai.

 Skeleton (Server-side proxy):

o Server par skeleton incoming request receive karta hai.
o Parameters ko unmarshalling (deserialization) karta hai.
o Actual server object ke method ko invoke karta hai.
o Result ya exception ko marshall karke client stub ko wapas bhejta hai.
o (Note: Java 2 SDK v1.2 ke baad skeletons Java-only environments mein required nahi
hote).

2. RMI Registry

 Ek naming service hai jaha server apne remote objects ko unique names ke saath register karta
hai (e.g., rmi://host:port/serviceName).
 Client registry mein object ka naam lookup karta hai aur stub reference obtain karta hai.
 Stub ke through client remote methods invoke karta hai.

Mechanism:

 Server-side: Remote object create hota hai aur registry mein bind/rebind kiya jaata hai ek
unique string name ke saath.
 Client-side: Client registry ko contact karta hai (default port 1099) aur lookup() operation karta
hai. Registry stub reference return karti hai.
 Location: Registry alag process mein run ho sakti hai (rmiregistry command-line tool) ya
server ke JVM mein [Link]() ke through create ki ja sakti hai.

📌 Stepwise RMI Working

1. Remote object jo service provide karna chahta hai, wo apna naam RMI registry mein register
karta hai.
2. Client object name use karke RMI registry navigate karta hai.
 3. RMI registry remote object ka reference (stub) client ko return karti hai.
4. Client procedure local procedure call ke through client stub ko invoke karta hai. Stub ek
collection of functions hota hai jo remote function ke naam ke saath match karte hain.
o Stub request message banata hai aur actual parameters ke saath server ko bhejta hai.
o Client stub response ka wait karta hai.
5. Client stub system call karta hai network routines ko.
6. Message local kernel ke through remote kernel ko bheja jaata hai.
7. Remote kernel message receive karke RRL (Remote Reference Layer) ko transfer karta hai. RRL
system call ke through server stub ko call karta hai.
8. Server stub parameters ko unpack (unmarshall) karta hai aur server procedure ko call karta hai.
9. Server procedure apna kaam perform karta hai aur result server stub ko return karta hai.
o Server stub result ko marshall karke RRL ko bhejta hai.
10. Result server kernel ke through client kernel ko transmit hota hai.
o Client kernel result ko client stub ko pass karta hai.
o Client stub result ko unpack karta hai aur caller ko return kar deta hai.

💡 Diagram Ideas
1. Stub-Skeleton Communication Flow:
o Client → Stub → Transport Layer → Server Skeleton → Server Object → Result →
Skeleton → Stub → Client.
2. RMI Registry Flow:
o Server binds object → Registry → Client lookup → Stub reference → Remote method
invocation.
3. Stepwise RMI Execution:
o Numbered arrows showing: Register → Lookup → Stub call → Kernel transfer → RRL →
Server stub → Server execution → Result back.

📊 Summary Table – RMI Components

Component Role Function

Stub Client-side proxy Marshall parameters, send request

Skeleton Server-side proxy Unmarshall parameters, invoke method, marshall result

RMI Registry Naming service Stores remote objects with unique names

Transport Layer Communication medium Transfers messages between client & server JVMs
Message oriented
Communication

🔗 Messaging & Types of Communication in

Distributed Systems
🌐 Context

RPC aur RMI communication ko hide karte hain distributed systems mein, aur access
transparency enhance karte hain. Lekin dono hamesha appropriate nahi hote.

 Agar receiving side request issue hone ke time par active na ho, toh RPC/RMI fail ho jaate hain.
 RPC inherently synchronous hai → client block ho jaata hai jab tak request process na ho. Kabhi-
kabhi humein messaging-based communication chahiye hota hai jo flexible ho.

📌 Types of Communication
1. Transient Communication

 Messages har intermediate hop par store hote hain jab tak next node ready ho delivery ke liye.
 Agar receiver active nahi hai toh message discard ho jaata hai.
 Example: UDP-based video streaming (agar packet drop ho gaya toh koi retry nahi hota).

2. Persistent Communication

 Messages thodi der ke liye buffer hote hain.

 Agar message deliver nahi hua toh discard ho jaata hai.
 Example: Packet transmission in Internet (TCP/IP routing).
3. Synchronous Communication

 Sender apna execution block kar deta hai jab tak acknowledgment/response na aaye.
 Example: Telephone communication (caller wait karta hai jab tak receiver reply kare).

4. Asynchronous Communication

 Sender apna execution continue karta hai bina wait kiye.

 Example: Email system (mail bhejne ke baad sender apna kaam continue kar sakta hai).

⚡ Persistent Communication Variants

5. Persistent Synchronous Communication

 Sender message bhejne ke baad block ho jaata hai aur acknowledgment ka wait karta hai.
 Message local buffer mein store hota hai jab tak receiver run karke receive na kare.

👉 Example: Reliable messaging system jaha sender ko confirmation chahiye ki message deliver
hua.

6. Persistent Asynchronous Communication

 Sender message bhejta hai aur turant apna kaam continue karta hai.
 Message reliably store hota hai aur offline/disconnected receiver ko jab wo reconnect kare tab
deliver hota hai.
 Data loss prevent hota hai.
 Commonly achieved via message queues (e.g., Kafka, RabbitMQ).

👉 Example: WhatsApp message delivery (agar receiver offline hai toh message queue mein
store hota hai aur reconnect hone par deliver hota hai).

⚡ Transient Communication Variants

7. Transient Asynchronous Communication

 Sender message bhejta hai bina response ka wait kiye.

 Agar receiver active nahi hai ya network drop ho gaya toh message discard ho jaata hai.
 Sender aur receiver dono simultaneously active hone chahiye.
  Example: UDP protocol ya simple RPC jaha speed > reliability.

8. Transient Synchronous Communication

 Sender message bhejta hai aur block ho jaata hai jab tak acknowledgment/response na aaye.
 Message temporary hold hota hai (transient). Agar receiver active nahi hai toh discard ho jaata
hai.
 Sender aur receiver dono simultaneously active hone chahiye.
 Example: HTTP web server communication.

🔎 Subtypes of Transient Synchronous Communication

1. Receipt-based transient synchronous communication
o Sender block hota hai jab tak communication software message ko acknowledge na kare
(e.g., OS buffer mein store hone ka confirmation).

2. Delivery-based transient synchronous communication

o Sender specifically wait karta hai jab tak message receiver ke endpoint/queue tak
deliver na ho.

3. Response-based transient synchronous communication

o Sender wait karta hai jab tak receiver message process karke reply/result na bheje.

👉 Example: Web API calls jaha client response ka wait karta hai.

💡 Diagram Ideas
1. Communication Types Chart:
o Tree diagram: Communication → Transient / Persistent → Synchronous / Asynchronous
→ Subtypes.
2. Flow Diagram:
o Sender → Message Buffer → Receiver (showing synchronous block vs asynchronous
continue).
3. Comparison Table:
o Columns: Type, Blocking Behavior, Persistence, Example.