​ ​ ​ ​ ​ DC Exam Prep

1)​ Identify and explain issues in distributed system?

Ans

A distributed system is a network of independent computers that appear to the users

as a single coherent system. While distributed systems offer high scalability,
availability, and performance, they also introduce a variety of complex challenges.
This assignment highlights the six major issues faced in the design and
implementation of distributed systems.

1. Fault Tolerance

Definition:​
Fault tolerance is the system’s ability to continue functioning even in the presence of
failures (hardware, software, or network).

Explanation:

●​ Failures are inevitable due to distributed nature.​

●​ Systems must detect, isolate, and recover from faults.​

●​ Examples: Data replication, checkpointing, retries, etc.​

2. Scalability

Definition:​
Scalability refers to the system's ability to handle growing amounts of work or its
potential to accommodate growth.

Explanation:

●​ Adding more nodes should not degrade performance.​

●​ Issues: Bottlenecks, increased communication, and management complexity.​

●​ Solutions include distributed databases, load balancing, and partitioning.​

3. Security

Definition:​
Security is about protecting data and resources from unauthorized access and
ensuring integrity and confidentiality.

Explanation:

●​ Threats include data breaches, man-in-the-middle attacks, and denial of

service.​

●​ Distributed nature increases attack surface.​

●​ Techniques: Encryption, authentication, authorization, firewalls.​

4. Synchronization

Definition:​
Synchronization ensures that the operations across distributed nodes are
coordinated in time.

Explanation:

●​ There is no global clock in distributed systems.​

●​ Event ordering (Lamport Timestamps, Vector Clocks) is needed.​

●​ Ensures consistency, mutual exclusion, and coordination.​

5. Resource Management

Definition:​
Resource management involves efficient allocation and scheduling of distributed
resources.

Explanation:

●​ Includes CPU cycles, memory, storage, and bandwidth.​

 ●​ Challenges: Heterogeneous systems and dynamic availability.​

●​ Requires load balancing, scheduling algorithms, and monitoring.​

6. Transparency

Definition:​
Transparency hides the complexities of the distributed system from the user and
programmer.

Types of Transparency:

●​ Access Transparency: Access to resources appears uniform.​

●​ Location Transparency: User need not know where resources are.​

●​ Replication & Failure Transparency: Failures and replicas are hidden.​

Explanation:

●​ Important for usability and fault recovery.​

●​ Difficult to implement in complex, large-scale systems.

●​

7. Heterogeneity

Definition:​
Heterogeneity refers to the diversity in hardware, operating systems, networks, and
programming languages in a distributed system.

Explanation:

●​ Components may differ in architecture and software environment.​

●​ Communication and interoperability can become complex.​

●​ Solutions: Middleware, standard communication protocols (e.g., REST, RPC).​

8. Concurrency

Definition:​
Concurrency is the ability of the system to allow multiple processes to execute
simultaneously.

Explanation:

●​ Multiple users/processes can access shared resources concurrently.​

●​ Risks: Race conditions, deadlocks, inconsistency.​

●​ Techniques: Locks, semaphores, transaction protocols (e.g., 2PC, 3PC).

Conclusion

Distributed systems offer immense benefits in terms of scalability and efficiency.

However, they also introduce multiple challenges—ranging from fault tolerance to
heterogeneity and concurrency. Effective handling of these issues is essential to
ensure the robustness and usability of the system. With careful design and modern
tools, most of these issues can be minimized to deliver seamless distributed
experiences.

2)​ Analyze how Ricard - Agrawala's algorithm optimises the message overhead in
acheiving mutual exclusion?
Ans

The Ricart–Agrawala algorithm is an efficient decentralized approach to achieving mutual

exclusion in distributed systems. It optimizes message overhead primarily by reducing the
number of messages exchanged for critical section (CS) entry.

In this algorithm, when a process wants to enter the CS, it sends a REQUEST message to
all (N − 1) processes. Each receiving process either immediately replies with a REPLY
message or defers the reply based on the timestamp comparison. The requesting process
enters the CS only after receiving all (N − 1) REPLY messages.

The optimization in message overhead comes from the following aspects:

1.​ Reduced Number of Messages:​

Unlike Lamport’s algorithm which uses 3(N − 1) messages (REQUEST, REPLY,
RELEASE), Ricart–Agrawala only uses 2(N − 1) messages per CS entry. There is no
 separate RELEASE message needed.​

2.​ No Central Coordinator:​

The algorithm avoids the central coordinator model, which typically reduces
communication costs and eliminates a single point of failure.​

3.​ Efficient Conflict Resolution Using Timestamps:​

Logical timestamps allow processes to determine the order of requests without extra
communication. This avoids redundant messaging and maintains fairness.​

4.​ Deferred Replies:​

If a process is in or requesting the CS with a higher priority (based on timestamp), it
defers the REPLY. This ensures only necessary messages are sent, contributing to
message efficiency.​

Overall, the Ricart–Agrawala algorithm maintains mutual exclusion while minimizing the
communication cost, making it suitable for systems where message efficiency is critical.

3) Compare Threads vs Process

4) Describe the desirable features of global scheduling algorithm?

Ans:

1. Introduction
Global scheduling in distributed systems refers to the process of making scheduling
decisions by considering the state and workload of all available nodes in the system. Unlike
local scheduling, which only considers one node, global scheduling attempts to optimize
performance across the entire distributed system.

2. Desirable Features of a Global Scheduling Algorithm

1. Fairness

The algorithm should ensure that no task or user is unfairly delayed or starved. All tasks
should receive equitable access to computational resources.

2. Efficiency

It should maximize system throughput and minimize job completion time. Idle resources
must be efficiently utilized.

3. Scalability

The algorithm must scale well with the increasing number of tasks and computing nodes
without degradation in performance.

4. Adaptability

It must adapt to changes in workload, resource availability, and system configuration in real
time.

5. Low Overhead

The scheduling mechanism should not consume excessive network bandwidth, memory, or
processing power.

6. Load Balancing

Workload should be evenly distributed among all participating nodes to avoid bottlenecks
and improve overall system performance.

7. Fault Tolerance

The algorithm should handle node failures gracefully by redistributing the tasks without
interrupting ongoing processes.

8. Transparency

Users should not be aware of the complexity involved in scheduling. The system should
provide location and access transparency.

9. Priority Support
It should support scheduling based on task priorities, ensuring that critical or time-sensitive
tasks are executed promptly.

3. Conclusion

A good global scheduling algorithm in a distributed system must be fair, efficient, scalable,
and fault-tolerant. It should ensure optimal use of system resources while providing a
transparent and reliable computing environment for the users.

5) Explain message communication model in DS covering transient synchronous trancient

asynchronous persistent synchronous and persistent asynchronous?

Ans:

1. Introduction

In Distributed Systems (DS), processes residing on different nodes must communicate with
each other to exchange data and coordinate actions. Communication between these
processes is typically done using message passing. The Message Communication Model
defines how messages are sent, stored, and received, and is broadly classified based on
two dimensions:

●​ Synchronous vs. Asynchronous Communication​

●​ Persistent vs. Transient Communication​

2. Communication Dimensions

a. Synchronous Communication

In synchronous communication, the sender and receiver must be active simultaneously. The
sender blocks (waits) until the receiver acknowledges receipt of the message.

b. Asynchronous Communication

In asynchronous communication, the sender does not wait for the receiver. It sends the
message and continues its execution without blocking.

c. Persistent Communication
In persistent communication, the message is stored by the communication system
(middleware or message queue) until it is successfully delivered to the receiver, even if the
receiver is temporarily unavailable.

d. Transient Communication

In transient communication, the message is stored only while both sender and receiver are
active. If the receiver is not ready or the message is not delivered immediately, it is lost.

3. Types of Communication Models

Type Sender Message Message Lost If... Example
Waiting Storage

Transient Yes Not stored Receiver not Phone call with no

Synchronous available instantly voicemail

Transient No Not stored Receiver not Text message sent

Asynchronous ready at the to offline user
moment

Persistent Yes Stored until - Voicemail, or

Synchronous delivery blocking email
send

Persistent No Stored until - Email, message

Asynchronous delivery queue systems

i. Transient Synchronous Communication

●​ In this model, the sender waits for the receiver to be ready and to acknowledge
receipt of the message.​

●​ If the receiver is not available at the time of sending, the message is discarded.​

●​ Use Case: Real-time systems or live chat without message buffering.​

ii. Transient Asynchronous Communication

●​ Here, the sender sends the message and does not wait.​

●​ However, the message will be lost if the receiver is not available or ready.​

●​ Use Case: Unreliable datagram-based protocols (e.g., UDP).​

iii. Persistent Synchronous Communication

●​ The sender waits until the message is stored and acknowledged by the receiver.​

●​ The message is kept in storage (queue or buffer) until the receiver receives it.​

●​ Use Case: Systems that require guaranteed delivery with confirmation (e.g., email
systems with delivery receipts).​

iv. Persistent Asynchronous Communication

●​ The sender does not wait for the receiver.​

●​ The message is stored and delivered whenever the receiver is ready.​

●​ Use Case: Message queue systems like Kafka, RabbitMQ.​

4. Conclusion

The choice of a communication model in distributed systems depends on the requirements

for timing, reliability, and performance. Persistent models offer higher reliability but may
incur storage overhead, whereas transient models are lightweight but less reliable. Similarly,
synchronous models provide tight coordination at the cost of blocking, while asynchronous
models support concurrent execution.

6) Describe the working of RPC (Remote Procedure Call) in detail.

Ans:

1. Introduction

Remote Procedure Call (RPC) is a powerful communication mechanism used in distributed

systems, which allows a program to invoke a function located on another computer in the
network, as if it were a local function. It abstracts the underlying network communication and
provides a seamless interface to the programmer.

2. Components of RPC

●​ Client: Initiates the function call.​

 ●​ Server: Provides the actual implementation of the function.​

●​ Client Stub: Interface on the client side that represents the remote function.​

●​ Server Stub: Interface on the server side that receives the call and invokes the
actual function.​

●​ Marshalling/Unmarshalling: The process of packing and unpacking function

parameters for transmission over the network.​

3. Working of RPC – Step-by-Step Flow

1.​ Client calls the local stub function.​

2.​ Client stub marshals the procedure name and arguments into a message.​

3.​ The message is sent over the network to the server.​

4.​ Server stub unmarshals the message and retrieves the arguments.​

5.​ Server stub calls the actual procedure.​

6.​ The result is marshalled back into a message by the server stub.​

7.​ The message is sent to the client stub.​

8.​ The client stub unmarshals the result and returns it to the client program.​

4. Features of RPC

●​ Transparency: Hides the complexities of remote communication.​

●​ Language and OS independence.​

●​ Synchronous or asynchronous communication possible.​

5. Advantages
 ●​ Simplifies distributed computing.​

●​ Allows reuse of remote services.​

●​ Easy to integrate with existing systems.​

6. Disadvantages

●​ Network dependency may cause delays or failures.​

●​ Limited support for complex data types.​

●​ Harder to debug compared to local procedure calls.​

7. Diagram of RPC Flow

(In actual exams, draw a diagram showing Client → Stub → Network → Server Stub →
Procedure and back.)

8. Conclusion

RPC is a vital concept in distributed systems that simplifies the process of calling remote
services. By making remote calls appear as local calls, it improves abstraction and
modularity, enabling scalable system development.

7) Explain suzuki kasami broadcast algorithm for mutual exclusion?

Ans:

1. Introduction

In distributed systems, mutual exclusion is essential to prevent concurrent access to critical

shared resources. The Suzuki-Kasami algorithm is a token-based broadcast algorithm
that ensures mutual exclusion among distributed processes using a single transferable
token.

2. Terminology
 ●​ Token: A unique control message that grants permission to enter the critical section.​

●​ Request Number (RN[i]): An array maintained by each process to store the latest
request number from each process.​

●​ Last Request Number (LN[i]): Maintained in the token; represents the last request
number served for each process.​

3. Working of the Algorithm

i. Requesting Critical Section

●​ When a process Pi wants to enter the critical section:​

○​ It increments its request number RN[i].​

○​ It broadcasts a request message to all other processes.​

ii. Receiving a Request

●​ When a process Pj receives a request from Pi, it updates RN[i] if the request
number is higher than the one it has.​

iii. Granting the Token

●​ If Pj holds the token and is not in the critical section, and it sees that RN[i] >
LN[i], it sends the token to Pi.​

iv. Entering and Releasing the Critical Section

●​ The process that receives the token enters the critical section.​

●​ After exiting, it updates the token's LN[i] to its latest served request.​

●​ It checks for any other pending requests. If found, it sends the token to the next
eligible process.​

4. Example Flow
Assume 3 processes: P0, P1, P2

●​ P0 holds the token.​

●​ P2 requests critical section:​

○​ P2 sends request to all.​

○​ P0 sees P2’s request and sends the token.​

○​ P2 enters CS, exits, and sends token to next requester if any.​

5. Advantages

●​ Only one token → no conflicts.​

●​ Broadcast ensures global awareness of requests.​

●​ Fewer messages in the long run compared to some other mutual exclusion
algorithms.​

6. Disadvantages

●​ Token loss may lead to deadlock.​

●​ Token recovery mechanism is needed.​

●​ Requires reliable broadcasting.​

7. Conclusion

Suzuki-Kasami’s algorithm is a simple and efficient solution for achieving mutual exclusion in
distributed systems using a single token and broadcasted requests. It offers fairness,
simplicity, and reduced message overhead in the long run.

8) Analyze the architecture and performance of Andrew File System (AFS). Compare it
with Network File System (NFS). Discuss the advantages and limitations of each.
Ans:

1. Introduction

Distributed File Systems (DFS) allow multiple users and systems to share files across a
network as if the files were stored locally. Two notable DFS implementations are the Andrew
File System (AFS) and the Network File System (NFS). Each follows a client-server
architecture but differs significantly in their design, performance, and scalability.

2. Architecture of AFS

●​ AFS follows a client-server architecture.​

●​ It employs whole-file caching on the client side.​

●​ When a client accesses a file, it downloads the entire file locally.​

●​ A callback mechanism ensures consistency by notifying clients when a cached file

is updated on the server.​

3. Architecture of NFS

●​ NFS also uses a client-server model.​

●​ Clients access files remotely, without downloading the entire file.​

●​ It relies on Remote Procedure Calls (RPC) for communication.​

●​ Earlier versions lack caching; later versions introduced limited caching mechanisms.​

4. Performance Comparison

Criteria AFS NFS

File Access Local (after first access) Remote (every time)

Server Load Lower (due to caching) Higher

Network Traffic Reduced after first Continuous

access

Consistency Maintained via callbacks Maintained via frequent

checks

Scalability High Limited

5. Advantages and Limitations

AFS Advantages:

●​ Efficient performance with reduced server communication.​

●​ Scalable for large systems.​

●​ Callback mechanism reduces unnecessary traffic.​

AFS Limitations:

●​ More complex to configure.​

●​ Large file downloads may cause delays on first access.​

NFS Advantages:

●​ Simple and widely supported.​

●​ Effective for small, local networks.​

NFS Limitations:

●​ High dependency on the server.​

●​ Lower performance due to repeated remote access.​

6. Conclusion

While both AFS and NFS serve the purpose of file sharing in a distributed environment, AFS
offers better scalability and performance due to its caching mechanism and callback
strategy. NFS, though simpler, may suffer from performance bottlenecks in larger systems.
The choice depends on the system size, complexity, and performance requirements.

*****Advantages of AFS (Andrew File System)

1.​ Efficient Caching​

○​ Caches entire files locally, reducing repeated server requests.​

2.​ Reduced Server Load​

○​ Clients operate independently after receiving files.​

3.​ Scalability​

○​ Suitable for systems with hundreds or thousands of clients.​

4.​ Callback Mechanism​

○​ Server notifies clients when a file has been modified → ensures consistency
efficiently.​

5.​ Location Transparency​

○​ Clients don’t need to know file server locations; files appear to be locally
available.​

6.​ Security & Authentication (AFS3)​

○​ Uses Kerberos authentication for secure access.​

7.​ Fault Tolerance​

○​ If the server is temporarily unavailable, cached files may still be accessible.​

❌ Limitations of AFS
 1.​ High Initial Latency​

○​ First-time access is slow as the entire file is downloaded.​

2.​ Complex Setup​

○​ More difficult to configure and maintain than NFS.​

3.​ Write Delay​

○​ Changes are written back only when the file is closed, not instantly → not
ideal for real-time collaborative editing.​

4.​ Larger Cache Requirements​

○​ Needs more disk space on client side to store full file caches.​

5.​ Token Management​

○​ In multi-user file editing, managing who has access to what becomes

complex.​

✅ Advantages of NFS (Network File System)

1.​ Simplicity​

○​ Easy to install and set up in Unix/Linux environments.​

2.​ Transparent Access​

○​ Files appear local even if they’re stored remotely.​

3.​ Real-Time File Sharing​

○​ Files can be edited by multiple users in real-time (no full caching).​

4.​ Wide Support​

○​ NFS is supported by nearly all operating systems.​

5.​ Version Improvements​

○​ Newer versions (NFSv4) offer better caching, security, and performance.​

 6.​ Low Disk Use on Client​

○​ No need to store entire files locally.​

❌ Limitations of NFS
1.​ High Server Load​

○​ Every read/write request goes to the server → bottleneck risk.​

2.​ Poor Network Performance Impact​

○​ Slower networks can lead to significant lag in file access.​

3.​ Limited Caching (Older Versions)​

○​ Earlier versions lack effective caching, unlike AFS.​

4.​ Security Concerns​

○​ Basic authentication in older versions can lead to unauthorized access.​

5.​ No Offline Access​

○​ If server goes down or network breaks, client cannot access files.​

6.​ Concurrency Issues​

○​ Multiple users editing the same file at once may lead to conflicts.

9) Compare Load Sharing, Task Assignment, and Load Balancing

strategies for process scheduling in Distributed Systems.

Ans:

In a Distributed System (DS), scheduling strategies are critical for improving resource
utilization, responsiveness, and system performance. Three prominent strategies are Load
Sharing, Task Assignment, and Load Balancing. Each strategy aims to optimize the
placement of processes, but they differ in their goals, timing, and implementation.

1. Load Sharing Strategy

 ●​ Definition:​
Load sharing aims to prevent overload by transferring tasks from overloaded nodes
to underloaded ones.​

●​ Key Features:​

○​ Reactive approach.​

○​ No global system knowledge required.​

○​ Triggered only when a node becomes heavily loaded.​

●​ Advantages:​

○​ Simple and easy to implement.​

○​ Reduces bottlenecks caused by overloads.​

●​ Limitations:​

○​ Does not aim for equal distribution.​

○​ Idle nodes may remain underutilized.​

○​ May lead to suboptimal performance in balanced environments.​

2. Task Assignment Strategy

●​ Definition:​
This strategy selects the best-suited node for a task at the time of arrival based on
predefined metrics like CPU power, memory availability, etc.​

●​ Key Features:​

○​ Decision made at the time of task submission.​

○​ Uses heuristics like minimum load, fastest processor, etc.​

●​ Advantages:​

○​ Efficient task placement based on known capabilities.​

○​ Reduces chances of bad placements.​

 ●​ Limitations:​

○​ Requires accurate knowledge of node capabilities.​

○​ Does not account for dynamic load changes.​

○​ Once assigned, tasks are usually not migrated.​

3. Load Balancing Strategy

●​ Definition:​
Load balancing aims to distribute tasks evenly among all available nodes to
optimize system-wide performance.​

●​ Key Features:​

○​ Proactive and dynamic.​

○​ Involves continuous monitoring of system loads.​

○​ May include task migration.​

●​ Advantages:​

○​ Ensures optimal resource utilization.​

○​ Prevents both overloading and underutilization.​

○​ Improves overall system performance.​

●​ Limitations:​

○​ Complex to implement.​

○​ Requires frequent communication and monitoring.​

○​ May cause overhead due to task migration.​

Comparison Table
 Feature Load Sharing Task Assignment Load Balancing

Main Goal Avoid overload Assign task to best Equalize load across
node all nodes

Timing Reactive At task arrival Proactive &

continuous

Load Information Minimal Static or limited Full global system

Required (local/partial) dynamic data view

Task Migration Rare No Yes

Complexity Low Medium High

Performance Moderate Good (if task fits High

node)

Conclusion

All three strategies serve different purposes in distributed systems. Load Sharing is simple
and suitable for small or loosely-coupled systems. Task Assignment provides initial
efficiency but lacks adaptability. Load Balancing, though complex, ensures optimal and fair
use of resources, especially in large-scale or dynamic systems.

10) Explain the Bully Election Algorithm with the help of an example.

Ans:

In distributed systems, a coordinator is responsible for managing shared resources or

synchronization among processes. If the coordinator fails, an election algorithm is used to
select a new one. One such algorithm is the Bully Election Algorithm, which elects the
process with the highest process ID as the new coordinator.
1. Introduction to Bully Election Algorithm:

The Bully Algorithm is a leader election algorithm used in distributed systems where
each process has a unique identifier (ID). The algorithm ensures that the process with the
highest ID becomes the new coordinator after failure detection.

2. Working of the Bully Algorithm:

●​ Each process in the system is assigned a unique numeric ID.​

●​ A process initiates an election if it detects that the current coordinator has failed.​

●​ It sends an ELECTION message to all processes with higher IDs.​

●​ If no higher ID process replies, the initiating process becomes the new

coordinator and sends a COORDINATOR message to all others.​

●​ If one or more higher ID processes respond with an OK message, the initiating

process withdraws, and the higher ID process continues the election in the same
way.​

●​ This continues until the process with the highest ID, which receives no response
from higher processes, declares itself the coordinator.​

3. Example:

Consider 5 processes in a system:

arduino

CopyEdit

Process IDs: P1, P2, P3, P4, P5

1 2 3 4 5

Let the current coordinator (P5) crash. Here's how the election proceeds:

1.​ P2 detects the failure and initiates an election.​

○​ Sends ELECTION messages to P3, P4, and P5.​

 ○​ P3 and P4 respond with OK. P5 is unresponsive (crashed).​

○​ P2 withdraws from the election.​

2.​ P3 continues the election.​

○​ Sends ELECTION to P4 and P5.​

○​ P4 responds with OK. P5 is unresponsive.​

○​ P3 withdraws.​

3.​ P4 now initiates.​

○​ Sends ELECTION to P5.​

○​ No response from P5.​

○​ P4 declares itself the new coordinator.​

4.​ P4 sends COORDINATOR message to P1, P2, and P3 to inform them of the new
coordinator.​

4. Key Messages Used:

Message Description
Type

ELECTION Sent to higher ID processes to start election

OK Sent by higher ID process to acknowledge it's

alive

COORDINATO Sent by the new leader to announce itself

R
5. Advantages:

●​ Simple and easy to understand.​

●​ Guarantees that the process with highest ID becomes coordinator.​

●​ Suitable when process IDs represent relative power (e.g., computing capacity).​

6. Limitations:

●​ Generates many messages, especially in large systems.​

●​ Assumes that all processes know each other’s IDs.​

●​ Assumes reliable message delivery and process availability.​

●​ Not efficient for dynamic systems where nodes frequently join or leave.​

7. Conclusion:

The Bully Election Algorithm ensures that the process with the highest ID becomes the
coordinator in case of failures. Although simple and effective in smaller systems, its
performance can degrade in large, dynamic environments due to high message overhead.

11) Explain the Different Data-Centric Models in Distributed Systems.

Ans:

In Distributed Systems, Data-Centric Models define how data is structured, stored,

accessed, and synchronized across multiple nodes. These models aim to ensure data
consistency, availability, and performance in environments where data may be
replicated or distributed.

The main Data-Centric Models include:

1. Replication Model

●​ Definition:​
In this model, multiple copies (replicas) of data are maintained across different
 nodes.​

●​ Purpose:​
Improve fault tolerance, availability, and performance.​

●​ Types of Replication:​

○​ Synchronous Replication: All replicas are updated at the same time.​

○​ Asynchronous Replication: Updates are sent to replicas after a delay.​

●​ Challenges:​

○​ Maintaining consistency among all replicas.​

○​ Handling conflicts due to concurrent updates.​

2. Caching Model

●​ Definition:​
Frequently accessed data is stored in a local temporary memory (cache) to
reduce access time.​

●​ Purpose:​
Enhance performance by reducing communication with the main data server.​

●​ Types:​

○​ Client-side Caching: Cache is stored on the user's device.​

○​ Server-side Caching: Cache is maintained at the server.​

●​ Challenges:​

○​ Staleness: Cached data might become outdated.​

○​ Requires cache consistency protocols.​

3. Mobile Model

●​ Definition:​
The data or computation moves across different nodes to be closer to the user or
 where it's needed.​

●​ Example:​
In edge computing, data is moved closer to the device (mobile, IoT) for faster
response.​

●​ Purpose:​
Improve responsiveness and reduce network latency.​

●​ Challenges:​

○​ Ensuring data security during movement.​

○​ Managing updates and versions.​

4. Transaction Model

●​ Definition:​
Data operations are grouped into transactions that follow the ACID properties
(Atomicity, Consistency, Isolation, Durability).​

●​ Purpose:​
Ensure reliable updates and data integrity even in failure conditions.​

●​ Challenges:​

○​ Implementing distributed two-phase commit protocols.​

○​ Handling network partitions or failures.​

5. Consistency Models

●​ Definition:​
Define how updates to a data item are visible to different users in the system.​

●​ Types:​

○​ Strict Consistency: All users see the same value at the same time.​

○​ Sequential Consistency: Operations appear in same order for everyone.​

 ○​ Eventual Consistency: All replicas will eventually become consistent.​

○​ Causal Consistency: Preserves the cause-effect relationship between

operations.​

●​ Purpose:​
Balance between performance and correctness.​

✅ Advantages of Data-Centric Models:

●​ Efficient data sharing and storage.​

●​ High availability through replication and caching.​

●​ Flexibility to choose consistency vs. speed tradeoffs.​

●​ Improved fault tolerance.​

❌ Limitations:
●​ Complexity in managing replication and consistency.​

●​ Overhead due to synchronization and conflict resolution.​

●​ Difficulties in ensuring data integrity across failures or concurrent access.​

Conclusion:

Data-Centric Models are fundamental in distributed systems to manage how data is

handled across multiple nodes. They provide different strategies like replication, caching,
transactions, and consistency models to ensure that data remains reliable, accessible, and
consistent, despite the challenges of distribution.

11) Explain Maekawa’s Algorithm for Mutual Exclusion and specify the properties of Quorum
Sets

Ans:

Maekawa’s algorithm is a distributed mutual exclusion algorithm designed to reduce the

number of messages and decision overhead compared to fully connected approaches. The
algorithm introduces the concept of quorum sets to ensure that mutual exclusion is
maintained with fewer communication messages.

1. Basic Concept:

Each process in the system is associated with a quorum set, a subset of processes
(including itself). To enter the Critical Section (CS), a process must obtain permission
(REPLY) from all members of its quorum.

The key idea is that all quorum sets intersect — meaning that any two processes must
share at least one common process in their respective quorum sets. This common member
ensures that no two processes can enter the CS simultaneously.

2. Algorithm Steps:

A. Request Phase:

●​ The requesting process Pi sends a REQUEST message to all processes in its quorum
set Qi.​

B. Granting Phase:

●​ A process grants permission to only one request at a time.​

●​ If it has already granted permission to another, it queues incoming requests.​

C. Enter Critical Section:

●​ Process Pi enters CS after receiving REPLY from all members of Qi.​

D. Release Phase:

●​ After exiting CS, Pi sends a RELEASE message to all in Qi.​

●​ Quorum members can now process next queued request, if any.​

3. Quorum Set Properties:

To ensure correctness, quorum sets must satisfy the following:

 Property Description

Intersection Every pair of quorum sets must share at least one process in
common.

Minimality Quorum sets should be as small as possible while still

intersecting.

Symmetry All processes may have quorum sets of the same size (for
(optional) fairness).

4. Example:

Assume 9 processes: P1 to P9.

●​ P1’s quorum: {P1, P2, P3}​

●​ P2’s quorum: {P2, P3, P4}​

●​ P3’s quorum: {P3, P1, P5}​

Notice all quorums intersect with each other.

If P1 wants to enter CS:

●​ It sends REQUEST to P1, P2, P3.​

●​ Waits for REPLY from all.​

●​ Once done, sends RELEASE.​

5. Advantages:

●​ Reduces message complexity to O(√n).​

 ●​ No need to contact all processes.​

●​ Decentralized and fault-tolerant.​

6. Limitations:

●​ Requires careful design of quorum sets.​

●​ Deadlocks and starvation are possible without proper request queuing.​

●​ Quorum members may become bottlenecks if over-requested.​

Conclusion:

Maekawa’s algorithm uses quorum-based permissions to ensure mutual exclusion in

distributed systems with reduced communication overhead. By satisfying specific quorum
properties, it guarantees correctness and improves efficiency compared to traditional mutual
exclusion algorithms.

12) Explain code migration?

Ans:

1. Introduction

Code migration refers to the movement of code across different nodes in a distributed
system. It enables dynamic relocation of processes or components from one machine to
another during execution, allowing the system to achieve better load balancing, flexibility,
and resource utilization.

In distributed environments, code migration is a key feature in mobile agents, cloud

platforms, and adaptive applications.

2. Types of Code Migration

Code migration can be classified into the following types based on what is transferred:

a. Weak Mobility

●​ Only the code segment is moved.​

 ●​ The execution starts from the beginning at the new machine.​

●​ Example: Applets in a browser.​

b. Strong Mobility

●​ Both the code and execution state (e.g., variables, program counter) are moved.​

●​ The program resumes from where it left off.​

●​ More complex but provides seamless execution.​

3. Components Involved in Migration

A migrating entity usually consists of:

●​ Code Segment: Instructions to be executed.​

●​ Execution State: Values of variables, program counter, call stack, etc.​

●​ Resource Bindings: References to external files, databases, or devices.​

4. Approaches to Code Migration

a. Process Migration

●​ The entire running process is moved from one node to another.​

●​ Used in load balancing and fault tolerance.​

●​ Example: Process migration in Linux clusters.​

b. Object Migration

●​ Objects (in object-oriented systems) are moved, including their methods and
attributes.​

●​ Popular in Java RMI and CORBA environments.​

c. Mobile Agent Migration

 ●​ An autonomous agent moves with code, state, and data.​

●​ Acts independently and intelligently.​

●​ Used in network monitoring and e-commerce.

Why Do We Do Code Migration? (Simple Reasons)

1.​ To Balance Workload (Load Balancing)​

If one computer is doing too much work, we move some tasks to less busy
computers. This keeps the system fast and prevents overloading.​

2.​ To Improve Speed (Reduce Delay)​

Sometimes, it's faster to move the code closer to the data or user.​
Example: If your program needs data stored on Computer B, moving the code to B
will make access faster than fetching data over the network.​

3.​ To Handle Failures (Fault Tolerance)​

If one machine is going to crash or shut down, we move the code somewhere else
to keep things running.​

4.​ To Save Money (Cloud Usage)​

In cloud systems, we run code on cheaper or more available servers. So, we move
code to servers that cost less or are more available.​

5.​ To Update or Replace Software Dynamically​

If a newer version of a program is available, we can replace the old code without
stopping the whole system. This makes maintenance easier.

Benefits of Code Migration

●​ Load Balancing: Tasks move from busy nodes to idle ones.​

●​ Dynamic Deployment: Code can be updated or replaced on-the-fly.​

●​ Reduced Latency: Bringing computation closer to data sources.​

●​ Fault Tolerance: Faulty nodes can hand over their tasks to healthy ones.​

7. Challenges in Code Migration

●​ Security Issues: Migrated code might be malicious or tampered.​

●​ Heterogeneity: Different architectures (e.g., OS, CPU types) complicate migration.​

 ●​ State Transfer: Capturing and restoring execution state is difficult in strong mobility.​

●​ Resource Binding: Ensuring access to external dependencies at the new location.​

8. Real-World Examples

●​ Java RMI (Remote Method Invocation): Supports object migration with stubs and
skeletons.​

●​ Aglets: Java-based mobile agent platform.​

●​ Cloud Functions: Modern serverless architectures support code migration for

scalability.​

9. Conclusion

Code migration in distributed systems enables flexible, dynamic, and efficient system
behavior by allowing code to move across machines. Though it introduces complexities in
state transfer and security, it is a powerful paradigm for modern distributed computing,
especially in cloud, IoT, and mobile agent-based applications.

13) explain features in distributed file system and explain model file service architecture.

Ans:

1. Introduction

A Distributed File System (DFS) enables users to store, access, and manage files across
multiple distributed nodes while providing a unified interface as if the data resides on a
single system. DFS plays a critical role in distributed computing by offering transparency,
reliability, and scalability in file handling.

2. Features of Distributed File System

1.​ Location Transparency​

Users are unaware of the physical location of the file. The system maps logical file
names to physical storage transparently.​
 2.​ Access Transparency​
Access to remote files is similar to local files. No difference in interface for local vs.
remote files.​

3.​ Concurrency Control​

Multiple users can access and modify the same file simultaneously using locking or
versioning mechanisms.​

4.​ Fault Tolerance and Reliability​

DFS provides data redundancy using replication, ensuring data availability even if a
node or server fails.​

5.​ Scalability​
DFS can handle a growing amount of work or an increasing number of clients by
adding more servers.​

6.​ Performance​
Uses techniques such as caching, replication, and load balancing to ensure fast file
access.​

7.​ Security​
Incorporates mechanisms for authentication, authorization, and encryption to ensure
data security.​

8.​ Heterogeneity​
DFS operates across different hardware platforms and operating systems using
standard protocols.​

9.​ Consistency​
Ensures users view the most recent version of a file using synchronization protocols.​

10.​Data Sharing​
Files can be shared across multiple users and applications with controlled access.​

3. File Service Architecture (Model)

The file service architecture defines how client requests for file operations are handled by
the distributed file system.

✅ There are typically 3 layers in this model:

a. Client Module
 ●​ Runs on the user's machine.​

●​ Provides an interface for system calls like open(), read(), write(), and
close().​

b. File Service Module

●​ Handles high-level operations such as file creation, deletion, and directory

management.​

●​ Also handles file locking, naming, and file lookup.​

c. Storage Service Module

●​ Manages the low-level storage operations such as data block read/write.​

●​ Interacts with physical storage devices.​

📌 Diagram of File Service Architecture:

mathematica

CopyEdit

User Application

Client Module

File Service Module

Storage Service Module

↓
Physical Storage (Disks)

4. Conclusion

The Distributed File System provides an efficient and scalable way to manage files over a
network. With features like transparency, fault tolerance, and concurrency control, DFS is
widely used in modern computing systems. The File Service Architecture ensures modularity
and efficient file handling by dividing the system into client, service, and storage
components.

—------------------------------------------------------------------------------------------------------------------------

14) explain process of schronisatio wrt physical and logical clock?

Ans:

1. Introduction
In a distributed system, different nodes operate independently and maintain their own clocks.
Due to clock drift and lack of a global time reference, these clocks may differ, leading to
inconsistencies in event ordering and coordination. Synchronization is required to ensure
consistent time perception across the system.

2. Synchronization with Physical Clocks

A physical clock is a hardware-based timekeeping mechanism found in each

computer system that measures the passage of real-world time. In distributed
systems, physical clocks are used to generate timestamps for events, and
efforts are made to synchronize these clocks across all nodes to maintain
temporal consistency. Due to differences in oscillator frequencies and
environmental conditions, physical clocks are subject to drift and may gradually
become unsynchronized without periodic correction.

🧪 Characteristics:
●​ Represents actual time (e.g., 12:45 PM).​

●​ Can be synchronized using:​

○​ Cristian’s Algorithm​

○​ Berkeley Algorithm​

○​ NTP (Network Time Protocol)​

●​ Prone to clock drift (small errors accumulate over time).​

​

b. Algorithms Used:

●​ Cristian’s Algorithm:​
Uses a time server to send accurate time to other nodes.​
Adjusts time considering message transmission delay.​

●​ Berkeley Algorithm:​
Averages the time of all nodes in the system and then corrects each clock
accordingly.​
No master clock is assumed.​

●​ NTP (Network Time Protocol):​

Hierarchical, fault-tolerant protocol widely used for synchronizing clocks over the
 internet.​

3. Synchronization with Logical Clocks

Definition of Logical Clock

A logical clock is an abstract mechanism used in distributed systems to assign

timestamps to events in such a way that the order of events can be
determined, even in the absence of synchronized physical time. Logical clocks
provide a partial or total ordering of events based on causal relationships,
ensuring correct event sequencing without depending on real-time clocks.

🧪 Characteristics:
●​ Does not represent real time.​

●​ Ensures correct ordering of events.​

●​ Two main types:​

○​ Lamport Timestamps: Establish "happened-before" relationships.​

○​ Vector Clocks: Track causality more precisely.​

a. Lamport’s Logical Clock:

●​ Each process maintains a counter.​

●​ On each event or message, the counter is incremented.​

●​ Helps determine the order:​

If L(A) < L(B), then A happened before B.​

b. Vector Clocks:

●​ Each process maintains a vector of timestamps for all nodes.​

●​ Captures causal relationships between events more accurately.​

 ●​ Helps detect concurrent events (when neither happened before the other).​

4. Comparison

Feature Physical Clocks Logical Clocks

Based On Real-world time Event order

Goal Synchronize actual time Order events correctly

Accuracy Required High Low (only order matters)

Algorithms Cristian, Berkeley, NTP Lamport, Vector Clocks

5. Conclusion

Synchronization in distributed systems is essential to ensure reliable communication and

coordination. Physical clock synchronization is used for time-sensitive applications, while
logical clock synchronization is ideal for maintaining the order of events. Both approaches
play vital roles in maintaining consistency and correctness across distributed environments.