Transcript Distributed System Models

Distributed System Models
(Fundamental Model)
 Architectural Model
 Goal




Reliability
Manageability
Adaptability
Cost-effectiveness
 Service Layers


Platform
Middleware
 System Architecture



Client/Server
Proxy
Peer to Peer
 Variations on Client/Server

Mobile code and mobile agent
 Design requirements for distributed systems
Objectives of the lecture
 To provide fundamental models that reflect common
properties for distributed system designs.
 To understand the characteristics of the most common
fundamental models of distributed systems.
System models – what and why?
 System model:
 Abstract, consistent description of a relevant aspect of a distributed
system.
 A system model could address:
 What are the main entities in the system?
 How do they interact?
 What are the characteristics that affect their individual and
collective behavior?
 The purpose of a system model:
 Make explicit all assumptions.
 To make generalizations concerning what is possible or
impossible.
Distributed system models
 Architectural models:
?
 Fundamental models:
 Formal description of system properties common in all
architectural models
 Interaction, failure, security
Fundamental models
 Interaction model:
 Performance of processes and communication channels,
absence of a global clock, timing problems, …
 Failure model:
 Failures of processes and communication channels,
 reliable communication…
 We define and Classifies the faults and their effects
 Security model:
 Possible threats to processes and communication channels
 secure channels…
Interaction
model - basics
 Interaction
 Multiple server processes may cooperate to provide service
eg.DNS
 A set of peer processes may cooperate to achieve common
goal eg. Voice conferencing

Communication & Coordination
 Distributed Algorithm
 definition of the steps to be taken by each of the processes of
which DS is made of, including the transmission of messages.
 Rate at which each process proceed and the timing of transmission
of messages cannot in general be predicted.
 Each process has its own state.
 Significant factors affecting interacting processes:
 Communication performance.
 Lack of global notion of time.
Interaction model – Significant factors
 Performance of communication channels:
 Latency.

Delay between sending of a message by one process and its receipt
by another.

Transmission time


Delay network access time


Time taken to for the first of the string of bits transmitted
through a network to reach its destination.
Increase significantly with increase in network load.
Operating system communication services time

In sending and receiving messages. Varies with load on OS
 Bandwidth.

total amount of information that can be transmitted in given time
 Jitter.

Variation in the time taken to deliver a series of messages. e.g.
multimedia data
Interaction model – Signifiant factors (cont.)
 Computer clocks and timing events.
 Local processes use time service
 Different time values for processes at different systems
 Drift rate

The relative amount of time that a clock differs from a perfect
reference clock
 Computers may use radio receivers to get time from GPS
 Costly
Interaction model –
synchronous vs. asynchronous
 Synchronous distributed systems:
 The time to execute each step of a process has known lower
and upper bounds.
 Each message transmitted over a channel is received within a
known bounded time.
 Each process has a local clock whose drift rate from real time
has a known bound.
Interaction model – synchronous vs.
asynchronous
 Asynchronous distributed systems
 – no bounds on:



Process execution speed.
Message transmission delays.
Clock drift rates.
 Web is asynchronous system
 Actual distributed systems are very often asynchronous


Sharing processors
Sharing network
Interaction model – event ordering
s end
X
receiv e
1
m1
2
Y
receiv e
4
s end
3
m2
receiv e
Phy sical
time
receiv e
s end
Z
receiv e
receiv e
m3
A
t1
t2
m1
m2
receiv e receiv e receiv e
t3
Lamport Logical Clock for time stamping
Failure Models
 Failure

System doesn’t give desired behavior


Component-level failure
System-level failure (incorrect result)
 Fault

Cause of failure (component-level)



Transient: Not repeatable
Intermittent: Repeats, but (apparently) independent of
system operations
Permanent: Exists until component repaired
 Failure Model
 How the system behaves when its not working
properly
Failure models - Types
 Omission failures.
 Arbitrary failures.
 Timing failures.
Failure model - omission failure (1)
 A process or communication channel fails to perform
actions that it is supposed to do.
 Process omission failures:
 Crash.

Use timeouts.
 Process crash is called Fail-stop



If other processes can detect certainly that Process has
been crashed.
Can be produced in synchronous systems only.
Where message delivery is guaranteed.
Failure model – omission failure (2)
 Communication omission failures:
 Communication primitives are send and receive.



Send-omission failures.
Receive-omission failures.
Channel-omission failures.


Also known as dropping message
Generally caused by


Lack of buffer space at receiving end or intervening gateway
Network transmission error, detected by a checksum
process p
process q
send m
receiv e
Communic ation c hannel
Outgoing mess age buffer
Incoming mes sage buffer
Failure model – Arbitrary failure
 Arbitrary or Byzantine failures
 Describe the worst possible failure semantics, in which any
type of error may occur

process/channel exhibits arbitrary behavior
 Arbitrary Process failure
Process may omit a step/s or Perform uninterested step/s
 Arbitrary Communication Failure
 Messages contents can be corrupted, a duplicate message can
be sent or message can be lost on its way
 Rare and can be detected by checksum or message numbering

Failure model – overview of omission failures
Class of failure Affects Description
Process halts and remains halted. Other processes may
not be able to detect this state.
Fail-stop
Process Process halts and remains halted. Other processes may
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 send,but
a
the message is not put
in its outgoing message buffer.
Receive-omissionProcess A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
Process orProcess/channel exhibits arbitrary behaviour: it may
(Byzantine)
channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
Crash
Process
Failure model - timing failures
 Applicable in synchronous distributed systems.
 Time limits
 Process execution time
 Message delivery time
 Clock drift rate
Class
Affects
Description
Performance
Process
Performance
Channel
Process exceeds the bounds on the interval
between two steps.
A message’s transmission takes longer than the
stated bound.
Clock
Process
Process’s local clock exceeds the bounds on its
rate of drift from real time.
 Real Time Operating System
Provides timing guarantee
 Multimedia

Failure model - remedies
 Masking failures:
 A knowledge of the failure characteristic of a component can enable
us to develop a reliable service which use such components which
can fail.
 Converting failure, retransmit message, replication, restoring
information
 Reliability of one-to-one communication:
 Correct message delivery in presence of failure
 Validity: Any message in the outgoing message buffer is
eventually delivered to the incoming message buffer.
 Integrity: The message received is identical to one sent, and
no messages are delivered twice.
Security model - basics
 The security of a distributed system:
 securing the processes and the channels
 protecting the objects against unauthorized access.
 Protecting objects.
Ac cess right s
inv oc ation
Client
result
Principal (user)
Netw ork
Server
Principal (s erv er)
•Access rights:
• Who is allowed to perform operation
•Principal:
• Authority associated with each invocation and each result – The
behalf on which it is issued
Object
Security model – Securing processes
 Securing processes and their interactions.
 Processes interact by sending messages
 Servers and Peers expose their interfaces
Security model – enemies and threats
 The enemy
 capable of sending any message to any process and reading or
copying any message between a pair of processes.
 Threats to processes.
generate a message with a forged source IP address
 Servers.
 Clients.
 Threats to communication channels.
copy, alter or inject messages as they travel across the network


Privacy
Integrity
Security model - the enemy
Copy ofm
The enemy
Processp
m’
m
Processq
Communication channel
Security model – defeating security threats
 Shared secret
 Private information of two users
 Encryption
 Process of scrambling messages to hide the contents
 Cryptography
 The science of keeping messages secure
 based on encryption algorithms that use secret keys
 Authentication.
 include in a message an encrypted portion to guarantee its
authenticity
Security model - Secure channels
 Secure channels.
 Encryption and authentication are used to build secure
channels as service layers on top of the exiting
communication services
 Characteristics
 Identity of the processes
 Privacy and integrity
 Physical or logical time
PrincipalB
PrincipalA
Processp
Secure channel
Processq
Security model – Other possible threats
 Denial of service
 attack by making excessive and pointless invocations
resulting in overloading of physical resource
 Mobile code
 Can play Torjan Horse role
 e.g. e-mail attachment, java applets
Summary
 Models in general.
 Architectural models:
 Fundamental models:
 Interaction.
 Failure.
 Security.