UNIT-1

INTRODUCTION
NOV-DEC 2022

Q1: What is Distributed System?

Or
Why would you design a system as a distributed system.

A distributed system is a network of computers that work together to solve problems

or perform tasks. Instead of using just one computer, a distributed system splits the
work across many machines, which communicate with each other to achieve a
common goal. These computers can be located in different places, but they act like a
single system to the user.

A distributed computing system is basically a collection of processors, where each

processor has its own local memory and peripherals & processors communicate
through message passing.
The computers or nodes work together, communicate over a network, and coordinate
their activities to achieve a common goal by sharing resources, data, and tasks.

For Example- when you use google or Netflix, the service you use is powered by
many servers (computers) all over the world working together to quickly deliver the
results or stream videos. This setup makes things faster, more reliable, and able to
handle large amount of data or users at once.
Key benefits of DS include:
Distributed systems offer several advantages, making them a popular choice for
modern applications. Here are the key benefits explained simply:

1. Scalability
• Distributed systems can easily grow by adding more machines or nodes. This
helps handle more users or data without overloading a single machine.
• It can handle more tasks by adding more computers.

2. Reliability
• If one machine fails, others can take over. This ensures the system keeps
running smoothly, reducing downtime.

3. Performance
• Tasks are divided among multiple machines, so they get done faster. This
improves the overall speed and efficiency of the system.

4. Flexibility
• Different parts of the system can run on different types of machines. This
makes it easier to use resources efficiently.

5. Cost-effectiveness
• Instead of one expensive supercomputer, you can use multiple affordable
machines to get similar results.

6. Fault Tolerance
• If one computers fails then others can continue the work.

7. Geographical Distribution
• Machines can be located in different places, allowing users from all over the
world to access the system quickly and reliably.

8. Resource Sharing
• Distributed systems let machines share their resources, like storage or
computing power, for better utilization.

9. Speed
• By Spreading out tasks, things get done faster.
Characteristics of a Distributed System:

1. Multiple Nodes
o A distributed system consists of multiple nodes (computers, servers, or
devices), each performing a specific task.
2. Coordination
o Nodes coordinate with each other to complete tasks, often through
communication protocols like HTTP, RPC, or gRPC.
3. Shared Goals
o All nodes work together to achieve common objectives, like processing
user requests or storing large amounts of data.
4. Transparency
o A good distributed system hides its complexity from users. For instance,
users don’t need to know which server processes their request.

Components of a Distributed System:

1. Hardware Nodes:
o Physical devices like computers, servers, or IoT devices.
2. Network:
o A communication channel (e.g., the Internet or LAN) connecting the
nodes.
3. Middleware:
o Software that manages communication, coordination, and data sharing
between nodes.
4. Applications:
o Programs or services running on the system, like cloud storage,
databases, or e-commerce platforms.

Advantages of Distributed Systems:

1. Scalability: Handle growing demand by adding more nodes.

2. Fault Tolerance: Survive hardware or software failures.
3. Resource Sharing: Efficient utilization of distributed resources.
4. Performance: Divide tasks among nodes to improve processing speed.
5. Geographical Reach: Nodes can be spread worldwide to serve users in
different regions.

Challenges in Distributed Systems:

 1. Complexity: Hard to design and maintain.
2. Latency: Communication between nodes may be slower than within a single
machine.
3. Consistency: Keeping data synchronized across all nodes.
4. Security: Ensuring data is protected during transmission and storage.
5. Fault Detection: Identifying and handling failures in a distributed
environment.

Examples of Distributed Systems:

1. Google Search: Uses a distributed system to process billions of search queries.

2. Facebook: Stores and processes user data across multiple servers.
3. Netflix: Distributes content from servers worldwide to ensure smooth
streaming.
4. Cloud Services: Platforms like Microsoft Azure or AWS rely on distributed
systems.

Q2: Describe the goal of distributed systems.

The primary goal of distributed systems are:

1. Scalability: DS can handle more complexity and tasks by adding more computer
to the network the efficiency of the system should be increased.

2. Reliability: If one machine fails, others can take over. This ensures the system
keeps running smoothly, reducing downtime.

3. Performance: By spreading out the tasks into multiple computers the system can
work faster and the system performance should be increased.

4. Resource Sharing: Distributed system allows computer to share resources like

(data, file, printer or computational power) across the network.

5. Concurrency: Multiple users should be able to access shared resources without

any interference or inconsistency.

6. Hide Complexity: Make it easy for users by hiding how the system works behind
the scenes, like where data is stored or how it’s managed.

7. Transparency: Let users access data or services from anywhere without worrying
about where they are physically stored.
8. Handle Growth: Add more computers or upgrade them to handle more users or
bigger workloads easily.

9. Fault Tolerance: Stay operational even if some computers or parts fail, so users
don’t face interruptions.

10. Share Resources: Allow multiple people to share data, storage, or processing
power without issues.

11.Work Faster: Split work across multiple computers to finish tasks quickly and
respond to users faster.

12. Flexible: Let the system grow, change, or update parts without affecting the rest
of it.

13.Coordination: Make sure everything stays consistent when multiple users or

systems work together on the same data.

14. Security: Protect data and communication from hackers, and allow only
authorized people to access it.

15.Cost-effectivness: Use affordable hardware instead of expensive systems to keep

costs low.

16. Support Variety: Work with different types of computers, operating systems,
and networks to ensure everything connects and works together.

Q3: Explain system model with suitable examples.

Or
Explain distributed computing system models.

DS can be classified into different models:

1. Physical model
2. Architectural model
3. Fundamental model
Distributed systems can be understood through different models, each addressing
specific aspects of the system's design and behavior. Here are the primary types of
distributed system models:

Physical Model

The physical model explains the hardware parts of a distributed system. It includes
computers, devices, and their connections. This model helps in designing, managing,
and checking the system’s performance.

Example: A cloud-based distributed system with multiple servers spread across

different data centers.

Main parts of a physical model:

1. Nodes
o These are devices like computers, servers, or workstations that process
data, perform tasks, and communicate with others.
o Nodes provide an interface for users to access services like storage,
databases, processing, or web browsing.
o Each node has an operating system, software, and middleware to manage
communication and tasks.
2. Links
o Links are the communication paths between nodes and devices. They
can be wired (e.g., copper wires, fiber optics) or wireless.
o Types of connections:
▪ Point-to-point: Connects two nodes for data transfer.
▪ Broadcast: One node sends data to many nodes.
▪ Multi-access: Many nodes share the same channel and use
protocols to avoid conflicts.
3. Middleware
o Middleware is software on the nodes that allows decentralized control
and decision-making.
o It manages tasks like communication, resource sharing, fault handling,
synchronization, and security.
4. Network Topology
o This is the layout of nodes and links in the system. Common layouts are
bus, star, mesh, ring, or hybrid.
o The choice of topology depends on the system’s purpose and needs.
5. Communication Protocols
o These are rules for sending data through the links. Examples include
TCP, UDP, HTTPS, and MQTT.
o They enable nodes to communicate and understand the data exchanged.
2.Architectural Models in Distributed Computing Systems

An architectural model in distributed computing defines the overall structure and

design of the system. It shows how different parts of the system are organized to
work together, covering how the system is developed, deployed, and operated. A
well-designed architectural model ensures efficient resource use and better
scalability.
Here are the main types of architectural models:

1. Client-Server Model
This model is centralized. It has clients that request services and servers that
respond by providing those services. Communication happens through a
request-response process.
o Works using protocols like TCP/IP and HTTP.
o Common in web services, cloud computing, and database systems.
2. Peer-to-Peer (P2P) Model
This is a decentralized system where all devices (called peers) are equal in
capability. Peers can both request and provide services.
o Peers communicate directly with each other without a central server.
o The system is flexible as peers can join or leave easily.
o Example: BitTorrent for file sharing.
3. Layered Model
This model organizes the system into multiple layers. Each layer provides a
specific service and interacts only with its neighbouring layers using
predefined rules.
o Simplifies complexity by separating concerns between layers.
o Creates a clear structure for the system.
o Example: The OSI model for networking.
 4. Microservices Model
This model splits a large application into smaller, independent services. Each
service focuses on one function and runs separately.
o Services are independently developed, deployed, and scaled.
o Makes the system easier to maintain and more scalable.
o Example: Online shopping platforms with separate services for
payments, orders, and user accounts.

These models provide a framework to build efficient and scalable distributed

systems.

3. Fundamental Model
The fundamental model in distributed computing is a basic framework that helps us
understand the key features of distributed systems. It focuses on the core components
needed to explain how distributed systems work. There are three main types of
fundamental models:

1. Interaction Model
This model explains how different processes in a distributed system communicate
and work together. Key components include:
• Message Passing:

Processes send and receive messages containing data, instructions, or requests.

This communication can be:
o Synchronous: Messages are exchanged in real-time, with immediate
responses.
o Asynchronous: Messages are sent without waiting for an immediate
reply.
• Publish/Subscribe System:

o A publisher shares messages on specific topics.

o Subscribers who are interested in those topics receive and act on the
messages.
o Useful in event-driven systems, like notification services.

2. Failure Model: Defines the types of failures that can occur in the system (e.g.,
network failures, node crashes, message loss) and how the system responds.

3. Security Model: Focuses on security threats like unauthorized access, attacks,

or data tampering, and the mechanisms to protect the system.

Example: The model helps describe how a distributed database handles

communication delays, potential node failures, and security risks like hacking
attempts.
Each of these models helps in understanding different aspects of how a distributed
system is organized, operates, and how it can handle challenges.
Q4: Discuss about the issues in design of distributed systems.

• Network Reliability: Communication between computers may fail or be delayed,

leading to problems in data sharing or coordination.

• Latency: Some tasks might take longer due to physical distance or network issues,
slowing down the system.

• Data Consistency: Ensuring all parts of the system have the same up-to-date
information can be challenging, especially when updates happen in different places.

• Fault Tolerance: Parts of the system may fail (e.g., a server crashes), so the system
needs a way to keep working or recover quickly.

• Scalability: As more computers or users join the system, it can become harder to
manage performance and resources efficiently.

• Security: More computers mean more points that can be vulnerable to attacks, so
securing the system is more complex.
• Synchronization: Keeping clocks or data synchronized across different machines
can be tough, as each machine may run at slightly different speeds.

Concurrency: Multiple tasks happening at the same time can cause issues like data
conflicts or resource competition.

Resource Management: Efficiently distributing tasks and managing resources (like

memory or processing power) across machines is challenging.

Complexity: Designing and managing a system with many independent parts is

more complex than working with a single system, leading to higher chances of bugs
or errors.

Network Congestion
• The system’s performance can degrade when too many messages are sent over
the network, causing delays and reduced throughput.

Error Recovery and Rollback

• When failures occur, the system needs to be able to recover gracefully,
including rolling back incomplete operations without affecting system
consistency.

Middleware and Abstraction

• Distributed systems need middleware to manage communication between
components, and ensuring this middleware is flexible, efficient, and transparent
is difficult.

Load Balancing
• Efficiently distributing workloads across nodes to prevent overloading certain
parts of the system while others remain idle.

Global Clock Synchronization

• In distributed systems, maintaining synchronized clocks across all components
can be difficult due to network delays and hardware differences.

Network Partitioning
• Network failures can split the system into isolated parts, making it difficult for
components to communicate, impacting system reliability.

Availability
• The system must remain available even during failures, meaning users should
be able to access the system, but this may conflict with consistency in some
cases.
Data Integrity

Ensuring that data remains correct and consistent across all distributed components
can be a challenge, especially during network failures.

Q5: Briefly describes distributed computing environment (DCE).

A distributed application is a program that runs on more than one machine and
communicates through a network. It consists of separate parts that execute on
different nodes of the network and cooperate in order to achieve a common goal. It
uses Client-Server Model.

Distributed Computing Environment (DCE) is an integrated set of services and tools

which are used for building and running Distributed Applications. It is a collection
of integrated software components/frameworks that can be installed as a coherent
environment on top of the existing Operating System and serve as a platform for
building and running Distributed Applications.
Distributed Computing Environment(DCE) is an integrated set of services and tools
which are used for building and running Distributed Applications. Using DCE
applications, users can use applications and data at remote servers. Application
programmers or clients need not be aware of where their programs will run or where
the data that they want to have access, will be located.

DCE was developed by the Open Software Foundation(OSF) using software

technologies contributed by some of its member companies which are now
popularly known as The Open Group.

DCE framework/Services include:

Remote Procedure Call (RPC): It is a call made when a Computer

program wants to execute a subroutine in a different computer (another
computer on a shared network).

Distributed File System (DFS): It provides a transparent way of accessing

a file in the system in the same way as if it were at the same location.|

Directory Service: It is used to keep track location of Virtual Resources in

the Distributed System. These Resources include Files, Printers, Servers,
Scanner, and other machines. This service prompts the user to ask for
resources(through the process) and provide them with convenience.
Processes are unaware of the actual location of resources.
 Security Service: It allows the process to check for User Authenticity.
Only an authorized person can have access to protected and secured
resources. It allows only an authorized computer on a network of Distributed
Systems to have access to secured resources.

• Distributed Time Service: Inter-Process Communication between different

system components requires synchronization so that communication takes
place in a designated order only. This service is responsible for maintaining a
global clock and hence synchronizing the local clocks with the notion of time.

• Thread Service: The Thread Service provides the implementation of

lightweight processes (threads). Helps in the synchronization of multiple
threads within a shared address space.

DCE Architecture

DCE supports the structuring of distributed computing systems into so-

called cells which consist of 3 types of machines, User, administrator, and Server.
This is done to keep the size of the administration domain manageable. A cell is
basically a set of nodes that are managed together by one authority.

Cell boundaries of a cell represent security firewalls; access to resources in a

foreign cell requires special authentication and authorization procedures that are
different from secure intra-cell interactions.

The highest privileges within a cell are assigned to a role called DCE
cell administrator which has control over all system services within the network,
remotely. It has privileges over all resources within a Distributed Computing
Environment cell.

Major components of cell:

• Security Server which is responsible for User Authenticity

• Cell Directory Server(CDS) – the repository of resources

• Distributed Time Server – provides the clock for synchronization of the

entire cell.
 figure 1: DCE Architecture

Advantages of DCE:
• Security
• Lower Maintenance Cost
• Scalability and Availability
• Reduced Risks

Summary of DCE Benefits:

• Transparency: DCE hides the complexity of distributed computing, making

remote systems appear as if they are local.

• Scalability: It allows the system to scale by adding more machines to the

network without major changes.

• Fault Tolerance: Through replication and error handling, DCE ensures that
the system remains operational even when parts of it fail.

• Security: Built-in security mechanisms ensure that communication and

resources are protected in the distributed system.
 UNIT-2
Communication
Nov-Dec 2022

Q1: Define message passing?

Message Passing is form of communication used in distributed system where

different processes send and receive message to exchange data.

Message passing in a distributed system is a communication method where

processes running on different machines or nodes exchange information by sending
and receiving messages. It is a fundamental mechanism for enabling coordination,
sharing data, and synchronization between distributed components.

Key Characteristics:

1. Asynchronous or Synchronous Communication:

o Synchronous: The sender waits for a response after sending a message.

o Asynchronous: The sender continues processing without waiting for a
response.
2. Direct or Indirect Communication:

o Direct: Messages are sent directly between processes, often using their
addresses or identifiers.
o Indirect: Messages are sent through an intermediary, such as a message
queue or broker.
3. Reliability:

oReliable systems ensure message delivery even in the presence of

failures.
o Some systems may tolerate occasional message loss (best-effort
delivery).
4. Format:

o Messages typically have a structured format, including a header

(metadata) and body (payload/data).
Advantages:
• Enables interaction across geographically distributed systems.
• Facilitates fault tolerance and scalability.
• Supports modular and flexible system design.
Examples of Message Passing in Distributed Systems:
• Remote Procedure Calls (RPC): Allows invoking functions on remote
systems as if they were local.
• Message Queues (e.g., RabbitMQ, Kafka): Provide asynchronous message
delivery.
• Publish-Subscribe Models: Systems like MQTT and Pub/Sub for real-time
updates.
Message passing plays a crucial role in ensuring seamless interaction and
consistency in distributed systems.

Types of Message Passing in Distributed Systems

Message passing describes the method by which nodes or processes interact and
share information in distributed systems. Message passing can be divided into two
main categories according to the sender and reciever’s timing and synchronization:

1. Synchronous Message Passing

Synchronous message passing involves a tightly coordinated interaction between

the sender and receiver. The key characteristics include:

• Timing Coordination: Before proceeding with execution, the sender waits

for the recipient to confirm receipt of the message or finish processing it.

• Request-Response Pattern: often use a request-response paradigm in which

the sender sends a message requesting something and then waits for the
recipient to react.

• Advantages:
o Ensures precise synchronization between communicating entities.
o Simplifies error handling as the sender knows when the message has
been successfully received or processed.

• Disadvantages:
o May introduce latency if the receiver is busy or unavailable.
o Synchronous blocking can reduce overall system throughput if many
processes are waiting for responses.

2. Asynchronous Message Passing

Asynchronous message passing allows processes to operate independently of each
other in terms of timing. Key features include:
 • Decoupled Timing: The sender does not wait for an immediate response
from the receiver after sending a message. It continues its execution without
blocking.

• Event-Driven Model: Communication is often event-driven, where

processes respond to messages or events as they occur asynchronously.

• Advantages:
o Enhances system responsiveness and throughput by allowing processes
to execute concurrently.
o Allows for interactions that are loosely connected, allowing processes
to process messages at their own speed.

• Disadvantages:
o Requires additional mechanisms (like callbacks or event handlers) to
manage responses or coordinate actions.
o Handling out-of-order messages or ensuring message delivery
reliability can be more complex compared to synchronous
communication.

3. Unicast Messaging
Unicast messaging is a one-to-one communication where a message is sent from a
single sender to a specific receiver. The key characteristics include:
• Direct Communication: The message is targeted at a single, specific node or
endpoint.
• Efficiency for Point-to-Point: Since only one recipient receives the message,
resources are efficiently used for direct, point-to-point communication.

• Advantages:
o Optimized for targeted communication, as the message is only sent to
the intended recipient.
o Minimizes network load compared to group messaging, as it doesn’t
broadcast to unnecessary nodes.

• Disadvantages:
o Not scalable for group communications; sending multiple unicast
messages can strain the system in larger networks.
o Can increase the complexity of managing multiple unicast connections
in large-scale applications.

4. Multicast Messaging
Multicast messaging enables one-to-many communication, where a message is sent
from one sender to a specific group of receivers. The key characteristics include:
 • Group-Based Communication: Messages are delivered to a subset of nodes
that have joined the multicast group.
• Efficient for Groups: Saves bandwidth by sending the message once to all
nodes in the group instead of individually.
• Advantages:
o Reduces network traffic by sending a single message to multiple
recipients, making it ideal for content distribution or group updates.
o Scales efficiently for applications where data needs to reach specific
groups, like video conferencing or online gaming.
• Disadvantages:
o Complex to implement as nodes need mechanisms to manage group
memberships and handle node join/leave requests.
o Not all network infrastructures support multicast natively, which can
limit its applicability.

5. Broadcast Messaging
Broadcast messaging involves sending a message from one sender to all nodes
within the network. The key characteristics include:
• Wide Coverage: The message is sent to every node, ensuring that all nodes
in the network receive it.
• Network-Wide Reach: Suitable for announcements, alerts, or updates
intended for all nodes without targeting specific ones.
• Advantages:
o Guarantees that every node in the network receives the message, which
is useful for critical notifications or status updates.
o Simplifies dissemination of information when all nodes need to be
aware of an event or data change.
• Disadvantages:
o Consumes significant network resources since every node, regardless
of relevance, receives the message.
o Can lead to unnecessary processing at nodes that don’t need the
message, potentially causing inefficiency.

COMMUNICATION PROTOCOLS FOR MESSAGE PASSING IN

DISTRIBUTED SYSTEMS

1. Transmission Control Protocol (TCP)

2. User Datagram Protocol (UDP)
3. Message Queuing Telemetry Transport (MQTT)
4. Hypertext Transfer Protocol (HTTP)
Q2: Describe Marshalling, with suitable example.
Or
Explain in details about Marshalling procedures.

Marshalling in a distributed system refers to the process of converting an object or data structure
into a format that can be transmitted over a network or stored for later use. It is a critical aspect of
remote communication, ensuring that data can be exchanged between processes running on
different machines.

In the context of distributed systems, marshalling is essential for sending complex data structures,
such as objects, lists, or dictionaries, between a client and a server using a communication protocol.

Marshalling Process:

1. Purpose of Marshalling:
o To enable data exchange between distributed systems.
o To ensure compatibility across different platforms and programming languages.
o To convert in-memory objects or data structures into a transferable format.

2. Steps in Marshalling:
o Serialization:
▪ The object or data structure is transformed into a sequence of bytes or a
network-compatible format.
▪ For example, in Java, an object is serialized into a byte stream using
interfaces like Serializable.
o Packaging:
▪ The serialized data is packaged with metadata, such as the type of data,
length, or encoding, to aid in deserialization.
o Transmission:
▪ The packaged data is transmitted across the network to the receiving end.

Steps in Marshalling:

1. Identify the Data: Select the data or object to be marshalled.

2. Serialize the Data: Convert the data into a linear format, like JSON, XML, or binary.
3. Add Metadata (optional): Include additional information like data type, encoding, and
length for processing.
4. Transmit the Data: Send the serialized data to the destination system.

3. Unmarshalling:
o This is the reverse process of marshalling.
o The serialized data is received, unpackaged, and converted back into the original
object or data structure.
 o This ensures that the receiving system can reconstruct and understand the transmitted
data.

Why is Marshaling Important?

• Platform Independence: Different systems may have different ways of representing data.
Marshaling allows data to be standardized for transmission.
• Complex Data Handling: Marshaling enables complex data structures, like objects or
nested lists, to be transmitted easily between different systems.
• Network Communication: Data must be marshaled to send it as a network packet, ensuring
that both the sender and receiver understand the data format.

Challenges in Marshalling:

• Platform Heterogeneity:
o Different systems may have varied data formats type representations.
• Efficiency:
o Serialization can be computationally expensive and add overhead to the
communication process.
• Security:
o The serialized data may be vulnerable to tampering or injection attacks if not
properly secured.
• Complexity:
o Handling complex data structures like nested objects, arrays, or graphs can
complicate marshalling.
Example of Marshalling:
Let us consider a simple example of marshalling involving a client-server
architecture where client needs to send the request to server application to access
the user information.

Advantages of Marshalling:
• Interoperability: Enables communication across different systems and
platforms.
• State Preservation: Objects can be saved and restored later.
• Ease of Data Sharing: Simplifies the process of sending complex data
structures.

Disadvantages of Marshalling:
• Performance Overhead: Serialization and deserialization processes can be
slow.
• Compatibility Issues: Different systems may have issues understanding each
other's formats without a common standard.
• Security Risks: Exposed serialized data can be exploited by attackers.

Examples of Marshalling Protocols and Frameworks:

1. CORBA (Common Object Request Broker Architecture):

o Uses IIOP (Internet Inter-ORB Protocol) for marshalling and
unmarshalling.

2. Java RMI (Remote Method Invocation):

o Relies on Java's built-in serialization for object marshalling.

3. Protocol Buffers (Google's Protobuf):

 o A highly efficient binary serialization protocol.

4. JSON or XML:
o Common formats for text-based serialization, often used in RESTful
APIs.
5. Apache Thrift:
o A cross-language serialization library.

Key Features of Marshalling:

1. Serialization: Data is converted into a serial format like JSON, XML, or
binary.
2. Interoperability: Enables communication between systems that might have
different data representations.
3. Platform Independence: Abstracts away system-specific details to ensure
compatibility.
4. Error Handling: Handles data integrity during conversion and transmission.

Applications:
• Remote Procedure Calls (RPC): Sending method arguments and receiving
results.
• Distributed Systems: Sharing data between nodes.
• Web APIs: REST and GraphQL use JSON/XML for marshalling requests
and responses.

Q3: Explain Remote Procedure Call (RPC) Model, with suitable example.

Remote Procedure Call (RPC) is a powerful technique for constructing distributed,

client-server based applications.
Remote Procedure Call (RPC) is a communication paradigm used in distributed
systems that allows a program to execute a procedure on another machine as if it
were a local procedure.

How Does RPC Work?

1. Client makes a request:

o The client (the user’s computer or application) wants to use a function
that is on a different computer (the server).
 o The client calls the function, but it doesn’t know how to directly
communicate with the server.
2. Client Stub:
o A stub is like a "proxy" or a stand-in for the actual function.
o The client stub takes the function call, converts the function and its
data into a message, and sends it to the server. This process is called
marshalling (packing the data to be sent).
3. Server Stub:
o The server stub receives the message from the client, unpacks the data
(called unmarshalling), and calls the actual function on the server.
4. Server executes the function:
o The server performs the function that the client requested (like
checking a user’s balance or fetching data).
5. Sending back the response:
o Once the function is complete, the server sends the result back to the
client through the server stub and client stub.
6. Client gets the result:
o The client stub receives the result, unpacks it, and sends it to the client
application.

Key Concepts:

• Stubs: Act as proxies to manage serialization (marshalling) and

deserialization (unmarshalling) of data.
• Transparency: The client and server communicate without being aware of the
underlying networking details.
• Communication: RPC typically uses protocols like HTTP, TCP, or UDP for
transport.

Example:

Imagine an online banking system where a client app on a user's device requests the
server to fetch the account balance.

1. Client-side:
o The user clicks "Check Balance" on their app. The app calls a
checkBalance() function.
o This call is intercepted by the client stub, which prepares a message
with the user ID and sends it to the server.
2. Server-side:
o The server stub receives the message, extracts the user ID, and calls the
actual checkBalance() function on the server.
o The server fetches the balance from the database.
3. Response:
o The server stub sends the balance back to the client stub.
o The client stub processes the response and displays the balance to the
user.

Advantages of RPC:

1. Simplifies the development of distributed systems.

2. Provides a familiar method-call semantics to programmers.
3. Hides the complexity of network communication.

Disadvantages:

1. Less efficient compared to direct calls due to network overhead.

2. Fault tolerance is complex since both client and server processes must handle
failures (e.g., lost messages, timeouts).
3. Security concerns due to communication over networks.

How to Make a Remote Procedure Call

The calling environment is suspended, procedure parameters are transferred across
the network to the environment where the procedure is to execute, and the
procedure is executed there. When the procedure finishes and produces its results,
its results are transferred back to the calling environment, where execution resumes
as if returning from a regular procedure call.

Working of a RPC
Steps in RPC Working:

1. Client Request (Client-side)

o The client application wants to execute a procedure on a remote server,

so it calls a local function (stub) that acts as a proxy for the remote
procedure.
 o The client does not know where the actual function is located (on the
server) or how it works, so the call looks just like a normal function
call.
2. Client Stub (Client-side)

o The client stub is a piece of code that acts as a placeholder for the
remote procedure. When the client calls the procedure, the client stub
intercepts the call.
o The client stub marshals (packs) the procedure arguments and prepares
them to be sent over the network to the server. Marshaling involves
converting the data into a format that can be transmitted (like
converting data into a byte stream).
o It also creates a network request and sends it over the network to the
server.
3. Network Communication

o The message containing the procedure request (along with its

parameters) travels over the network from the client to the server.
o The communication is often handled using protocols like TCP/IP or
HTTP, but this is abstracted from the client and server by RPC
mechanisms.

4. Server Stub (Server-side)

o The server stub receives the incoming network message and extracts
(unmarshals) the procedure parameters.
o The server stub then invokes the corresponding procedure on the
server, passing it the parameters from the client.

5. Server Execution (Server-side)

o The server executes the procedure with the given parameters, just like
any normal local procedure call.
o After execution, the server prepares the result (or any error message) to
send back to the client.

6. Sending the Response

o The result of the procedure (such as data or success/failure

information) is marshaled by the server stub and sent back over the
network to the client.

7. Client Stub (Client-side)

 o The client stub receives the response from the server, unmarshals the
data, and hands it back to the client application.
o The client application now processes the result just like a normal local
function call result.
8. Client Application Receives the Result

o The client application receives the results from the remote procedure
and continues its normal execution as if the function was executed
locally.

Q4: What are the main issues in designing a Transparent RPC mechanism?

Designing a transparent RPC mechanism (where the remote procedure call appears
to be a local function call) comes with several challenges. Here are the main issues
faced in creating such a system:

1. Network Latency

• Problem: When calling a remote function, there’s a delay because the data has
to travel over the network.
• Challenge: It’s hard to reduce this delay because network speed can vary.
• Solution: Use faster communication methods, cache data, and minimize the
number of remote calls.

2. Fault Tolerance and Reliability

• Problem: Remote calls can fail if there are network issues, server crashes, or
timeouts.
• Challenge: Making the system reliable so that it can handle these failures.
• Solution: Add retry mechanisms, timeouts, and error handling to recover from
issues.

3. Data Serialization/Deserialization

• Problem: Data has to be converted (serialized) into a format that can be sent
over the network, and then converted back (deserialized) on the other side.
• Challenge: Different computers may use different formats, so packing and
unpacking data can be tricky.
• Solution: Use common data formats like JSON or Protocol Buffers to make
sure the data can be read everywhere.

4. Heterogeneity
 • Problem: The client and server might use different operating systems,
hardware, or software.
• Challenge: Ensuring the RPC system works across different types of systems.
• Solution: Make the system platform-independent and use standard protocols
and formats.

5. Security

• Problem: Since RPC involves sending data over the network, it could be
intercepted or tampered with.
• Challenge: Ensuring that data is secure and can’t be accessed by unauthorized
users.
• Solution: Use encryption (like TLS/SSL) and authentication methods (like
API keys) to secure the communication.

6. Transparency of Remote Execution

• Problem: RPC should make remote calls appear just like local ones, without
exposing the complexities of how they work.
• Challenge: Hiding all the technical details of remote communication while still
handling errors, delays, and retries.
• Solution: The system should handle communication and errors automatically,
so developers don’t have to worry about them.

7. Performance and Overhead

• Problem: Remote calls take more time due to network, data conversion, and
processing.
• Challenge: Remote calls are slower than local ones, and this can affect
performance.
• Solution: Reduce the number of remote calls and optimize data transfer.

8. Scalability

• Problem: As the number of users or servers increases, it’s harder to keep the
RPC system efficient.
• Challenge: Ensuring the system can handle many requests at once without
slowing down.
• Solution: Use load balancing (distribute the work), and break the system into
smaller, manageable parts.

9. Interface Definition and Versioning

 • Problem: The client and server need to agree on how they communicate. If the
function changes (e.g., adding/removing parameters), it can break
communication.
• Challenge: Keeping the interface compatible between versions.
• Solution: Use an Interface Definition Language (IDL) and carefully manage
version changes so older versions still work.

Summary of Main Issues:

• Network Latency: Slow network can cause delays.

• Fault Tolerance: Handling failures like server crashes.
• Data Serialization: Converting data into a suitable format for transfer.
• Heterogeneity: Differences in systems that need to be addressed.
• Security: Protecting data from being tampered with.
• Transparency: Hiding the complexity of remote calls.
• Performance: Avoiding slowdowns from remote calls.
• Scalability: Ensuring the system can grow without losing efficiency.
• Interface Versioning: Keeping communication consistent across updates.

Each of these challenges needs careful planning and solutions to build an RPC system
that is fast, reliable, and transparent for users and developers.

Q:5 Describe three different process-addressing mechanisms. Discuss

their relative advantage and disadvantages.
The following are the two types of addressing schemes supported by the Message
Process Addressing:

Explicit Addressing
Implicit Addressing

1. Explicit Addressing

In explicit addressing, the program or instruction clearly tells the computer where to
find the data. The memory location (address) is directly mentioned in the
instruction.
Example:
If an instruction says "Add the value from address 500," it’s explicitly telling the
computer to go to memory location 500 to get the value.
Advantages:
• You know exactly where the data is, so you have full control over it.
• It’s clear and specific.
Disadvantages:
• It can be less flexible because you always need to specify a location.
• If you need to change the memory location, you may have to update multiple
instructions.

2. Implicit Addressing

In implicit addressing, the program doesn’t tell the computer where to find
the data. Instead, it assumes the data is in a specific place, like a register or a
default memory area (e.g., the stack).
Example:
If an instruction says "Add the value," it might be understood that the value is
already in a special place, like a register called "accumulator," without the need to
specify it.
Advantages:
• The instructions are simpler and shorter because you don’t need to mention
memory locations every time.
• It makes things faster and less complicated.
Disadvantages:
• You don’t have full control over where the data is, so it’s less flexible.
• It can be harder to manage if you have many data locations or complex tasks.

The three common process addressing mechanisms—Physical Addressing, Logical

Addressing, and Segmented Addressing—are methods used by operating systems
to handle memory access in a computer system. Here’s an explanation of each:

1. Physical Addressing

Physical addressing refers to the actual memory location in the computer’s

physical memory (RAM).
Physical addressing is when a program directly uses the actual memory locations in
the computer's RAM.
How it works:
• The operating system or hardware assigns processes to specific physical
memory locations.
• The program uses a physical address to access memory directly.
Advantages:
• Simple and direct: There is no translation involved since the address directly
maps to physical memory.
 • Fast access: Since no address translation is required, it can be faster in terms
of memory access.
Disadvantages:
• Lack of process isolation: Different processes can overlap and interfere with
each other because they share the same physical memory.
• No virtual memory: Without translation, it’s harder to implement techniques
like paging and swapping, which can limit memory usage flexibility.

2. Logical Addressing

Logical addressing (also known as virtual addressing) refers to the address used
by a program in its code, which does not directly correspond to physical memory.
The operating system and hardware use a mechanism called paging or
segmentation to map these logical addresses to physical addresses.
How it works:
• Each process is given its own address space (logical addresses), which is
separate from the physical memory.
• A memory management unit (MMU) is used to convert logical addresses to
physical addresses through address translation.
Advantages:
• Isolation: Processes can’t directly access the memory of other processes,
enhancing security and stability.
• Virtual memory: Logical addressing allows the use of more memory than
physically available by swapping data in and out of physical memory.
• Flexibility: The operating system can manage memory more efficiently,
providing features like paging and memory protection.
Disadvantages:
• Overhead: The translation from logical to physical addresses introduces
additional computational overhead.
• Complexity: Requires more complex memory management systems like page
tables, which add system complexity.

3. Segmented Addressing

Segmented addressing is a more structured form of logical addressing. It divides

memory into different segments, such as code, data, stack, etc. Each segment has a
starting address (called a segment base) and a size.

How it works:

• The address is divided into two parts: a segment number and an offset.
• The segment number points to a specific segment in memory, and the offset
tells you where the data is within that segment.
 • The operating system and the hardware use a segment table to map segment
numbers to actual physical memory addresses.
Advantages:
• Modularity: Programs are split into logical segments like code, data, and
stack, making it easier to manage large programs.
• Protection: Each segment can have its own access permissions (read, write,
execute), increasing security.
• Efficiency: Segmented memory helps with better memory utilization, as you
can allocate memory based on the program's specific needs.
Disadvantages:
• Complexity: Segment management can be complex, as the system must
handle various segments and ensure the correct mapping of segments.
• Fragmentation: If segments are not managed well, it can lead to
fragmentation, which can waste memory.

Summary of Differences:
Mechanism Description Advantages Disadvantages
Direct access to
Physical No process isolation,
physical memory Simple and fast
Addressing limited flexibility.
addresses.
Uses virtual memory Process isolation,
Logical Translation overhead,
with address virtual memory,
Addressing complexity.
translation. flexibility
Memory is divided Modularity,
Segmented Complexity, potential
into segments (e.g., protection, efficient
Addressing fragmentation.
code, data). allocation
Each addressing mechanism has its own use cases depending on the system
requirements, such as speed, security, and memory management capabilities.

Q6: What is RMI ( Remote Method Invocation), Explain.

The RMI (Remote Method Invocation) is an API that provides a mechanism to

create distributed application in java. The RMI allows an object to invoke methods
on an object running in another JVM.
RMI (Remote Method Invocation) is a Java API that allows objects in one Java
Virtual Machine (JVM) to invoke methods on objects in another JVM. It facilitates
communication between distributed Java applications, enabling an object in one
machine to call methods on an object located on a different machine, similar to how
local method calls are made. This is especially useful for client-server applications
where the client and server might be running on different systems or machines.

The RMI provides remote communication between the applications using two
objects stub and skeleton.

Understanding stub and skeleton

RMI uses stub and skeleton object for communication with the remote object.

A remote object is an object whose method can be invoked from another JVM. Let's
understand the stub and skeleton objects:

1. Stub (Client Side):

• Think of the stub as a remote control for a remote object.

• When the client wants to call a method on a remote object (which is on a
different machine), it doesn't directly call the method. Instead, it calls the
method on the stub.
• The stub sends the request to the remote object on the server, gets the result,
and then sends it back to the client.
• So, the stub is like a messenger that handles the communication for the client.

2. Skeleton (Server Side):

• The skeleton is like a receiver on the server side.

• When the client sends a request through the stub, the skeleton receives it.
• The skeleton then forwards the request to the actual remote object on the
server, gets the result, and sends it back to the stub (which sends it to the
client).
• It’s like a helper on the server that manages the incoming requests from clients
and sends the response.

Key Points:

• Stub = Client-side messenger (talks to the remote object).

• Skeleton = Server-side receiver (helps talk to the actual object).
Working of RMI

Here’s how RMI (Remote Method Invocation) works in simple terms:

1. Define the Remote Interface:

• First, you create a remote interface. This interface defines the methods that
can be called remotely (i.e., from another machine or computer). It’s like
creating a list of actions you want to do from afar.
2. Create the Remote Object (Server Side):
• Next, on the server side, you write the class that actually implements the
remote interface. This class does the actual work (like adding numbers,
sending messages, etc.).
• The server makes the object available to clients by binding it to a name in a
special RMI registry (a directory of available objects).
3. Start the RMI Registry:
• The RMI registry is a small server that holds the names of available remote
objects. It helps clients find and connect to the server-side objects.
4. Client Calls Remote Methods:
• On the client side, the client doesn’t call the method directly on the server
object. Instead, the client calls the method on a stub (a proxy or placeholder
for the remote object).
• The stub takes the request, sends it over the network to the server, and waits
for the response.
5. Server Receives and Processes the Request:
• The request from the client reaches the server's skeleton (older RMI versions).
The skeleton takes the request, forwards it to the actual remote object, and gets
the result.
• The result is then sent back to the client through the stub.
6. Client Gets the Result:
• The client receives the result from the stub, which has returned the data sent by
the server after processing the request.
RMI Example

In this example, The client application need only two files, remote interface and
client application. In the rmi application, both client and server interacts with the
remote interface. The client application invokes methods on the proxy object, RMI
sends the request to the remote JVM. The return value is sent back to the proxy object
and then to the client application.

RMI Example

The is given the 6 steps to write the RMI program.

1. Create the remote interface
2. Provide the implementation of the remote interface
3. Compile the implementation class and create the stub and skeleton objects
using the RMI tool
4. Start the registry service by RMI registry tool
5. Create and start the remote application
6. Create and start the client application
Advantages of RMI:

1. Easy to Use:
o RMI makes it simple to connect computers over a network. It hides the
complexity of sending data, so you don’t have to worry about the
technical details.
2. Object-Oriented:
 o You can work with objects just like you would in regular Java programs.
This makes it easier to design distributed applications.
3. Automatic Data Handling:
o RMI automatically converts objects into a format that can be sent over
the network (serialization) and back again. You don’t need to manually
handle data conversions.
4. Built-in Security:
o RMI comes with security features that help protect your application,
such as making sure that only trusted clients can access the remote
services.
5. Scalable:
o You can easily add more servers as your application grows, without
changing the client code.
6. Cross-Platform (with Java):
o Since RMI works with Java, it can run on different operating systems,
like Windows and Linux, without any special changes.

Disadvantages of RMI:

1. Only Works with Java:

o RMI is only for Java applications. If you want other languages (like
Python or C++) to communicate with Java, RMI won’t work directly.
2. Can Be Slow:
o RMI can slow down your application because it has to convert data, send
it over the network, and wait for a response. This is not ideal for real-
time or performance-critical apps.
3. Setup Can Be Complicated:
o Setting up RMI requires a bit of work, like defining interfaces,
implementing server-side objects, and configuring the registry. This can
be tricky for beginners.
4. Depends on the Network:
o Since RMI relies on network communication, it can be affected by
network problems like slow speeds or disconnections.
5. Limited Features:
o RMI isn’t as flexible as other technologies like web services or APIs,
which can be used by different types of applications or languages.
Applications of RMI:
1. Distributed Applications
2. Remote File Access
3. Online Games
4. Banking Systems
5. Customer Support Systems
 UNIT-3
Distributed Shared Memory
Q1: Define Distributed Shared Memory?

Distributed Shared Memory (DSM) is a mechanism in distributed computing that

allows physically separated computers (nodes) to share memory as if they were part
of a single shared memory system.

It is a mechanism that manages memory across multiple nodes and makes inter-
process communications transparent to end-users. The applications will think that
they are running on shared memory.
DSM is a mechanism of allowing user processes to access shared data without using
inter-process communications. In DSM every node has its own memory and provides
memory read and write services and it provides consistency protocols.
The distributed shared memory (DSM) implements the shared memory model in
distributed systems but it doesn’t have physical shared memory. All the nodes share
the virtual address space provided by the shared memory model. The Data moves
between the main memories of different nodes.

Distributed Shared Memory (DSM) is like a shared notebook for computers that are
working together. Even though each computer (or node) has its own separate
memory, DSM makes it look like they are all writing and reading from the same
notebook. This helps the computers share information easily without worrying about
where the data is stored.

Key Features of DSM:

1. Transparency:
o Applications do not need to know whether memory access is local or
remote.
2. Data Consistency:
o DSM systems use protocols to ensure consistency among copies of
shared data.
3. Synchronization:
o Mechanisms like locks or semaphores are provided to coordinate access
to shared data.
4. Scalability:
o Allows adding more nodes to improve performance.
Types of Distributed Shared Memory

1. On-Chip Memory
• The data is present in the CPU portion of the chip.
• Memory is directly connected to address lines.
• On-Chip Memory DSM is expensive and complex.

2. Bus-Based Multiprocessors
• A set of parallel wires called a bus acts as a connection between CPU and
memory.
• Accessing of same memory simultaneously by multiple CPUs is prevented by
using some algorithms.
• Cache memory is used to reduce network traffic.

3. Ring-Based Multiprocessors
• There is no global centralized memory present in Ring-based DSM.
• All nodes are connected via a token passing ring.
• In ring-bases DSM a single address line is divided into the shared area.

Advantages of Distributed Shared Memory (DSM):

1. Simplified Programming Model:

o Developers can write programs as if they are working with shared
memory, without worrying about explicit message passing.
2. Transparency:
o DSM hides the complexities of distributed systems, such as data location
and communication.
 3. Scalability:
o New nodes can be added to the system, allowing it to handle larger
workloads.
4. Resource Sharing:
o Enables efficient use of distributed memory resources across multiple
nodes.
5. Reduced Communication Overhead:
o By providing a shared memory abstraction, DSM reduces the need for
frequent, explicit message exchanges between nodes.
6. Fault Tolerance:
o Some DSM systems offer mechanisms to replicate data, making the
system more resilient to node failures.

Disadvantages of Distributed Shared Memory (DSM):

1. Performance Overhead:
o Consistency maintenance and synchronization protocols can slow down
the system compared to local memory access.
2. Complexity in Consistency Models:
o Ensuring consistency across nodes is challenging and may lead to
increased latency.
3. Network Latency:
o Accessing remote memory can be significantly slower than accessing
local memory, leading to potential bottlenecks.
4. Limited Scalability in Some Systems:
o Performance might degrade as the number of nodes increases, especially
if the consistency protocol is not efficient.
5. Debugging Difficulties:
o Distributed nature makes debugging harder since issues can arise from
network delays or consistency problems.
6. Higher Development Costs for Some Applications:
o While DSM simplifies certain aspects, applications requiring fine-tuned
performance might need additional optimizations.

Q2: What are the three main approaches for designing a DSM
system?
Here’s a simplified explanation of the three main approaches to designing a
Distributed Shared Memory (DSM) system:

1. Hardware-Based DSM
 • What it is: The system's hardware (like the processor or memory controller)
manages shared memory.
• How it works: Uses hardware rules to make sure all connected computers see
the same memory data.
• Pros:
o Super fast and efficient.
o Easy for programmers since the hardware handles everything.
• Cons:
o Very expensive to build.
o Hard to make changes or adapt.
• Best for: Systems needing high speed and performance, like powerful servers
or supercomputers.

2. Software-Based DSM

• What it is: Software programs handle shared memory instead of hardware.

• How it works: Special software makes sure that all connected computers share
memory correctly.
• Pros:
o Cheaper and easier to set up on regular computers.
o Flexible and easier to customize.
• Cons:
o Slower than hardware-based DSM.
o Can be tricky for programmers to get the best performance.
• Best for: Systems like computer clusters or workstation networks where cost
and flexibility matter.

3. Hybrid DSM

• What it is: A mix of hardware and software to get the best of both worlds.
• How it works: Hardware does basic tasks quickly, and software manages
higher-level memory sharing.
• Pros:
o Balances speed, cost, and flexibility.
o Makes good use of both hardware and software strengths.
• Cons:
o More complicated to design.
o The system's performance depends on how well the hardware and
software work together.
• Best for: Systems needing a balance of performance and affordability.

In short, hardware-based DSM is fast but costly, software-based DSM is flexible but
slower, and hybrid DSM is a middle ground that combines the two.
Q3: Describe the process migration features.

What is Process Migration?

It’s the ability to move a running program (called a process) from one computer to
another in a network of connected computers, while keeping it running smoothly and
ensuring its data remains correct.

Process migration in distributed systems refers to the transfer of a process or its

execution state from one node (computer or server) to another within a network. This
can be done for various reasons such as balancing the load across nodes, optimizing
resource usage, improving system performance, or enhancing fault tolerance and
recovery.

• The process typically involves saving the current state of the process, including
its memory and execution context, transferring this state to the target node, and
then resuming execution on the new node.

• This capability is crucial in distributed systems where resources are spread

across multiple machines, enabling dynamic adjustments to changing
workloads and system conditions.

Why is it Important?

Process migration helps:

1. Balance the load: Prevent one computer from being overloaded while others
are idle.
2. Handle failures: Move programs away from computers that are about to fail.
 3. Use resources efficiently: Distribute programs across computers to improve
performance.

Key Features

1. Transparent Memory Access

o Even after moving, the program can access its data like it’s still on the
old computer.
o DSM ensures all data stays consistent and correct across computers.
2. Dynamic Load Balancing
o Programs can move to less busy computers, helping share the workload
evenly.
o This avoids slowdowns caused by too many programs running on one
computer.
3. Fault Tolerance
o If a computer fails or is about to fail, programs can move to another
working computer.
o The program continues running without losing data.
4. Data and State Transfer
o The program’s current state (what it’s doing, its memory, and data) is
moved to the new computer.
o DSM ensures the program can still access shared memory from the new
location.
5. Consistency Maintenance
o DSM makes sure all computers have the same view of shared data.
o Any changes to shared data are updated everywhere.
6. Minimal Downtime
o Migration techniques like "pre-copy" reduce the time the program needs
to pause.
o The program keeps running during most of the transfer, with a quick
final pause to complete it.
7. Scalability
o Migration works well even in large systems, helping distribute programs
effectively across many computers.

Challenges

1. Overhead: Transferring program data can take time and slow things down.
2. Synchronization: Making sure the program’s data and state are always up-to-
date.
 3. Latency: Delays during migration can affect time-sensitive tasks.
4. Security: Protecting program data during the move.

Process migration in DSM makes it easier to move programs between computers

without stopping them. It helps distribute work, handles failures, and improves
efficiency. However, it needs careful handling of data and timing to work smoothly.

Types of Process Migration in Distributed Systems

Below are the types of process migration in distributed system:

• Static Migration:
o Definition: The entire process is moved to a new node, and
it starts execution from the point where it was suspended.
o Pros: Simple to implement; the process state is saved and
restored in full.
o Cons: High overhead due to the transfer of the entire
process state; not ideal for processes with large memory
footprints.
• Dynamic Migration:
o Definition: The process migrates while it is still running,
often by migrating its active state incrementally.
o Pros: Reduces downtime and allows for more fluid load
balancing.
o Cons: More complex to manage; requires sophisticated
mechanisms to maintain consistency and manage
intermediate states.
• Preemptive Migration:
o Definition: The process is temporarily paused, its state is
saved, and it is then moved to a new node where it resumes
execution.
o Pros: Allows for planned migrations with minimal
disruption.
o Cons: The process experiences a temporary halt, which
may affect performance.
• Non-Preemptive Migration:
o Definition: The process continues execution until it reaches
a natural stopping point or checkpoint before migration
occurs.
o Pros: Avoids disruption during migration; can be more
efficient for long-running processes.
o Cons: Requires processes to reach suitable stopping points,
which may not always align with optimal migration times.
• Incremental Migration:
 o Definition: The process state is migrated incrementally, in
stages, rather than all at once.
o Pros: Can reduce the impact of migration on system
performance and allows for smoother transitions.
o Cons: More complex to implement; requires careful
coordination to maintain process state consistency.

Steps involved in Process Migration in Distributed Systems

The steps which are involved in migrating the process are:

• Step 1: Selection of Process for Migration

o Description: Identify the process that needs to be migrated
based on criteria such as load balancing, resource
optimization, or fault tolerance.
o Details: Evaluate the process’s resource usage, current load
on the source node, and potential benefits of migration.
• Step 2: Choosing the Destination Node
o Description: Select the appropriate destination node where
the process will be relocated.
o Details: Consider factors like available resources,
compatibility, network latency, and current load on
potential destination nodes.
• Step 3: Migrating the Process to the Destination Node
o Description: Transfer the process from the source node to
the destination node.
o Details: This involves several subcategories of migration,
each addressing different aspects of the process’s state and
execution.

Q4: What are the different design and implementation issues

in distributed systems, explain.
Or
Explain the design and implementation issues of distributed
shared memory.
Designing and implementing a Distributed Shared Memory (DSM) system
involves addressing several challenges to provide a unified memory abstraction
across distributed nodes. These issues are primarily related to consistency,
performance, scalability, and fault tolerance. Here are the key design and
implementation issues:

1. Memory Consistency

• Issue: Making sure all nodes see the same data in shared memory.

• Challenge: Deciding how quickly updates are shared across nodes:

o Strict Consistency: Updates are seen immediately by all (hard to
achieve).
o Sequential Consistency: Operations seem to happen in a specific order.
o Release Consistency: Updates are shared at specific points (e.g., after
locks).

2. Memory Coherence

• Issue: Managing how memory blocks are shared when multiple nodes use the
same data.
• Methods:
o Write-Invalidate: Deletes other copies when one node writes to the
data.
o Write-Update: Updates all copies whenever one node writes.
• Challenge: Choosing a method that reduces communication between nodes.

3. Data Replication and Migration

• Replication: Copying data to multiple nodes for faster access.

• Migration: Moving data closer to the node that uses it the most.
• Challenge: Deciding when to replicate or move data for better performance
without causing conflicts.

4. Synchronization
 • Issue: Coordinating access to shared data to prevent errors.
• Methods: Using locks or barriers to control which node can update data.
• Challenge: Making synchronization fast and scalable for many nodes.

5. Communication Overhead

• Issue: DSM systems rely on sending messages between nodes to share data or
updates.
• Challenge: Reducing the number and size of these messages to improve
performance.

6. Granularity

• Issue: Deciding how big a chunk of memory (block) to share:

o Coarse-Grained: Larger blocks reduce messages but may include
unnecessary data.
o Fine-Grained: Smaller blocks send only what’s needed but require
more messages.
• Challenge: Choosing the right size for better performance.

7. Scalability

• Issue: Ensuring DSM works well even as more nodes are added.
• Challenge: Designing protocols that handle many nodes without slowing
down.

8. Fault Tolerance

• Issue: Ensuring the system continues working if a node or connection fails.

• Challenge: Using backups or checkpoints to recover quickly without losing
data.

9. Heterogeneity
 • Issue: DSM must work across nodes with different hardware or operating
systems.
• Challenge: Making the system flexible enough to handle various
configurations.

10. Security

• Issue: Protecting shared memory from unauthorized access or tampering.

• Challenge: Adding security without slowing down the system.

11. Transparency

• Issue: Making the memory appear as one big shared space, hiding the
complexity of distribution.
• Challenge: Keeping this illusion while ensuring efficient operation.

12. Performance Optimization

• Caching: Storing data locally for quick access.

• Prefetching: Predicting and loading needed data in advance.
• Challenge: Using these techniques without creating new problems like data
conflicts.

13. False Sharing

• Issue: When unrelated data in the same memory block is updated, causing
unnecessary synchronization.
• Challenge: Reducing such cases to improve performance.

14. Load Balancing

• Issue: Ensuring work is evenly distributed across nodes.

• Challenge: Migrating data or processes without disrupting the system.
15. Latency

• Issue: The time it takes to access data across the network.

• Challenge: Minimizing delays while keeping the system consistent.

Q5: Describe details about sequential and release consistency

models.
Or
Explain Sequential consistency in distributed shared memory.

In distributed systems, consistency models establish criteria for data

synchronization and specify how users and applications should interpret data
changes across several nodes.

In distributed systems, consistency models come in a variety of forms. Every

consistency model has advantages and disadvantages, and the system’s particular
requirements will determine which model is best.

Sequential Consistency Model

The sequential consistency model is a memory consistency model used in parallel
computing. It ensures that the results of memory operations are predictable and
follow a simple and intuitive rule: the order of operations is the same as if they were
executed sequentially in some order. Here's a detailed explanation:

Sequential consistency is a consistency model that ensures that the order in which
operations are executed by different processes in the system appears to be consistent
with a global order of execution. It ensures that the result of any execution of a
distributive system is the same as if the operations of all the processes in the system
were executed in some sequential order, one after the other.

• It means that all the processes or threads in a system see memory operations
(reads and writes) in the same order.
• Imagine everyone in a room watching a play. Even if the play happens in a
random order, everyone agrees on the sequence of events.

How it Works

1. Program Order: Each thread follows the order of operations written in its
program. For example, if Thread A writes X = 1 and then reads Y, it will
always do these actions in this order.
2. Global Agreement: All threads agree on the order in which everyone's
operations happened, even if the actual order is random.

Example

Say there are two threads, A and B, and two shared variables, X and Y, both starting
at 0:

• Thread A:
1. Write X = 1
2. Read Y
• Thread B:
1. Write Y = 1
2. Read X

Possible consistent orders:

1. Thread A writes X = 1, reads Y = 0, then Thread B writes Y = 1, reads X = 1.

2. Thread B writes Y = 1, reads X = 0, then Thread A writes X = 1, reads Y = 1.
No matter the order, all threads see the same sequence of events. For example,
Thread A can't see Y = 1 unless Thread B has already written it.

Why is it Useful?

• Easy to Understand: Developers don't need to worry about strange or

unpredictable memory behavior.
• Predictable Results: Makes debugging and testing easier.

Drawbacks

• Slower Performance: Ensuring a global order can slow down the system,
especially with many threads or processes.
• Not Always Practical: Modern systems often use weaker consistency models
for better speed and scalability.

In short, sequential consistency makes memory behavior simple and predictable but
can come at the cost of performance.

Here are the types of consistency in distributed systems:

1. Strict Consistency
2. Sequential Consistency
3. Causal Consistency
4. Eventual Consistency
5. Monotonic Read Consistency
6. Monotonic Write Consistency
7. Strong Consistency
8. Weak Consistency
9. Release Consistency
RELEASE CONSISTENCY

Release consistency in distributed systems is a way of handling updates to shared

data across multiple computers, balancing performance and data accuracy. It is a
"weaker" form of consistency compared to stricter models, like sequential
consistency, and is used when speed and scalability are more important than always
having the latest data.

Key Ideas of Release Consistency:

1. Acquiring and Releasing Data:

o When a process acquires data (accesses it), it can read the latest version
of that data.
o When a process releases data (updates or writes it), it makes sure that all
other processes that acquire the data later will see the updated version.
2. Visibility of Updates:
o After a process releases the data, all other processes that acquire the data
afterward will see the updated version.
o However, between the acquisition and release, other processes may see
old or inconsistent data.
3. Relaxed Consistency:
o Release consistency doesn't require processes to always see the latest
data instantly. Updates may be delayed, as long as the release and
acquire operations are properly followed.
4. Advantages:
o This model reduces the need for constant synchronization between
processes, which makes the system faster and more scalable.
 It's useful for systems where perfect consistency is not needed all the
o
time, but the release-acquire rule ensures correctness when needed.
5. Where It’s Used:
o Release consistency is commonly used in distributed systems, like
distributed shared memory or certain replicated databases, where
performance is crucial, but some flexibility in data consistency is
acceptable.

Simple Example:

Imagine two processes, P1 and P2, working with shared data:

1. P1 acquires the data, changes it, and then releases it.

2. P2 acquires the data after P1's release and sees the updated value.

Between the time P1 acquires the data and releases it, P2 might see old data. But once
P2 acquires the data after the release, it gets the updated version.

Comparing with Other Models:

• Sequential Consistency: Every process sees operations in the same order. It’s
stricter than release consistency.
• Eventual Consistency: Even more relaxed than release consistency, where all
replicas of data will eventually become the same, but not immediately.

In short, release consistency is a compromise, allowing faster, scalable systems where

data updates are not always immediate, but correctness is ensured when necessary.