1.

Communication in Distributed Systems

Distributed systems involve multiple computers working together over a
network. For them to work smoothly, they need efficient ways to
communicate.

2. Remote Procedure Call (RPC)

What is RPC?
• RPC allows a program to call a function on another machine as if it were
a local function.
• It hides the complexities of networking and makes communication easy.
How does RPC work?
1. Client makes a function call just like a normal function.
2. Client stub packs (marshals) the request and sends it over the network.
3. Server stub receives the request, unpacks it, and calls the actual
function.
4. Function executes on the server, and the result is packed and sent back.
5. Client stub unpacks the result and gives it to the client.
Features of RPC
• Looks like a normal function call but works over a network.
• Simple to use because it hides network details.
• Can handle failures using different strategies.
Types of RPC Binding (Client-Server Connection)
• Static Binding: Server is known at compile time.
• Dynamic Binding: Server is found at runtime (via a binding agent).
Failure Handling in RPC
• At-most-once: Ensures the function is executed only once.
• At-least-once: May execute multiple times but guarantees at least one
execution.
• Exactly-once: Ideal case where it runs exactly one time, no matter what.
Types of Message-Oriented Communication
MOC can be categorized based on how messages are delivered, stored, and
acknowledged:
1.1 Persistent vs. Transient Communication
Messages can either be stored for later retrieval (persistent) or discarded if the
receiver is unavailable (transient).
1.1.1 Persistent Communication
• Messages are stored by the system until the receiver retrieves them.
• This is useful when the sender and receiver do not need to be online at
the same time.
• Example: Email, message queues (RabbitMQ, Kafka).
1.1.2 Transient Communication
• Messages exist only while the sender and receiver are active.
• If the receiver is down, the message is lost.
• Example: TCP/UDP-based communication (live streaming, VoIP calls).

Stored Sender & Receiver Active at the

Type Example
Messages? Same Time?

Email, Kafka,
Persistent Yes No
RabbitMQ

TCP, UDP, Live

Transient No Yes
Streaming
1.2 Synchronous vs. Asynchronous Communication
1.2.1 Synchronous Communication
• The sender waits for the receiver to acknowledge the message before
continuing.
• Guarantees message delivery but can slow down performance.
• Example: HTTP requests, Remote Procedure Calls (RPC).
1.2.2 Asynchronous Communication
• The sender sends the message and moves on without waiting for a
reply.
• This improves efficiency but does not guarantee immediate delivery.
• Example: Message queues (RabbitMQ, Kafka), event-driven systems.

Type Sender Waits for Reply? Faster Performance? Example

Synchronous Yes No RPC, HTTP API Calls

Asynchronous No Yes Kafka, Event Queues

2. Message Passing Protocols

Message-Oriented Communication follows different protocols based on
reliability and acknowledgment requirements.
2.1 Request-Reply Protocol
• The client sends a request and waits for a reply from the server.
• Used when confirmation of execution is necessary.
• Example: HTTP, Remote Database Queries.
2.2 Request-Reply-Acknowledgment Protocol
• Adds an extra acknowledgment step to ensure the message is received.
• Useful in high-reliability applications where messages must not be lost.
• Example: Banking Transactions, Online Payments.
2.3 Stream-Oriented Communication
• Used for continuous data transfer, where timing matters.
• Suitable for real-time applications like audio/video streaming.
• Example: YouTube video streaming, VoIP calls (Zoom, Google Meet).

Protocol Type Use Case Example

Request-Reply Client asks, server responds HTTP, Database Queries

Request-Reply-Ack Ensures message delivery Banking Transactions

Stream-Oriented Continuous data flow Video Streaming, VoIP

3. Group Communication in MOC

Sometimes, communication is not just between two processes but involves
multiple receivers or senders.
3.1 One-to-Many (Multicast/Broadcast)
• One sender communicates with multiple receivers.
• Example: Live streaming, online gaming servers.
3.2 Many-to-One
• Multiple senders send messages to one receiver.
• Example: Multiple sensors sending data to a central server.
3.3 Many-to-Many
• Multiple senders and receivers exchange messages.
• Example: Chat applications, peer-to-peer networks.
4. Reliability in Message-Oriented Communication
Some applications require guaranteed delivery, while others can tolerate
message loss. Different reliability models exist:
4.1 Reliability Models
• 0-Reliable: No response expected (fire-and-forget).
• 1-Reliable: Sender expects a response from at least one receiver.
• m-out-of-n Reliable: Sender expects responses from at least m receivers
out of n.
• All-Reliable: All receivers must acknowledge the message.

Reliability
Guarantee Use Case
Model

Logging, Debugging
0-Reliable No guarantee
Messages

At least 1 receiver
1-Reliable Chat Apps, IoT Devices
acknowledges

m-out-of-n Some receivers acknowledge Distributed Databases

All-Reliable All receivers must confirm Financial Transactions

4. Group Communication
Sometimes, communication is not just one-to-one, but between multiple
processes.
Types of Group Communication
1. One-to-Many (Multicast/Broadcast)
o Example: A live stream where one sender sends data to many
users.
2. Many-to-One Communication
o Example: Multiple sensors sending data to one database.
3. Many-to-Many Communication
o Example: Multiplayer online games where all players send and
receive data.
Reliability in Multicast Communication
• 0-reliable: No confirmation if message is received.
• 1-reliable: At least one receiver must confirm.
• All-reliable: All receivers must confirm before proceeding.

5. Stream-Oriented Communication
Why is it needed?
• In video calls or music streaming, messages must be delivered on time
(not too early or too late).
• Traditional message-based systems do not guarantee timing, so stream-
based systems are used.
Different Transmission Modes
• Asynchronous: No timing guarantees (e.g., text messages).
• Synchronous: Guarantees an upper delay limit (e.g., live video chat).
 • Isochronous: Has both minimum and maximum delay limits (e.g., real-
time gaming).

6. Server Management in RPC

Types of Servers
1. Stateless Servers
o Do not remember past requests.
o Example: A simple file download server.
2. Stateful Servers
o Remember past interactions.
o Example: An online shopping cart.
Types of Server Lifetimes
1. Instance-per-call: Server is created for each request and then destroyed.
2. Instance-per-session: Server stays active for an entire session.
3. Persistent Server: Server runs indefinitely and handles multiple clients.

7. Call Semantics in RPC

When an RPC call is made, different strategies handle failures:
• Maybe: If a response is delayed, the client moves on.
• At-least-once: Retries the call until a response is received.
• At-most-once: Ensures no duplicate execution.
• Exactly-once: Guarantees execution only once (best case).