0% found this document useful (0 votes)
8 views6 pages

Distributed Communication Primitives Explained

Uploaded by

samfrancissam06
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views6 pages

Distributed Communication Primitives Explained

Uploaded by

samfrancissam06
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Primitives for Distributed Communication

In a distributed system, processes run on different machines and communicate by sending messages.
The basic operations are Send() and Receive().
1. Parameters
 Send(dest, buffer) → Sends data from sender’s buffer to the destination process.
 Receive(source, buffer) → Receives data from a source into the receiver’s buffer.

2. Buffered vs Unbuffered
 Buffered: Data copied to a kernel buffer before sending; sender can continue without waiting
for receiver.
 Unbuffered: Data sent directly from user buffer to receiver; sender may wait until receiver is
ready.

3. Blocking vs Non-blocking
 Blocking: Process waits until the operation finishes (send acknowledged or message
received).
 Non-blocking: Operation starts and control returns immediately; process can do other work
while message is sent/received.

4. Synchronous vs Asynchronous
 Synchronous: Sender and receiver meet (handshake). Send completes only when receiver is
ready.
 Asynchronous: Send completes after data leaves sender’s buffer, without waiting for
receiver.

5. Four Send Modes


1. Blocking synchronous send – Wait until receiver copies data and sends acknowledgement.
2. Non-blocking synchronous send – Starts send, returns immediately; completion checked
later.
3. Blocking asynchronous send – Wait until data is copied to kernel buffer.
4. Non-blocking asynchronous send – Start copying, return immediately, check completion
later.

6. Receive Modes
 Blocking receive: Wait until message arrives.
 Non-blocking receive: Return immediately, check later when message arrives.

7. Examples
 MPI: MPI_Send, MPI_Isend, MPI_Recv
 RPC / RMI / CORBA: Higher-level communication built on message passing.

Conclusion:
These primitives decide when a process waits and how data is moved. Correct choice improves
performance, avoids deadlocks, and ensures reliable communication in distributed systems.
Global State of a Distributed System
1. Definition
The global state of a distributed system is the combined condition of:
 Local state of each process
 State of all communication channels
It represents a possible configuration of the whole system at a specific instant of time.
Since there is no shared memory and no global clock, computing this state is challenging.

2. Components
a) Local State of a Process
 Includes: processor registers, program counter, call stack, local memory, and variable values.
 Depends on the process’s execution at that moment.
b) State of a Communication Channel
 The set of messages in transit (sent but not yet received) on that channel.

3. Why Global State is Important


 Debugging and Monitoring – Helps to understand and trace system behavior.
 Deadlock Detection – Identify if processes are all waiting for each other.
 Termination Detection – Find out if computation has completed.
 Checkpointing and Recovery – Save system state to recover from failures.
 Performance Analysis – Evaluate how processes and channels behave.

4. How It is Computed – Distributed Snapshot


Since no global clock exists, snapshots must be coordinated:
Chandy–Lamport Algorithm (example method):
1. A process initiates the snapshot by recording its local state and sending a marker message on
all outgoing channels.
2. When a process receives a marker for the first time, it records its local state and sends
markers on its own outgoing channels.
3. Each process records messages arriving on a channel after recording its state but before
receiving a marker on that channel — these are the in-transit messages (channel state).

5. Example
Imagine 3 processes P1, P2, P3 connected in a ring:
 Local state: execution variables in each process.
 Channel state: messages sent but not yet received (e.g., P1 → P2: “update”, still in transit).

Conclusion:
The global state is a snapshot that combines all local and channel states, essential for consistency,
coordination, and fault recovery in distributed systems.

Design Issues and Challenges in Distributed Systems (System Perspective)


1. Introduction
Designing a distributed system is complex because processes run on different machines, communicate
over networks, and must appear as a single system to the user. From a system perspective, the design
must handle communication, coordination, security, scalability, and fault tolerance.

2. Main Issues
a) Communication
 Provide reliable and efficient message exchange between processes.
 Examples: Remote Procedure Call (RPC), Remote Method Invocation (RMI).
b) Process Management
 Creation, scheduling, and termination of processes/threads.
 Support migration of code and mobile agents between machines.
c) Naming
 Assign unique, location-independent names to resources and processes.
 Must be robust and scalable for geographically distributed systems.
d) Synchronization
 Coordinate access to shared resources and events.
 Techniques: Mutual exclusion, leader election, physical/logical clock synchronization, global
state recording.
e) Data Storage and Access
 Design distributed file systems and databases for easy and efficient data access.

f) Consistency and Replication


 Replication improves performance and fault tolerance, but must maintain data consistency
across copies.
g) Fault Tolerance
 Detect and recover from failures.
 Techniques: Reliable communication, checkpointing, distributed commit protocols.
h) Security
 Protect data and communication using cryptography, authentication, authorization, and secure
channels.
i) Transparency (hiding system complexity)
 Access transparency – hide differences in data formats.
 Location transparency – hide location of resources.
 Migration transparency – move resources without changing names.
 Replication transparency – hide if resource is replicated.
 Concurrency transparency – allow simultaneous access without conflict.
 Failure transparency – mask system failures.
j) Scalability and Modularity
 System should grow without performance loss.
 Use techniques like replication, caching, asynchronous processing.

3. Conclusion
Addressing these system-level design issues ensures that the distributed system is reliable, secure,
scalable, and user-friendly, meeting both technical and performance goals.

Need of Clock Synchronization in Distributed Systems


1. Introduction
 In distributed systems, each machine has its own clock.
 Due to hardware drift, these clocks do not run at exactly the same rate → no single global
clock.
 Many distributed algorithms need events to be ordered consistently across machines.
 Clock synchronization ensures all processes have a common notion of time, either physical
or logical.

2. Why Synchronization is Needed


1. Event Ordering – Decide the correct order of events happening in different processes.
2. Causal Relationship – Ensure events that depend on each other are processed in correct
order.
3. Coordination – Tasks like mutual exclusion, leader election need agreed timing.
4. Logging & Debugging – Merge logs from different machines in correct order.
5. Transactions – Maintain consistency in distributed databases.
6. Fault Detection – Timeout-based detection needs accurate timing.

3. Methods of Synchronization
a) Scalar Time (Lamport’s Logical Clock)
 Introduced by Lamport to order events without a physical clock.
 Rules:
1. All counters start at 0.
2. Increment local counter for every event (internal, send, receive).
3. When sending a message → attach current counter value.
4. When receiving a message →
Ci = max(Ci, Cm) then increment by 1.
 Properties:
o Consistency: Clock values always increase.
o Total ordering: Tie-breaking using process IDs.
o Event counting: Clock value − 1 = events before this event.
o Limitation: Does not give strong consistency (can’t always detect concurrency).

b) Vector Time (Vector Clocks)


 Extends Lamport’s clock for strong consistency.
 For N processes, each process keeps a vector of size N.
 Rules:
1. Initially all counters = 0.
2. Increment own counter for each local event.
3. On send: attach vector clock.
4. On receive: increment own counter, then update each element to
max(local[i], received[i]).
 Properties:
o Strong consistency: Can determine if two events are causally related.
o Captures concurrency explicitly.

4. Conclusion
Clock synchronization is essential to maintain order, causality, and coordination in distributed
systems.
Physical synchronization (e.g., NTP) keeps real clocks close; logical clocks (Lamport’s, vector
clocks) provide ordering without depending on real time.

Common questions

Powered by AI

Distributed systems face challenges in achieving clock synchronization due to hardware drift, which causes clocks to run at different rates, and the absence of a global clock. Logical clocks, such as Lamport's Scalar Time, provide a mechanism for consistent event ordering without relying on physical time, whereas vector clocks offer strong consistency by allowing distributed systems to determine causal relationships and capture concurrency. These techniques ensure that distributed algorithms can order events correctly, ensuring coordination and consistency across the system .

The Chandy-Lamport algorithm facilitates the computation of a global state by providing a method to capture a consistent snapshot across distributed processes. It accomplishes this through the use of marker messages that are sent by a process to its outgoing channels after recording its local state. When a marker is received for the first time, a process records its state and propagates markers along its outgoing channels. This coordination ensures that the global state includes all in-transit messages between processes, allowing for an accurate and consistent representation of the system state without reliance on global clocks .

Clock synchronization in distributed databases benefits distributed transactions by ensuring that operations are ordered consistently, which is crucial for maintaining data integrity and respect transaction order across distributed nodes. It enables proper execution of timeout-based processes and deadlock detection, critical for transaction management. Synchronization methods like logical clocks ensure that distributed transactions abide by causal relationships, aligning with consistency models and preventing anomalies such as write-write conflicts .

Transparency in distributed systems improves user interaction by hiding the complexities and inefficiencies of system operations. For instance, access transparency allows users to interact with data without knowing its format or location, while replication transparency ensures users are unaware of data being stored in multiple locations. This abstraction leads to a user-friendly experience as users can interact with the system as if it is a single coherent unit. System performance also benefits as these transparencies enable optimizations like caching and replication without impacting user experience .

Primitives for distributed communication, such as Send() and Receive(), are essential in determining when a process waits and how data is moved in a distributed system. They ensure performance by allowing operations to be asynchronous or non-blocking, enabling processes to continue other tasks without waiting for message delivery. Reliability is maintained by selecting appropriate send modes, such as blocking synchronous or non-blocking asynchronous sends, which help to avoid deadlocks and ensure message delivery .

To ensure data consistency in distributed systems with replicated data, methods such as synchronous replication, where updates are simultaneously reflected across all copies, and eventual consistency, where replicas gradually synchronize, are used. The trade-offs include the complexity and overhead of maintaining strong consistency via synchronous replication, which can affect performance and scalability. Eventual consistency offers better scalability and availability but may lead to temporary discrepancies between replicas, which can complicate application logic and data correctness .

The absence of a global clock in distributed systems challenges the implementation of distributed algorithms that require coordinated timing for events, as processes operate independently with potentially differing local times. This affects timing-based operations like mutual exclusion, event ordering, and coordination. Solutions such as logical clocks (e.g., Lamport's and vector clocks) are used to provide a coherent notion of event order, allowing processes to coordinate without real-time synchronization. These mechanisms enable algorithms to maintain consistent state awareness and causal ordering across processes despite the lack of a global time reference .

Communication and naming significantly affect the scalability and transparency of distributed systems. Efficient and reliable communication mechanisms are vital for processes to exchange messages seamlessly across different machines, while improper handling can lead to bottlenecks and failures. Naming, which involves assigning location-independent names to resources, ensures resources are accessible and discoverable, supporting scalability by allowing growth without reconfiguration. Both aspects also contribute to different forms of transparency, such as location and migration transparency, which help hide complexities of the system from users, enabling a more seamless interaction with distributed resources .

Scalar clocks, like Lamport's Logical Clock, offer simplicity by providing a total order of events based on incremented counters but lack the ability to detect concurrency, as they do not capture causal relationships beyond simple ordering. In contrast, vector clocks provide a more complex but comprehensive solution, allowing the explicit detection of causal relationships and concurrent events by maintaining a vector of counters for each process. This complexity enables systems to better manage concurrency and event causality, crucial for systems that require strong consistency and coordination .

The global state of a distributed system, which combines the local states of individual processes and the states of communication channels, is crucial for monitoring and debugging. It helps trace system behavior and understand interactions between components, which is necessary for deadlock detection, performance analysis, and system recovery through checkpointing. Without a consolidated global state, it would be challenging to identify issues across distributed components .

You might also like