Chapter 2: System Models

Objectives To provide students with

conceptual models to support their study of distributed systems.

To motivate the study of many of the design problems and solutions.

Introduction 2 types which are:

~ Architectural models~ Fundamental models

Provide a high-level view of the distribution of functionality between components and the relationships between them.

Models determine the distribution of data and computational tasks among the physical nodes of the system.

Helpful when evaluating the performance, reliability, scalability and other properties of distributed systems.

Architectural Models

Architectural models (cont.)

Architectural model consider: placement of the components

across a network of computers - define useful pattern for distribution data or workload

interrelationship between components – functional pattern of communication between them.

Architectural models (cont.)

Software Layers

What is “Software architecture”?

- structuring of software as layers or modules in a single computer

- services offered & requested between process located in same or different computer

Fig. 2.1: Software & hardware service layers in DS

Applications, services

Computer and network hardware

Platform

Operating system

Middleware

2 main types of architecture model:~ Client-server model~ Peer-to-peer model

Client-server model can be modified by:~ Partitioning of data or replication at

cooperating servers~ Caching of data by proxy servers & clients~ Use of mobile code & agents~ Requirement to add & remove mobile

devices in a convenient manner

Architectural models (cont.)

Fig. 2.2: Clients invoke individual servers

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

Peer-to-peer model ~ Process involved in task/activity play

similar roles~ interactively cooperating as peers

without any distinction between client and server process

~ exploit resources in a large number of participating computers for fulfillment of a given task

Architectural models (cont.)

Fig. 2.3: A distributed application based on peer processes

Application

Application

Application

Peer 1 Peer 2

Peer 3

Peers 5 .... N

Sharable objects

Application

Peer 4

Variation derived based on factor: ~ use multiple servers and caches to ↑

performance & resilience~ use mobile code & mobile agent~ user need for ↓ cost computers with

limited hardware resources that are simple to manage

~ requirement to add & remove mobile devices in a convenient manner

Architectural models (cont.)

Fig. 2.4: A service provided by multiple servers

Server

Server

Server

Service

Client

Client

Proxy servers & caches:Cache ~ Store of recent used data object that is closer

than object themselves. ~ When a new object is received at a computer,

cache store, replacing some object necessarily.

~ Caches may be allocated with each client @ they may be allocated at proxy server.

Proxy server ~ ↑ availability & performance of services by

reduced load of WAN and web servers~ May be used to access remote web servers

through a firewall

Architectural models (cont.)

Fig. 2.5: Web proxy server

Client

Proxy

Webserver

server

Web server

Client

Fig. 2.6: Web appletsa) Client request results in the downloading of applet code

Web server

ClientWeb serverApplet

Applet codeClient

b) Client interacts with the applet

Applet are well-known and widely used example of mobile code.

Fig. 2.7: Thin clients & compute servers

Thin

Client

Application

Process

Network computer or PCCompute server

network

Thin client

~ software layer that supports a window based user interface on a computer

~ local to the user while execution application programs on a remote computer.

Issues that addressed in the design of DS.

3 fundamental models:~ Interaction Model~ Failure Model~ Security Model

Fundamental Models

Interaction Model~ Synchronous DS by Hadzilacos &

Touge[1994] - time to execute each step of process has

known lower & 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 bounded time

Fundamental Models (cont.)

Interaction Model~ Asynchronous DS has no bounds on: - process execution speed: -> a process step may take only a

picoseconds and another a century.

- message transmission delays -> a message from process A to B

may be delivered in negligible time & another make take several years

- clock drift rate

Fundamental Models (cont.)

Interaction Model~ Event Ordering - Event (sending or receiving message)

at one process occurred before, after or concurrently with another event at another process

- Execution of a system can be in terms of events & ordering despite the lack of accurate clock

Fundamental Models (cont.)

Fig. 2.8: Real-time ordering of events

send

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

Failure Model~ Hadzilacos & Touge [1994] provide a

taxonomy distinguish between failure of process & communication channel:

- Omission failure - Arbitrary failure- Timing failure

Fundamental Models (cont.)

Fig.2.9: Processes and channels

process p process q

Communication channel

send

Outgoing message buffer

Incoming message buffer

receivem

Fig. 2.10: Omission & arbitrary failures

Class 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 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 a send, 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.

Fig. 2.11: Timing failures

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.

Security Model~ Securing the processes & the

channels used for their interaction ~ Protecting objects that they

encapsulated against unauthorized access

Fundamental Models (cont.)

Fig. 2.12: Objects & principals

Network

invocation

resultClient

Server

Principal (user) Principal (server)

ObjectAccess rights

Fig. 2.13: The enemy

Communication channel

Copy of m

Process p

Process q

m

The enemym’

Fig. 2.14: Secure channels

Principal A

Secure channelProcess p

Process q

Principal B