System Models

Architectural model

 Structure of the system in terms of components

Goals:
 reliable, manageable, adaptable, cost-effective system design

 We will see:
What are the components
Placement of the components, and
Interrelationships between the components
 Component processes
Server process, client process, peer process
Software Layers in DS (Software Architecture)

 The term s/w architecture referred originally to the

structuring of s/w as layers or modules in a single
computer and more recently in terms of services
offered and requested between processes located in
the same or different computers.

 This process- and service-oriented view can be

expressed in terms of service layers
Software Layers in DS (Software Architecture)

Applications, services

To mask the heterogeneity &

Middleware to provide a convenient
Programming model

Operating system
Platform
Ex. x86/Windows,
Computer and network hardware SPARC/Solaris,
PowerPC/MacOS,
x86/Linux
Middleware Basics

 Representation
processes or objects interacting with each other to implement
communication and resource sharing
 Function
provides building blocks for developing SW components that can
interact in a DS
An Important goal is to hide the heterogeneity of the underlying
platforms from applications
 Examples
Remote method invocation, group communication, replication
Earliest middlewares: Sun RPC, ISIS group communication
OO middlewares: OMG’s CORBA, MS’s DCOM, Java RMI
Middleware basics (contd.)

 Services for application programs

CORBA: naming, security, transaction, persistent storage,
event notification
 Limitations of middlewares
Many dist. apps rely entirely on middleware services for
communication and data sharing. But some aspects of
dependability require support at the application level.
Saltzer, Reed and Clarke’s classic paper “End-to-end
Arguments in System Design” makes a valuable point
about the design of distributed systems.
 The paper appeared in ACM TOCS vol. 2 (9), 1984.
Middleware

 To paraphrase their statement: Some communication

related functions can be completely and reliably implemented
only with the knowledge and help of the application standing
at the end points of the communication system. Therefore,
providing that function as a feature of the communication
system itself is not always sensible.
 Their argument runs counter to the view that all
communication activities can be abstracted away
from the programming of applications by the
introduction of appropriate middleware layers.
Distributed systems Architectures

 Client-server architectures
Distributed services which are called on by clients.
Servers that provide services are treated differently
from clients that use services
Basic model
Variations
 Distributed object architectures
No distinction between clients and servers. Any object
on the system may provide and use services from
other objects
Objects and interfaces
The Client-Server Model

 A server is a program that provide a service.

It makes some resource available to other programs running
somewhere on the network.
The resource could be anything: a database, a file system, a
printer, a modem, a screen, or a scanner.
The server program runs on the machine which resource is
attached to, and waits passively until the services are required.
Servers are often started up at boot-time, via commands in a start-
up script and Servers usually spent most of their time asleep,
waiting for work.
 A client is a program that uses a resource.
It may be running on the machine to which the resource is
attached, or on a different machine.
A client actively makes a connection across the network to the
server it requires.
The Client-Server Model (cont.)

 The terms client and server are sometimes used to

refer to a machine.
We may point out a computer on our network which has
a large disk attached and say “That is our file server, and
these workstations here are its clients”.
We may refer to a machine with a printer attached as a
“print server”.

 The term client and server refer to the relationship

between individual programs, not to machines.
In general, machines cannot simply be labeled as clients
and servers.
The Client-Server Model (cont.)

 One machine might be a server for a piece of the file

system, but a client of a remote print server.
 Example, a program which is a server for a database
might itself contact a time server to obtain an accurate
timestamp to attach to a new record in the database.
 In UNIX world, the term daemon is sometimes used to
refer to a server.
It means that the server is “permanently available”, which
implies that it is started at boot-time.
Daemon usually provide a “system-related” service, such as:
rlogind, telnetd, ftpd, httpd, nfsd,… etc.
Client-server architectures

 The application is modelled as a set of services that

are provided by servers and a set of clients that use
these services
 Clients know of servers but servers need not know
of clients
Server name/IP address and Port number
 Clients and servers are logical processes
Can be in the same machine
 The mapping of processors to processes is not
necessarily 1 : 1
Client-Server architecture

Client invocation invocation Server

result result
Server

Client
Key:
Process: Computer:

• Servers may in turn be clients

• Web servers may be clients of File servers, DNS servers
A service provided by multiple servers

Service

Replicated data
Server

Client partitioned in
multiple servers.
Server

Client
Server
Web proxy server

Client Web
server
Proxy
server

Client Web
server

Involves caching of data

improves availability and performance
Proxy servers may be used to access remote
web servers through a firewall
A distributed application based on peer processes

Application Application

Coordination Coordination
code code

Application

Coordination
code • Code in the peer process maintains
consistency and synchronization
• No designated clients or servers
•All play similar roles interacting
cooperatively as peers.
Variations on the client-server model

 Several variations can be derived from the

consideration of the following factors:

 The use of mobile code and mobile agents

 User’s need for low-cost computers with limited h/w

resources that are simple to manage

 The requirement to add and remove mobile devices in a

convenient manner
Layered application architecture

 Presentation layer (UI)

Concerned with presenting the Presentation layer
results of a computation to
system users and with collecting
user inputs
 Application processing layer
Concerned with providing Application processing
application specific functionality layer
e.g., in a banking system,
banking functions such as open
account, close account, etc.
Data management
 Data management layer layer
Concerned with managing the
system databases
Fat client model

 More processing is delegated to the client as the

application processing is locally executed

 Most suitable for new Client-Server systems where

the capabilities of the client system are known in
advance

 More complex than a thin client model especially for

management. New versions of the application have
to be installed on all clients
Example of a Three-tiered System

 The general organization of an Internet search engine

into three different layers

1-28
Multi-tiered Architectures

 Alternative client-server organizations (a) – (e).

1-29
Other Variations of client-server model: Mobile Code

Java applets
Push model: initiated by the server
Pull model: initiated by the client
a) client request results in the downloading of applet code

Client Web
Applet code server

b) client interacts with the applet

Web
Client Applet server
Mobile Code

 It can give good interactive response since it does

not suffer from the delays or variability of b/w
associated with network communication.

 Potential security threat to the local resources ---

give applets limited access to local resources.
Mobile agent

 Mobile agents
A running program that travels from one machine to other in
a network carrying out task on someone’s behalf eventually
returning with the result.
 e.g. install and maintain s/w on the computers within an organization or
compare the prices of products from a number of vendors by visiting the site
of each vendor and performing a series of database operations.

A potential security threat

The environment receiving a mobile agent should decide on which of the

local resources it should be allowed to use, based on the identity of the
user on whose behalf the agent is acting
Interfaces and Objects

 Distributed processes can also be developed by using

objected oriented languages (C++/Java)
 Many objects can be encapsulated in server or peer
processes, and reference to them are passed to other
processes so that their methods can be accessed by
remote invocation. Adopted by ---
 CORBA
 Java RMI
 New services and new types of object can be
instantiated and immediately be made available for
invocation – dynamic.
Fundamental models

 A system model
defines
 the entities
 their interactions
 characteristics that affect their behavior

purposes
 explicitly states all relevant assumptions
 generalize what is possible or not based on the assumptions

We’ll study
 Interaction model
 Failure model
 Security model
Fundamental models

 Concerned with the properties that are common in

all of the architectural models.

 No global time in a DS – clocks on different

computers do not necessarily give the same time.
Fundamental models

 All communication between processes is achieved

by means of messages – message communication
over a network can be affected by delays, can suffer
from a variety of failures and is vulnerable to attacks.

 These issues are addressed by three models.

Interaction model, Failure model & Security model

 Interaction model deals with the performance

and with the difficulty of setting time limits in a
Distributed System.
Interaction model, Failure model & Security model

 Failure model attempts to give a precise

specification of the faults that can be exhibited
by a process and communication channels.

 It defines reliable communication and correct

processes.
Interaction model, Failure model & Security model

 Security models discusses the possible threats

to processes and communication channels.

 Introduces the concept of a secure channel,

which is secure against those threats.
Interaction model

 Issues related to the interactions between processes

What are the issues?

process p process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer
Interaction model

 Significant factors affecting interacting processes in

a distributed system

Communication performance is often a limiting

characteristics

It is impossible to maintain a single global notion of time

 Interaction model

 Performance of Communication channel

Latency: the delay between the sending of a message by one
process and its receipt by another is referred to as latency that
includes
 propagation delays – time taken for the first of a string of bits transmitted through a
network to reach its destination
 network delays – delay in accessing the network
 OS delays – time taken by the OS communication services at both the sending
and receiving processes
Bandwidth
 The capacity of the communication channel

Jitter
 Variation in time taken to deliver a series of messages.
 Relevant to multimedia data -- Audio-video
Interaction model

 Clocks and timing

Absence of global clock, clock drift rate
 Two important variants of the Interaction Model
 It is hard to set time limits on the time taken for processor
execution, message delivery or clock drift.
 Two opposing extreme positions provide a pair of simple models
 The first has a strong assumption of time and the
second makes no assumptions about time
Synchronous DS
Asynchronous DS
Synchronous and asynchronous DS

 Synchronous
Processing time (time to execute each step of a process)
has a known lower and upper bound
Msg. Transmission delay is within a known bound
Local clock drift rates are also within a known bound
Examples: Multiprocessor systems

 Asynchronous
Processing time doesn’t have any bound
Msg. Transmission delay doesn’t have any bound
Local clock drift rates don’t have any bound
Examples: Internet, wireless networks, datacenters, most real systems
Synchronous and asynchronous DS

 Synchronous
Possible to suggest likely upper & lower bounds but
difficult to arrive at a realistic values and to provide
guarantee for the chosen values
Possible to use timeouts
Unless the values of the bounds are guaranteed, any
design based on those will not be reliable
Modeling an algorithm as a synchronous system may be
useful for giving some idea of how it will behave in a real
distribute system
Synchronous and asynchronous DS

 Asynchronous
Many DS (e.g. Internet) are very useful w/o being able to
qualify as synchronous system
Actual DS are very often asynchronous
There are many design problems that cannot be solved for
an asynchronous system that can be solved when some
aspects of time are used.
Any solution that is valid for asynchronous DS is also valid
for synchronous DS
 Real-time ordering of events

User A:
• X sends a message with the subject “Meeting”
• Y and Z reply with the subject “Re: Meeting”
send receive receive
X
1 m 4
1
m
send 2
receive
Y 2 3 Physical
receive time

send
Z
receive receive
From Subject
m m m
3 1 2
A
receive receive receive
t1 t2 t3
Failure model

 Types of failures
Omission failure
 process
 communication channel

Arbitrary failure
Timing failure
process p process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer
Failure Types
Process omission failure
 Crash-stop (fail-stop) – a process halts and does not execute any
further operations
 Crash-recovery – a process halts, but then recovers (reboots) after
a while
Special case of crash-stop model (use a new identifier on
recovery)

We will focus on Crash-stop failures

They are easy to detect in synchronous systems
Not so easy in asynchronous systems
Failure Types
Communication omission failures
 Send-omission: loss of messages between the sending process
and the outgoing message buffer (both inclusive)
What might cause this?
 Channel omission: loss of message in the communication channel
What might cause this?
 Receive-omission: loss of messages between the incoming
message buffer and the receiving process (both inclusive)
What might cause this?
Failure Types
Arbitrary failures
 Arbitrary process failure: arbitrarily omits intended processing
steps or takes unintended processing steps.
 Arbitrary channel failures: messages may be corrupted,
duplicated, delivered out of order, incur extremely large delays;
or non-existent messages may be delivered.

 Above two are Byzantine failures, e.g., due to hackers, man-in-the-

middle attacks, viruses, worms, etc., and even bugs in the code
 A variety of Byzantine fault-tolerant protocols have been designed in
literature!
Omission and Arbitrary Failures

Class of failure Affects Description

Fail-stop Process Process halts and remains halted. Other processes may
or Crash-stop 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.
Masking & reliability

• Masking failures:
Some services can mask a failure, e.g., checksums
are used to mask corrupted messages – effectively
converting an arbitrary failure into an omission failure,
omission failures can be masked by retransmission

• Reliable communication is defined in terms of :

- Validity: a message eventually reaches the
destination
- Integrity: the message received is identical to the
message sent
Security model

 The security of a DS can be achieved by securing

the processes and the channels used for their
interactions and by protecting the objects that
they encapsulate against unauthorized access

 Access rights – specify who is allowed to perform the

operations of an object
 Principal – associated with each invocation and each
result the authority on which it is issued. A principal may
be a user or a process
Securing Processes and their Interactions

 Processes interact by sending messages

Due to the openness of the underlying networks and the
communication services, the messages are vulnerable to
attacks

 The Enemy
To model security threats we postulate an enemy or an
adversary who can pose security threats

 Threats assessment
is an important aspect of security model
Security threats

The enemy (intruder)

1. Threats to the processes
2. Threats to the servers
3. Threats to the communication channel

Copy of m

The enemy
m’
Process p m Process q
Communication channel
Secure channel

 Encryption and authentication are used to build secure

channels as a service layer on top of existing
communication services. Has the following props.
Each process knows reliably the identity of the principal on
whose behalf the other process is executing
Ensures the privacy and integrity of the data transmitted
across it
Each message includes a physical or logical timestamp to
prevent messages from being replayed or reordered
Other forms of threats:
1. Denial of service attacks
2. Threats associated with the mobile codes