Distributed Systems EXAM Questions and Answers 2024/2025 | verified
Distributed System - A collection of autonomous computers/devices which perform a task
together
Host - Computer or device that contains one or more CPUs, memory, and possibly disk storage
Network - Links hosts together
Middleware - Layer of software whose purpose is to mask the heterogenerity of the distributed
system, and to provide a convenient programming model for programmers
Characteristics of a DS - 1. Each host operates independently, so there is no central authority,
although hosts may be allocated as authorities on particular tasks
2.Each host keeps time separately, so every host has a clock, synchronization requires an algorithm
3.Hosts fail independently of one another
4. Hosts exchange messages to: share state, use others' resources, notify remote changes. This is both
the function of a DS and the means to control the DS
Design Considerations - Openness, scalability, transparency, management, heterogeneity,
concurrency, fault tolerance, security, performance, other issues
Openness (design consideration) - Interfaces to the OS, network, and services must be based on
published specifications (such as standards)
Allows for new hosts to be added to the network
1. Makes it possible for one vendor to build systems which interact with those of another vendor
2. Without such openness, user has to buy everything from the same vendor
Concurrency (design consideration) - Concurrency is important because:
,1. Even if the DS is comprised only of hosts running a single process, the distributed system as a whole
will be multi-process
2. Multiple clients may try to access a service
3. Duplicated resources may provide equivalent services
So issues similar to those in multi-process operating systems must be addressed: locking,
synchronization
Scalability (design consideration) - Scalability pros of DS:
1. relatively cheap components may be used to build a small system at first
2. Additional components can be easily added as demand on the system increases
For this to work we need duplicated resources, allowing us to avoid: the notion of single master services,
short fixed names, performance bottlenecks
Scalability and state:
Some resources have state information, and the duplication of state information leads to the problem of
propagating changes of state to the various copies
State Information - Data that alters the resource's future responses to requests (e.g. The State of a
file server is the data held on disk, alterations to the state alter the response given to a read request)
Fault Tolerance (design consideration) - Increased number of components leads to an increased
likelihood that at least one component fails at any given time, so design the DS to continue to work even
if any component fails.
Use fault isolation, and fault masking
Need hardware redundancy and software recovery
There are different measures of failure rate
,Fault tolerance is costly
There are different failure modes
Fault Isolation - Fault occurring in one resource does not affect operation of other resources (need
hardware redundancy)
Fault Masking - Take action to restore the service when a particular resource of the service fails
without the user noticing (need software recovery)
Types of Measures of Failure Rate - 1. Mean Time Before Failure (MTBF)
2. t-Fault Tolerance
Mean Time Before Failure (MTBF) - 1. Average period of time between failures, can assume a
random distribution of failures, can also measure using the probability of a failure occurring in any
period of time
t-fault Tolerance - Must be more than t failed components before a service fails
Can be a more intuitive measurement
Tells us that we can suffer t failures before losing a service
Failure Modes - Different ways a system can fail. We can evaluate systems based on how well they
perform in the presence of different kinds of failures
1. Failstop
2. crash
3. crash+link
4. Receive omission
, 5. Send omission
6. General omission
7. Byzantine failure
Failstop - A processor halts and remains halted. This halt can be detected by other processors
Crash - A processor halts and remains halted, but cannot be detected by other processors.
Crash+link - Network fails to deliver message because the link is broken
Receive Omission - A failure mode where either a crash or a processor fails to read some of the
messages sent to it
Send Omission - A failure mode where either a crash or a processor fails to write some messages
required by the protocol
General Omission - A failure mode that is either a send or receive omission
Byzantine Failure - A failure mode where the processor behaves in a manner not permitted by the
protocol (bug, Logic failure in the code)
Failure Mode Illustration - Service 1 fails:
Failstop: client knows that service 1
Has failed, So uses service 2
Crash: client does not know service 1 has failed, so client blocks, waiting for a response
In failure, service 1 may or may not be still active:
Crash: service 1 does not process message from client
Receive omission: service 1 does not receive clients messages
Distributed System - A collection of autonomous computers/devices which perform a task
together
Host - Computer or device that contains one or more CPUs, memory, and possibly disk storage
Network - Links hosts together
Middleware - Layer of software whose purpose is to mask the heterogenerity of the distributed
system, and to provide a convenient programming model for programmers
Characteristics of a DS - 1. Each host operates independently, so there is no central authority,
although hosts may be allocated as authorities on particular tasks
2.Each host keeps time separately, so every host has a clock, synchronization requires an algorithm
3.Hosts fail independently of one another
4. Hosts exchange messages to: share state, use others' resources, notify remote changes. This is both
the function of a DS and the means to control the DS
Design Considerations - Openness, scalability, transparency, management, heterogeneity,
concurrency, fault tolerance, security, performance, other issues
Openness (design consideration) - Interfaces to the OS, network, and services must be based on
published specifications (such as standards)
Allows for new hosts to be added to the network
1. Makes it possible for one vendor to build systems which interact with those of another vendor
2. Without such openness, user has to buy everything from the same vendor
Concurrency (design consideration) - Concurrency is important because:
,1. Even if the DS is comprised only of hosts running a single process, the distributed system as a whole
will be multi-process
2. Multiple clients may try to access a service
3. Duplicated resources may provide equivalent services
So issues similar to those in multi-process operating systems must be addressed: locking,
synchronization
Scalability (design consideration) - Scalability pros of DS:
1. relatively cheap components may be used to build a small system at first
2. Additional components can be easily added as demand on the system increases
For this to work we need duplicated resources, allowing us to avoid: the notion of single master services,
short fixed names, performance bottlenecks
Scalability and state:
Some resources have state information, and the duplication of state information leads to the problem of
propagating changes of state to the various copies
State Information - Data that alters the resource's future responses to requests (e.g. The State of a
file server is the data held on disk, alterations to the state alter the response given to a read request)
Fault Tolerance (design consideration) - Increased number of components leads to an increased
likelihood that at least one component fails at any given time, so design the DS to continue to work even
if any component fails.
Use fault isolation, and fault masking
Need hardware redundancy and software recovery
There are different measures of failure rate
,Fault tolerance is costly
There are different failure modes
Fault Isolation - Fault occurring in one resource does not affect operation of other resources (need
hardware redundancy)
Fault Masking - Take action to restore the service when a particular resource of the service fails
without the user noticing (need software recovery)
Types of Measures of Failure Rate - 1. Mean Time Before Failure (MTBF)
2. t-Fault Tolerance
Mean Time Before Failure (MTBF) - 1. Average period of time between failures, can assume a
random distribution of failures, can also measure using the probability of a failure occurring in any
period of time
t-fault Tolerance - Must be more than t failed components before a service fails
Can be a more intuitive measurement
Tells us that we can suffer t failures before losing a service
Failure Modes - Different ways a system can fail. We can evaluate systems based on how well they
perform in the presence of different kinds of failures
1. Failstop
2. crash
3. crash+link
4. Receive omission
, 5. Send omission
6. General omission
7. Byzantine failure
Failstop - A processor halts and remains halted. This halt can be detected by other processors
Crash - A processor halts and remains halted, but cannot be detected by other processors.
Crash+link - Network fails to deliver message because the link is broken
Receive Omission - A failure mode where either a crash or a processor fails to read some of the
messages sent to it
Send Omission - A failure mode where either a crash or a processor fails to write some messages
required by the protocol
General Omission - A failure mode that is either a send or receive omission
Byzantine Failure - A failure mode where the processor behaves in a manner not permitted by the
protocol (bug, Logic failure in the code)
Failure Mode Illustration - Service 1 fails:
Failstop: client knows that service 1
Has failed, So uses service 2
Crash: client does not know service 1 has failed, so client blocks, waiting for a response
In failure, service 1 may or may not be still active:
Crash: service 1 does not process message from client
Receive omission: service 1 does not receive clients messages
