Distributed System

Models

Lecture Objectives
To

provide models for helping to

perceive different distributed system
designs
To understand the characteristics of
the most common architectural models
of distributed systems
To know some of the factors that
produce variety to these models

Distributed System
Models

Architectural models
Architecture: structure of separately
specified components
Architectural models define what different
components exist and the relationships
between these components
E.g., protocol layers, client/server model,
peer-to-peer model

Distributed System
Models

Fundamental models
Formal description of system properties
common in all architectural models
Some of these properties in distributed
systems are:
There is no global time in a distributed
system.
All communication between processes
is achieved by means of messages.

Distributed System
Models
* Message communication in distributed
systems has the following properties:
Delay
Failure
Security attacks
proces s p

proces s q

send m

receive

Communic ation c hannel

Outgoing m ess age buff er

Inc oming mess age buff er

Distributed System
Models
* Message communication issues are
addressed by three models:
Interaction Model
It deals with performance and
with the difficulty of setting of
time limits in a distributed
system.

Distributed System
Models
Failure Model
It attempts to give a precise
specification of the faults that
can be exhibited by processes
and communication channels.
Security Model
It discusses possible threats to
processes and communication
channels.

Architectural Models

Functions of individual components is abstracted away

Architectural models consider instead the patterns for
communication and workload distribution
Distinction between client, server and peer processes
Assessment of workload
Failure impact analysis

Overall goal: structure should meet present and future

demands on

Reliability
Manageability
Adaptability
Cost-effectiveness

Layers

Basic idea to break up the complexity of

systems by designing them through layers
and services
layer: group of closely related and highly
coherent functionalities
layer n+1
service: functionality provided
to a superior layer
n-service

Examples of layered architectures

operating systems (kernel,
other services)
computer network protocol
architectures

layer n
n-1 -service
layer n-1

Layers
Applications, serv ic es

Middleware

Operating s y stem
Platf orm
Computer and network hardware

Layers: Platform
Platform:

Operating system and

hardware
Supplies system programming interface
Windows XP / Pentium processor
Solaris / SPARC processor

Layers: Middleware

Middleware: a layer of software whose

purpose is to mask heterogeneity and to
provide a convenient programming model for
programmers
Supplies application programming interface
Can also provide services
Naming
Security

Transactions
Persistent

storage
Event notification
And others

Layers: Middleware

Limitations
Why not adding all the functionality inside
communication system so application programmer
does not have to care about anything else?
The end-to-end argument [Reed, 1984]
Some

functions can only be correctly implemented with

the help of application level information
Therefore providing that questioned function as a feature
of the communication system is not possible
E.g., for the data communication system to be
extraordinarily reliable does not reduce the burden on
the application program to ensure reliability at
application level

End-to-End Argument
Reliable

file transfer between two

computers when errors happen rarely
File
Disk

Computer A
File transfer
application

Computer B
File transfer
application

Disk

Communication system
Two

different designs were compared

End-to-End Argument

First design relied on that every step in

communication system works correctly
Duplicate copies, timeout, retry, packet
checksums

Requires writing correct programs which is

hard to accomplish and doing everything
twice appear uneconomical
And still, the design wont work correctly for
example if either of the file transfer
application fails to read or write data to disk

Application level also needs error correction

mechanisms

End-to-End Argument

Second design used end-to-end check and

retry on application level
File checksum which is checked after file transfer
If something goes wrong file transfer is retried

This design works correctly and without a

need for communication system to provide
any guarantees on reliable data transmission
From the point of view of file correctness reliability
mechanisms at lower levels become useless
But as a performance enhancement to avoid
transferring file multiple times some form of error
correction at lower levels may be useful

System Architectures
Client-server

model
Multiple servers model
Proxy server model
Peer-to-peer model

System Architectures:
Client-Server Model
The

Client

most widely used

inv ocation
res ult

inv ocation

Serv er

Serv er

res ult

Client
Key :
Proc es s:

Computer:

System Architectures:
Client-Server Model
Client: Process wishing to access data, use
resources or perform operations on a different
computer
Server: Process managing data and all other
shared resources amongst servers and clients,
allows clients an access to resource and
performs computation
Interaction: invocation / result message pairs
Example
http

server: client (browser) requests page, server

delivers page

System Architectures:
Client-Server Model

Multi-tier architectures (2-tier, 3tier) are special cases of clientserver model where multiple tiers
increase the scalability of the
server

Client-Server Model

(Coverting A Database App.)

Client-Server Model

(Coverting A Database App.)

Different Client/Server models are

obtained by locating different
components and combinations of the
application on the client and server(s).
In General:
- presentation logic stays on the client
- DBMS and database move to the
server.

Client-Server Model

(Coverting A Database App.)

- parts of the business/application and
database logic can be used by
several clients are placed on the
server.

Client-Server Model

(Coverting A Database App.)

The 2-Tier Model

Client-Server Model

(Coverting A Database App.)

The

2-Tier Model

Client-Server Model

(Coverting A Database App.)

Three

ways of distributing the business

logic (i.e. the program code):
- locate it entirely on client (fat client)
- locate it entirely on server (fat server)
- split it between client and server

Client-Server Model

(Coverting A Database App.)

The

3-Tier Model

System Architectures:
Multiple Servers Model
Serv ic e

Serv er
Client

Serv er

Client
Serv er

System Architectures:
Multiple Servers Model

Services may be provided by multiple servers

Partitioned or replicated service-related objects
Replication provides
Increased performance, availability and fault-tolerance

But requires replica coordination / consistency

preservation
E.g. high available web servers (portals, download
centers), information services
Servers maintain either replicated or distributed
database

System Architectures:
Proxy Server Model
Web
serv er

Client
Prox y
serv er

Client

Web
serv er

System Architectures:
Proxy Server Model

Cache: a close store of recently used data

Considerably increases performance in many
applications
But requires cache coherence protocols

Proxy server: a shared cache of resources

Renders replication/distribution transparent
Most commonly used for web access

System Architectures:
Proxy Server Model
Frequently

used in search-engines

System Architectures:
Peer-to-Peer Model
Application

Application

Coordination
code

Coordination
code

Application
Coordination
code

System Architectures:
Peer-to-Peer Model

Peer processes: processes have similar roles

No absolute distinction between client/server
May still assume client/server roles from time to
time
Peer is both a client and a server

Reduces inter-process communication delay

for local object access
Increased fault-tolerance and scalability
Coordination difficult
E.g. distributed search, routing, distributed
computing, news servers

Variations on the
Client-Server Model
Variations

inside the client-server

model come from the following factors:
communication can be initiated by server
the use of mobile code and mobile agents
lightweight clients based on users need
for low-cost computers and easy
management

Variations on the
Client-Server Model
Server

push model

Server initiates dialogue

Pushes information to client
Client needs application that listens for
server pushes
E.g. Wireless Application Protocol push
messages

Variations on the
Client-Server Model

Mobile code: Code that is sent to a client

process to carry out a specific task
a) client reques t results in the downloading of applet code

Client
Applet code

Web
serv er

b) client interacts with the applet

Client

Applet

Web
serv er

Variations on the
Client-Server Model

Mobile agents
Executing program (code + data) that migrates
between processes in a network
Carries

out an autonomous task usually on some other

process behalf
Has internal knowledge, beliefs and goals

Advantage: local access everywhere

Savings

in communication costs

Potential security threat

Limited

applicability

E.g., information collection from multiple sources,

worm programs (e-mail)

Variations on the
Client-Server Model
Network computer
or PC
Thin
Client

Compute server
network

Application
Process

Variations on the
Client-Server Model

Network computer
All files stored remotely
Minimum of local software and hardware
Any local disk used mainly as a cache

Thin client
Does not even run its own applications
Executes windows-based user interface on a local
computer
Programs are run by a powerful computing server
Citrix WinFrame thin client process for Windows,
X11 server on Unix systems

Summary
Architectural

models

Service layers
End-to-End argument
Client/server model
Multiple servers model
Proxy server model
Peer-to-peer model
Variations