DISTRIBUTED SYSTEM

System Models

2
Prepared by: Khem Thay
SYSTEM MODELS
▪ There are 3 important models which design distributed system:
▪ Physical models: the types of computers and devices that constitute a system
and their interconnectivity.
▪ Architectural models: a system for the computational and communication
tasks to be performed by its computational elements. The computational
elements can be individual computers or aggregates of them supported by
appropriate network interconnections. Client-Server and peer-to-peer are 2 of
the commonly-used forms of architectural model.
▪ Fundamental models: take an abstract view to describe solutions to the issues
of distributed systems.

2
SYSTEM MODELS
▪ There is no global time in a distributed system; This is because
nodes in a distributed system can be located all over the world,
and network delays can make it difficult to synchronize clocks
perfectly. Clocks on different nodes may run at different rates
due to hardware differences or environmental factors.
▪ All communication between processes are achieved by the
means of messages. Message communication over a
computer network can be affected by delays, surfer from a
variety of failures and is vulnerable to security attacks.

3
SYSTEM MODELS
▪ These 3 issues are solved by 3 models:
▪ Interaction model: (solves message delay issues) deals with performance
and the difficulty of time limits, EX: message delivery. This model considers
the structure and sequencing of the communication between the elements of
the system.
▪ Failure model: (considers the ways system can fail then make it operate
correctly) gives a clear specification of the faults that can happen in processes
and communication channels. It defines reliable communication and correct
processes.
▪ Security model: (explains the possible threats to processes and
communication channels, and then introduces the concept of secure
channel). This model considers how the system is protected against attempts to
interfere with its correct operation.

4
INTRODUCTION
▪ The problems that designers of distributed systems face include:
▪ Widely varying modes of use: the component parts of systems are subject
to wide variations in workload.
▪ Wide range of system environments: a distributed system can
accommodate heterogeneous hardware, OS and networks. The networks
may differ widely in performance, Ex: wireless networks operate at a
fraction of the speed of LANs.
▪ External threats: attacks on data integrity and secrecy, denial of service
attacks.
▪ Internal problems: non-synchronized clocks, conflicting data updates
and modes of hardware and software failure involve the individual
system components.

5
PHYSICAL MODELS
▪ Physical model is a representation of the underlying hardware
elements of a distributed system that hide away from the specific
details of computer and networking technologies used.
▪ Baseline physical model is a minimal physical model of a
distributed system that acts as an extensible set of compute nodes
interconnected by network that are required for passing of
messages.
▪ Beyond this baseline model, we can usefully identify three
generations of distributed systems:

6
PHYSICAL MODELS
▪ Early distributed system: it might consisted of between 10 and 100 nodes
interconnected by a LAN, which supported some services of sharing resources
across the Internet.
▪ Internet-scale distributed system: Such systems exploit the infrastructure
offered by the Internet to become truly global. They incorporate large numbers
of nodes and provide distributed system services across organizational
boundaries.
▪ Contemporary distributed systems: In the above systems, nodes were typically
desktop computers and therefore relatively static, discrete and autonomous. The
key trends in distributed system leads to:
▪ The emergence of mobile computing:
▪ The emergence of ubiquitous computing
▪ The emergence of cloud computing
7
PHYSICAL MODELS
▪ Physical architecture of distributed system has significant increase
in the level of heterogeneity. These systems use varied set of
networking technologies and offer a wide variety of applications
and services.
DISTRIBUTED SYSTEMS OF SYSTEMS:
▪ This refer to ultra-large-scale (ULS) distributed systems.
▪ The complexity of modern distributed systems considers the
physical architectures as systems of systems. They can be defined
as a complex system consisting of a series of subsystems that work
in their own way and come together to perform a particular task or
tasks, EX: servers of cloud computing system
8
ARCHITECTURAL MODELS
▪ Architecture of a system refers to the structure in terms of
separated components and their interrelationships.
▪ The goal is to make the system reliable, manageable, adaptable
and cost-effective.
▪ The architectural models used in distributed systems include:
▪ Client-server models
▪ Peer-to-peer approaches
▪ Distributed objects
▪ Distributed components
▪ Distributed event-based systems

9
ARCHITECTURAL MODELS
▪ The comparation of architectural model:

10
ARCHITECTURAL MODELS
▪ Architecture of a system refers to the structure in terms of
separated components and their interrelationships.
▪ The goal is to make the system reliable, manageable, adaptable
and cost-effective.
▪ The architectural models used in distributed systems include:
▪ Client-server models
▪ Peer-to-peer approaches
▪ Distributed objects
▪ Distributed components
▪ Distributed event-based systems

11
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Communicating entities
▪ From a system perspective: the entities that communicate are
processes. So distributed system can be seen as a number of
processes coupled with appropriate interprocess communication
paradigms. In distributed system, processes are replaced by
threads, so it is threads that are the endpoints of communication.
▪ From a programming perspective:
▪ Objects: in distributed object-based approaches, a computation consists of a
number of interacting objects.
▪ Components: is the resemble of objects. Components specify objects’
interfaces and the assumptions (method) they make.
▪ Web services: closely related to objects and components, but web services are
integrated into the WWW by using web standards to represent services.
12
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Communicating Paradigms
▪ Communication paradigms refers to how all entities
communicate with one another.
▪ 3 types of communication paradigm include:
▪ Interprocess communication: is the low-level support for communication
between processes, including message-passing primitives, direct access to
API and multicast communication.
▪ Remote invocation: covers a range of techniques based on a two-way
exchange between communicating entities and results in the calling of a
remote operation, procedure or method.
▪ Request-reply protocols: a pattern used in the underlying message-passing
service to support client-server computing. It involves a pairwise exchange
of messages from client to server and from server back to client.
13
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)
Communicating Paradigms
▪ Most distributed systems use:
▪ Remote procedure calls (RPC): procedures in processes on remote
computers can be called as if they are the procedures in local address
space. RPC hides the encoding and decoding of parameters, results,
and the passing of messages. RPC supports client-server computing
by: servers offer the operations through service interface and clients
can calls these operations directly as if they were available locally
▪ Remote method invocation (RMI): similar to RPC but deal with
distributed objects. A calling to an object can invoke a method of a
remote object. The underlying details are generally hidden from the
user.
▪ RPC and RMI have 1 thing in common: communication represents
a two-way relationship between a sender and a receiver, with the
senders directing messages or invocations to the associated
receivers. Receivers also aware of the ID of senders, and in most
cases both parties must exist at the same time.
14
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Communicating Paradigms
▪ Techniques of indirect communication, through a third entity,
allow a strong degree of decoupling between senders and
receivers.
▪ Group communication
▪ Publish-subscribe systems
▪ Message queues
▪ Tuple spaces
▪ Distributed shared memory (DSM)

15
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

▪ Group communication: concerns with the delivery of messages to a set of

recipients. It is a multiparty communication paradigm supporting one-to-
many communication. Group communication relies on group ID. Recipients
can receive messages sent to a group by joining the group. Senders can
send messages to the group via the group ID; senders don’t need to know
the recipients of the message.
▪ Publish-subscribe systems: sometimes called distributed event-based
systems, ensures information generated by producers in routed to
consumers who desire this information, Ex: a large number of producers (or
publishers) distributed information items of interest (events) to a number of
consumers (or subscribers).

16
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

▪ Message queues: offers a point-to-point service that producer’s processes

can send messages to a specified queue, and consumer’s processes can
receive messages from the queue or be notified of the arrival of new
messages in the queue. Queues offer an indirection between the producer
and consumer processes.
▪ Tuple spaces: supports a model whereby processes can place arbitrary
items of structured data in persistent tuple space, then other processes can
read or remove such tuples from the tuple space. Readers and writers don’t
need to exist at the same time because the tuple space is persistent.
▪ Distributed shared memory (DSM): provide an abstraction for sharing
data between processes that don’t share physical memory. Programmers
are presented with a familiar abstraction of reading or writing (shared) data
structures as if they were in their own local address spaces.

17
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Roles and responsibilities

▪ Processes take on given roles, and these roles are
fundamental in establishing the overall architecture. The
role of individual process leads to 2 architectural styles:
▪ Client-Server: client processes interact with server processes in
order to access the shared resources that they manage.
▪ Peer-to-peer: all of the processes play similar roles, interacting
cooperatively as peers without any distinction between client and
server processes.

18
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Client-server
▪ Client processes interact with server processes of different computers in order
to access the shared resources managed by the remote computers.
▪ Servers may in turn be clients of other servers. Ex: search engine is both a
server and a client: it responds to queries from browser clients, and it runs web
crawlers that act as clients of other web servers.

19
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

Peer-to-peer
▪ All processes involved in a task or activity have similar roles, interacting
cooperatively as peers without any distinction.
▪ All participating processes run the same program and offer the same set of
interfaces to each other.
▪ The network and computing resources owned by each users of a service
could also be used to support that service. This means that the resources
available to run the service grow with the number of users.

20
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

▪ Peer-to-peer applications and systems have been constructed to enable

millions of computers to provide access to data and other resources that they
collectively store and manage.
▪ The aim of peer-to-peer architecture is to exploit the resources from
participating computers for the fulfilment of a given task or activity.

21
ARCHITECTURAL MODELS (ARCHITECTURAL ELEMENTS)

▪ Applications are composed of large numbers of peer processes running

on all computers, and the communication pattern depends on
application requirements.
▪ A large number of data objects are shared. Each individual computer
holds only a small part of the application DB, storages, processes and
communication loads for accessing to the distributed objects across
computers and network links.
▪ Each object is replicated in several computers to further redistribute the
load and to provide resilience in case of disconnection of any individual
computers.

22
REFERENCE

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012

23