System Models

Architectural Model
Fundamental Models
Introduction

• Some of the problems that the designers of

distributed systems face are:
 Widely varying modes of use: The component parts of
systems are subject to wide variations in workload.
 Wide range of system environments: A distributed system
must accommodate heterogeneous hardware, operating
systems and networks.
 Internal problems: Non-synchronized clocks, conflicting
updates, many modes of hardware and software failure.
 External threats: Attacks on data integrity and secrecy,
denial of service.

DC - UNIT 1 2
Introduction

• Systems should be designed to function correctly in

any circumstance. This gives rise to the problems of
common properties and design issues in the form of
descriptive models.
• Two types of models:
 Architectural model - client-server model and its variations,
peer processes
 Fundamental model - the interaction model, the failure
model, the security model

DC - UNIT 1 3
Architectural models

• The architecture of a system is the structure in terms

of separately specified components.
• Architecture models provide a high-level view of the
distribution of functionality between components and
the relationships between them to make system
reliable, manageable, adaptable and cost-effective.
• Architectural models determine the distribution of
data and computational tasks amongst the physical
nodes of the system and are helpful when evaluating
the performance, reliability, scalability and other
properties of distributed systems.

DC - UNIT 1 4
Building a Architectural Model

• It simplifies the functions of individual components of

a distributed system around the concepts of process
and objects. It can be achieved by classifying
processes as server processes, client processes
and peer processes (for cooperating and
communicating).
• It decides the placement of the components across
a network of computers.
• It decides the interrelationships between the
components.
• More dynamic systems can be built as variations on
the client-server model.
DC - UNIT 1 5
Software Layers (Layer Architecture)

• The software architecture referred as services.

• A server is a process that accepts requests from
other process.
• A distributed service can be provided by one or
more servers
• A platform is the lowest-level hardware and software
layer that provide services to the layers above.
 Intel x86/Windows, SPARC/SunOS, Intel x86/Solaris, Intel
x86/Linux, PowerPC/MacOS
• A middleware is a software layer that masks
heterogeneity and provides a programming model.
DC - UNIT 1 6
Figure 2.1
Software and hardware service layers in distributed systems

Applic ations, services

Middlew are

Operating sy stem

Platform

Computer and netw ork hardw are

DC - UNIT 1 7
Software Layers (Layer Architecture)

• Middleware (continued):
 It is represented by processes or objects that interact with
each other to implement communication and resource-
sharing support for distributed applications.
 It also provides essential support for distributed application
development and is likely to offer greater support in the
future.
 Examples – Remote Procedure Call (RPC), Object-oriented
middleware products and standards - Common Object
Request Broker Architecture (CORBA), JAVA Remote
Object Invocation (RMI), Distributed Component Object
Model (DCOM), Reference Model for Open Distributed
Processing (RM-ODP).
DC - UNIT 1 8
System Architectures (Process Placement)

• It has major implications for the performance,

reliability and security of systems.
• A client-server model (Fig. 2.2) is most important
and widely employed.
 Client invocation (request) and server result (reply)
 Servers may in turn be clients.
• Services provided by multiple servers (Fig. 2.3):
 Each web server managers its own set of resources.
 Users employ a browser to access a resource at any one
of the servers.
 Replication is used to increase performance and
availability and to improve fault tolerance.
DC - UNIT 1 9
Figure 2.2
Clients invoke individual servers

Client inv oc ation Server

inv oc ation

result result
Server

Client
Key:
Proc es s: Computer:

DC - UNIT 1 10
Figure 2.3
A service provided by multiple servers

Service

Server
Client

Server

Client
Server

DC - UNIT 1 11
System Architectures (Process Placement)

• Proxy servers and caches (Fig. 2.4):

 Cache is a store of recently use data objects that is closer
than the objects themselves.
 Web browsers maintain a cache of recently visited web
pages and other resources in the client's local file system.
• Peer processes (Fig. 2.5) are processes interacting
cooperatively as peers to perform a distributed
activity or computation without any distinction
between clients and servers.

DC - UNIT 1 12
Figure 2.4
Web proxy server

Client Web
s erv er
Prox y
s erv er

Client Web
s erv er

DC - UNIT 1 13
 SYSTEM MODE
System Architectures
 Peer-to-Peer model
 All of the processes play similar roles,
interacting cooperatively as peers to perform a
distributed activities or computations
 without any distinction between clients and
servers or the computers that they run on.

DC - UNIT 1 14
Figure 2.5
A distributed application based on peer processes

Applic ation Applic ation

Coordination Coordination
c ode c ode

Applic ation

Coordination
c ode

DC - UNIT 1 15
 SYSTEM MODE
System Architectures
Peer 2

Peer 1
Application

Application

Sharable Peer 3
objects
Application

Peer 4

Application

Peers 5 .... N

A distributed application based

on the peer-to-peer architecture
DC - UNIT 1 16
 SYSTEM MODE
Variants of Client Sever Model
 The problem of client-server model is placing a
service in a server at a single address that does not
scale well beyond the capacity of computer host and
bandwidth of network connections.

 To address this problem, several variations of client-

server model have been proposed.

 Some of these variations are discussed in the next

slide.

DC - UNIT 1 17
Variations on the client-server model

• Factors to consider on the client-server model:

 The use of mobile code and mobile agents.
 The need for low-cost computers (thin clients).
 The requirement to add and remove mobile devices in a
convenient manner.
• Mobile code – Code is downloaded from server
and runs locally.
• Mobile agents - A running program travels from one
computer to another in network.
• Network Computers - OS and application software
are downloaded from network and runs locally.

DC - UNIT 1 18
 SYSTEM MODE
Variants of Client Sever Model
Mobile code
 Applets are a well-known and widely used
example of mobile code.
 Applets downloaded to clients give good
interactive response
 Mobile codes such as Applets are a potential
security threat to the local resources in the
destination computer.

DC - UNIT 1 19
 SYSTEM MODE
Variants of Client Sever Model
 Browsers give applets limited access to local
resources.
 For example, by providing no access to local
user file system.
 E.g. a stockbroker might provide a customized
service to notify customers of changes in the
prices of shares;
 to use the service, each customer would have to
download a special applet that receives updates
from the broker’s server, display them to the user

DC - UNIT 1 20
 SYSTEM MODE
Variants of Client Sever Model
a) client request res ults in the dow nloading of applet c ode

Client Web
Applet code s erv er

b) client interac ts w ith the applet

Web
Client Applet s erv er

Web applets
DC - UNIT 1 21
 SYSTEM MODE
Variants of Client Sever Model
Mobile agents
 A running program (code and data) that travels
from one computer to another in a network
carrying out of a task, usually on behalf of
some other process.
 Examples of the tasks that can be done by
mobile agents are:
 To collecting information.
 To install and maintain software maintain on the
computers within an organization.
 To compare the prices of products from a number
of vendors.

DC - UNIT 1 22
 SYSTEM MODEL
Variants of Client Sever Model
Advantage:
- Reduce communication cost and time by replacing
remote invocation with local ones.

Disadvantages:
Limited applicability.
Security threat of the visited sites resources.

DC - UNIT 1 23
 SYSTEM MODE
Variants of Client Sever Model
Network computers
 It downloads its operating system and any
application software needed by the user from
a remote file server.

 Applications are run locally but the file are

managed by a remote file server.

 Network applications such as a Web browser

can also be run.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

DC - UNIT 1 24
 SYSTEM MODE
Variants of Client Sever Model
Thin clients
 A software layer that supports a window-based
user interface on a computer that is local to
the user while executing application programs
on a remote computer.

 Same low management and hardware costs

as the network computer scheme.

 Instead of downloading the code of

applications into the user’s computer, it runs
them on a compute server.

DC - UNIT 1 25
 SYSTEM MODE
Variants of Client Sever Model

 Compute server is a powerful computer that

has the capacity to run large numbers of
application simultaneously.

 The compute server will be a multiprocessor or

cluster computer running a multiprocessor
version of an operation system such as UNIX
or Windows.

DC - UNIT 1 26
Figure 2.7
Thin clients and compute servers

Compute server
Network computer or PC

Thin network Application

Client Process

DC - UNIT 1 27
 SYSTEM MODE
Variants of Client Sever Model
Thin client implementations
 Thin client systems are simple in concept and
their implementation is straightforward in some
environment.
 For example, most variants of UNIX include
the X-11 window system.

DC - UNIT 1 28
 Variants of Client Sever Model
The X-11 window system
 The X-11 window system is a process that
manages the display and interactive input
devices (keyboard, mouse) of the computer on
which it runs.
 X-11 provides an extensive library of
procedures (the X-11 protocol) for displaying
and modifying graphical objects in windows as
well as the creation and manipulation of the
windows themselves.
 The X-11 system is referred to as a window
server process.
DC - UNIT 1 29
 Variants of Client Sever Model
 The clients of X-11 server are the application
programs that the user is currently interacting
with.
 The client programs communicate with the
server by invoking operations in the X-11
protocol.
 These include operations to draw text and
graphical objects in windows.

DC - UNIT 1 30
Thin clients

Advantage:
Good interactive response since.
Does not suffer from the delays or variability of
bandwidth associated with network
communication.
Disadvantage:
Security threat to the local resources in the
destination computer.

DC - UNIT 1 31
 Variants of Client Sever Model
Mobile devices and spontaneous
interoperation
 Mobile devices are hardware computing
components that move between physical
locations and thus networks, carrying software
component with them.
 Connects both mobile & non mobile devices to
network
 Many of these devices are capable of wireless
networking ranges of hundreds of meters such
as WiFi (IEEE 802.11), or about 10 meters
such as Bluetooth.

DC - UNIT 1 32
 Variants of Client Sever Model

 Mobile devices include:

 Laptops
 Personal digital assistants (PDAs)
 Mobile phones
 Digital cameras
 Wearable computers such as smart watches

DC - UNIT 1 33
Mobile devices and Spontaneous networking

• Key Features of Spontaneous Networking:

 Easy connection to a local network
 Easy integration with local services
• Security problems from connectivity of mobile users:
 Limited connectivity
 Security and privacy

DC - UNIT 1 34
Spontaneous networking in a hotel

Music
service Alarm
gateway service
Internet

Hotel wireless
network
Discovery
service
Camera

TV/PC Guests
Laptop PDA
devices

DC - UNIT 1 35
Spontaneous networking in a hotel

Music service : can have speakers anywhere

/wirless headsets
Alarm service: wake up service
TV/PC : tv with set up box
-access to web via hotel’s Internet gateway
- web based interface to all hotel facilities

DC - UNIT 1 36
Features of Spontaneous Networking

• The purpose of a discovery service is to accept

and store details of services that are available on the
network and to respond to queries from clients.
• A discovery service offers two interfaces:
 A registration service accepts registration requests from
servers and records the details in the discovery service’s
database.
 A lookup service accepts queries concerning available
services and searches its database for registered services
that match the queries.

DC - UNIT 1 37
Features of Spontaneous Networking

DC - UNIT 1 38
Interface and Objects
• The set of functions available for invocation in a
process is specified by one or more interface
definitions.
• Each server process is seen as a single entity with a
fixed interface defining the functions that can be
invoked in it.
• Many objects can be in a server process,references
to them are passed to other processes
• Methods can be accessed by remote invocation

DC - UNIT 1 39
Design Issues

• Performance issues:
 limited processing and communication capacities of
computers and networks
 Responsiveness, Throughput, Balancing computational
loads
• Quality of service - Reliability, Security,
Performance, Adaptability
• Use of caching and replication - Web-caching
protocol
• Dependability issues - Correctness, Security, Fault
tolerance

DC - UNIT 1 40
Architectures Design Requirements
Performance Issues:
Considered under the following factors:
 Responsiveness:
• Fast and consistent response time is important for the users of
interactive applications.
• Response speed is determined by the load and performance of
the server and the network and the delay in all the involved
software components.
 Throughput:
• The rate at which work is done for all users in a distributed
system.
 Load balancing:
• Enable applications and service processes to proceed
concurrently without competing for the same resources.
• Exploit available processing resources.
DC - UNIT 1 41
Architectures Design Requirements
 Quality of Service:
Main system properties that affect the service quality are:
Reliability: related to failure fundamental model (discussed later).
Performance: ability to meet timeliness guarantees.
Security: related to security fundamental model (discussed later).
Adaptability: ability to meet changing resource availability and
system configurations.
 Dependability issues:
A requirement in most application domains.
Achieved by:
Fault tolerance: continuing to function in the presence of failures.
Security: locate sensitive data only in secure computers.
Correctness of distributed concurrent programs: research topic.
DC - UNIT 1 42
Fundamental models

• Fundamental models are concerned with a more

formal description of the properties that are common
in all the architectural models.

Purpose of model:
• To make explicit all assumptions about system
• Generalizations of what is possible /not possible

DC - UNIT 1 43
Fundamental models

• What should be captured in a model?

 Interaction: How do components interact and coordinate to
solve a problem?
 Failure: What are the potential failures and how do they
affect the results?
 Security: What are the system's vulnerabilities and how
should they be handled?

DC - UNIT 1 44
Interaction model

• Distributed systems are composed of many

processes, interacting in complex way:
 Multiple server processes may cooperate with one another
to provide a service. For example, Domain Name Service.
 A set of peer processes may cooperate with one another
to achieve a common goal. For example, a voice
conferencing system.
 Their behavior and state can be described by distributed
algorithm - steps to be taken by each processes, including
the transmission of messages between them.

DC - UNIT 1 45
Interaction models
• Processes interact through message passing to
solve a problem.
• Factors affect interacting processes:
 Performance of the communication channels
 Synchronization of the clocks
• Communication performance:
 Latency – delay between the start of a message’s
transmission from one process and the beginning of its
receipt by another
 Bandwidth – total amount of information transmitted in a
given time
 Jitter – variation in time taken to deliver a series of
messages.
DC - UNIT 1 46
Clocks and event ordering

• Messages are often timestamped to indicate

ordering.
• Each computer has at least one local clock.
• Timestamps are often based on local clock values.
• Local clocks aren't synchronized.
• The term clock drift rate refers to the relative amount
that a computer clock differs from a perfect
reference clock.

DC - UNIT 1 47
Clocks and event ordering

• Some approaches to correct the times on computer

clocks:
 Get time readings from GPS
 GPS can send timing messages to other computers in the
network.
• Two variants of the interaction model are defined:
 Synchronous distributed system – strong assumption of
time
 Asynchronous distributed system – no assumptions about
time

DC - UNIT 1 48
Synchronous Distributed System

• The bounds are defined:

 Bounded time for each processing step
 Bounded time to transmit each message
 Clock drift for each process in a known bound
• Modelling an algorithm as a synchronous system
may be useful for simulating the real system.
• Synchronous distributed system can be built based
on if there is sufficient processor cycles and network
capacity.

DC - UNIT 1 49
Asynchronous Distributed System

• No bounds on:
 Time for each processing step
 Time to transmit each message
 Clock drift for each process.
• This exactly models the Internet.
• Actual distributed systems are very often
asynchronous because of the need for processes to
share the processors and for communication
channels to share the network.
• Some design problems can be solved when some
time constraints are used. For example, multimedia.
DC - UNIT 1 50
Event ordering

• When does an event (sending or receiving a

message) from one process occur relative to an
event from another process?
• A mailing list contains users X, Y, Z and A:
 X sends an email to the list with subject Meeting: (m1)
 Y and Z reply by each sending a message to the list with
subject Re: Meeting (m 2 and m 3 respectively)
• Example: What are the possible orderings of
messages in the following scenario?

DC - UNIT 1 51
Figure 2.9
Real-time ordering of events

s end receiv e receiv e

X
1 m1 4
m2
s end
receiv e
2 3 Phy sical
Y
receiv e time

s end
Z
receiv e receiv e

m3 m1 m2
A
receiv e receiv e receiv e
t1 t2 t3

DC - UNIT 1 52
Logical time

• If the clocks are roughly synchronized, then these

timestamps will often be in the correct order. But
clocks cannot be synchronized perfectly across a
distributed system.
• Logical time: Provide proper ordering of events
without reference to physical clocks (Lamport,
1978).
• Example - In the email scenario:
 X sends m1 before Y sends m2
 Y sends m2 before X receives m2
 Y receives m1 before Y sends m2

DC - UNIT 1 53
Failure models

• Processes and communication channels may fail.

Failure models define the ways in which failure may
occur in order to provide and understanding of the
effects of failures.
• Failure types:
 Omission failures refer to cases when process or
channel fails to do something.
 Arbitrary failures or Byzantine failures usually refer to
sabotage.
 Timing failures are applicable in synchronous distributed
systems where required time bounds are exceeded
DC - UNIT 1 54
Figure 2.10
Processes and channels

proc es sp proc es s q

send m receiv e

Communic ation c hannel

Outgoing mes sage buffer Inc oming mes sage buffer

DC - UNIT 1 55
Failure models

• Omission failures
 Process omission failures: crash - halt
 Communication omission failures does not transport a
message (caused by lack of buffer space): send omission
failure, receive omission failure, channel omission failure
• Arbitrary failures (Fig 2.11)
 the worst failure
 It arbitrarily omits intended processing steps or takes
unintended processing steps can not be detected
• Timing failures (Fig 2.12) occur only in synchronous
distributed systems (limits on execution time).

DC - UNIT 1 56
Figure 2.11
Omission and 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 Process or Process/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.

DC - UNIT 1 57
Figure 2.12
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.

DC - UNIT 1 58
Failure Models

• Deal with failures:

 Masking failures:
o Masking failures can be done with the knowledge of the
failure characteristics.
o A service masks a failure, either by hiding it altogether
or by converting it into a more acceptable type of
failure.
o Masking can be done by replication.
 A reliable communication service can mask some of those
failures.

DC - UNIT 1 59
Reliable communication

• Validity – Any message in the outgoing message

buffer is eventually delivered to the incoming
message buffer
• Integrity - The received message is identical to the
sent message and is delivered exactly once.
• The threats to integrity come from two independent
sources:
 A protocol may accept a message twice.
 Malicious users may inject a fake message.
• How does a communication service provide validity
and integrity?
DC - UNIT 1 60
Security model

• The architectural model provides the basis for our

security model.
• The security of distributed systems can be achieved
by:
 Protect processes and channels from corruption.
 Protect resources (encapsulated by objects) from
unauthorized access.
• Processes encapsulate objects which may hold a
user's private data. To support this, access rights
are used for specifying the allowable operations on
an object.

DC - UNIT 1 61
Security model

• A principal is an authority associated with each

invocation or each result.
• The server is responsible for verifying the identity of
the principal behind each invocation and checking
their rights.
• It is required to protect processes and their
interactions from attack.
• An enemy is capable of sending any message to
any process and reading or copying any message
between a pair of processes, as shown in Fig. 2.14.
DC - UNIT 1 62
Figure 2.13
Objects and principals

Ac cess rights Object

inv oc ation

Client
result Server

Principal (user) Netw ork Principal (s erv er)

DC - UNIT 1 63
Figure 2.14
The enemy

Copy of m

The enemy
m’
Process p m Process q
Communication channel

DC - UNIT 1 64
Threats

• Threats could do to processes or communication

channels.
• Threats to processes include server attack and client
one.
• An enemy can copy, alter or inject messages as they
travel across the network.
• Defeating security threats by use of secure channel:
 Cryptography and shared secrets (encryption/
decryption) - Cryptography is based on encryption
algorithms that use secret keys.
 Authentication - Message includes an encrypted portion.

DC - UNIT 1 65
Secure Channel

• A secure channel has the following properties:

 Each of the processes knows reliably the identity of the
principal on whose behalf the other process is executing.
 A secure channel ensures the privacy and integrity
(protection against tampering) of the data transmitted
across it.
 Each message includes a physical or logical time stamp to
prevent messages from being replayed or reordered.
• Virtual Private Network (VPN) and Transport
Layer Security (TLS), the successor of Secure
Sockets Layer (SSL) are two instances of secure
channels.
DC - UNIT 1 66
Figure 2.15
Secure channels

Principal A Principal B

Process p Secure channel Process q

DC - UNIT 1 67
Other Threats

• Denial of service – Making excessive and pointless

invocations on services or message transmissions in
a network result in overloading of physical
resources.
• Mobile code – For example, virus, worms, or Trojan
horse.
• The uses of security models need to be balanced
against threats.

DC - UNIT 1 68
Summary

• Middleware (CORBA and Java RMI) provides

essential support for distributed application
development and is likely to offer greater support in
the future.
• The client-server architecture is predominant, but
there are many variations, some of which differ
markedly from the client-server model.
• Three fundamental models do not encompass all of
the design issues for distributed systems.

DC - UNIT 1 69
Summary

• The classification of processes and communication

channels' failures is useful for the analysis of failures
of protocols. Timing failures occur only in
synchronous systems. Most failures in distributed
systems are benign (e.g. omission but not Byzantine
failures). A service may mask the failures of the
components from which it is constructed.
• The security model discusses the possible threats to
processes and communication channels. It
introduces the concept of a secure channel, which is
secure against those threats.

DC - UNIT 1 70