DSchap-02.ppt

DISTRIBUTED SYSTEM
MODELS
Ezeji IN

Chapter Outline
 Overview of distributed system models
 Physical Models
 Architectural Models
 Architectural Patterns
 Middleware Solutions
 Fundamental models

Overview of distributed System Models
• Distributed system design can effectively be communicated/
described in 3 ways:
• Physical Models
• Capture the hardware composition of a system and their
interconnecting networks
• Architectural Models
• Capture the computational elements and communication tasks
performed by the elements
• Fundamental Models
• Takes an abstract perspective in order to examine individual
aspects of a distributed system.

Physical Models
• Physical models of distributed systems can best be understood from the evolution
distributed systems
• Baseline physical model
• This defines the minimal physical models as an extensible set of computer
nodes interconnected by computer networks
• Three generation of distributed system can be identified from this baseline
model
• Early distributed systems
• emerged in the 1970s/80s
• 10s of nodes are connected in LAN sharing a small range of services
such as printers, file servers, email, etc.
• Internet scale distributed systems
• Emerged in the 1990s
• An extensible sets nodes interconnected by a network of networks
• Contemporary distributed systems

Contemporary distributed systems
• These has emerged as a result of the 3 major trends in
distributed system we discussed before:
1. Emergence of mobile computing
2. Emergence of ubiquitous computing
3. Emergence of cloud computing
• These systems deploy an increasingly varied set of
networking technologies and offer a wide variety of
applications and services

6
Generations of distributed systems

Architectural models
• The architecture of a system is its structure in terms of
separately specified components and their relationships
• To lay a foundation to understand the different architectural
models used in distributed systems the following is to be
discussed first:
• Core underlying architectural elements
• Architectural patterns
• Middleware platforms

Architectural elements
• To understand the fundamental building blocks of a
distributed system, it is important to consider four key
questions:
1. What are the entities that are communicating in the distributed system
2. How do they communicate/ communication paradigm used
3. What roles and responsibilities the entities have
4. How are they mapped on to the physical distributed infrastructure

Communicating Entities
1. Objects
• Computation consists of a number of interacting objects representing natural units of
decomposition for the problem domain
• Objects are accesses via interfaces with an appropriate interface definition language (IDL).
2. Components
• Components like objects they offer problem oriented abstractions for building distributed
systems
• Components make all dependencies between objects explicit and provides a set of related objects
as a single entity
3. Web Services
• Closes related with objects and components
• They are different from objects and components in the sense they are intrinsically integrated in
the web.
• A Web service is defined as
.. software application identified by a URI, whose interfaces and bindings
are capable of being defined, describe and discovered as XML artifacts

Communication paradigms
• We consider 3 types of communication paradigms
1. Interprocess communication
• Low level support for communication b2n processes in DSs
• This involves message passing primitives and access to |API offered by Internet
Protocols (socket programming)
2. Remote invocation
• Two-way exchange b2n communicating entities in a DS and resulting in the
calling of remote operation/method
• It is currently the most common communication paradigm
• Examples include: Request-Reply protocols, Remote Procedure Call (RPC), and
Remote Method Invocation (RMI)
3. Indirect communication
• Communication is done through a third-part entity
• Senders do not need to know who they are sending to (space uncoupling)
• Senders and receivers' do not need to exist at the same time (time uncoupling)
• Key techniques include: group communication, publish/subscribe systems,
Message queues, Tuples spaces, and Distributed shared memory
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

11
Communicating entities and
communication paradigms

Roles and Responsibilities
• When entities are interacting they do take different roles
• These roles can then be used to describe a distributed
system
• We discuss two architectural styles that take this view;
• client-server and,
• Peer-to-Peer architectures.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Clients invoke individual servers
Serv er
Client
Client
inv ocation
result
Serv er
inv ocation
result
Process:
Key:
Computer:

A Peer-to-peer architecture

An example P2P system
The principal working of BitTorrent [Pouwelse et al. (2004)].

Placement
• Deals with how the object/components/web services are
mapped on to the underlying physical distributed
infrastructure
• Placement has a bearing on the properties of a DS, which
include: performance, availability, reliability, security, etc
• Placement design strategies
• Mapping services to multiple servers
• Caching
• Mobile code
• Mobile agents

Mapping services to multiple servers
• Services may be implemented as several server processes in
separate host computers interacting as necessary to provide
a service to client processes
• There are options of placing the entities:
1. Entities on which the service is based on may be partitioned on to separate
machines
2. Entities may be replicated on several host
Serv er
Serv er
Serv er
Serv ic e
Client
Client

Caching
• A cache is a store of recently used data objects that is closer
to one client or a particular set of clients than the objects
them selves
Client
Proxy
Web
server
Web
server
server
Client

Mobile code and Mobile Agents
• Applets
• The user running a browser selects a link to an applet whose code is stored in
a web server and the code is downloaded to the browser and runs there
• Mobile agents
• A mobile agent is a running program that travels from one computer to
another in a network carrying out tasks on someone’s behalf
• Both applets and agents are potential security threats
a) client request results in the downloading of applet code
Web
server
Client
Web
server
Applet
Applet code
Client
b) client interacts with the applet

Architectural patterns
• Architectural patterns build on the more primitive architectural
elements (objects, components, web services) and provide
recurring structures that have been shown to work well in
certain circumstances
• We are going to look at the following patterns
• Layering
• Tiered architecture
• Thin clients
• Proxy pattern
• Brokerage pattern
• Reflection

Layering
• A complex system is partitioned into a number of layers, with a given layer
making use of the services offered by the layer below it.
• Platform
• A platform for DSs and applications consists of the lowest level hardware and
software layers. E.g intel x86/windows, x86/linux, etc
• Middleware
• A layer of software, whose purpose is to mask heterogeneity and to provide a
convenient programming model to application programmers
Applications, serv ic es
Computer and network hardware
Platf orm
Operating s y stem
Middleware

Tiered Architecture
• Tiered architectures are complementary to layering
• Whereas layering deals with vertical organization of services,
tiering is a technique to organize functionality in a given layer
and place this functionality into appropriate servers and onto
physical nodes.
• Most application can be functionally decomposed into the
following components
• Presentation logic
• Application logic
• Data logic
• Tiering deals with how this components can be realized in
say a client-server technology.
•

23 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Two-tier and three-tier architectures

Alternative 2-tiered client-server
Architectures

Thin Clients
• A thin client is a software layer that supports a window-based
user interface that is local to the user while executing
application programs on a remote computer
• The advantage of using thin-clients is potentially simple local
devices can be significantly enhanced with a lot of networked
applications
Thin
Client
Application
Process
Network computer or PC
Compute server
network

Other Commonly occurring patterns
• The proxy pattern
• It is designed to support location transparency in distributed systems in RPC
and RMI
• The proxy offers exactly the same interface as the remote object.
• The brokerage Pattern
• The brokerage pattern is an architectural pattern for supporting
interoperability in potentially complex distributed infrastructures
• The pattern consists of a trio; the service requestor, service provider and the
brokerage
• Reflection pattern
• It is meant to support introspection and intercession
• Introspection: is the dynamic discovery of properties of the system
• Intercession: is the ability to dynamically modify structure or behaviour
• Reflection has been widely used in the field of reflective middleware to
support configurable and reconfigurable middleware architecture

Proxy Pattern in RPC

28 Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
The brokerage architectural pattern

Middleware Solutions
• Middleware solution are based on the principles of
architectural models we have discussed.
• Middleware provides support for (some of):
– Naming, Location, Service discovery, Replication
– Protocol handling, Communication faults, QoS
– Synchronisation, Concurrency, Transactions, Storage
– Access control, Authentication
• The next slide discusses the major categories of middleware
and some examples of middleware systems.
• Limitations of middleware
• Some aspects of dependability of the system require support at
application level. It is infeasible to have a middle that can adapt to all
types of applications

Categories of middleware

Fundamental Models
• The different architectural models we have discussed share
some fundamental properties
• For instance; All of the models share design requirements for achieving
• Performance and reliability characteristics of processes and networks
• Security of shared resources in the system
• The purpose of fundamental models is:
• To make explicit all the relevant assumptions about the systems we are
modeling
• To make generalization concerning what is possible or impossible, given
those assumptions
• We are going to discuss fundamental models that examine 3
important aspects of distributed systems:
• Interaction,
• Failure, and
• security

Interaction Models
• Deals with how communication (information flow) and
coordination(synchronization and ordering of activities)
between processes are to be handled.
• The significant factors that affect interacting processes in
distributed systems are:
1. Communication performance. It is often a limiting characteristic
in DSs
2. The impossibility of maintaining a single global notion of time

Communication performance of Communication
Channels
• Communication over computer networks has the following performance
characteristics relating to latency, bandwidth, and jitter
• Latency: the delay between the start of the message’s transmission from one
process and the beginning of its receipt by another.
• Latency includes:
• Time taken for the first string of bits transmitted to reach the
destination
• The delay in accessing the network
• Time taken by the operating system communication services at both
ends
• Bandwidth: total amount of information that can be transmitted over a given
time.
• Jitter: is the variation in the time taken to deliver a series of messages
• Very important to consider for multimedia data

Computer Clocks and timing of events
• Each computer has its own internal clock.
• The time on different machine is hardly the same.
• This is because computer clocks drift from perfect
time and their drift rates differ.
• Two interaction models are defined on the basis of
time
• Synchronous Distributed Systems
• Asynchronous Distributed systems

Synchronous Distributed systems
• Has strong assumption of time
• A synchronous systems is a system with the following bounds
defined:
• The time to execute each step has known lower and upper bounds
• Each message transmitted over the channel is received within a known
bounded time
• Each process has a local clock whose drift rate from real time has a known
bound
• For any distributed system it is possible to suggest the
bounds for process execution time, message delay and drift
rates, but…
• It is difficult to arrive at realistic values and to provide
guarantees for them.

Asynchronous Distributed systems
• Makes no assumption about time.
• It is a systems that has no bounds on:
• Process execution speeds- each step may take an arbitrary long
time
• Message transmission delays – messages can be received after an
arbitrary long time
• Clock drift rates are arbitrary
• Problems on arbitrary time limits are solved by allowing the
communicating entities to do some other things while waiting
for responses.
• Asynchronous systems use the concept of event ordering to
establish a logical clock.

Event Ordering
send
receive
send
receive
m1 m2
2
1
3
4
X
Y
Z
Physical
tim e
A
m3
receive receive
send
receive receive receive
t1 t2 t3
receive
receive
m2
m1

Failure Models
• In DSs both processes and communication channels fail
• The failure model defines the ways in which failure may occur
in order to provide an understanding of the effects of failures
• The following categories of failure models have been
identified:
• Omission failures
• Arbitrary Failures
• Timing failures

Omission failures
• Omission failures refer to cases when a process or communication
channel fails to perform action that it is suppose to do.
• Omission can be classified into two groups:
• Process Omission Failures
• These occur when a process crashes. That’s is a process has halted and it will not
execute any further steps of its program ever.
• Other processes may detect crashes by the fact that the process repeatedly fails to
respond to invocation messages
• This detection method depends on the use of timeouts
• A process crash is called a fail-stop if other processes can detect certainly that it
has crashed.
• Communication Omission Failures
• A communication channel produces an omission failure if it does not transport a
message from the sender machine’s outgoing message buffer to the receiver
machine’s incoming message buffer.
• This is known as dropping messages
• There 3 types of comm. Omission failures: send omission failures, channel
omission failures and receive omission failures

Processes and channels
processp process q
Communication channel
send
Outgoing m essage buff er Incoming message buff er
receive
m

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-omissionProcess 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.

Arbitrary Failures
• An arbitrary failure of a process is one in which it arbitrarily
omits intended processing steps or takes unintended
processing steps
• E.g. A process may set a wrong value in response to an
invocation
• These cannot be detected by checking whether a process
responds to invocations
• Arbitrary failures for communication channels are rare
because software is able to recognize them. E.g. checksum
can detect corrupted messages

Timing failures
• Timing failures applicable to synchronous distributed systems
• In DSs time limits are set on process execution time,
message delivery time and clock drift rate.
• This results in the 3 types of failures in the table below.
• Any of these failures may result in responses not being
available to clients within a specified time interval
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 Models
• The security of a distributed system can be achieved by
securing the processes and the channels used for their
interactions and by protecting the objects that they
encapsulate.
• Protecting the Objects
• Protecting objects deals with granting access rights to the objects.
• Access rights specify who is allowed to what on the object
Network
inv ocation
result
Client
Serv er
Principal (user) Principal (server)
Object
Access rights

Securing Processes and their Interactions
• Processes interact by sending messages to each other.
• The messages are exposed to attach because networks and
communication service that they use are open.
• In order to understand possible threats to a DSs the concept of an enemy
is used
• An enemy is entity that is capable sending any message to any process
and reading and copying any message sent between a pair of processes
• Threats include; threats to processes and threats to
communication channels

Threats to Processes
• Lack of a reliable knowledge of a source of a message is a
threat to the correct functioning of both servers and clients
• Servers
• Servers can receive invocations from many different clients and it cannot
necessarily determine the identity of the principal behind the invocation
• If a server requires inclusion of the identity of the principal the enemy can
easily give a false identity
• Clients
• When a client receives a response from the server it an not tell whether the
response is from the intended server.

Threats to Communication Channels
• An enemy can copy, alter or inject messages as they travel
across the network and its interleaving gateways
• Such attacks presents a threat to the privacy and integrity of
information as it travels over the network and integrity of the
system itself
• Another form of attack is when a message s copied to be
replayed at a later time.
• Threats to communication channels are counteracted by the
use of a secure channels.

Secure Channels
• Techniques for securing channels are mainly based on
authentication and encryption
• shared secrets
• The client and the server have a shared secret only known to them.
• The client and the server processes identify themselves by proving that they
know the secret
• Cryptography
• Is the science of keeping messages secure by scrambling a message in such a
way as to hide its contents
• Modern cryptography is based on encryption algorithms that use secret keys.
• Authentication
• Authentication is the process of verifying that the entity is who it claims to be.
• Shared secret keys and cryptography are often used for authentication.

Properties of Secure channels
• Each processes knows reliably the identity of the principal on
whose behalf the other process is executing
• Ensures privacy and integrity of the data transmitted.
• Each message includes a physical or logical timestamp to
prevent messages from being replayed.

DSchap-02.ppt

Recommended

Recommended

More Related Content

Similar to DSchap-02.ppt

Similar to DSchap-02.ppt (20)

Recently uploaded

Recently uploaded (20)

DSchap-02.ppt