Models of Distributed System

Distributed Computing
EG 3113 CT Diploma in Computer Engineering
5th Semester
Unit 3.3 Models of Distributed System
Lecture by : Er. Ashish K.C(Khatri)

Models of Distributed System:
• The distributed system models are listed as:
1. Physical Model
2. Architectural Model
3. Fundamental Model
8/16/2022 Distributed Computing Notes © Er. Ashish K.C(Khatri) 2

1. Physical Model:
• Physical models consider the types of computers and devices that constitute a
system and their interconnectivity, without details of specific technologies.
• Physical models are the most explicit way in which to describe a system; they
capture the hardware composition of a system in terms of the computers (and
other devices, such as mobile phones) and their interconnecting networks.
• 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.

Some Physical Model:
• Baseline physical model:
• A distributed system in which hardware or software components located at
networked computers communicate and coordinate their actions only by passing
messages.
• This leads to a minimal physical model of a distributed system as an extensible set
of computer nodes interconnected by a computer network for the required passing
of messages

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

• Internet-scale distributed systems:
• Building on this foundation, 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, the underlying physical infrastructure consists of a physical
model that is, 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.
• They incorporate large numbers of nodes and provide distributed system services
for global organizations and across organizational boundaries.

• Contemporary distributed systems:
• In the above 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, leading to the need for
added capabilities such as service discovery and support for spontaneous interoperation
• 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).

2. Architectural Model:
• The architecture of a system is its structure in terms of separately specified
components and their interrelationships. The overall goal is to ensure that the
structure will meet present and likely future demands on it.
• The architectural model describes responsibilities distributed between system
components and how are these components placed.
• They are of two types:
a. Client-Server Model
b. Peer-to-Peer Model

a. Client-Server Model:
• The system is structured as a set of processes, called servers, that offer services to
the users, called clients.
• The client-server model is usually based on a simple request/reply protocol,
implemented with send/receive primitives or using remote procedure calls (RPC)
or remote method invocation (RMI):
• The client sends a request (invocation) message to the server asking for some
service;
• The server does the work and returns a result (e.g. the data requested) or an error
code if the work could not be performed.
• A server can itself request services from other servers; thus, in this new relation,
the server itself acts as a client.

b. Peer-to-Peer Model:
• All processes (objects) play a similar role.
• Processes (objects) interact without a particular distinction between clients and servers.
• The pattern of communication depends on the particular application.
• A large number of data objects are shared; any individual computer holds only a small
part of the application database.
• Processing and communication loads for access to objects are distributed across many
computers and access links.
• This is the most general and flexible model.
• Peer-to-Peer tries to solve some of the above.
• It distributes shared resources widely -> share computing and communication loads.

Architectural Patterns:
• They are not themselves necessarily complete solutions but rather offer partial
insights that, when combined with other patterns, lead the designer to a solution
for a given problem domain.
• Some architectural patterns are:
Layering
Tiered architecture
Thin clients

Layering architecture:
• In a layered approach, a complex system is partitioned into a number of layers,
with a given layer making use of the services offered by the layer below.
• A given layer therefore offers a software abstraction, with higher layers being
unaware of implementation details, or indeed of any other layers beneath them.
• In terms of distributed systems, this equates to a vertical organization of services
into service layers.
• A distributed service can be provided by one or more server processes, interacting
with each other and with client processes in order to maintain a consistent system-
wide view of the service’s resources

• A platform for distributed systems and applications consists
of the lowest-level hardware and software layers.
• These low-level layers provide services to the layers above
them, which are implemented independently in each
computer, bringing the system’s programming interface up to
a level that facilitates communication and coordination
between processes.
• Intel x86/Windows, Intel x86/Solaris, Intel x86/Mac OS X,
Intel x86/Linux and ARM/Symbian are major examples.
• Middleware is represented by processes or objects in a set of
computers that interact with each other to implement
communication and resource-sharing support for distributed
applications.
• It is concerned with providing useful building blocks for the
construction of software components that can work with one
another in a distributed system.

Tiered architecture:
• Tiered architectures are complementary to layering.
• Whereas layering deals with the vertical organization of services into layers of
abstraction, tiering is a technique to organize functionality of a given layer and
place this functionality into appropriate servers and, as a secondary consideration,
on to physical nodes.
• Types:
- Two Tier
- Three Tier

• consider the functional decomposition of a given application, as follows:
• the presentation logic, which is concerned with handling user interaction and
updating the view of the application as presented to the user;
• the application logic, which is concerned with the detailed application-specific
processing associated with the application (also referred to as the business logic,
although the concept is not limited only to business applications);
• the data logic, which is concerned with the persistent storage of the application,
typically in a database management system.

2-Tier architecture:
• In the two-tier solution, the three aspects mentioned above must be partitioned into
two processes, the client and the server.
• This is most commonly done by splitting the application logic, with some residing
in the client and the remainder in the server (although other solutions are also
possible).
• The advantage of this scheme is low latency in terms of interaction, with only one
exchange of messages to invoke an operation.
• The disadvantage is the splitting of application logic across a process boundary,
with the consequent restriction on which parts of the logic can be directly invoked
from which other part.

3-Tier architecture:
• In the three-tier solution, there is a one-to-one mapping from logical elements to
physical servers and hence, for example, the application logic is held in one place,
which in turn can enhance maintainability of the software.
• Each tier also has a well-defined role; for example, the third tier is simply a
database offering a (potentially standardized) relational service interface.
• The first tier can also be a simple user interface allowing intrinsic support for thin
clients (as discussed below).
• The drawbacks are the added complexity of managing three servers and also the
added network traffic and latency associated with each operation.

Thin Clients:
• The trend in distributed computing is towards moving complexity away from the
end-user device towards services in the Internet.
• This is most apparent in the move towards cloud computing but can also be seen
in tiered architectures.
• This trend has given rise to interest in the concept of a thin client, enabling access
to sophisticated networked services, provided for example by a cloud solution,
with few assumptions or demands on the client device.
• More specifically, the term thin client refers to a software layer that supports a
window-based user interface that is local to the user while executing application
programs or, more generally, accessing services on a remote computer.

3. Fundamental Model:
• The fundamental model is based on the fundamental properties that allow us to be more
specific about their characteristics and the failures and security risks they might exhibit.
• In general, such a fundamental model should contain only the essential ingredients that
we need to consider in order to understand and reason about some aspects of a system’s
behavior.
• The purpose of such a model is:
• To make explicit all the relevant assumptions about the systems we are modelling.
• To make generalizations concerning what is possible or impossible, given those
assumptions
• Types:
- Interaction
- Fault
- Security

i. Interaction Model:
• Interaction models are for handling time i. e. for process execution,
message delivery, clock drifts, etc.
• They are of two types:
a. Synchronous distributed system
b. Asynchronous distributed system

a. Synchronous System:
• Lower and upper bounds on the execution time of processes can be set.
• Transmitted messages are received within a known bounded time.
• Drift rates between local clocks have a known bound.
• In synchronous distributed systems there is a notion of global physical time (with
a known relative precision depending on the drift rate).
• Only synchronous distributed systems have predictable behavior in terms of
timing. Only such systems can be used for hard real-time applications.
• In synchronous distributed system it is possible and safe to use timeouts in order
to detect failures of a process or communication link.
• It is difficult and costly to implement synchronous distributed systems.

b. Asynchronous System:
• Many distributed systems (including those on the Internet) are asynchronous.
• No bound on process execution time (nothing can be assumed about speed, load,
and reliability of computers).
• No bound on message transmission delays (nothing can be assumed about speed,
load, and reliability of interconnections)
• No bounds on drift rates between local clocks.
• In an asynchronous distributed system there is no global physical time. Reasoning
can be only in terms of logical time (see lecture on time and state).
• Asynchronous distributed systems are unpredictable in terms of timing.
• No timeouts can be used.

ii. Fault Model:
• Failures can occur both in processes and communication channels. The reason can
be both software and hardware faults.
• Fault models are needed in order to build systems with predictable behavior in
case of faults (systems that are fault-tolerant).
• such a system will function according to the predictions, only as long as the real
faults behave as defined by the “fault model”.

iii. Security:
• The modular nature of distributed systems and their openness exposes
them to attack by both external and internal agents.
• Our security model defines and classifies the forms that such attacks
may take, providing a basis for the analysis of threats to a system and
for the design of systems that are able to resist them.

Models of Distributed System

More Related Content

What's hot (20)

Similar to Models of Distributed System (20)

More from Ashish KC (20)

Recently uploaded (20)

Models of Distributed System