Distribution System

Gafat Institute of

Technology

Department of

Computer

Group Assignment

Prepared by:

No. FULL NAEME ID NUMBER

1 ABEL TADELE
2 FIKADE MULATU 0701
3 ESRAEL ADAMU 0611
4 HAYLEMARIAM DESTA
5 HABTAMU GEBEYAWU 3090
6 ELIYAS YIMER

1
 TABLE CONTENT

[Link]………………………….…………………………………….………3

[Link] ………………………………………………………………..……..…..4

[Link] Is Middle ware…………………………………………………………………...5

[Link] We Need Middleware………………………………………………………..….6

[Link]…………………………………………………………………………………7

[Link] We Need Multicast ………………………………………………………..…….7

[Link] To A Server…………………………………………………………………..…..9

[Link] Communication ………………………………………..…………..10

9. Example of Where An Address Of An Entity …………………………………..11

10. Hierarchical Location Service …………………………..…………………………12

11. DNS ….…………………………………….…………………………………………..13

12. Three Sources Of Delay….…………………………………….……………………15

[Link] Of Two Machines In A Distributed System……………………….15

[Link] Coordinator Crashes……………………………………………………..17

[Link] Consistency Models…………………………………………….………18

[Link] How Replication in DNS Takes Place………………………………18

[Link] DNS Replication Works so Well…………………………………………19

[Link] Systems………….………………………………………………..20

[Link] Browser………………………………………………………………23

[Link]……………………………………………………………..……….24

2
 Acknowledgment
We express our sincere gratitude to Debre Tabor University and the Department of
Computer Science for their guidance and support in our exploration of distributed
systems.

Special thanks go to our instructor for providing comprehensive assignments that

encouraged us to delve deeply into the concepts and practical applications of
distributed systems.

We also thank our peers for their collaborative efforts and insightful discussions that
enriched our understanding of the subject matter.

3
 Abstract
Distributed systems play a crucial role in modern computing, enabling the efficient
and reliable coordination of resources and tasks across multiple nodes. This document
explores fundamental concepts related to distributed systems, including middleware,
multicast communication, asynchronous and synchronous remote procedure calls, and
connectionless communication. The aim is to provide clarity on these topics through
detailed analysis and practical examples, focusing on how these mechanisms enhance
scalability, efficiency, and fault tolerance in distributed environments. Additionally,
practical challenges such as location resolution, clock synchronization, and
coordinator failures are discussed, along with solutions to address them, emphasizing
the need for robust designs in dependable systems.

4
1, Briefly explain, what is middle ware? Why we need it?

 What is Middle ware?

Middle ware:- is a software layer that sits between an operating system and applications on
each side of a distributed system. It facilitates communication, data management, and other
services needed by applications in a networked or distributed environment.

Middle ware acts as a bridge to enable interoperability between different software

applications or between applications and hardware, often providing common services like
messaging, authentication, transaction management, and database connectivity.

5
1.1Why Do We Need Middle ware?
1,Simplifies Communication:- Middle ware provides a standard communication mechanism,
allowing distributed systems or applications on different platforms to communicate
seamlessly without having to manage low-level networking or protocol details.

2,Interoperability:- It enables different applications or systems that may use different

programming languages, protocols, or hardware to work together. Middle ware abstracts the
complexities of interacting with diverse systems, making it easier to integrate different
technologies.

3,Scalability:- Middle ware supports the scalability of applications by offering features like
load balancing, message routing, and fault tolerance, which are essential when handling
growing numbers of users or distributed nodes.

4,Reliability and Fault Tolerance:- Middle ware often includes mechanisms for ensuring
reliability in communication, such as retrying failed messages or managing transactional
consistency, so distributed systems can continue operating smoothly even in the face of errors
or crashes.

5,Security:- Middle ware can provide security features like authentication, encryption, and
access control, helping to protect data and ensure that only authorized users or systems can
access sensitive resources.

6,Transaction Management:- In distributed systems, middle ware can handle complex

transaction management, ensuring that operations across multiple systems or databases
maintain consistency and integrity.

7,Abstraction and Simplification:- Middle ware abstracts low-level networking and system
details, enabling developers to focus on application logic rather than dealing with complex
communication protocols or infrastructure challenges.

6
2,What is multicast? Why we need it in distributed system?

 What is Multicast?
Multicast is a method of communication in networking where data is sent from a source to
multiple recipients (or "listeners") in a network.

Unlike unicast, where data is sent from a single source to a single recipient, multicast allows
the source to send a single copy of the data to multiple recipients at once.

Figure 2: multicasting

2.1 Why Do We Need Multicast in Distributed Systems?

Multicast is valuable in distributed systems for several reasons:

1. Efficient Data Distribution

 Minimized Bandwidth Usage: Without multicast, if you wanted to send the same
data to multiple recipients (e.g., thousands of clients), you would need to send a
separate copy of the data to each client (unicast). This results in high bandwidth usage
and network congestion. With multicast, a single message is sent to the multicast
group, and the network infrastructure efficiently replicates and forwards it to all the
group members.
 Reduced Redundancy: It reduces the redundancy of sending the same data over and
over again to each receiver, improving network efficiency.

2. Scalability

 Handling Large Groups: In distributed systems where large numbers of machines

(clients, servers, or nodes) need to receive the same data (e.g., software updates,
sensor readings, live video feeds), multicast scales much better than unicast. Instead
of needing a separate transmission to each node, multicast allows for a single


7
  transmission to multiple clients simultaneously, making the system more scalable and
reducing the load on the source system.
 Less Overhead for the Source: Multicast reduces the load on the source because it
doesn't need to manage individual connections for each recipient, which is especially
important in systems where large numbers of clients need to be served concurrently.

3. Réal-Time Communication

 Live Streaming & Multimedia: Multicast is ideal for applications requiring real-
time communication, such as live streaming, conferencing, or broadcasting. For
example, in a video conferencing system or live sports broadcast, multicast allows the
source (e.g., the video server) to send a stream to multiple viewers in real-time
without overloading the network.
 Low Latency: The ability to transmit data to multiple receivers simultaneously with
low latency is crucial for many real-time distributed applications like gaming, VoIP,
and multimedia broadcasting.

4. Group Communication

 Efficient Notification/Message Broadcasting: In distributed systems, there may be

scenarios where a system needs to send the same message or update to all or a large
subset of nodes in a network.
 Consensus Protocols: In some distributed systems, nodes may need to communicate
and agree on certain actions (e.g., in distributed consensus algorithms like Paxos or
Raft). Multicast allows for efficient broadcasting of proposals or heartbeats to
multiple nodes simultaneously.

5. Cost Efficiency

 Less Load on Network Infrastructure: Multicast reduces the load on routers and
network infrastructure since it avoids sending duplicate copies of data across the
same network segments. This can save resources for both the sender and the network.
 Cost-Effective for Broadcasting: Multicast is often cheaper in terms of both
bandwidth and computation for scenarios where information needs to be broadcast to
many recipients (e.g., system updates or media distribution).

Conclusion:-Multicast is a powerful technique in distributed systems that allows efficient,

scalable, and low-latency communication between a source and multiple recipients. It
minimizes the use of network resources and is essential for scenarios where large groups of
systems need to receive the same information, such as real-time streaming, broadcasting, or
large-scale data distribution.

8
3, assume a client calls an asynchronous RPC to a server, and
subsequently waits until the server returns a result using another
asynchronous RPC. Is this approach the same as letting the client
execute a normal RPC? What if we replace the asynchronous RPCs
with asynchronous R PCs?
To better understand the difference, let’s break it down into two parts: the first scenario where
the client calls asynchronous R PCs, and the second scenario where the client executes normal
R PCs.

Scenario 1: Asynchronous RPC Calls

When the client calls an asynchronous RPC, it sends the request to the server and does not
block or wait for the response immediately. Instead, it proceeds with other operations (such as
executing other R PCs, handling other tasks, or waiting for responses). However, in your
scenario, after calling an asynchronous RPC to the server, the client waits for the server's
result via another asynchronous RPC.

Although the client is using asynchronous R PCs for both calls, the fact that it waits for the
result in the second asynchronous call introduces a blocking behaviour, making the client wait
for the result of the server's operation. The key point here is that even though the R PCs are
asynchronous, the client essentially becomes blocked waiting for the result of the second
RPC. So, in this case, the client still ends up waiting (blocking) for the response in the end.

Scenario 2: Normal RPC Calls (Synchronous)

In a normal RPC, the client sends a request to the server and waits (blocks) for the server to
return the response. This blocking behaviour happens within the normal synchronous flow,
meaning the client is paused until the result is returned from the server.

Comparison:

 Asynchronous R PCs in Scenario 1: While the client uses asynchronous R PCs, it waits
for the result of the server’s response after the second asynchronous call, which
introduces blocking behaviour. It behaves similarly to a synchronous RPC in terms of
waiting for the result.
 Normal (Synchronous) R PCs in Scenario 2: The client calls a synchronous RPC and
waits for the result. It’s a simple blocking call, and there’s no expectation for the client to
proceed with other tasks while waiting.

In conclusion, if the client waits for the result of an asynchronous RPC in a similar way to
how it would block in a synchronous RPC, then the overall behaviour between the two
approaches is essentially the same. The client waits for the response in both cases, making the
distinction between asynchronous and synchronous R PCs somewhat irrelevant in this
specific situation.

9
4,Describe how connection-less communication between a client and
a server proceeds when using sockets.
In connection-less communication, the client and server communicate without establishing a
persistent connection, and each message (or data gram) is sent independently. This is typically
implemented using UDP (User Data-gram Protocol), which is a connection-less transport
protocol. The key idea is that messages can be sent and received without the need for a formal
handshake or maintaining a continuous connection between the client and the server.

Here’s how connection-less communication proceeds using sockets:

1. Client Sends a Data-gram to the Server:-

 The client uses a socket to send data to the server. The socket is configured to use
UDP, which does not require establishing a connection.
 The client prepares the data and packages it into a data-gram (a self-contained,
independent packet of information).

2. Server Listens for Incoming Datagrams:-

 The server also uses a socket, which is configured for receiving UDP messages.
 The server’s socket is set to listen for incoming data-grams using the recvfrom()
system call (or a similar function). This socket does not need to be explicitly
connected to a remote address, as it simply receives incoming data-grams.
 The server does not maintain an active connection with the client. Instead, it waits for
each incoming data-gram, processes it, and then may send a response back to the
client if necessary.

3. Server Sends a Response (if applicable):-

 If the server needs to reply to the client, it packages the response in a new data-gram
and sends it back to the client using the send to() call.
 The server must know the client's address and port, which were typically included in
the data-gram received from the client.

4. Client Receives the Data-gram:-

 The client receives the response in the form of a data-gram, which might contain a
message from the server or other data.
 Once the client receives the message, it processes it and may send further messages
(or terminate the communication).

5. Stateless Nature:-

 Both the client and the server do not retain state about each other. There’s no
established session or connection that persists across multiple messages.
 Each message is independent, and there’s no concept of "establishing" or "closing"
the connection in the traditional sense (as with TCP).

This connection-less model is often used in applications that prioritize speed over reliability
(such as real-time video/audio streaming, DNS queries, and simple message broadcasts),
where the occasional loss of packets is acceptable.

10
5,Give an example of where an address of an entity E needs
to be further resolved into another address to actually access
E

A common example where an address of an entity E needs to be further resolved into

another address is the DNS resolution process in the context of accessing a website.

Example: DNS Resolution for Website Access

Step 1: Initial Address (Domain Name):-

You want to visit a website, so you enter a domain name (e.g., [Link])
in your browser. This domain name is the address of the entity you're trying to access
(in this case, the web server that hosts the website).

Step 2: Resolving the Domain Name to an IP Address:-

The domain name ([Link]) is a human-readable address but the actual
network communication requires an IP address. To resolve this, the system uses DNS
(Domain Name System), which translates the domain name into an IP address.

1. The browser sends a query to a DNS server to resolve the domain name into
an IP address.
2. The DNS server replies with the IP address (e.g., [Link]) corresponding to
[Link].

Step 3: Further Resolution (IP Address for Network Communication):-

Now that the browser has the IP address ([Link]), it can directly access the web
server hosting the website.

The IP address is used to establish a connection to the server over the internet.

In this example:

 Entity E is the web server hosting the website (represented by its domain name,
[Link]).
 The domain name needs to be resolved into an IP address (such as [Link]) before
the actual network communication (accessing the web server) can happen.

This illustrates how a higher-level address (a domain name) must be resolved into a lower-
level address (an IP address) to enable access to the actual entity (the web server).

11
6,. In a hierarchical location service with a depth of k, how
many location records need to be updated at most when a
mobile entity changes its location?
In a hierarchical location service, the mobile entity’s location is typically stored at different
levels in the hierarchy, with each level representing a different scope of coverage (e.g.,
country, region, city, building, etc..). When a mobile entity changes its location, the location
records must be updated to reflect the new position at different levels of the hierarchy.

How Location Updates Work:

When a mobile entity moves, the location information must be updated at several levels in the
hierarchy, starting from the lowest level (where the entity's precise location is stored) up to
the highest level (which represents a more general location scope).

Maximum Number of Location Records to Update:

 At each level in the hierarchy, the system needs to update the location of the entity. This
means that if the mobile entity moves to a new location, it will trigger updates at every
level above it, starting from the lowest level and moving upwards.

 At level 0 (the root of the hierarchy), the mobile entity’s location will be stored or
referenced in some record. At each intermediate level, a reference to the entity's location
is updated, and at the lowest level (the most granular level), the exact location of the
entity will be recorded.

Thus, if the hierarchy has a depth of k, the entity's location will be updated at k levels (one
update per level).

Conclusion:-The maximum number of location records that need to be updated when a mobile
entity changes its location in a hierarchical location service with a depth of k is k.

12
7,Explain how DNS can be used to implement a home-based
approach to locating mobile hosts.
In a home-based approach to locating mobile hosts, a mobile device (host) registers its
location with a home server that serves as its home agent.

The idea is that the mobile host always appears to be at the same location (its "home
address"), regardless of where it physically moves within the network.

When the mobile host changes its physical location, this change needs to be communicated so
that other devices can still reach it.

Key Concepts:

 Mobile Host (MH): The device whose location is being tracked as it moves between
different networks.
 Home Agent (HA): A server (or DNS service) that knows the "home" address of the
mobile host, where the mobile host's information is kept.
 Home Network: The network that contains the mobile host's "home" address or entry
point in the system.
 Current Location (Care-of Address): The real-time IP address of the mobile host,
which changes as it moves to different networks.
 DNS (Domain Name System): A system for mapping domain names (such as
[Link]) to IP addresses, and vice versa.

How DNS Can Be Used in a Home-Based Approach:

1,Home Network Registration:-

 The mobile host initially has a static, permanent identifier (e.g., mobile-
[Link]) assigned by the home network. This is the mobile host's home
address.
 When the mobile host moves to a new network, it obtains a new care-of address (COA),
which is the IP address in the current network.

2,Dynamic DNS Update:-

 The mobile host communicates with its home agent (via a DNS server) to update its
location information.
 The mobile host updates its DNS record to associate its home address (mobile-
[Link]) with the new care-of address (the IP address in the current network).
This is done by sending a DNS update or query to the home DNS server.

3,DNS Resolution Process:-

 When another device (e.g., a user or service trying to reach the mobile host) wants to
communicate with the mobile host, it performs a DNS lookup for mobile-
[Link].
 The DNS system will resolve this domain name to the current care-of address (the IP
address where the mobile host is currently located), which was updated previously.

13
4,Forwarding Messages:-

 Once the DNS resolution returns the correct care-of address, the message is sent to the
mobile host's current location.
 If necessary, the home agent or the DNS server could forward the message to the correct
network (if the host’s IP address is not directly reachable).

5,Consistent Identification:

 Despite the mobile host moving, it always uses the same home address (mobile-
[Link]). The home agent keeps track of the current care-of address and
ensures that the DNS system reflects this update.
 This approach allows the mobile host to appear stationary to external parties, even
though its actual physical location may change frequently.

Conclusion:- By using DNS in a home-based approach to locating mobile hosts, the mobile
host can maintain a consistent, permanent identifier (home address) while seamlessly
updating its location (care-of address) as it moves between networks. DNS ensures that
messages are routed to the correct location without requiring external users or devices to track
or adjust to the host’s changing physical address. This provides the mobile host with mobility
while retaining a stable identity for communication.

14
8 ,Name at least three sources of delay that can be
introduced between WWV broadcasting the time and the
processors in a distributed system setting their internal
clocks

There are several sources of delay that can be introduced between WWV broadcasting the
time and processors in a distributed system setting their internal clocks. Here are at least
three:

1,Propagation Delay:- The time it takes for the WWV signal (radio waves) to travel from the
WWV transmitter to the receiver. This delay depends on the distance between the receiver
and the WWV broadcast source, and is typically on the order of milliseconds.

2,Signal Processing and Reception Delay:- The time taken by the receiver hardware to
process the incoming WWV signal, extract the time data, and convert it into a usable format.
This processing can introduce delays, depending on the receiver's hardware and software
capabilities.

3,Network Latency:- If the time signal is being relayed over a network (e.g., via a networked
time protocol like NTP), there will be additional delays due to the time it takes for the signal
to travel across the network to the distributed system’s processors. This can be influenced by
factors like network congestion, routing, and the physical distance between systems.

These delays can combine and lead to discrepancies between the actual time broadcast by

WWV and the time set on each processor in the system.

15
9 , Consider the behaviour of two machines in a distributed system.
Both have clocks that are supposed to tick 1000 times per
millisecond. One of them actually does, but the other ticks only 990
times per millisecond. If UTC updates come in once a minute, what is
the maximum clock skew that will occur?
To understand the maximum clock skew between the two machines, let’s break it down:

 Machine 1 ticks 1000 times per millisecond, which is the expected behaviour.
 Machine 2 ticks 990 times per millisecond, which means it is running 1% slower
than Machine 1.

If UTC updates come in once a minute, each update occurs every 60,000 milliseconds (1
minute).

 Step 1: Calculate the number of ticks per minute for each machine

Machine 1
Since Machine 1 ticks 1000 times per millisecond, in one minute (60,000 milliseconds), the
number of ticks is:-

1000 ticks/ms×60,000 ms=60,000,000 ticks1000 \, \text{ticks/ms} \times 60,000 \, \text{ms}

= 60,000,000 \, \text{ticks}1000ticks/ms×60,000ms=60,000,000ticks

Machine 2
Since Machine 2 ticks 990 times per millisecond, in one minute (60,000 milliseconds), the
number of ticks is:-

990 ticks/ms×60,000 ms=59,400,000 ticks990 \, \text{ticks/ms} \times 60,000 \, \text{ms} =

59,400,000 \, \text{ticks}990ticks/ms×60,000ms=59,400,000ticks

 Step 2: Calculate the difference in ticks between the two machines

The difference in ticks between Machine 1 and Machine 2 in one minute is:-

60,000,000−59,400,000=600,000 ticks60,000,000 - 59,400,000 = 600,000 \, \

text{ticks}60,000,000−59,400,000=600,000ticks

Step 3: Convert the difference in ticks to time

Each tick represents one microsecond (1 ms / 1000), so the time difference corresponding to
600,000 ticks is:-

600,000 ticks×1 μs=600 milliseconds600,000 \, \text{ticks} \times 1 \, \mu s = 600 \, \

text{milliseconds}600,000ticks×1μs=600milliseconds

Conclusion:The maximum clock skew between the two machines after one minute is 600
milliseconds

16
10,. Suppose that the coordinator crashes. Does this always
bring the system down? If not, under what circumstances
does this happen? Is there any way to avoid the problem and
make the system able to tolerate coordinator crashes?

In a distributed system, the crash of a coordinator does not necessarily bring the entire system
down. The impact of a coordinator crash depends on how the system is designed and the
specific role of the coordinator. Let's break this down:

1. Does the coordinator crash always bring the system down?

 No, it does not always bring the system down. The system can continue to function if
it is designed to handle coordinator failures gracefully.
 If the coordinator is responsible for tasks like leader election, coordination of
resources, or managing requests, its failure might impact ongoing operations.
However, if the system has mechanisms in place for fail-over or recovery, it may
continue working.

2. Under what circumstances does the crash bring the system down?

The system will likely be brought down if:

 Single Point of Failure: The coordinator is the sole entity responsible for critical
decisions, and there are no fall-back mechanisms. In this case, the failure of the
coordinator can stop the system from making progress.
 No Redundancy: If there is no replica or backup coordinator that can take over the role,
the system might halt until the coordinator is restored.

3. Can the problem be avoided and make the system tolerate coordinator crashes?

Yes, the system can be designed to tolerate coordinator crashes. Here are a few strategies to
achieve that:

 Replication of the Coordinator: One common approach is to have replicated

coordinators (or a backup coordinator). In this set-up, the system ensures that there is
always a backup available to take over if the primary coordinator fails.
 Leader Election: Use a leader election protocol (such as Paxos, Raft, or Zab) to ensure
that if the coordinator crashes, another machine can be elected as the new coordinator.
This guarantees that the system can continue operating without needing manual
intervention.
 State Machine Replication: Systems like Zoo-keeper use state machine replication,
where multiple copies of the coordinator state are maintained across different nodes. If
the coordinator fails, the system can quickly recover by using one of the replica
coordinators.
 Time-outs and Heartbeats: Set up time-outs and heartbeat mechanisms where other
nodes can detect if the coordinator has failed and take action (e.g., trigger a new leader
election or fail-over to a backup coordinator).
 Transactional Integrity: Ensure that the system uses transactional consistency where
operations can be rolled back or committed, allowing recovery from a coordinator crash
without losing system consistency.

17
11, Explain in your own words what the main reason is for
actually considering weak consistency models.
 the group member try to reflect their own idea but with regard this all the group
member agreed on :- the main reason for considering weak consistency models is to
make the system faster and able to handle more users. When you try to keep everything
perfectly consistent all the time, it can slow down the system a lot because every part of
it has to check and update the data all the time. This takes a lot of time and resources.

With weak consistency, the system doesn’t worry about being perfectly up-to-date at
every moment. This means it can be quicker and still keep working well even when
there’s a lot of traffic or when some parts of the system aren’t connected. The data might
not always be the same everywhere right away, but it usually gets there eventually.

So, weak consistency is useful when it's more important to have better performance and
keep the system running smoothly even if data isn’t always completely consistent at the
same time.

12, Explain how replication in DNS takes place, and why it

actually works so well. During the discussion of consistency
models, we often referred to the contract between the
software and data store. Why is such a contract needed?
Réplication in DNS (Demain Name System)

Replication in DNS happens through a system of distributed servers that store copies of the
DNS records.

1,Primary and Secondary DNS Servers:- A domain’s DNS information (like A records,
MX records, etc..) is usually stored in a primary DNS server. This primary server is
responsible for holding the authoritative record for that domain. secondary DNS servers
(which are replicas of the primary server) are also set up to store the same information. These
secondary servers regularly query the primary server to synchronize their data and ensure that
they have the latest version of the records.

2,TTL (Time to Live):- DNS records have a TTL value, which tells DNS resolvers how long
they can cache the record before they need to query the authoritative servers again. This
ensures that DNS records can be replicated across various servers around the world without
needing immediate updates every time a change is made.

3,Hierarchical Structure:- DNS operates in a hierarchical structure, with root servers at the
top, followed by top-level domain (TLD) servers, and then authoritative servers for individual
domains. Replication occurs at various levels in this hierarchy, allowing for a distributed and
scalable way to serve DNS requests.

18
12.1 Why DNS replication works so well:
 Redundancy:- By having multiple DNS servers spread across different locations
(primary and secondary servers), the system is fault-tolerant. If one server goes down,
another can take over, ensuring continuous service.
 Scalability:- DNS replication allows the system to handle millions of requests by
distributing the load across different servers around the world. This makes it much
more scalable.
 Fault tolerance:- If one DNS server is slow or down, DNS resolvers will attempt to
query other servers in the network, ensuring that DNS queries still get answered even
during server failures or network issues.
 Caching:- The TTL mechanism reduces the number of queries that need to be made
to authoritative servers, improving performance and reducing the load on the primary
DNS servers.

Why a Contract Between Software and Data Store Is Needed

When discussing consistency models in distributed systems, a contract between the software
(application) and the data store (database) is essential because it defines the expectations and
guarantees of how data is handled, especially in terms of consistency, availability, and
partition tolerance (the CAP theorem).

Here’s why such a contract is needed:

1,Clear Expectations: The contract establishes clear rules about how data will be read,
written, and synchronized. For example, will the system use strong consistency (where all
nodes have the same data at the same time) or eventual consistency (where data will
eventually be consistent, but not immediately)? This clarity helps developers design
applications that can work reliably under the given model.

2,Consistency Guarantees: The contract helps define the level of consistency that the system
provides. In distributed systems, different consistency models (like linearisability, causal
consistency, or eventual consistency) affect how data is accessed and updated. The contract
ensures that the system and the software agree on which consistency model to implement, so
that developers know what behaviour to expect when interacting with the data store.

3,Error Handling and Recovery: The contract also specifies what happens in case of
failures, such as network partitions or crashes. For example, with eventual consistency, the
system might tolerate temporary inconsistencies but ensure eventual convergence. The
contract defines how the system should handle these situations, giving developers a
predictable way to manage errors and system failures.

4,Performance Trade-offs: The consistency model directly impacts performance. For

instance, strong consistency can slow down a system because it requires constant
synchronization, while weaker consistency models may allow faster access. The contract
helps developers understand these trade-offs and design their system accordingly, balancing
the need for performance with the need for consistency.

In summary, a contract between the software and the data store is needed to set expectations
about data consistency, availability, and fault tolerance. It helps manage the complexity of

19
distributed systems and ensures that both the application and the data store operate in
harmony according to predefined rules and guarantees.

13, Dependable systems are often required to provide a high

degree of security. Why?
Dependable systems are often required to provide a high degree of security because security
is a key aspect of dependability. A dependable system is one that is reliable, available, and
fault-tolerant, ensuring it operates correctly even under adverse conditions. Security is crucial
for ensuring that a system remains dependable in the face of potential attacks, vulnerabilities,
or misuse. Here's why security and dependability go hand in hand:

1. Protection from Unauthorized Access:-

A dependable system must ensure that only authorized users can access its resources and data.
If an attacker gains unauthorized access, they can compromise the system's integrity, leading
to failures, data corruption, or denial of service. For instance, a financial transaction system
needs to ensure that only legitimate users can make transactions. Without security measures
like authentication and authorization, the system becomes vulnerable to malicious actors.

2. Prevention of Data Corruption or Loss:-

Dependable systems must preserve the integrity of the data they process and store. Security
mechanisms, such as encryption, access control, and data validation, protect data from being
altered or corrupted by malicious users or software. If a system is not secure, attackers can
tamper with data, causing errors that could undermine the system’s functionality or lead to
incorrect decisions.

3. Availability and Protection from Denial-of-Service (Dos) Attacks:-

Security also plays a critical role in ensuring availability, which is a core component of
dependability. A system that is not secure is susceptible to denial-of-service (Dos) attacks,
where an attacker floods the system with requests to exhaust resources and make the system
unavailable. If security measures are not in place to prevent or mitigate such attacks, the
system could fail to provide services when needed.

4. Protection Against Malicious Behaviour:-

Malicious users or attackers may exploit vulnerabilities in a system, either through direct
attacks or by causing the system to behave in unintended ways. A dependable system must
have strong security measures in place to detect and defend against these threats, ensuring that
even in the presence of malicious behaviour, the system remains functional and trustworthy.

5. Resilience in the Face of Threats:-

Security adds to the system’s resilience against attacks that could otherwise cause it to fail.
For example, ensuring confidentiality through encryption ensures that sensitive information is
protected even if the system is compromised. Integrity checks, audit logs, and other security
features ensure that if an attack does occur, it can be detected, and the system can recover
quickly without catastrophic consequences.

20
6. Trustworthiness:-

The trust that users, organizations, and customers place in a system is directly tied to its
security. If users believe that their data, privacy, and transactions are at risk, they will not
trust the system. A dependable system, therefore, needs to have strong security measures in
place to maintain that trust and ensure its continued operation and reputation.

Conclusion:- In summary, security is an integral part of dependability because it ensures the

system’s integrity, availability, and confidentiality. Without robust security, a system could be
vulnerable to attacks or misuse, potentially causing data breaches, service disruptions, or loss
of functionality, all of which would undermine its dependability. Therefore, security is not
just an add-on but a necessary foundation for building reliable and trustworthy systems.

14, What makes the fail-stop model in the case of crash failures so difficult to
implement?

The fail-stop model in the case of crash failures assumes that when a component (e.g., a
server or process) crashes, it halts its operation and stops entirely, providing a clear indication
of failure. While this model simplifies fault detection, implementing it in practice is difficult
due to several challenges:

1. Detecting Failures Accurately

 Unreliable Detection: In a distributed system, detecting a crash can be tricky. A process

might become unresponsive due to high load or network partitioning, making it hard to
distinguish between a crash (fail-stop) and temporary unresponsiveness. For example, a
process might not actually crash but instead just be slow, making it difficult for the
system to decide whether the process has truly failed or is just delayed.
 Lack of Immediate Notification: The failing component does not always have the
capability to notify other components immediately that it has stopped. In some systems,
especially those without heartbeats or failure detection mechanisms in place, the
component might not communicate failure directly, which can result in other parts of the
system waiting for responses that will never come.

2. Coordinating Failure Recovery

 Complex Recovery Protocols: In a distributed system where many components are

interdependent, it can be hard to coordinate the recovery process after a crash. The fail-
stop model assumes that when a component crashes, the system can seamlessly detect it
and then recover, but in practice, recovery often requires significant coordination (e.g.,
reassigning tasks, resynchronizing state, or electing new leaders) that can be complex
and error-prone.
 Consistency Issues: Systems may need to ensure consistency when recovering from
failures. After a crash, certain processes might need to be rolled back or resynchronized
to restore a consistent state, and this process can be difficult to manage. In systems using
weak consistency models, handling the aftermath of a crash without violating
consistency can be even more challenging.

3. Failure Propagation

21
 Cascading Failures: In a distributed system, one component’s crash might cause others
to fail, either directly (e.g., through resource exhaustion) or indirectly (e.g., through
missed communications or cascading errors). The fail-stop model assumes that failure is
isolated to the crashed component, but in reality, a failure in one part of the system can
cause a ripple effect, making it harder to handle crash recovery.
 Lack of Isolation: Properly isolating failure to the crashed component and ensuring that
other components continue to function normally is difficult. In practice, ensuring that the
failure of one component doesn't affect others can require significant redundancy, fault
tolerance, and careful architectural design.

4. Ambiguity in Distributed Systems

 Network Partitions: In a distributed system, a network partition might occur, causing

nodes to become temporarily isolated. During this partition, nodes might incorrectly
assume that another node has failed when it’s simply unreachable. The fail-stop model
assumes that a crash results in a clear, unequivocal failure, but in reality, distinguishing
between crashes and network issues can be very difficult.
 Non-atomic Failures: Failures can occur in an unpredictable manner. A node might fail
in the middle of processing a request or during an update operation, leading to
inconsistent states. The fail-stop model doesn't account for partial failures where the
system is in an uncertain state, making it difficult to recover gracefully.

5. Time-outs and Recovery Timing

 Handling Time-outs: In the fail-stop model, if a node crashes, other components

typically wait for a time-out before assuming the node has failed. However, setting
appropriate time-outs is tricky: too short, and you risk prematurely assuming failure; too
long, and the system becomes slow to respond to actual failures. The challenge is finding
a balance to minimize delays while avoiding false alarms.
 Re-synchronization Delays: After detecting a crash, the system may need to re-
synchronize or reassign tasks to other nodes, which can cause delays in recovery. The
fail-stop model requires that these processes be handled quickly and without introducing
inconsistency or data loss, which is challenging in distributed environments.

Conclusion:-Implementing the fail-stop model in distributed systems is difficult because crash

detection is not always reliable, recovery from failures can be complex, failure might
propagate in unexpected ways, and distinguishing between network issues and actual crashes
can be ambiguous.

22
15, Consider a Web browser that returns an outdated cached page
instead of a more recent one that had been updated at the server. Is
this a failure, and if so, what kind of failure? Can the model of triple
modular redundancy described in the text handle Byzantine failures?
1. Is this a failure?

Yes, this situation can be considered a failure, though it depends on the context and the
expectations for the system. In the case of a web browser returning an outdated cached page
instead of a more recent one that has been updated on the server, this could be classified as a
consistency failure. The browser is supposed to provide the most up-to-date content, but
instead, it returns outdated information from its cache, which violates the expectation of
freshness and correctness of the data.

However, this failure could also be seen as a performance issue (e.g., because the browser
didn't properly check if the cached version was up-to-date) or a timeliness failure (where the
browser failed to get the latest data in time, but it isn't necessarily corrupted data).

2. Can the model of triple modular redundancy (TMR) handle Byzantine failures?

Triple Modular Redundancy (TMR) is a fault-tolerant technique that involves creating three
replicas of a system and using a majority voting mechanism to determine the correct output.
The basic idea is that if one component fails, the other two can still provide the correct result.
However, TMR has limitations in handling certain types of failures.

Byzantine Failures:-

A Byzantine failure occurs when a system component (such as a server, node, or process)
exhibits arbitrary or malicious behaviour, potentially providing incorrect, inconsistent, or
conflicting information to other parts of the system. These failures are more complex than
simple crashes, as the component may still be "alive" and operational but behave
unpredictably or maliciously.

In the context of TMR:-

 TMR and Byzantine failures: TMR can tolerate crash failures, where one component
stops functioning altogether. However, Byzantine failures are more problematic for TMR
because TMR assumes that the faulty components will still behave in a predictable way
(just producing incorrect results or outputs), not arbitrary or malicious behaviour. If all
three components in a TMR system are compromised (for example, if they all serve
incorrect or conflicting data), TMR may not be able to distinguish between valid and
invalid outputs, as the majority voting mechanism might still return an incorrect result.
 Handling Byzantine failures: To handle Byzantine failures, a more advanced technique
is needed, such as the Byzantine Fault Tolerance (BFT) algorithm. BFT systems can
tolerate malicious or arbitrary failures by using complex protocols that ensure that a
correct result can still be achieved, even if some components are behaving in a Byzantine
manner. BFT typically requires more than three replicas (often more than five) and
complex algorithms to reach a consensus despite the presence of faulty components.

23
References

[Link], A. S., & Van Steen, M. (2017). Distributed Systems: Principles

and Paradigms (3rd ed.). Pearson.

[Link], G., Dollimore, J., Kindberg, T., & Blair, G. (2011). Distributed
Systems: Concepts and Design (5th ed.). Addison-Wesley.

[Link], J. L., & Patterson, D. A. (2019). Computer Architecture: A

Quantitative Approach (6th ed.). Morgan Kaufmann.

[Link], K. (2005). Reliable Distributed Systems: Technologies, Web

Services, and Applications. Springer.

[Link], G. R. (2000). Foundations of Multithreaded, Parallel, and

Distributed Programming. Addison-Wesley.

[Link] Computer Society. (2019). IEEE Standard for Distributed Interactive

Simulation. IEEE Std 1278.1-2019.

[Link], L. (1978). "Time, Clocks, and the Ordering of Events in a

Distributed System." Communications of the ACM, 21(7), 558-565.

…. THANK YOU …

24