Transcript system model Lec2

NET 422
Dr: Naglaa Soliman
Chapter 2: System models
 Introduction
 Architectural model
 Fundamental model
Introduction
• In this chapter we bring out the common properties and design
issue for DS in the form of descriptive models.
• Each model is intended to provide an abstract, simplified but
consistent description of a relevant aspect of distributed system
design.
• This chapter provides an explanation of three important and
complementary ways in which the design of distributed systems
 Physical models
They capture the hardware composition of a system in terms of the computers
(and other devices, such as mobile phones) and their interconnecting networks.
 Architectural models
Describe a system in terms of the computational and communication tasks
performed by its computational elements.
 Fundamental models
Take an abstract perspective in order to examine individual aspects of a
distributed system. Three important aspects of distributed systems:
interaction models, failure models, security models,.
Problems that designers face:
 Widely varying modes of use
 Wide range of system environment
 Internal problems:
 Non-synchronized clocks
 Conflicting data updates
 Many modes of HW and SW failure involving the individual components
of a system
 External threats: Attacks and denial services
System models
Architectural model
Fundamental model
Layered structure
Interaction model
Main architectural models
Failure model
Variant of client-server model
Security model
features
Design requirement
Architectural model
Major concerns: to make the system:




Reliable
Manageable
Adaptable
Cost-effective
The architectural model of a distributed system simplifies and
abstracts the functions of the individual components of the
DS and then it considers:
 The replacement of the components across a network of
computers
 The interrelationships between the components
Architectural model
System simplification:
Classifying processes to identify the responsibilities which helps
us to assess their workloads and determine the impact of
failures in each process.
Processes classes:
 Server processes
 Client processes
 Peer processes
Architectural model
Dynamic systems:
 Moving code to reduce access delay and minimize
communication traffic
 Adding new computers and allowing them to discover the
services and offer their services to others
Architectural model
Software layers:
 Software architecture:
 Platform ( hardware + OS)
 Middleware
 Services:
 Remote method invocation
 Communication between a group of processes
 Notification of events ………..etc
 Examples:
 CORBA: Common Object Request Broker Architecture
 Java RMI : Java Remote Method Invocation
 Web services
 DCOM: distributed component object model
 The ISO/ITU-T : International Organization for Standardization /International
telecommunication union
 Limitation of middleware
Figure 2.1
Software and hardware service layers
in distributed systems
Applic ations, services
Middleware
Operating s ys tem
Platform
Computer and network hardware
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 2.2
Clients invoke individual servers
Client
invocation
result
invocation
Server
result
Server
Client
Key:
Proc ess :
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Computer:
Architectural model
System architecture
1. Client- server
 Web server is a client of a local file server that manages the files in which the
web pages are stored
 Web servers and most other internet services are clients of the DNS
services.
 Search engines
What are crawlers?
Programs run in the background at a search engine site using HTTP request to
access web servers throughout the internet
 Simple
 Scale poorly:
Q: The search engine is both a server and a client , explain.
Q:A typical search engine would normally include many concurrent threads of
execution, what do they do? and what do they need?
Architectural model
2.
Peer-to-peer
 All process in a task or activity play the same roles
 It enables hundreds of thousand computers to provide access to
data and other resources
 E.g :Napster application for sharing digital music files
 A large number of data object are shared
 Each computer holds only a small part of the application
database and storage
 This architecture is more complex
 Replication is provided to distribute the load and provide
resilience
Figure 2.3
A distributed application based on peer
processes
P ee r 2
P ee r 1
Applic a tion
Applic a tion
P ee r 3
Sha ra ble
obje c ts
Applic a tion
P ee r 4
Applic a tion
P ee rs 5 .... N
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Architectural model
3.
Variations
 The use of multiple servers and caches
 The use of mobile code and mobile agents
 Users need for low-cost computers with limited hardware
resources that are simple to manage
 The requirement to add and remove mobile devices in a
convenient manner
Figure 2.4
A service provided by multiple servers
Servic e
Server
Client
Server
Client
Server
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Architectural model
 Interfaces and objects
 Modula
 C++
 Java
Architectural model
Design requirement for distributed architectures
1. Performance issues
 Responsiveness
 Users require fast and consistent response
 The speed is affected by the load, performance and delays in all software
components involved
 To achieve a good response time, systems must be composed of relatively few
SW layers and the quantity of transferred data must be small
 Throughput
 The measure of performance
 Affected by processing speed and data transfer rate
 Balancing computational loads
 Applet
 Several computers
Architectural model
2.
Quality of service
 It is affected by
 Reliability
 Security
 Performance
 adaptability
Use of caching and replication
4. Dependability issue
3.
 Fault tolerance
 Redundancy
 Retransmission
 security
Fundamental model
The system model has to address the questions :
 What are the main entities in the system?
 How do they interact?
 What are the characteristics that affect their individual and
collective behavior?
The purpose of a model:
 To make explicit all the relevant assumptions about the system
 To make generalization concerning what is possible or
impossible, given those assumptions.
 General –purpose
 Guarantees
Fundamental model
1.
Interaction model
 Multiple server processes may cooperate with one another to provide a service
 A set of beer processes may cooperate with one another to achieve a common
goal
Distribution algorithm: the steps to be taken by each of the process of which the
system is composed
 Massages are transmitted to:
 Transfer information
 Coordinate activities
It is difficult to describe the rate because of the failure Interacting processes
perform all of the activity in a distributed system
Each process has its own private state
Interacting process is affected by:
 Communication performance
 Timing issue
Fundamental model
Performance of communication channels
 Latency: is the delay between the start of a message’s
transmission from one process and its receipt by another and it
includes:
 Transmission time through the network
 Time needed to reach the network which increases with the increase of
the network load
 The time taken by the operating system communication services
 The bandwidth of the computer network
 jitter
 Computer clock and timing events
Clock drift rate: the relative amount that a computer clock differs
from a perfect reference clock
Approach to correcting the times on computer clocks:
 Radio receivers to get time readings from the GPS
Fundamental model
Two variants of the interaction model
 Synchronous DS
 The time to execute each step of a process has known lower and upper
bounds
 Each message transmitted over a channel is received within a known
bounded time
 Each process has a local clock whose drift rate from real time has a known
bound
 Asynchronous DS
 No bounds on process execution
 No bounds on message transmission delay
 No bounds on clock drift rate
Fundamental model
Event ordering
 Knowing whether an event at one process occurred before,
after or concurrently with another event at another process.
 Logical time can be used to provide an ordering among the
events at process running in different computers in a distributed
system
 If the clocks on X’s,Y’s and Z’s computers could be
synchronized, each message could carry the time on local
computer’s clock
Figure 2.8
Real-time ordering of events
s end
X
receive
1
m1
2
Y
receive
4
s end
3
m2
receive
Physic al
ti me
receive
s end
Z
receive
receive
m3
A
t1
t2
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
m1
m2
receive receive receive
t3
Fundamental model
Failure model
2.
1.
Omission failures
 Process omission failure
 Communication omission failure
Caused by lack of buffer space
 Network transmission error
 Send-omission failure
 Receive-omission failure
 Channel omission failure

2.
Arbitrary failures
 The process may set wrong values in its data items
 The process my return a wrong value in response to an invocation
Figure 2.10
Omission and arbitrary failures
Class of failure
Fail-stop
Affects
Process
Description
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 2.9
Processes and channels
proc es s p
proc es s q
send m
receive
Communic ation c hannel
Outgoing mess age buffer
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Incoming mess age buffer
Fundamental model
3.
Timing failures
Class of Failure
Clock
Affects
Process
Performance
Process
Performance
Channel
Description
Process’s local clock exceeds the bounds on its
rate of drift from real time.
Process exceeds the bounds on the interval
between two steps.
A message’s transmission takes longer than the
stated bound.
Figure 2.11:Timing failures
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Fundamental model
 Masking failures
 Multiple servers
 Knowledge of the failure characteristics of component
 a service masks a failure by:
 Hiding it
 Converting it into a more acceptable type
 Reliability of one-to-one communication
 Reliable communication is defined in terms of validity and integrity as
follows:
 Validity: any message is delivered
 Integrity : received message = sent message with no duplication
Fundamental model
 The threats com from:
 Any protocol does not reject a message that arrives twice
 Malicious users
Fundamental model
3.
Security model
 The security of a DS can be achieved by securing the processes
and the channel used and by protecting the objects that they
encapsulate against unauthorized access.
 Protecting objects
 Using access rights
 Securing processes and their interactions
 The enemy
 Threats to processes
 Threats to communication channels
Figure 2.12
Objects and principals
Acc es s rights
invocation
Client
result
Princi pal (us er)
Network
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Server
Princi pal (s erver)
Objec t
Fundamental model
 Defeating security threats
1. Cryptography and shared secrets

Cryptography is the science of keeping messages secure

Encryption is the process of scrambling a message to hide its
contents.
2. Authentication

It is to include in a message an encrypted portion that contains
enough of the contents of the message to guarantee its authenticity,
for example:
o
a representation of the requesting principal’s identity
o The identity of the file
o The date and time of the request …….
3.
Secure channels
Secure channel has the following properties:
•
Each process knows the identity of the principal on whose behalf the
other process is executing
•
A secure channel ensures the privacy and integrity of the transmitted
data
•
Each message include a physical or logical time stamp
 Other possible threats from an enemy
 Denial of service
 Mobile code
 The uses of security models
Figure 2.13
The enemy
Copy ofm
The enemy
Processp
m’
m
Processq
Communication channel
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Figure 2.14
Secure channels
PrincipalB
PrincipalA
Processp
Secure channel
Instructor’s Guide for Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
Processq