MOD 2

1) Difference between RMI and RPC? (5 marks)

2) Define Remote Procedure Call (RPC). Explain the working of RPC in

Detail. (10 marks)

Remote Procedure Call (RPC) is a protocol that enables one program to invoke a procedure
(or function) located on a different computer or server over a network, as if it were a local
function. The core idea behind RPC is to abstract the complexities of network
communication, allowing developers to focus on high-level functionality rather than low-
level networking details.
RPC forms the foundation for many distributed systems, allowing them to share resources
and services by making cross-network function calls in a seamless and standardized way.
 Detailed Working of RPC:
To understand RPC thoroughly, it helps to look at its components, execution flow, and key
concepts involved in the communication process.

1. Key Components of RPC:

• Client:
The client is the program that initiates the request by calling a remote procedure. It behaves
as if it is making a local function call.
• Server:
The server is the remote system that implements the actual procedure and processes the
client’s request.
• Stubs (Client-side and Server-side):
Stubs act as intermediaries between the client and server. They handle the packaging
(marshalling) and unpackaging (unmarshalling) of data.
• Marshalling and Unmarshalling:
o Marshalling is the process of converting parameters into a byte stream suitable for
transmission over a network.
o Unmarshalling is the reverse process of reconstructing the original data from the
byte stream.
• Transport Layer:
Responsible for sending and receiving the messages over the network.

2. Step-by-Step Flow of RPC:

Here is how an RPC call is executed:
1. Client calls the client-side stub:
o The client invokes a local procedure call on the client stub as if calling a local
function.
2. Marshalling the parameters:
o The client stub takes the input parameters and marshals them into a format suitable
for network transmission.
3. Message is sent over the network:
o The client stub then sends the marshalled message using a system call to the
operating system, which forwards it over the network to the server.
4. Server receives the request:
o On the server side, the operating system delivers the message to the server stub.
5. Unmarshalling the request:
o The server stub unmarshals the request and extracts the parameters from the
message.
6. Procedure execution:
o The server stub calls the actual procedure using the extracted parameters.
7. Marshalling the result:
o Once the server has executed the procedure, it returns the result to the server stub,
which then marshals the return value.
8. Message sent back to client:
o The result is sent back to the client over the network via the transport layer.
9. Client receives the response:
o The client’s operating system passes the message to the client stub.
10. Unmarshalling and return:
• The client stub unmarshals the result and passes it to the original calling procedure in the
client program.

3. Types of RPC Communication:

• Synchronous RPC:
The client waits (is blocked) until the server finishes executing the requested procedure and
sends back the result.
• Asynchronous RPC:
The client sends the request and immediately proceeds with other tasks. It does not wait for
the server’s response, which will arrive later.

4. Binding in RPC:
• Static Binding:
The server to which the client binds is decided at compile-time.
• Dynamic Binding:
The client determines the server during run-time, typically using a name server or registry.

5. Advantages of RPC:
• Transparency:
Abstracts the network, making remote calls look like local ones.
• Reusability:
Enables reusability of code on the server side by exposing functionalities as services.
• Interoperability:
Facilitates communication between applications written in different languages or running on
different platforms (depending on implementation).
• Simplified Development:
Developers are relieved from handling network communication directly.

6. Disadvantages and Challenges:

• Complex Debugging:
Troubleshooting errors across multiple networked systems is more difficult than in local
programs.
• Performance Overhead:
Additional processing for marshalling/unmarshalling and network latency can reduce
performance.
• Network Dependency:
RPC is dependent on network reliability; if the network is slow or fails, so will the procedure
call.
• Security Concerns:
Communication across networks must be secured to prevent attacks, requiring encryption,
authentication, and access control.

Example of RPC in Real Use:

Suppose you are developing a calculator app. Instead of building the logic for complex
mathematical operations into every client device, you write that logic on a centralized server.
A mobile client uses RPC to send numbers to the server, asking it to compute something like
 a square root. The server processes the request and returns the result. The mobile app
simply displays the result without knowing the internal logic behind the computation.

Conclusion:
RPC is a powerful abstraction for building distributed applications by enabling function calls
across a network. Its ability to mimic local calls and simplify client-server communication has
made it a foundational concept in distributed systems. By handling tasks like message
formatting, network transmission, and interface definition, RPC allows developers to build
robust, scalable systems with ease. However, attention must be paid to network issues, error
handling, and security to fully leverage its potential.

3) Differentiate between message-oriented communication and stream

oriented communication. (10 marks)
In distributed systems and computer networking, communication between processes or
components is fundamental. Two commonly used paradigms are Message-Oriented
Communication and Stream-Oriented Communication. Each has distinct mechanisms,
benefits, and appropriate use cases. Understanding the differences between them helps in
choosing the right communication model based on application requirements like real-time
processing, reliability, or data volume.

1. Overview of Message-Oriented Communication

Message-oriented communication is a method where data is exchanged between systems in
discrete chunks, referred to as messages. Each message is a complete unit of information
that can be sent, received, and processed independently.
Key Characteristics:
• Asynchronous by nature: The sender and receiver do not need to interact with each other at
the same time. Messages can be queued and processed later.
• Message Boundaries: Messages are self-contained and maintain distinct boundaries. The
system knows where one message ends and the next begins.
• Loose Coupling: The sender and receiver are loosely connected, meaning the
communication can continue even if one party is temporarily unavailable.
• Middleware Support: Often facilitated by Message Oriented Middleware (MOM) like Apache
Kafka, RabbitMQ, or IBM MQ.
Examples:
• Email systems
• Publish/Subscribe architectures
• IoT devices sending sensor data
• Message Queueing in enterprise applications

2. Overview of Stream-Oriented Communication

Stream-oriented communication involves a continuous flow of data between two endpoints.
It operates much like a pipeline, where one process writes data to the stream and another
reads from it, often in real time.
Key Characteristics:
• Persistent Connection: A continuous connection between sender and receiver is typically
required throughout the communication session.
• No Message Boundaries: Data flows as an unstructured stream of bytes. Application logic is
required to determine where one logical message ends and another begins.
• Order Preservation: Data arrives in the same order it was sent.
• Synchronous or Near-Synchronous: Though it can be buffered, many stream-based systems
rely on real-time or near-real-time interaction.
Examples:
• Video or audio streaming (e.g., Netflix, Spotify)
• TCP connections for file transfer
• Unix pipes and inter-process communication
• Real-time chat applications

3. Detailed Comparison
Message-Oriented Stream-Oriented
Feature Communication
Communication
Communication Continuous data stream
Discrete message passing
Model
Data Units Individual messages Byte stream

Connectionless (UDP, Connection-oriented (TCP)

Connection
MOM) or loosely coupled
Message No inherent boundaries
Explicit and preserved
Boundaries
Not always guaranteed Preserves order of
Order of Delivery transmission
(depends on system)
Often higher; relies on Lower for real-time streams
Latency
queuing and buffering
Messaging apps, logging, Multimedia, file transfer,
Use Cases live data feeds
alerts, microservices

Retransmission or message Built-in reliability (TCP

Error Handling handles errors)
requeueing
Tightly coupled, good for
Flexibility Highly decoupled, scalable constant data flow

Middleware Supports queuing systems Supports protocols like TCP

Support and brokers and HTTP streaming

4. Advantages and Disadvantages

Message-Oriented Communication
Advantages:
• High scalability and fault tolerance.
• Decouples producer and consumer.
• Good for intermittent network availability.
• Supports asynchronous processing.
 Disadvantages:
• Higher complexity in ordering and consistency.
• Not suited for real-time continuous data.
• Requires message brokers or additional infrastructure.
Stream-Oriented Communication
Advantages:
• Efficient for continuous and high-volume data.
• Maintains order of data.
• Better for real-time applications like live video or voice calls.
Disadvantages:
• Tight coupling between sender and receiver.
• Requires active connection; can be vulnerable to disconnection.
• No inherent message boundaries—requires parsing logic.

5. Real-World Analogy
• Message-Oriented Communication is like mailing letters. Each letter is a complete package
with a sender and recipient. They are delivered independently, and the receiver may open
them at any time.
• Stream-Oriented Communication is like a phone call. Once the call is connected, a
continuous flow of conversation happens in real-time until the connection is terminated.

6. Conclusion
Both message-oriented and stream-oriented communication play vital roles in distributed
systems. The selection between the two depends on application requirements.
• If the application demands reliable delivery of discrete, decoupled messages, message-
oriented communication is ideal.
• If the application needs real-time, sequential, and continuous data transfer, stream-
oriented communication is the better choice.
Understanding their underlying mechanisms and differences enables system architects and
developers to design robust and scalable distributed applications tailored to their specific
communication needs.

4) What is group communication? Explain 1:M and M:1 group

communication. (10 marks)
Group communication in distributed systems refers to the exchange of information among a
set of processes or nodes that are organized into a logical group. Unlike point-to-point
communication, where a message is exchanged between a single sender and a single
receiver, group communication facilitates the transmission of messages between one-to-
many or many-to-one participants.
Group communication is essential in various distributed applications where coordination,
consistency, and reliability across multiple nodes are critical. It helps in tasks such as
collaborative processing, data replication, fault tolerance, and system monitoring.

Key Features of Group Communication:

• Scalability: Supports communication between multiple systems efficiently.
• Multicast Support: Utilizes multicast protocols like IP Multicast to deliver messages to many
recipients at once.
• Reliability: Often includes guarantees like reliable delivery, ordering, and atomic broadcast.
• Synchronization: Useful in maintaining a consistent state across replicated services or nodes.
• Transparency: The underlying group management and message dissemination are often
hidden from the application layer.

Types of Group Communication Patterns:

There are various types of communication models based on the sender-receiver relationship.
Two commonly used models are:

1. 1:M (One-to-Many) Communication:

In this model, one sender transmits a message to multiple receivers simultaneously. It is
often referred to as multicast communication.
Use Cases:
• Broadcasting notifications or alerts to multiple clients.
• Replicating data across multiple servers.
• Software updates distribution in large-scale systems.
• Collaborative applications like online gaming or video conferencing.
Example in Distributed Systems:
Consider a stock trading system where a central server sends real-time stock price updates
to thousands of client applications. Instead of sending individual messages to each client, the
server uses 1:M communication to multicast the update, ensuring all clients receive it
simultaneously.
Advantages:
• Efficiency: One message is sent and delivered to all recipients simultaneously.
• Consistency: All receivers receive the same message at the same time, improving
synchronization.
• Reduced Network Traffic: Reduces duplication of message sending across the network.
Protocols Supporting 1:M:
• IP Multicast: Used in local and wide-area networks to deliver messages to multiple
subscribers.
• Spread Toolkit: A group communication toolkit that ensures reliability and ordering.

2. M:1 (Many-to-One) Communication:

In this model, multiple senders communicate with a single receiver. It is often used in
systems where a central coordinator or server gathers data from various sources.
Use Cases:
• Sensor networks reporting data to a central server.
• Log collection from distributed microservices into a monitoring system.
• Feedback collection or voting systems in distributed protocols.
• Distributed machine learning, where worker nodes send results to a central node.
Example in Distributed Systems:
Imagine a weather monitoring system where multiple sensors in different cities send
temperature, humidity, and pressure data to a central analytics server. The server aggregates
this data to forecast weather patterns.
Advantages:
• Centralized Control: Simplifies the logic by having a central point of data collection and
decision-making.
• Aggregation: Allows for data analysis, summarization, or aggregation at a single node.
• Monitoring: Easier to implement system-wide health checks and diagnostics.
Challenges:
• Scalability: The single receiver can become a bottleneck if the number of senders grows
large.
• Fault Tolerance: If the central receiver fails, the entire communication pipeline can be
disrupted.

Technologies and Protocols Used in Group Communication:

• Apache ZooKeeper: A coordination service for distributed systems that uses group
communication for leader election, configuration management, etc.
• Message Passing Interface (MPI): Widely used in parallel computing for group-based
communication among nodes.
• Spread Toolkit and JGroups: Provide high-level group communication primitives such as
reliable multicast and membership management.

Group Communication Semantics:

Group communication systems often provide semantics to ensure reliable and ordered
delivery of messages:
1. Reliable Delivery: Ensures messages are delivered to all non-faulty group members.
2. FIFO Ordering: Messages from a sender are received in the order sent.
3. Total Ordering: All group members receive all messages in the same order.
4. Atomic Broadcast: All-or-nothing message delivery; either all members receive the message,
or none do.
These semantics are important in distributed systems for maintaining consistency,
consensus, and fault-tolerance.

Conclusion:
Group communication plays a pivotal role in modern distributed systems by enabling
structured and efficient data exchange among multiple processes. The 1:M model helps in
broadcasting messages from a central source to multiple receivers efficiently, making it ideal
for real-time updates and notifications. In contrast, the M:1 model supports gathering data
from distributed sources to a central point, which is essential in data aggregation and
monitoring systems.
By utilizing specialized group communication protocols and tools, developers can ensure
reliability, scalability, and coordination in complex distributed environments.

5) Explain the message communication model in distributed systems,

covering transient synchronous, transient asynchronous, persistent
synchronous, and persistent asynchronous communications. (10 marks)
In distributed systems, multiple computers or processes communicate with one another to
exchange data, coordinate tasks, and maintain system-wide coherence. This communication
is primarily facilitated through message-passing mechanisms, given the absence of shared
memory. A well-defined message communication model helps ensure effective and reliable
interaction between distributed components.
Two critical characteristics that define communication in distributed systems are:
1. Persistence – Determines how long a message remains in the system if the recipient is not
available.
2. Synchronicity – Defines whether the sender waits (blocks) for the message to be delivered or
processed before continuing.
Combining these two characteristics yields four fundamental message communication
models:

1. Transient Asynchronous Communication

Definition:
In this model, the message is sent and not stored anywhere if the receiver is not ready or
available. Additionally, the sender does not wait for an acknowledgment after sending the
message. Once the message is sent, it is considered "gone."
Characteristics:
• Transient: Message exists only while the receiver is active and available.
• Asynchronous: Sender continues its operation immediately after dispatching the message.
• No Guarantees: Message may be lost if the receiver crashes or is unavailable at the time of
sending.
Example:
• UDP (User Datagram Protocol) communication in networked applications.
• A weather sensor broadcasts data periodically; if the listener isn't running at that moment,
the message is lost.
Advantages:
• Low latency
• Efficient for real-time or non-critical data
Disadvantages:
• Not reliable
• No delivery confirmation or retry mechanism

2. Transient Synchronous Communication

Definition:
The sender waits (is blocked) until the message is acknowledged by the receiver or at least
until it is confirmed that the message was delivered.
There are different variants depending on when the sender is unblocked:
• When the message is delivered.
• When the message is received and acknowledged.
• When the response is received after message processing.
Characteristics:
• Transient: Message is lost if the recipient is unavailable.
• Synchronous: Sender is blocked until a certain event (like delivery or processing
acknowledgment).
Example:
• Traditional Remote Procedure Call (RPC) over unreliable transport layers.
• Real-time gaming interactions where acknowledgement is required but no message storage
exists.
Advantages:
• Greater control and assurance of delivery than asynchronous.
• Feedback allows for better error handling.
Disadvantages:
• Blocking may reduce efficiency.
• Still not reliable under network failures.
 3. Persistent Asynchronous Communication
Definition:
In this model, messages are stored persistently until the receiver is ready to accept them.
The sender does not wait for acknowledgment and can continue processing immediately
after sending.
Characteristics:
• Persistent: Messages are stored in queues or buffers until delivery.
• Asynchronous: Sender does not wait for any response.
Example:
• Email systems
• Messaging Queues like Kafka, RabbitMQ, and Azure Service Bus
Advantages:
• Very reliable – messages are not lost even if the receiver is down.
• Ideal for decoupled systems or delayed processing.
Disadvantages:
• Higher overhead due to persistent storage.
• Delivery delays are possible.

4. Persistent Synchronous Communication

Definition:
The sender waits for acknowledgment that the message has been received (or processed),
and the message itself is stored persistently until that happens. This model ensures reliable
and interactive communication with guarantees of delivery.
Characteristics:
• Persistent: Messages are saved until the receiver confirms successful receipt.
• Synchronous: Sender is blocked until confirmation of delivery or processing.
Example:
• Financial transactions using secure messaging systems.
• Order confirmation in e-commerce systems where reliability is critical.
Advantages:
• Guarantees reliability and delivery acknowledgment.
• Useful for mission-critical applications.
Disadvantages:
• High latency
• Greater resource consumption due to blocking and message storage
Why These Models Matter in Distributed Systems:
In a distributed system, communication is not always reliable or timely due to network
failures, latency, or system crashes. These four models help in selecting appropriate
mechanisms based on application needs:
• High performance, low reliability? → Transient Asynchronous
• Reliable delivery with delay tolerance? → Persistent Asynchronous
• Critical transactions needing confirmation? → Persistent Synchronous
Each model strikes a balance between speed, reliability, and resource usage. Understanding
these combinations helps developers design scalable, fault-tolerant, and efficient systems
tailored to specific use cases.