Transcript Figure 15.1 A distributed multimedia system

Lecture 2: System Models
Haibin Zhu, PhD.
Assistant Professor
Department of Computer Science
Nipissing University
© 2003
1
Why have system models?
Make assumptions clear
Organize and classify different approaches
Make generalizations
2
Architectural model
Defines the way in which the components of
systems interact with one another and the way in
which they are mapped onto an underlying network
of computers.
Structure in terms of separately specified components.
Placement of components across a network of computers
Interrelationships between components
Division of responsibilities among components
3
Terminology
server
process that accepts requests from other process.
service
What provided by one or more servers
platform
hardware and underlying operating system
middleware
software layer that masks heterogeneity and provides a
programming model
4
Figure 2.1 Software and hardware service
layers in distributed systems
Applications, services
Middlew are
RPC, CORBA, DCOM, RMI
Operating s ys tem
Platform
Computer and netw ork hardw are
5
Client/Server
Server: A subsystem that provides a particular type
of service to a priori unknown clients.
Control functionally distributed among the various
servers in the system.
Control of individual resources is centralized in a
server(localized?)
Problems:
 Reliability/Availability
 Scalability
 Replication?
6
Figure 2.2 Clients invoke individual servers
Client
invocation
res ult
invocation
Server
Server
res ult
Client
Key:
Process :
Computer:
7
Figure 2.3 A service provided by multiple servers
Service
Server
Client
Server
Client
Server
8
Figure 2.4 Web proxy server
Web
server
Client
Proxy
server
Client
cache
Web
server
9
Peer processes
All of the processes play similar roles, interacting
cooperatively as peers to perform a distributed
activity or computation without any distinction
between clients and servers.
10
Figure 2.5 A distributed application based on
peer processes
Application
Application
Coordination
code
Coordination
code
Application
Coordination
code
11
Variations on the client-server model
Mobile code
Mobile agents
Network computers
Thin clients
12
Figure 2.6 Web applets
a) client request res ults in the dow nloading of applet c ode
Client
Applet code
Web
s erv er
b) client interac ts w ith the applet
Client
Applet
Web
s erv er
13
Mobile Agent
A running programming including both code and
data that travels from one computer to another in a
network carrying out a task on someone’s behalf,
such as collecting information, eventually returning
with the results.
It is a potential security threat to the resources in
computers that they visit.
14
Network Computers
It downloads its operating system and any
application software needed by the user from a
remote file server.
Its disk (if included) holds only a minimum of
software. The extra space is used as a cache
holding copies of software and data files that have
recently loaded from servers.
Low cost on hardware and management.
15
Figure 2.7 Thin clients and compute servers
•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.
•Low cost on hardware and management.
Compute server
Network computer or PC
Thin
Client
network
Application
Process
16
Design requirements for distributed architecture
Performance
Responsiveness & Throughput
QoS (Quality of Services)
Reliability, Security, Performance, & Adaptability
Caching and replication
Dependability
Correctness, security, & fault tolerance
17
Fundamental Models
 A model includes:
Main entities
Interactions
Individual and collective characteristics
 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?
18
Interaction models
Processes interact through message-passing to
solve a problem.
Interaction is influenced by:
Performance of the communication channels
Synchronization of the clocks
19
Communication performance:
Latency
The delay between the sending of a message by one
process and its receipt by another
Data, network, and OS
Bandwidth
The total amount of information that can be transmitted
over a (network) in a given time.
Jitter
Variation in time taken to deliver a series of messages.
20
Clocks and event ordering:
Messages are often time-stamped to indicate
ordering.
Each computer has at least one local clock.
Time-stamps are often based on local clock values.
Local clocks aren’t synchronized.
21
Synchronous & Asynchronous distributed
system:
Synchronous
Can bound:
Time for each processing step
Time to transmit each message
Clock drift for each process.
Asynchronous
No bounds on:
Time for each processing step
Time to transmit each message
Clock drift for each process.
22
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 sending each a message to the list with
subject Re: Meeting (m2 and m3 respectively)
Example: What are the possible orderings of
messages in the following scenario?
23
Figure 2.9 Real-time ordering of events
s end
X
receiv e
1
m1
2
Y
receiv e
4
s end
3
m2
receiv e
Phy sical
time
receiv e
s end
Z
receiv e
receiv e
m3
A
t1
t2
m1
m2
receiv e receiv e receiv e
t3
24
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
25
Failure models
CDK:
“…(define) the ways in which failure may occur in
order to provide and understanding of the effects of
failures.”
Omission failures - process or channel fails to do
something
Process and communication
Arbitrary failures - usually refer to sabotage
Not only do not good, but also do bad
Timing failures - required time bounds are exceeded
26
Figure 2.10 Processes and channels
process p
process q
send
m
receiv e
Communic ation c hannel
Outgoing mess age buffer
Incoming mes sage buffer
27
Figure 2.11 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.
28
Figure 2.12 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.
29
Reliable one-to-one 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:
Retransmission
Spurious message
30
Security model
Protect processes and channels from corruption.
Protect resources (encapsulated by objects) from
unauthorized access.
31
Figure 2.13 Objects and principals
Ac cess rights
Object
inv oc ation
Client
result
Principal (user)
Netw ork
Server
Principal (s erv er)
32
Figure 2.14 The enemy
•Threats to processes;
•Threats to communication channels and
•Denial of services
Copy of m
The enemy
Process p
m’
m
Process q
Communication channel
33
Figure 2.15 Secure channels
•Encryption and authorization are used to build secure channels as
a service layer on top of existing communication services.
•Both processes are the authorities of accessing rights.
Principal B
Principal A
Process p
Secure channel
Process q
34
Basic terminology
Cryptography - science of keeping information
secure
Encryption - scrambling a message to hide its
contents
Authentication - method for assuring the true identity
of an entity
35
Summary
Architectural Model
Software layers
System architectures
Client/server
Proxy server
Peer server
Mobile code and mobile agent
Network computers and thin clients
Spontaneous networking
Fundamental models
Interaction model
Failure model
Security model
36