C-System Models Presentation files .ppt

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
Computer and network hardware
Platform
Operating system
Middleware
Ex. x86/Windows,
SPARC/Solaris,
PowerPC/MacOS,
x86/Linux
To mask the heterogeneity &
to provide a convenient
Programming model

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
Server
Client
Client
invocation
result
Server
invocation
result
Process:
Key:
Computer:
• Servers may in turn be clients
• Web servers may be clients of File servers, DNS servers

A service provided by multiple servers
Server
Server
Server
Service
Client
Client
Replicated data
partitioned in
multiple servers.

Web proxy server
Client
Proxy
Web
server
Web
server
server
Client
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
Coordination
Application
code
Coordination
Application
code
Coordination
Application
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.
 Data management layer
Concerned with managing the
system databases
Presentation layer
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
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
Java applets
Push model: initiated by the server
Pull model: initiated by the client

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.

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

 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
Communication channel
send
Outgoing message buffer Incoming message buffer
receive
m

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

 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
send
receive
send
receive
m
1
m
2
2
1
3
4
X
Y
Z
Physical
time
A
m
3
receive receive
send
receive receive receive
t1 t2 t3
receive
receive
m
2
m
1
User A:
• X sends a message with the subject “Meeting”
• Y and Z reply with the subject “Re: Meeting”
From Subject

Failure model
 Types of failures
Omission failure
 process
 communication channel
Arbitrary failure
Timing failure
processp process q
send
Outgoing message buffer Incoming message buffer
receive
m

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
 Receive-omission: loss of messages between the incoming
message buffer and the receiving process (both inclusive)
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!
Failure Types

Omission and Arbitrary Failures
Class of failure Affects Description
Fail-stop
or Crash-stop
Process Process halts and remains halted. Other processes may
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 asend,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.

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
Copy ofm
Processp Processq
m
The enemy
m’
The enemy (intruder)
1. Threats to the processes
2. Threats to the servers
3. Threats to the 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

C-System Models Presentation files .ppt

More Related Content

Similar to C-System Models Presentation files .ppt

Recently uploaded

C-System Models Presentation files .ppt