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 lectureTo 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 modelsArchitectural models:?Fundamental models:

Formal description of system properties common in all architectural models

Interaction, failure, security

Fundamental modelsInteraction 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

channelssecure channels…

Interaction model - basicsInteractionMultiple server processes may cooperate to

provide service eg.DNSA set of peer processes may cooperate to achieve

common goal eg. Voice conferencingCommunication & 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 factorsPerformance of communication channels:

Latency. Delay between sending of a message by one process and

its receipt by another. Transmission time

Time taken to for the first of the string of bits transmitted through a network to reach its destination.

Delay network access time Increase significantly with increase in network load.

Operating system communication services time In sending and receiving messages. Varies with load

on OSBandwidth.

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 serviceDifferent time values for processes at different

systemsDrift 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. asynchronousSynchronous 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. asynchronousAsynchronous distributed systems – no bounds on:

Process execution speed.Message transmission delays.Clock drift rates.

Web is asynchronous systemActual distributed systems are very often

asynchronousSharing processorsSharing network

Interaction model – event orderingsend

receive

send

receive

m1 m2

2

1

3

4X

Y

Z

Physical time

Am3

receive receive

send

receive receive receivet1 t2 t3

receive

receive

m2

m1

Lamport Logical Clock for time Lamport Logical Clock for time stampingstamping

Failure ModelsFailure

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 - TypesOmission 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 checksumprocess p process q

Communication channel

send

Outgoing message buffer Incoming message buffer

receivem

Failure model – Arbitrary failureArbitrary 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/sArbitrary 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 failuresClass of failure Affects Description

Fail-stop

Process Process halts and remains halted. Other processes may

detect this state.

Crash

Process Process halts and remains halted. Other processes maynot be able to detect this state.

Omission Channel A message inserted in an outgoing message buffer neverarrives at the other end’s incoming message buffer.

Send-omission Process A process completes a send, but the message is not putin its outgoing message buffer.

Receive-omissionProcess A message is put in a process’s incoming messagebuffer, but that process does not receive it.

Arbitrary(Byzantine)

Process orchannel

Process/channel exhibits arbitrary behaviour: it maysend/transmit arbitrary messages at arbitrary times,commit omissions; a process may stop or take anincorrect step.

Failure model - timing failuresApplicable in synchronous distributed systems.Time limits

Process execution timeMessage delivery timeClock drift rate

Class Affects Description

Performance Process Process exceeds the bounds on the intervalbetween two steps.

Performance Channel A message’s transmission takes longer than thestated bound.

Clock Process Process’s local clock exceeds the bounds on itsrate of drift from real time.

Real Time Operating System Provides timing guarantee

Multimedia

Failure model - remediesMasking 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:Validity: Any message in the outgoing message buffer is eventually delivered to the incoming message buffer.

Integrity:Integrity: The message received is identical to one sent, and no messages are delivered twice.

Security model - basicsThe security of a distributed system:

securing the processes and the channels protecting the objects against unauthorized access.

Protecting objects.

•Access rights:Access rights:• Who is allowed to perform operation

•Principal: Principal: • Authority associated with each invocation and each result – The

behalf on which it is issued

Network

invocation

resultClient

Server

Principal (user) Principal (server)

ObjectAccess rights

Security model – Securing processes Securing processes and their interactions.

Processes interact by sending messagesServers and Peers expose their interfaces

Security model – enemies and threatsThe 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

networkPrivacy Integrity

Security model - the enemy

Communication channel

Copy of m

Process p Process qm

The enemym’

Security model – defeating security threats

Shared secretPrivate information of two users

EncryptionProcess of scrambling messages to hide the

contentsCryptography

The science of keeping messages securebased on encryption algorithms that use secret keys

Authentication.include in a message an encrypted portion to

guarantee its authenticity

Security model - Secure channelsSecure channels.

Encryption and authentication are used to build secure channels as service layers on top of the exiting communication services

CharacteristicsIdentity of the processesPrivacy and integrity Physical or logical time

Principal A

Secure channelProcess p Process q

Principal B

Security model – Other possible threats

Denial of serviceattack by making excessive and pointless

invocations resulting in overloading of physical resource

Mobile codeCan play Torjan Horse rolee.g. e-mail attachment, java applets

SummaryModels in general.

Architectural models:

Fundamental models:Interaction.Failure.Security.