2. Sistemas Distribuidos
System Models
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Octubre, 2020
Loja, Ecuador
4. 4
Introduction
Distributed system design can be explained through three different models:
Physical models – models that capture the hardware composition of a system in terms of
computer and their interconnecting networks
Architectural models – models that describe the system in terms of the computational and
communication tasks performed by its computational elements
Fundamental models – models that describe an abstraction of individual items in
distributed systems. Three models; interaction, failure, and security models
5. 5
PHYSICAL MODELS
Basic physical models - baseline physical model
Model that shows hardware and software components located at
networked computers communicate and coordinate their actions by
passing message
Three generations of distributed systems:
Early distributed systems
Internet-scale distributed systems
Contemporary distributed systems
6. 6
PHYSICAL MODELS
intranet
ISP
desktop computer:
backbone
satellite link
server:
Se rv er
Cli ent
Cl ien t
invocat ion
r esul t
Serve rinvoca ti on
r es ul t
P ro cess:
Key:
Com pute r:
☎
network link:
☎
☎
☎
Figure 1.3 A typical portion of the Internet
Esto ha llevado a un
mayor énfasis en los
estándares abiertos
y las tecnologías de
middleware
asociadas, como
CORBA y, más
recientemente, los
servicios web
10. 10
ARCHITECTURAL MODELS
Architecture?
The structure of a system specifying its
components and their interrelationships
Why architecture?
To ensure that the structure will meet the current
and future demands on it
To provide a reliable, manageable, adaptable and
cost-effective system
11. 11
ARCHITECTURAL MODELS
How to understand the fundamental building
blocks of a distributed system?
What are the entities that are communicating in the
distributed system (communicating entities)?
How do they communicate, or, what communication
paradigm is used (communication paradigms)?
What roles and responsibilities do they have in the
overall architecture (roles and responsibilities)?
How do they mapped on to the physical distributed
architecture (what is their placement)?
Architectural elements:
13. 13
ARCHITECTURAL MODELS
Architectural elements:
Communication paradigms
Interprocess communication – low-level process support. E.g.
message passing primitives, direct access to API, multicast
communication
Remote invocation – common communication paradigm in
distributed systems. Two-way exchange between communicating
entities, common techniques; RPC, RMI, request-reply protocols
Indirect communication– E.g. group communication, publish-
subscribe systems, message queues, tuple spaces, distributed
shared memory
19. 19
ARCHITECTURAL MODELS
Architectural elements:
Placement strategies:
Mapping of services to multiple servers – several servers
process services in separate hosts. Example: Sun Network
Information Service (NIS)
Caching – storing recently used data objects. Example: web
proxy server
Mobile code – Code can be downloaded and run on user’s
machine. Example: Applet
Mobile agents – Code and data travel in a network and
performing specific tasks on behalf of the users. Example: Web
crawler program
21. 21
ARCHITECTURAL MODELS
Architectural elements:
a) client request results in the downloading of applet code
Web
server
Client
Web
serverApplet
Applet code
Client
b) client interacts with the applet
Web applets
22. 22
ARCHITECTURAL MODELS
Architectural patterns:
Layering –complex system is partitioned into a number of
layers. The top layer utilizes the services of the lower
layer
Tiered architecture – complementary to layering,
organizes the functionality of the given layer and place it
in appropriate server (physical nodes)
Thin clients – software layer that supports window-based
user interface in remote computers
Other patterns: e.g. proxy, brokerage, reflection
31. 31
Fundamental models
Interaction model
Process interaction in a distributed system are
affected by:
Performance of communication channels: latency,
bandwidth, jitter
Computer clocks – Clock drift rate
Synchronous distributed systems - Asinchronous
Time to execute each step of a process has known
Known time for transmitting messages
Local dirft clocks has a known bonds
32. 32
Fundamental models
Failure model
defines the ways in which failure may occur in
order to provide an understanding of its effects.
Categories of failures:
Omission failures - Process or channel failed to do
something
Arbitrary failures - Any type of error can occur in processes
or channels (worst)
Timing failures - Applicable only to synchronous distributed
systems where time limits may not be met
33. 33
Fundamental models
Process p Process q
Communication channel
send
Outgoing message buffer Incoming message buffer
receivem
Processes and channels
34. 34
Fundamental models
Class of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes may
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes asend, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
(Byzantine)
Process or
channel
Process/channel exhibits arbitrary behaviour: it may
send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
detect this state.
Omission and arbitrary failures
35. 35
Fundamental models
Class of Failure Affects Description
Clock Process Process’s local clock exceeds the bounds on its
rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
between two steps.
Performance Channel A message’s transmission takes longer than the
stated bound.
Timing failures
36. 36
Fundamental models
Security model - Secure processes and channels
and protect objects encapsulated against
unauthorized access.
Protecting access to objects - Access rights,
authentication of clients
Protecting processes and interactions
Threats to processes: problem of unauthenticated
requests / replies. e.g., "man in the middle"
Threats to communication channels: enemy may
copy, alter or inject messages as they travel across
network.
Use of “secure” channels, based on cryptographic methods.
