Unit 1

1. What is group communication? Explain Message ordering techniques (Absolute, consistent, and
casual ordering)

Ans -

 Group Communication refers to the process where multiple processes in a distributed system
communicate with each other simultaneously.
 In such systems, communication isn't just between two processes but rather involves broadcasting or
multicasting messages to multiple participants (group members).
 The key challenge is to ensure that messages sent by one process are delivered to all other processes
in a meaningful order.

Message Ordering Techniques are crucial for ensuring that all processes in the system have a consistent
view of the communication events. The main types of message ordering are:

1. Absolute Ordering (Total Ordering):

- In absolute ordering, all messages are delivered to all processes in the same global order.

- If process A sends message M1 and process B sends message M2, all processes must receive M1 and
M2 in the same order, even though they may have been sent from different processes.

- This method ensures strong consistency across the system but can introduce delays due to the need for
global synchronization.

2. Consistent Ordering:

- In consistent ordering, messages from the same sender are delivered in the order they were sent, but
messages from different senders may arrive in a different order at different processes.

- For example, if process A sends M1 followed by M2, all processes must receive M1 before M2.
However, messages from process B could arrive at different orders at different processes.

- This ensures local consistency but doesn't require global coordination, making it more efficient than
absolute ordering.

3. Causal Ordering:

- Causal ordering ensures that messages are delivered respecting the causal relationships between
events. If message M1 causally affects message M2 (e.g., a reply is sent after receiving a request), all
processes must see M1 before M2.

- However, messages that are independent of each other can be delivered in any order. This model
aligns with the natural order of events without requiring total global synchronization, making it more
efficient.

- It ensures that the system respects dependencies between messages, preserving logical consistency.
2. What is ordered message delivery? Compare the various ordering semantics for message
passing.

Ans

Ordered Message Delivery

 Ordered message delivery refers to the process in distributed systems where messages
exchanged between nodes are delivered in a specific, well-defined order.
 The main purpose of ordered message delivery is to maintain consistency across different
processes by ensuring that all nodes process events or messages in the same sequence.
 This ordering becomes critical in distributed systems, where events may arrive at different nodes
in different sequences due to varying network delays.
3. What is RPC? Explain in detail RPC execution

Ans -

 Remote Procedure Call (RPC) is a protocol used in distributed systems that allows a program to
execute a procedure (subroutine) on a remote server or system as if it were a local procedure call.
 RPC enables a client to invoke methods on a server residing in a different address space (often on
a different machine) as if they were local procedures.
 The client and server communicate over a network, allowing for remote interaction and
computation.

Steps in RPC Execution (as depicted in the diagram)

1. Client Makes a Call (Step 01):

- The client application makes a call to the remote procedure.

- The client calls the procedure locally, as if it's a normal function call.
2. Client Stub Packs the Request (Step 02):

- The Client Stub is a proxy function on the client machine that takes the procedure call, packs
(serializes) the arguments into a message format understandable by the server (this process is called
marshalling).

- After packing the data, the stub passes it to the RPC Runtime on the client side.

3. RPC Runtime Sends the Request (Step 03):

- The RPC Runtime is responsible for sending the packed data (now called a Call Packet) over the
network to the server machine.

- The RPC Runtime also waits for a response after sending the message.

4. Server Stub Unpacks and Calls the Procedure (Step 04):

- Once the server receives the Call Packet, the RPC Runtime on the server side forwards it to the Server
Stub.

- The Server Stub unpacks (deserializes) the data back into its original format (this process is called
unmarshalling) and calls the actual procedure (function) on the server.

5. Server Executes the Procedure and Sends the Response (Step 05):

- The procedure (or function) is executed on the server side with the provided arguments.

- Once the execution is complete, the server returns the result to the Server Stub.

- The Server Stub packs (marshals) the result and sends it back to the client.

6. Client Receives the Response (Step 06):

- The Client RPC Runtime receives the response packet (containing the result).

- The Client Stub unpacks (unmarshals) the result, and the client receives the return value as if the
procedure were executed locally.
4. What are the major issues in designing a distributed OS?

Ans -

Designing a distributed system involves addressing a variety of challenges that stem from its
decentralized and interconnected nature. The following key design issues need to be carefully managed to
ensure that the system performs well, remains scalable, secure, and provides a seamless experience for
users.

1. Scalability

- Challenge: The ability of a distributed system to handle an increasing number of nodes, users, or
requests without a drop in performance.

- Design Considerations: Systems must be designed to scale horizontally (adding more machines/nodes)
rather than just vertically (increasing capacity of individual machines). Technologies like load balancing,
sharding, and microservices architecture help in making systems scalable.

- Example: Cloud-based services like Google or Amazon are designed to dynamically scale their
resources based on traffic load.

2. Reliability

- Challenge: Ensuring the system continues to function correctly even in the presence of failures.

- Design Considerations: Reliability can be improved by using redundancy, fault-tolerant components,

and replication of critical services and data across nodes. Monitoring and failure recovery mechanisms
must also be implemented.

- Example: A distributed file system like Hadoop’s HDFS stores multiple copies of data on different
nodes to ensure data remains available even if some nodes fail.

3. Availability

- Challenge: Ensuring the system remains operational and accessible to users at all times.

- Design Considerations: High availability requires redundancy, replication, and failover mechanisms.
Ensuring that there is no single point of failure and that services can automatically recover or restart is
crucial for availability.

- Example: Cloud providers like AWS or Azure use multiple availability zones and data centers to
ensure uptime even if one location goes offline.
4. Consistency

- Challenge: Ensuring that all nodes in the system have the same view of data.

- Design Considerations: Consistency models, such as strong consistency, eventual consistency, or

causal consistency, need to be selected based on application requirements. Distributed databases like
Cassandra and DynamoDB provide tunable consistency to balance performance and consistency.

- Example: In a banking application, strong consistency is required to ensure that account balances are
the same across all nodes, whereas in social media feeds, eventual consistency may suffice.

5. Latency

- Challenge: The time it takes for a system to respond to user requests.

- Design Considerations: To reduce latency, data and services should be replicated close to the users
(e.g., using content delivery networks or edge computing). Optimizing network protocols and reducing
communication overhead between nodes also helps in reducing latency.

- Example: Netflix uses a global network of servers (CDNs) to ensure that video content is delivered
with minimal latency to users around the world.

6. Load Balancing

- Challenge: Evenly distributing the workload across all nodes in the system to prevent bottlenecks and
ensure optimal performance.

- Design Considerations: Load balancers can distribute incoming traffic or tasks across servers, ensuring
no single node is overwhelmed. Strategies include round-robin, least connections, or least response time
balancing.

- Example: A web server farm might use a load balancer to distribute incoming HTTP requests to
multiple web servers, ensuring that no one server becomes overloaded.

7. Security

- Challenge: Protecting the system from malicious attacks, unauthorized access, and data breaches.

- Design Considerations: Implementing encryption, authentication, access control, and regular security
audits are key. Distributed systems are more prone to security risks due to multiple communication
channels between nodes.

- Example: Secure communication protocols like TLS are essential for securing data transfers across
distributed systems, especially in financial applications.
8. Architectural Design Patterns

- Challenge: Choosing the right architectural pattern to suit the system’s requirements.

- Design Considerations: Architectural patterns like microservices, service-oriented architecture (SOA),

or event-driven architectures are commonly used in distributed systems. The design must be modular,
allowing independent components to scale and fail without affecting the entire system.

- Example: A microservices architecture, where different services (such as user management, payments,
and notifications) are independently developed and deployed, provides better fault isolation and
scalability.

9. Communication Issues

- Challenge: Ensuring efficient and reliable communication between distributed nodes.

- Design Considerations: Asynchronous communication, message queues, and reliable network

protocols are necessary to handle communication failures, delays, and message ordering issues. Systems
like Apache Kafka or RabbitMQ are used to handle asynchronous communication in distributed
environments.

- Example: In a real-time collaborative editing tool, efficient communication protocols are required to
synchronize the changes made by different users across multiple nodes.

10. Data Management

- Challenge: Handling large volumes of data spread across multiple nodes, while ensuring consistency,
availability, and fault tolerance.

- Design Considerations: Distributed databases, data partitioning, and replication are necessary to
manage data in distributed systems. The CAP theorem (Consistency, Availability, Partition Tolerance)
guides trade-offs in choosing a distributed database system. Systems like Cassandra and MongoDB are
designed to handle distributed data storage and management.

- Example: Google’s Bigtable and Amazon’s DynamoDB are examples of distributed databases that
manage large amounts of data with high availability and fault tolerance.
5. What are the different models used for building distributed computing systems?

1. Physical Model

A physical model represents the underlying hardware elements of a distributed system. It encompasses
the hardware composition of a distributed system in terms of computers and other devices and their
interconnections. It is primarily used to design, manage, implement, and determine the performance of a
distributed system

A physical model majorly consists of the following components:.

 Nodes
 Links
 Middleware
 Network Topology
 Communication Protocols

2. Architectural Model

Architectural model in distributed computing system is the overall design and structure of the system, and
how its different components are organised to interact with each other and provide the desired
functionalities. It is an overview of the system, on how will the development, deployment and operations
take place. Construction of a good architectural model is required for efficient cost usage, and highly
improved scalability of the applications.

The key aspects of architectural model are:

 Client-Server model
 Peer-to-peer model
 Layered model
 Micro-services model

3. Fundamental Model

The fundamental model in a distributed computing system is a broad conceptual framework that helps in
understanding the key aspects of the distributed systems. These are concerned with more formal
description of properties that are generally common in all architectural models. It represents the essential
components that are required to understand a distributed system’s behaviour. Three fundamental models
are as follows:

 Interaction Model
 Remote Procedure Call (RPC)
6. What different transparencies must a distributed system employ to achieve a single processor
image?

Ans -

1. Location Transparency

Location transparency refers to the ability to access distributed resources without knowing their physical
or network locations. It hides the details of where resources are located, providing a uniform interface for
accessing them.

 Importance: Enhances system flexibility and scalability by allowing resources to be relocated or

replicated without affecting applications.

 Examples:

o DNS (Domain Name System): Maps domain names to IP addresses, providing location
transparency for web services.

o Virtual Machines (VMs): Abstract hardware details, allowing applications to run

without knowledge of the underlying physical servers.

2. Access Transparency

Access transparency ensures that users and applications can access distributed resources uniformly,
regardless of the distribution of those resources across the network.

 Significance: Simplifies application development and maintenance by providing a consistent

method for accessing distributed services and data.

 Methods:
 o Remote Procedure Call (RPC): Allows a program to call procedures located on remote
systems as if they were local.

o Message Queues: Enable asynchronous communication between distributed components

without exposing the underlying communication mechanism.

3. Concurrency Transparency

Concurrency transparency hides the complexities of concurrent access to shared resources in distributed
systems from the application developer. It ensures that concurrent operations do not interfere with each
other.

 Challenges: Managing synchronization, consistency, and deadlock avoidance in a distributed

environment where multiple processes or threads may access shared resources simultaneously.

 Techniques:

o Locking Mechanisms: Ensure mutual exclusion to prevent simultaneous access to

critical sections of code or data.

o Transaction Management: Guarantees atomicity, consistency, isolation, and durability

(ACID properties) across distributed transactions.

4. Replication Transparency

Replication transparency ensures that clients interact with a set of replicated resources as if they were a
single resource. It hides the presence of replicas and manages consistency among them.

 Strategies: Maintaining consistency through techniques like primary-backup replication, where

one replica (primary) handles updates and others (backups) replicate changes.

 Applications:

o Content Delivery Networks (CDNs): Replicate content across geographically

distributed servers to reduce latency and improve availability.

o Database Replication: Copies data across multiple database instances to enhance fault
tolerance and scalability.

5. Failure Transparency

Failure transparency ensures that the occurrence of failures in a distributed system does not disrupt
service availability or correctness. It involves mechanisms for fault detection, recovery, and resilience.

 Approaches:

o Heartbeating: Periodically checks the availability of nodes or services to detect failures.

o Replication and Redundancy: Uses redundant components or data replicas to continue

operation despite failures.

 Examples:
 o Load Balancers: Distribute traffic across healthy servers and remove failed ones from
the pool automatically.

o Automatic Failover: Redirects requests to backup resources or nodes when primary

resources fail.

6. Performance Transparency

Performance transparency ensures consistent performance levels across distributed nodes despite
variations in workload, network conditions, or hardware capabilities.

 Challenges: Optimizing resource allocation and workload distribution to maintain predictable

performance levels across distributed systems.

 Strategies:

o Load Balancing: Distributes incoming traffic evenly across multiple servers to optimize
resource utilization and response times.

o Caching: Stores frequently accessed data closer to clients or within nodes to reduce
latency and improve responsiveness.

7. Security Transparency

Security transparency ensures that security mechanisms and protocols are integrated into a distributed
system seamlessly, protecting data and resources from unauthorized access or breaches.

 Importance: Ensures confidentiality, integrity, and availability of data and services in distributed
environments.

 Techniques:

o Encryption: Secures data at rest and in transit using cryptographic algorithms to prevent
eavesdropping or tampering.

o Access Control: Manages permissions and authentication to restrict access to sensitive

resources based on user roles and policies.

8. Management Transparency

Management transparency simplifies the monitoring, control, and administration of distributed systems by
providing unified visibility and control over distributed resources.

 Methods: Utilizes automation, monitoring tools, and centralized management interfaces to

streamline operations and reduce administrative overhead.

 Examples:

o Cloud Management Platforms (CMPs): Provide unified interfaces for provisioning,

monitoring, and managing cloud resources across multiple providers.

o Configuration Management Tools: Automate deployment, configuration, and updates

of software and infrastructure components in distributed environments.
7. What is RMI. Explain it.

Ans -

RMI stands for Remote Method Invocation. It is a mechanism that allows an object residing in one
system (JVM) to access/invoke an object running on another JVM.

RMI is used to build distributed applications; it provides remote communication between Java programs.
It is provided in the package java.rmi.

Architecture of an RMI Application

In an RMI application, we write two programs, a server program (resides on the server) and a client
program (resides on the client).

 Inside the server program, a remote object is created and reference of that object is made
available for the client (using the registry).

 The client program requests the remote objects on the server and tries to invoke its methods.
Let us now discuss the components of this architecture.

 Transport Layer − This layer connects the client and the server. It manages the existing
connection and also sets up new connections.

 Stub − A stub is a representation (proxy) of the remote object at client. It resides in the client
system; it acts as a gateway for the client program.

 Skeleton − This is the object which resides on the server side. stub communicates with this
skeleton to pass request to the remote object.

 RRL(Remote Reference Layer) − It is the layer which manages the references made by the
client to the remote object.

Working of an RMI Application

The following points summarize how an RMI application works −

1. When the client makes a call to the remote object, it is received by the stub which eventually
passes this request to the RRL.

2. When the client-side RRL receives the request, it invokes a method called invoke() of the
object remoteRef. It passes the request to the RRL on the server side.

3. The RRL on the server side passes the request to the Skeleton (proxy on the server) which finally
invokes the required object on the server.

4. The result is passed all the way back to the client.

Unit 2

What are physical and logical clock synchronization, explain the drifting of a clock.

Physical Clock Synchronization

 Physical Clock Synchronization refers to the method of aligning the time on computers or devices
to a common reference time, often using protocols like Network Time Protocol (NTP).
 This ensures that all devices in a network reflect the same physical time, which is essential for
time-sensitive applications, logging events, and coordinating actions across systems.

Logical Clock Synchronization

 Logical Clock Synchronization, on the other hand, does not rely on actual physical time but uses
a mechanism to order events in a distributed system.
 The most notable example is Lamport Timestamps, which assign a logical timestamp to each
event based on the events that occurred before it.
 This helps in maintaining a causal order of events in systems where physical time may not be
consistent.

Clock Drifting

 Clock drifting occurs when a clock's time deviates from the true time over a period due to
imperfections in the clock's mechanism or environmental factors.
 This can lead to discrepancies where devices report different times, impacting synchronization
efforts.
 For instance, if two systems are initially synchronized and one clock drifts faster than the other,
eventually they will report significantly different times, causing potential issues in event ordering
and coordination in distributed applications.
 To mitigate clock drifting, systems often implement periodic synchronization mechanisms that
adjust the clock based on a reliable time source, ensuring that any drift is corrected and
maintaining consistency across devices in a networked environment.
Write short notes on

a. Mutual Exclusion

Mutual Exclusion is a concurrency control principle used in operating systems and distributed systems to
prevent multiple processes or threads from simultaneously accessing a shared resource or critical section.
It ensures that if one process is executing in its critical section, no other process can enter its critical
section until the first process exits. Common algorithms for achieving mutual exclusion include Dekker's
algorithm, Peterson's algorithm, and using semaphores or mutexes. Ensuring mutual exclusion is crucial
for data integrity and consistency in multi-threaded environments.

b. Drifting of the Clock

Definition: Clock drift is the difference between the actual time and the time indicated by a clock.

It occurs when the clock runs faster or slower than the standard time.

The gradual deviation of a clock from the correct time over an extended period due to factors like
temperature changes, aging, and inaccuracies in the clock's mechanism

Characteristics:

• Rate of Change: Drift is typically expressed as a rate, such as seconds per day or parts per million
(ppm).

• Impact: Over long periods, drift can accumulate, leading to significant time discrepancies

c. Clock Stew

Definition: Clock skew is the difference in time readings between two clocks that are supposed to be
synchronized. It refers to the amount by which two clocks differ at a given point in time.

Characteristics:

• Causes: Skew can be caused by differences in clock rates, temperature variations, or manufacturing
discrepancies.

• Measurement: Often measured in milliseconds or microseconds.

d. Critical Section

A Critical Section is a segment of code in a concurrent program where shared resources are accessed and
modified. To maintain data integrity, only one process or thread can execute in its critical section at any
given time. The challenge of managing critical sections lies in ensuring mutual exclusion, preventing race
conditions, and avoiding deadlocks. Techniques such as semaphores, mutexes, and monitors are often
employed to control access to critical sections, ensuring that concurrent processes can safely interact with
shared data without compromising system stability.