📜 Exam Notes: Unit 3 - Communication

💡 Unit Introduction: Why Communication Matters

In a distributed system, you have many different processes (programs) running on many different computers.
These computers are separated by a network. For the system to do any useful work, these processes must be able
to talk to each other.

This unit is about the "plumbing" of a distributed system. It covers the different ways processes can send and
receive messages, from simple function calls to reliable, persistent queues and high-speed video streams.

1. Layered Protocols

 What it is: A model that organizes the complex job of network communication into a "stack" of layers. Each
layer has a specific responsibility and provides a service to the layer above it. The most famous models are
the OSI Model (7 layers) and the TCP/IP Model (4-5 layers).

 Analogy (Sending a Package):

o Application Layer: You write a letter (the data).

o Transport Layer (TCP): You put the letter in a box and add a label with the person's name at the
destination (the "port number," which identifies the application, e.g., web server, game). This layer
ensures the letter arrives in one piece.

o Network Layer (IP): You add the full street address (the "IP address") so the package can get to the
right building. This layer handles routing the package across the world.

o Data Link/Physical Layer: The post office puts the package on a physical truck (like an Ethernet
cable or Wi-Fi signal) to actually move it.

 Why it matters: This separation makes the system modular. You can change your Wi-Fi card (Physical
Layer) without having to rewrite your web browser (Application Layer).

2. Types of Communication

This describes the basic styles of how messages can be sent.

 Synchronous vs. Asynchronous Communication

o Synchronous (or Blocking): Like making a phone call. The sender sends a message and then stops
all work and waits until it gets a reply.

 Pro: Simple to program and understand.

 Con: Very inefficient. The sender (client) is "blocked" and can't do anything else.

o Asynchronous (or Non-Blocking): Like sending a text message. The sender sends a message and
immediately continues doing other work. The reply, if any, is handled later (e.g., via a
notification).
  Pro: Highly efficient. Allows the sender to stay busy.

 Con: More complex to program (you have to handle a reply that could come at any time).

 Persistent vs. Transient Communication

o Persistent: Like email. The message is sent to a "middle-man" (like a mail server) that stores the
message safely until the receiver is ready for it. The receiver does not have to be online when the
message is sent.

 Pro: Very reliable and "decoupled" (sender and receiver don't need to be active at the same
time).

o Transient: Like a live phone call. The message is sent directly, and if the receiver is not online and
listening at that exact moment, the message is dropped and lost. The system does not store it.

 Con: Less reliable. Requires both sender and receiver to be active.

3. Basic RPC Operation (Remote Procedure Call)

 What it is: An RPC allows a program on one machine (the "client") to call a function or procedure that is on
another machine (the "server") as if it were a normal, local function.

 The Goal: To achieve location transparency. The programmer writing the code doesn't need to know (or
care) that the function is running on a different computer.

 How it Works (The Stub/Skeleton Model):

1. Client Stub: The client code calls a local "placeholder" function called a stub. This stub has the
same name as the remote function (e.g., calculate_sum(5, 10)).

2. Marshalling: The client stub's job is to take the parameters (like 5 and 10), pack them into a
message that can be sent over the network. This packing process is called marshalling or
"serialization."

3. Network Transport: The client's operating system sends this message to the server.

4. Server Skeleton: A "skeleton" on the server receives the message.

5. Unmarshalling: The skeleton unpacks the message ("unmarshalling") to get the parameters (5 and
10).

6. Server Call: The skeleton now calls the actual calculate_sum function on the server with these
parameters.

7. Return: The server function returns the result (e.g., 15). This result is marshalled by the skeleton,
sent back over the network, unmarshalled by the client stub, and finally returned to the client's
original code.

4. Parameter Passing
  The Problem: In an RPC, the client and server are on different machines. They do not share memory. This
means you cannot simply "pass a pointer" or "pass a reference" to a variable, because that memory address
is meaningless on the other machine.

 How it's solved:

o Pass-by-Value: This is the most common method. The value of the parameter is copied, marshalled,
and sent. If the server changes its copy of the value, the client's original variable is not affected.

o Pass-by-Reference (Simulated): This is much harder. To simulate pass-by-reference (where the

1. The client stub copies the data (e.g., a whole array).

2. This copy is sent to the server.

3. The server modifies its copy.

4. When the function returns, the server sends the entire modified copy back to the client.

5. The client stub overwrites its original data with the new copy.

5. Asynchronous RPC

 What it is: A variation of RPC that is asynchronous (non-blocking). The client makes the remote call but
does not wait for the reply.

 How does the client get the result?

o Callbacks: The client passes a special "callback function" as one of the parameters. When the server
is finished, it makes a new RPC call back to the client, running the callback function to deliver the
result.

o Futures (or Promises): This is more common. The RPC call immediately returns a special object
called a "Future." The client can continue working. When it needs the result, it checks the Future. It
can either:

 poll(): Ask the Future, "Is the result ready yet?"

 wait(): Block only at that point until the result is ready.

6. Message-Oriented Transient Communication

 What it is: This is a simpler, more direct form of communication. Instead of faking a "function call," the
client and server just send and receive discrete messages.

 Key Features:

o Transient: As discussed in Topic 2, the system does not store the message. If the receiver is not
ready, the message is dropped.
 o Example: Basic Socket Programming (like with TCP). The sender send()s a packet and the
receiver must have an active listen() or receive() call ready to catch it.

7. Message-Oriented Persistent Communication

 What it is: A much more reliable form of messaging, often called Message-Oriented Middleware (MOM).

 Key Feature (Persistent): This uses a "broker" or "message queue" (like RabbitMQ, Kafka, or ActiveMQ)
that sits between the sender and receiver.

 How it Works:

1. The sender (or "Producer") sends its message to a "queue" on the message broker.

2. The broker confirms to the sender that the message is safely stored. The sender can now move on.

3. The receiver (or "Consumer") connects to the broker whenever it's ready (it could be hours later)
and pulls messages from the queue.

 Why it matters: This decouples the sender and receiver. They don't need to be online at the same time.
It's the standard for reliable systems (e.g., processing financial transactions, handling web orders).

8. Support for Continuous Media

 What is Continuous Media? This is any data that must be "played" over time, such as audio and video.

 The Challenge: This data is fundamentally different from text or files.

o It is time-sensitive. A video frame that arrives 2 seconds late is useless and should be dropped. A
file packet that arrives 2 seconds late is fine.

o It is high-bandwidth. It requires a large, constant flow of data.

 This special data needs special support, which is...

9. Streams and Quality of Service (QoS)

 Stream: A continuous, time-sensitive flow of data (like a video stream from Netflix or a live video call).

 Quality of Service (QoS): The normal internet is "best-effort," meaning it tries to deliver packets but
makes no guarantees. For continuous media, "best-effort" is not good enough. QoS is a set of guarantees
that the network promises to a stream.

 Key QoS Guarantees:

o Bandwidth: A promise for a minimum data rate (e.g., "you will always get at least 5 Mbps").

o Latency (Delay): A promise for a maximum delay (e.g., "your packets will never take more than
150ms to arrive"). This is critical for live calls.
 o Jitter: A promise about variation in delay. High jitter is when packets arrive in random, uneven
bursts (e.g., packet1...packet2, packet3, packet4...packet5). This causes stuttering in audio/video.
Low jitter is ideal.

10. Stream Synchronization

 What it is: The process of ensuring that two or more separate streams are played back together at the
correct time.

 The Problem: In a movie, the video track and the audio track are often separate streams. Because of
network jitter, the audio packets might arrive slightly faster than the video packets.

 The Solution (Lip-Sync):

1. All packets (both audio and video) are given timestamps by the sender.

2. The receiver (e.g., your video player) maintains a small buffer (it collects a few seconds of data
before starting).

3. It uses the timestamps to perfectly align the audio and video packets before playing them, ensuring
the "lip-sync" is correct.

11. Application-Level Multicasting

 What is Multicast? Sending a single message to a group of specific receivers. (Unicast = 1-to-1, Broadcast =
1-to-all).

 Network-Level Multicast: The "perfect" way to do this. The sender sends one packet, and the network
routers are smart enough to copy it and send it down all the paths to the receivers. This is very efficient but
complex and not widely supported on the public internet.

 Application-Level Multicasting (The Solution): Since the network routers won't do it, the applications do
it themselves.

o How it works: The applications in the group form a logical "overlay network" (often a tree). The
sender (at the root) sends the message to its 2-3 "children" in the tree. Those applications then
forward the message to their children, and so on.

o Use Case: This is how many peer-to-peer (P2P) live video streams work.

12. Gossip-Based Data Dissemination

 What it is: A way for a very large number of nodes (e.g., thousands of servers) to share ("disseminate")
information quickly and reliably.

 Analogy (Epidemic Protocol): It works exactly like a rumor or a virus (epidemic) spreading through a
population.

 How it Works:
 1. A node with new information (e.g., "Server C is down") doesn't try to tell all 10,000 other nodes.

2. Instead, it periodically picks a few (e.g., 3-5) other nodes at random and sends them the update
("gossip").

3. Any node that receives a new piece of gossip then becomes a gossiper itself. It also starts picking
random nodes to tell.

 Why it's so good:

o Highly Scalable: The load on any single node is tiny.

o Fault-Tolerant: The message gets through even if many nodes are down or slow. If one gossip fails,
the next one will just pick a different random node.

 Use Case: Widely used for failure detection, spreading configuration updates, and maintaining consistency
in large databases.