0% found this document useful (0 votes)
23 views35 pages

3) System Models

Uploaded by

CodeWithIndia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views35 pages

3) System Models

Uploaded by

CodeWithIndia
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

System Models

Contents

• Introduction
• Physical models
• Architectural models
• Fundamental models
Introduction
Distributed system design can be explained through
three different models:
Physical models – models that capture the hardware
composition of a system in terms of computer and their
interconnecting networks

Architectural models – models that describe the system in


terms of the computational and communication tasks
performed by its computational elements

Fundamental models – models that describe an abstraction


of individual items in distributed systems. Three models;
interaction, failure, and security models
Physical models
• A physical model is a representation of the underlying
hardware elements of a distributed system that abstracts
away from specific details of the computer and
networking technologies employed.
• Basic physical models
• Model that shows hardware and software components
located at networked computers communicate and
coordinate their actions by passing message.
• There are three generations of distributed systems:
• Early distributed systems
• Internet-scale distributed systems
• Contemporary distributed systems
Generations of Distributed systems
Early distributed systems:
Such systems emerged in the late 1970s and early 1980s in
response to the emergence of local area networking technology,
usually Ethernet.
These systems typically consisted of between 10 and 100 nodes
interconnected by a local area network, with limited Internet
connectivity and supported a small range of services such as
shared local printers and file servers as well as email and file
transfer across the Internet.
Individual systems were largely homogeneous and openness was
not a primary concern.
Providing quality of service was still very much in its infancy and
was a focal point for much of the research around such early
systems
Generations of Distributed systems
Internet-scale distributed systems:
Larger-scale distributed systems started to emerge in the 1990s in
response to the dramatic growth of the Internet during this time (for
example, the Google search engine was first launched in 1996).
In such systems, an extensible set of nodes interconnected by a
network of networks (the Internet). Such systems exploit the
infrastructure offered by the Internet to become truly global.
The level of heterogeneity in such systems is significant in terms of
networks, computer architecture, operating systems, languages
employed and the development teams involved.
Additional services were employed to provide end-to-end quality of
service properties in such global systems.
Generations of Distributed systems
Contemporary distributed systems:
In the previous systems, nodes were typically desktop computers and
therefore relatively static (that is, remaining in one physical location for
extended periods), discrete (not embedded within other physical
entities) and autonomous (to a large extent independent of other
computers in terms of their physical infrastructure).
The emergence of mobile computing has led to physical models where
nodes such as laptops or smart phones may move from location to
location in a distributed system.
The emergence of ubiquitous computing has led to a move from
discrete nodes to architectures where computers are embedded in
everyday objects and in the surrounding environment (for example, in
washing machines or in smart homes more generally).
The emergence of cloud computing and, in particular, cluster
architectures has led to a move from autonomous nodes performing a
given role to pools of nodes that together provide a given service (for
example, a search service as offered by Google).
Physical models
Architectural models

• Architecture?
• The structure of a system specifying its components and their
interrelationships

• Why architecture?
• To ensure that the structure will meet the current and future
demands on it
• To provide a reliable, manageable, adaptable and cost-effective
system
Architectural models
• Architectural elements:
• How to understand the fundamental building blocks of a
distributed system?
 What are the entities that are communicating in the distributed system
(communicating entities)?
 How do they communicate, or, what communication paradigm is used
(communication paradigms)?
 What roles and responsibilities do they have in the overall architecture (roles
and responsibilities)?
 How do they mapped on to the physical distributed architecture (what is their
placement)?
Architectural models
• Communicating entities:
 Processes: From a system perspective, the entities that communicate in a
distributed system are typically processes, leading to the prevailing view of a
distributed system as processes coupled with appropriate inter-process
communication paradigms.
 Objects: Objects have been introduced to enable and encourage the use of object-
oriented approaches in distributed systems (including both object-oriented design
and object-oriented programming languages).
 Components: Components resemble objects in that they offer problem-oriented
abstractions for building distributed systems and are also accessed through
interfaces.
 Web services: Web services represent the third important paradigm for the
development of distributed systems. Web services are closely related to objects and
components, again taking an approach based on encapsulation of behaviour and
access through interfaces. Web services are intrinsically integrated into the World
Wide Web, using web standards to represent and discover services.
Architectural models
Communication paradigms
How entities communicate in a distributed system
 Inter-process communication – low-level process support. E.g.
message passing primitives, direct access to API, multicast
communication.
 Remote invocation – common communication paradigm in
distributed systems. Two-way exchange between communicating
entities, common techniques; RPC, RMI, request-reply protocols
 Indirect communication– E.g. group communication, publish-
subscribe systems, message queues, tuple spaces, distributed
shared memory
Architectural models
Architectural models
Roles and responsibilities

•In a distributed system processes including web services interact


with each other to perform a useful activity.

•In doing so, the processes take on given roles, and these roles are
fundamental in establishing the overall architecture to be adopted.

•Two architectural styles stemming from the role of individual


processes:

Client-server

Peer-to-peer
Client-Server model
• Most widely employed model in DS.
• Client processes interact with individual server processes in potentially separate host
computers in order to access the shared resources that they manage.
• Web servers and most other Internet services are clients of the DNS service, which
translates Internet domain names to network addresses.
• Another web-related example concerns search engines, which enable users to look up
summaries of information available on web pages at sites throughout the Internet.

Client invocation Server


invocation

result result
Server

Client
Key:
Process: Computer:

Clients invoke individual servers


Peer to peer
• In this architecture all of the
processes involved in a task or
activity play similar roles,
interacting cooperatively as
peers without any distinction
between client and server
processes or the computers
on which they run.
• In practical terms, all
participating processes run
the same program and offer
the same set of interfaces to Peer-to-peer architecture
each other.
Mapping of services to multiple servers:
• The servers may partition the set of objects on which the service is based and
distribute those objects between themselves, or they may maintain replicated
copies of them on several hosts

Service

Server
Client

Server

Client
Server

A service provided by multiple servers


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
themselves.
• When a new object is received from a server it is added to the
local cache store, replacing some existing objects if necessary.
• When an object is needed by a client process, the caching service
first checks the cache and supplies the object from there if an up-
to-date copy is available. If not, an up-to-date copy is fetched.
• Caches may be co-located with each client or they may be located
in a proxy server that can be shared by several clients.
• Web browsers maintain a cache of recently visited web pages and
other web resources in the client’s local file system, using a
special HTTP request to check with the original server that cached
pages are up-to-date before displaying.
Client Web
server
Proxy
server

Client Web
server

Web proxy server


Architectural models

Architectural patterns:
Layering –complex system is partitioned into a number of
layers. The top layer utilizes the services of the lower
layer.

Tiered architecture – complementary to layering,


organizes the functionality of the given layer and place it in
appropriate server (physical nodes).

Thin clients – software layer that supports window-based


user interface in remote computers. A thin client is a
computer that runs from resources stored on a central
server instead of a localized hard drive. 
Applications, services

Middleware

Operating system
Platform

Computer and network hardware

Software and hardware service layers in distributed systems


Two-tier and three-tier architectures
Compute server
Network computer or PC

Thin network Application


Client Process

Thin clients and compute servers


Fundamental models

• The models are presented based on the


fundamental properties , characteristics and the
failures and security risks they might exhibit.
• 3 categories of fundamental models:
 Interaction
 Failure
 Security
Interaction model
• Fundamentally, distributed systems are comprised of entities
that communicate and coordinate by passing messages. 
• The following characteristics of communication channels
impact the performance of the system:
Latency - the time between the sending of a message at
the source and the receipt of the message at the
destination.
Bandwidth - the total amount of information that can be
transmitted over a given time period (e.g., Mbits/second).
Jitter - "the variation int he time taken to deliver a series
of messages.“
• Coordination of the actions of entities in a distributed
system is impacted by the fact that each entity will have a
different clock drift rate.
Failure model
• Defines the ways in which failure may occur in order to provide an
understanding of its effects.
• Categories of failures:
 Omission failures - Process or channel failed to do something.
 Process omission failures: When we say that a process has crashed we
mean that it has halted and will not execute any further steps of its
program ever.
 Communication omission failures: The communication channel
produces an omission failure if it does not transport a message from p’s
outgoing message buffer to q’s incoming message buffer. Generally
caused by lack of buffer space at the receiver or by a network
transmission error, detected by a checksum carried with the message
data.
 Arbitrary failures - Any type of error can occur in processes or channels
(worst). For example, a process may set wrong values in its data items.
 Timing failures - Applicable only to synchronous distributed systems
where time limits may not be met. Clock drift exceeds allowable bounds.
Process p Process q

send m receive

Communication channel
Outgoing message buffer Incoming message buffer

Processes and channels


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 ChannelA 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 Process orProcess/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.

Omission and arbitrary failures


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.

Timing failures
Security model
• Secure processes and channels and protect objects
encapsulated against unauthorized access.
• Protecting access to objects - Access rights, authentication of clients
Access rights Object
invocation

Client
result Server

Principal (user) Network Principal (server)

• Server manages a collection of objects on behalf of some users.


The users can run client programs that send invocations to the
server to perform operations on the objects.
• The server carries out the operation specified in each invocation
and sends the result to the client.
• Protecting processes and interactions
 Processes interact by sending messages. The messages are
exposed to attack because the network and the communication
service that they use are open. Servers and peer processes
expose their interfaces, enabling invocations to be sent to them
by any other process.
Copy of m

The enemy
m’
Process p m Process q
Communication channel

 Threats to processes: problem of unauthenticated requests /


replies. e.g., "man in the middle"
 Threats to communication channels: enemy may copy, alter or
inject messages as they travel across network.
 Use of “secure” channels, based on cryptographic methods.
Principal A Principal B

Process p Secure channel Process q

Secure channels
Thank you…
The end

You might also like