TDDD25
Distributed Systems
Models
of Distributed Systems
Christoph Kessler
IDA
Linköping University
Sweden
2024
Agenda
1. Architectural Models
2. Interaction Models
3. Fault Models
2
Basic Notions
Resources in a distributed system are shared between users.
They are normally encapsulated within one of the computers and
can be accessed from other computers by communication.
Each resource is managed by
a program,
the resource manager
It offers a communication
interface enabling the resource to
be accessed by its users.
Resource managers can,
in general, be modelled as processes.
If the system is designed according to an object-oriented
methodology, resources are encapsulated in objects.
2
Architectural Models
What are architectural models about?
Software architecture and hardware architecture
How are responsibilities distributed between system components, and
how are these components placed?
Client-server model
Peer-to-peer
And variations of the above two:
Proxy server
Mobile code
Mobile agents
Network computers
Thin clients
Mobile devices
Client – Server Architecture Model
The system is structured as a set of processes, called servers, that
offer services to the service users, called clients.
The client-server model is usually based on a simple request/reply
protocol, implemented
with send/receive primitives or
using remote procedure calls (RPC)
or remote method invocation (RMI):
– The client sends a request (invocation) message to the
server asking for some service.
– The server does the work and returns a result (e.g. the data
requested) or an error code if the work could not be
performed.
Client-Server Architecture Model
Client and Server are software roles associated with processes,
which may be mapped differently to hardware (computer nodes).
E.g., a server can itself request services from other servers;
in this new relation, the server itself acts like a client.
Peer-to-Peer (P2P) Architecture Model
All processes (objects) play a similar role:
Processes (objects) interact
without particular distinction
between clients and servers.
The pattern of communication depends
on the particular application.
A large number of data objects
are shared
Any individual computer holds only
a small part of the application data(base).
Processing and communication loads
for access to objects are distributed across
many computers and access links.
This is the most general and flexible model.
Data / file sharing (later)
Most common representative / standard in HPC:
MPI Message Passing Interface https://www.mpi-forum.org
Covered in great detail in TDDC78
Peer-to-Peer vs. Client-Server
Some problems with client-server:
Centralisation of service poor scaling
Limitations:
capacity of server
bandwidth of network connecting the server
Peer-to-Peer tries to solve some of the above problems
It distributes shared resources widely
computing and communication loads are shared
Problems with peer-to-peer:
High complexity, due to need to
cleverly place individual objects
retrieve the objects
maintain a potentially large number of replicas.
Variations of the Basic Models
Client-server and peer-to-peer can be considered as basic models.
Several variations have been proposed,
considering factors such as:
multiple servers and proxy servers / caches
mobile code and mobile agents
mobile devices
Proxy Server
A proxy server provides copies
(replications) of resources which
are managed
by other servers.
Proxy servers are typically used as caches for remote resources.
They maintain a cache of recently visited web pages or other resources.
When a request is issued by a client, the proxy server is first checked if the
requested object (information item) is available there.
Proxy servers can be located at each client, or
can be shared by several clients.
The purpose is to increase performance and availability,
by avoiding frequent accesses to remote servers.
Extension of proxy principle: Heavily used servers can be replicated to
multiple “back-end” servers (the service/data is “mirrored”)
server farm or spread geographically, plus front-end (proxy) server
the proxy server delegates service tasks (e.g., web page / file download, video
streaming, search) e.g. round-robin across the back-end servers
Mobile Code
Mobile code:
code sent from one computer to another and run at the destination.
Advantage: remote invocations are replaced by local ones.
Typical example: Java applets.
1
Mobile Agents
Mobile agent:
a running program that travels from one computer to another,
carrying out a task on someone’s behalf.
A mobile agent is a complete program, code + data,
that can work (relatively) independently.
The mobile agent can invoke local resources/data.
Typical tasks:
Collect information
Install/maintain software on computers
Compare prices from various vendors by visiting their sites.
Attention: potential security risk (like mobile code)!
1
Interaction Models
How do we handle time?
Are there time limits on process execution,
message delivery, and clock drifts?
Synchronous distributed systems
Asynchronous distributed systems
Synchronous Distributed Systems
Main features:
Lower and upper bounds on execution time of processes can be set.
Transmitted messages are received within a known bounded time.
Drift rates between local clocks have a known bound.
Important consequences:
1. In a synchronous distributed system, there is a notion of
global physical time
(with a known relative precision depending on the drift rate).
2. Only synchronous distributed systems are predictable in terms of
timing.
Only such systems can be used for hard real-time applications.
3. In a synchronous distributed system, it is possible and safe to use
timeouts in order to detect failures of a process or communication
link.
But ...
It is difficult and costly to implement synchronous
distributed systems.
Asynchronous Distributed Systems
Many distributed systems (including those on the Internet) are asynchronous:
No bound on process execution time
(nothing can be assumed about speed, load, reliability of computers).
No bound on message transmission delays
(nothing can be assumed about speed, load, reliability of interconnections)
No bounds on drift rates between local clocks.
Important consequences:
1. In an asynchronous distributed system, there is no global physical time.
Reasoning can be only in terms of logical time.
2. Asynchronous distributed systems are unpredictable in terms of timing.
3. No timeouts can be used.
Asynchronous systems are widely and successfully used in practice.
In practice, timeouts are used with asynchronous systems for failure
detection.
However, additional measures have to be applied in order to avoid
duplicated messages, duplicated execution of operations, etc.
Fault Models
What kind of faults can occur and what are their effects?
Omission faults
Arbitrary faults
Timing faults
Faults can occur both in processes and communication channels.
The reason can be both software and hardware.
Fault models are needed in order to build systems with predictable
behavior in case of faults (systems which are fault-tolerant).
A fault-tolerant system will function according to the predictions only
as long as the real faults behave as defined by the fault model. Otherwise
...
Omission Faults (Fail-Stop Model)
A processor or communication channel fails to perform actions it is supposed
to do: the particular action is not performed by the faulty component!
With omission faults:
If a component is faulty, it does not produce any output.
If a component produces an output, this output is correct.
With omission faults, in synchronous systems,
faults are detected by timeouts.
Since we are sure that messages arrive within a time interval, a
timeout will indicate that the sending component is faulty.
Such a system has a fail-stop behavior.
Arbitrary (Byzantine) Faults
This is the most general and worst possible fault semantics:
Intended processing steps or communications are omitted or/and
unintended ones are executed.
Results may not come at all,
or may come but carry wrong values.
Everything, including the worst, can happen!
Timing Faults
Timing faults can occur in synchronous distributed systems, where
time limits are set to process execution, communications, and clock
drifts.
A timing fault results in any of these time limits being exceeded.
Acknowledgments
Most of the slide contents is based on a previous version by
Petru Eles, IDA, Linköping University.
20
