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
Middleware
To mask the heterogeneity &
to provide a convenient
Programming model
Operating system
Platform
Computer and network hardware
Ex. x86/Windows,
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 startup 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
result
Client
invocation
Server
Server
result
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
Server
Replicated data
partitioned in
multiple servers.
Client
Server
Client
Server
Web proxy server
Web
server
Client
Pr oxy
server
Client
Involves caching of data
improves availability and performance
Proxy servers may be used to access remote
web servers through a firewall
Web
server
A distributed application based on peer processes
Application
Application
Coordination
code
Coordination
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
results of a computation to
system users and with collecting
user inputs

Application processing layer
Concerned with providing
application specific functionality
e.g., in a banking system,
banking functions such as open
account, close account, etc.

Presentation layer
Data management layer
Concerned with managing the
system databases
Application processing
layer
Data management
layer
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
Applet code
Web
server
b) client interacts with the applet
Client
Applet
Web
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
X
receive
1
m
1
2
Y
receive
4
send
3
m
2
receive
Physical
time
receive
send
Z
receive
receive
From
m
A
t1
t2
3
m
1
receive receive
t3
m
2
receive
Subject
Failure model
 Types of failures
Omission failure
 process
 communication channel
Arbitrary failure
Timing failure
process q
process p
send m
Communication channel
Outgoing message buffer
receive
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-themiddle 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
Fail-stop
or Crash-stop
Affects
Process
Omission
Channel
Description
Process halts and remains halted. Other processes may
detect this state.
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
Process p
m’
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