Introduction: Definition, Design Issues, Goals, Types of distributed systems, Centralized
Computing, Advantages of Distributed systems over centralized system .Limitation of
Distributed systems Architectural models of distributed system, Client-server
communication, Introduction to DCE
2. Distributed System
Mr. Sagar Pandya
Information Technology Department
sagar.pandya@medicaps.ac.in
Course
Code
Course Name Hours Per
Week
Total Hrs. Total
Credits
L T P
IT3EL04 Distributed System 3 0 0 3 3
3. Reference Books
Text Book:
1. G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems: Concepts
and design, Pearson.
2. P K Sinha, Distributed Operating Systems: Concepts and design, PHI
Learning.
3. Sukumar Ghosh, Distributed Systems - An Algorithmic approach, Chapman
and Hall/CRC
Reference Books:
1. Tanenbaum and Steen, Distributed systems: Principles and Paradigms,
Pearson.
2. Sunita Mahajan & Shah, Distributed Computing, Oxford Press.
3. Distributed Algorithms by Nancy Lynch, Morgan Kaufmann.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
4. Unit-1
Introduction: Definition,
Design Issues,
Goals, Types of distributed systems,
Centralized Computing,
Advantages of Distributed systems over centralized system .
Limitation of Distributed systems
Architectural models of distributed system,
Client-server communication,
Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
5. INTRODUCTION
What is a Distributed System?
A distributed system is one in which components located at
networked computers communicate and coordinate their actions only
by passing messages.
A distributed system consists of a collection of autonomous
computers linked by a computer network and equipped with
distributed system software.
This software enables computers to coordinate their activities and to
share the resources of the system hardware, software, and data.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
6. INTRODUCTION
A Distributed System Contains multiple nodes that are physically
separate but linked together using the Communication Network.
A distributed system is defined as set of autonomous Computers
System that appears to its users a single coherent system.
A Distributed System (DS) is one in which
Hardware and software components, located at remote networked
computers, coordinate and communicate their actions only by-
passing messages. Any distance may separate computers in the
network.
Sharing of resources is the main motivation of distributed systems.
Resources may be managed by servers and accessed by clients, or
they may be encapsulated as objects and accessed by client objects.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
7. INTRODUCTION
A distributed operating system runs on multiple independent
computers, connected through communication network, but appears
to its users as a single virtual machine and runs its own OS.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
8. WHAT IS A DISTRIBUTED COMPUTING
SYSTEM?
Over the past two decades, advancements in microelectronic
technology have resulted in the availability of fast, inexpensive
processors , and advancements in communication technology have
resulted in the availability of cost-effective and highly efficient
computer networks.
The net result of the advancements in these two technologies is that
the price performance ratio has now changed to favor the use of
interconnected, multiple processors in place of a single, high-speed
processor.
Computer architectures consisting of interconnected, multiple
processors are basically of two types:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
9. WHAT IS A DISTRIBUTED COMPUTING
SYSTEM?
1. Tightly coupled systems:- In these systems, there is a single
systemwide primary memory (address space) that is shared by all the
processors [Fig. l.1(a)].
If any processor writes, for example, the value 100 to the memory
location x, any other processor subsequently reading from location x
will get the value 100.
Therefore, in these systems, any communication between the
processors usually takes place through the shared memory.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
10. WHAT IS A DISTRIBUTED COMPUTING
SYSTEM?
2. Loosely coupled systems:- In these systems, the processors do
not share memory, and each processor has its own local memory
[Fig. l.1(b)].
If a processor writes the value 100 to the memory location x, this
write operation will only change the contents of its local memory and
will not affect the contents of the memory of any other processor.
Hence, if another processor reads the memory location x, it will get
whatever value was there before in that location of its own local
memory.
In these systems, all physical communication between the processors
is done by passing messages across the network that interconnects
the processors.
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
11. WHAT IS A DISTRIBUTED COMPUTING
SYSTEM?
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
12. WHAT IS A DISTRIBUTED COMPUTING
SYSTEM?
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Usually, tightly coupled systems are referred to as parallel processing
systems, and loosely coupled systems are referred to as distributed
computing systems, or simply distributed systems.
In short, a distributed computing system is basically a collection of
processors interconnected by a communication network in which
each processor has its own local memory and other peripherals, and
the communication between any two processors of the system takes
place by message passing over the communication network.
For a particular processor, its own resources are local, whereas the
other processors and their resources are remote.
Together, a processor and its resources are usually referred to as a
node or site or machine of the distributed computing system.
13. Why we need a distributed system?
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Economics: a collection of microprocessors offer a better
price/performance than mainframes.
Speed: a distributed system may have more total computing power
than a mainframe. Enhanced performance through load distribution.
Inherent distribution: Some applications are inherently distributed.
Ex. a supermarket chain.
Reliability: If one machine crashes, the system as a whole can still
survive. Higher availability and improved reliability.
Incremental growth: Computing power can be added in small
increments. Modular expandability
14. Why we need a distributed system?
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Data sharing: allow many users to access to a common data base
Resource Sharing: expensive peripherals like color printers
Communication: enhance human-to-human communication, e.g.,
email, chat
Flexibility: spread the workload over the available machines
Mobility : Access the system, data or resources from any place or
device.
15. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The distributed information system is defined as “a number of
interdependent computers linked by a network for sharing information
among them”.
A distributed information system consists of multiple autonomous
computers that communicate or exchange information through a
computer network.
Design issues of distributed system –
1. Heterogeneity : Heterogeneity is applied to the network, computer
hardware, operating system and implementation of different
developers. A key component of the heterogeneous distributed system
client-server environment is middleware.
Middleware is a set of services that enables application and end-user to
interacts with each other across a heterogeneous distributed system.
16. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The Internet enables users to access services and run applications
over a heterogeneous collection of computers and networks.
Heterogeneity (that is, variety and difference) applies to all of the
following:
Hardware devices: computers, tablets, mobile phones, embedded
devices, etc.
Operating System: Ms Windows, Linux, Mac, Unix, etc.
Network: Local network, the Internet, wireless network, satellite
links, etc.
Programming languages: Java, C/C++, Python, PHP, etc.
Different roles of software developers, designers, system managers
Different programming languages use different representations for
characters and data structures such as arrays and records.
17. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
These differences must be addressed if programs written in different
languages are to be able to communicate with one another.
Programs written by different developers cannot communicate with
one another unless they use common standards.
Middleware : The term middleware applies to a software layer that
provides a programming abstraction as well as masking the
heterogeneity of the underlying networks, hardware, operating
systems and programming languages.
Most middleware is implemented over the Internet protocols, which
themselves mask the differences of the underlying networks, but all
middleware deals with the differences in operating systems and
hardware
18. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
2. Openness: The openness of the distributed system is determined
primarily by the degree to which new resource-sharing services can be
made available to the users.
Open systems are characterized by the fact that their key interfaces are
published.
It is based on a uniform communication mechanism and published
interface for access to shared resources.
It can be constructed from heterogeneous hardware and software.
3. Scalability: Scalability of the system should remain efficient even
with a significant increase in the number of users and resources
connected.
19. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
4. Security : Security of information system has three components
Confidentially, integrity and availability. Encryption protects shared
resources, keeps sensitive information secrets when transmitted.
Confidentiality (protection against disclosure to unauthorized individuals)
Integrity (protection against alteration or corruption),
Availability for the authorized (protection against interference with the
means to access the resources).
5. Failure Handling: When some faults occur in hardware and the software
program, it may produce incorrect results or they may stop before they have
completed the intended computation so corrective measures should to
implemented to handle this case.
Failure handling is difficult in distributed systems because the failure is
partial i, e, some components fail while others continue to function.
20. Design Issues of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
6. Concurrency: There is a possibility that several clients will attempt
to access a shared resource at the same time. Multiple users make
requests on the same resources, i.e read, write, and update.
Each resource must be safe in a concurrent environment. Any object
that represents a shared resource a distributed system must ensure that
it operates correctly in a concurrent environment.
7. Transparency : Transparency ensures that the distributes system
should be perceived as a single entity by the users or the application
programmers rather than the collection of autonomous systems, which
is cooperating.
The user should be unaware of where the services are located and the
transferring from a local machine to a remote one should be
transparent.
21. Features of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Components in the system are concurrent.
There can be multiple components, but they will generally be
autonomous in nature.
A global clock is not required in a distributed system.
Compared to other network models, there is greater fault tolerance in a
distributed model.
Price/performance ratio is much better.
22. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
There are various important goals that must be met to build a
distributed system worth the effort. A distributed system should easily
connect users to resources, it should hide the fact that resources are
distributed across a network, must be open, and must be scalable.
1. Connecting Users and Resources Sharing:
The main goal of a distributed system is to make it easy for users to
access remote resources, and to share them with other users in a
controlled manner.
Resources can be virtually anything, typical examples of resources are
printers, storage facilities, data, files, web pages, and networks.
There are many reasons for sharing resources. One reason is
economics.
23. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
2. Transparency :
An important goal of a distributed system is to hide the fact that its
process and resources are physically distributed across multiple
computers. A distributed system that is capable of presenting itself to
users and applications such that it is only a single computer system is
called transparent.
The concept of transparency can be applied to many aspects of a
distributed system as shown in table.
Different Forms of Transparency –
24. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
S.No. Transparency Description
(1) Access Hide data representation.
(2) Location Hide location
(3) Migration Move place information.
(4) Relocation Hide moved place relocation.
(5) Replication Hide that a resource is replication.
(6) Concurrency Shared data bases access
(7) Failure Hide fact about resource failure.
(8) Persistence Hide fact about memory location.
25. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
3. Openness :
Another important goal of distributed systems is openness.
The openness of a computer system is the characteristic that
determines whether the system can be extended and reimplemented in
various ways.
The openness of distributed systems is determined primarily by the
degree to which new resource-sharing services can be added and be
made available for use by a variety of client programs.
If the well-defined interfaces for a system are published, it is easier for
developers to add new features or replace sub-systems in the future.
Example: Twitter and Facebook have API that allows developers to
develop theirs own software interactively.
26. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
4. Scalability :
The uncertain trend in distributed systems is towards larger systems.
This observation has implications for distributed file system design.
Algorithms that work well for systems with 100 machines can work
for systems with 1000 machines and none at all for systems with 10,
000 machines.
Distributed systems must be scalable as the number of user increases.
The scalability is defined by B. Clifford Neuman as
A system is said to be scalable if it can handle the addition of users
and resources without suffering a noticeable loss of performance
or increase in administrative complexity
27. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Scalability has 3 dimensions:
Size
Number of users and resources to be processed. Problem associated is
overloading
Geography
Distance between users and resources. Problem associated is
communication reliability
Administration
As the size of distributed systems increases, many of the system needs
to be controlled. Problem associated is administrative mess
28. Goals of a distributed system
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
5. Concurrency:
Both services and applications provide resources that can be shared by
clients in a distributed system.
There is therefore a possibility that several clients will attempt to
access a shared resource at the same time.
For example, a data structure that records bids for an auction may be
accessed very frequently when it gets close to the deadline time. For an
object to be safe in a concurrent environment, its operations must be
synchronized in such a way that its data remains consistent.
This can be achieved by standard techniques such as semaphores,
which are used in most operating systems.
29. Common Examples for distributed systems
include :
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Network file system, network printer etc
ATM (cash machine)
Distributed databases
Network computing
Global positioning systems
Retail point-of-sale terminals
Air-traffic control
Enterprise computing
WWW
30. DISTRIBUTED COMPUTING SYSTEM
MODELS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Various models are used for building distributed computing systems.
These models can be broadly classified into five categories-
Minicomputer,
Workstation,
Workstation-server,
Processor-pool, and
Hybrid.
31. Minicomputer Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The minicomputer model is a simple extension of the centralized
time-sharing system.
As shown in Figure 1.2, a distributed computing system based on
this model consists of a few minicomputers (they may be large
supercomputers as well) interconnected by a communication
network.
Each minicomputer usually has multiple users simultaneously logged
on to it.
For this, several interactive terminals are connected to each
minicomputer.
Each user is logged on to one specific minicomputer, with remote
access to other minicomputers.
32. Minicomputer Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The network allows a user to access remote resources that are
available on some machine other than the one on to which the user is
currently logged.
The minicomputer model may be used when resource sharing (such
as sharing of information databases of different types, with each type
of database located on a different machine) with remote users is
desired.
The early ARPAnet is an example of a distributed computing system
based on the minicomputer model.
34. Workstation Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
As shown in Figure 1.3, a distributed computing system based on the
workstation model consists of several workstations interconnected by
a communication network.
A company's office or a university department may have several
workstations scattered throughout a building or campus, each
workstation equipped with its own disk and serving as a single-user
computer.
It has been often found that in such an environment, at anyone time
(especially at night), a significant proportion of the workstations are
idle (not being used), resulting in the waste of large amounts of CPU
time.
Example:Sprite system & Xerox PARC.
35. Workstation Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Therefore, the idea of the workstation model is to interconnect all
these workstations by a high-speed LAN so that idle workstations
may be used to process jobs of users who are logged onto other
workstations and do not have sufficient processing power at their
own workstations to get their jobs processed efficiently.
In this model, a user logs onto one of the workstations called his or
her "home“ workstation and submits jobs for execution.
When the system finds that the user’s workstation does not have
sufficient processing power for executing the processes of the
submitted jobs efficiently, it transfers one or more of the processes
from the user’s workstation to some other workstation that is
currently idle and gets the process executed there, and finally the
result of execution is returned to the user’s workstation.
37. Workstation Server Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The workstation model is a network of personal workstations, each with
its own disk and a local file system.
A workstation with its own local disk is usually called a diskful
workstation and a workstation without a local disk is called a diskless
workstation.
With the proliferation of high-speed networks, diskless workstations have
become more popular in network environments than diskful
workstations, making the workstation-server model more popular than
the workstation model for building distributed computing systems.
As shown in Figure 1.4, a distributed computing system based on the
workstation server model consists of a few minicomputers and several
workstations (most of which are diskless, but a few of which may be
diskful) interconnected by a communication network.
39. Workstation Server Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
In this model, a user logs onto a workstation called his or her home
workstation.
Normal computation activities required by the user's processes are
performed at the user’s home workstation,
but requests for services provided by special servers (such as a file server
or a database server) are sent to a server providing that type of service
that performs the user's requested activity and returns the result of request
processing to the user’s workstation.
Therefore, in this model, the user's processes need not be migrated to the
server machines for getting the work done by those machines.
As compared to the workstation model, the workstation-server model has
several advantages:
40. Workstation Server Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. In general, it is much cheaper to use a few minicomputers equipped
with large, fast disks that are accessed over the network than a large
number of diskful workstations, with each workstation having a small,
slow disk.
2. Diskless workstations are also preferred to diskful workstations from a
system maintenance point of view. Backup and hardware maintenance
are easier to perform with a few large disks than with many small disks
scattered all over a building or campus.
Furthermore, installing new releases of software (such as a file server
with new functionalities) is easier when the software is to be installed on
a few file server machines than on every workstation.
41. Workstation Server Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The request-response protocol is known as the client-server model of
communication.
In this model, a client process (which in this case resides on a
workstation) sends a request to a server process (which in this case
resides on a minicomputer) for getting some service such as reading a
block of a file.
The server executes the request and sends back a reply to the client that
contains the result of request processing.
The V-System [Cheriton 1988] is an example of a distributed computing
system that is based on the workstation-server model.
43. Processor-Pool Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The processor-pool model is based on the observation that most of the time
a user does not need any computing power but once in a while the user may
need a very large amount of computing power for a short time.
Therefore, unlike the workstation-server model in which a processor is
allocated to each user, in processor-pool model the processors are pooled
together to be shared by the users as needed.
The pool of processors consists of a large number of microcomputers &
minicomputers attached to the network.
Each processor in the pool has its own memory to load & run a system
program or an application program of the distributed computing system.
In this model no home machine is present & the user does not log onto any
machine.
44. Processor-Pool Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
This model has better utilization of processing power & greater flexibility.
Example:Amoeba & the Cambridge Distributed Computing System.
In the processor-pool model there is no concept of a home machine. That is,
a user does not log onto a particular machine but to the system as a whole.
This is in contrastto other models in which each user has a home machine
(e.g., a workstation or minicomputer) onto which he or she logs and runs
most of his or her programs there by default.
As compared to the workstation-server model, the processor-pool model
allows better utilization of the available processing power of a distributed
computing system.
This is because in the processor-pool model, the entire processing power of
the system is available for use by the currently logged-on users
46. Hybrid Model
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The workstation-server model has a large number of computer users only
performing simple interactive tasks &-executing small programs.
In a working environment that has groups of users who often perform jobs
needing massive computation, the processor-pool model is more attractive
& suitable.
To combine Advantages of workstation-server & processor-pool models,a
hybrid model can be used to build a distributed system.
The processors in the pool can be allocated dynamically for computations
that are too large or require several computers for execution.
The hybrid model gives guaranteed response to interactive jobs allowing
them to be more processed in local workstations of the users
47. Centralized, Decentralized and Distributed
Systems
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Comparison between Centralized, Decentralized and Distributed
Systems
1. Centralized System
2. Decentralized System
3. Distributed System
We start with centralized systems because they are the most intuitive
and easy to understand and define.
48. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Centralized systems are systems that use client/server architecture where
one or more client nodes are directly connected to a central server.
This is the most commonly used type of system in many organizations
where client sends a request to a company server and receives the response.
49. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Example –
Wikipedia.
Consider a massive server to which we send our requests and the
server responds with the article that we requested.
Suppose we enter the search term ‘junk food’ in the Wikipedia search
bar.
This search term is sent as a request to the Wikipedia servers (mostly
located in Virginia, U.S.A) which then responds back with the
articles based on relevance.
In this situation, we are the client node, Wikipedia servers are central
server.
50. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Characteristics of Centralized System –
Presence of a global clock: As the entire system consists of a central
node(a server/ a master) and many client nodes(a computer/ a slave),
all client nodes sync up with the global clock(the clock of the central
node).
One single central unit: One single central unit which
serves/coordinates all the other nodes in the system.
Dependent failure of components: Central node failure causes
entire system to fail.
This makes sense because when the server is down, no other entity is
there to send/receive response/requests.
51. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Scaling –
Only vertical scaling on central server is possible. Horizontal scaling
will contradict the single central unit characteristic of this system of a
single central entity.
Components of Centralized System –
Node (Computer, Mobile, etc.).
Server.
Communication link (Cables, Wi-Fi, etc.).
Architecture of Centralized System –
Client-Server architecture. The central node that serves the other
nodes in the system is the server node and all the other nodes are the
client nodes.
52. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Limitations of Centralized System –
Can’t scale up vertically after a certain limit – After a limit, even if
you increase the hardware and software capabilities of the server
node, the performance will not increase appreciably leading to a
cost/benefit ratio < 1.
Bottlenecks can appear when the traffic spikes – as the server can
only have a finite number of open ports to which can listen to
connections from client nodes.
So, when high traffic occurs like a shopping sale, the server can
essentially suffer a Denial-of-Service attack or Distributed Denial-of-
Service attack.
53. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Advantages of Centralized System –
• Easy to physically secure.
• It is easy to secure and service the server and client nodes by virtue
of their location
• Smooth and elegant personal experience – A client has a dedicated
system which he uses(for example, a personal computer) and the
company has a similar system which can be modified to suit custom
needs
• Dedicated resources (memory, CPU cores, etc)
• More cost efficient for small systems up to a certain limit – As the
central systems take less funds to set up, they have an edge when
small systems have to be built
54. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
• Quick updates are possible – Only one machine to update.
• Easy detachment of a node from the system. Just remove the connection
of the client node from the server and Node detached.
• Disadvantages of Centralized System –
• Highly dependent on the network connectivity – System can fail if the
nodes lose connectivity as there is only one central node.
• No graceful degradation of system – abrupt failure of the entire system
• Less possibility of data backup. If the server node fails and there is no
backup, you lose the data straight away.
• Difficult server maintenance – There is only one server node and due to
availability reasons, it is inefficient and unprofessional to take the
server down for maintenance.
55. CENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
• Applications of Centralized System –
• Application development – Very easy to setup a central server and
send client requests. Modern technology these days do come with
default test servers which can be launched with a couple commands.
For example, express server, django server.
• Data analysis – Easy to do data analysis when all the data is in one
place and available for analysis
• Personal computing.
• Organisations Using –
• National Informatics Center (India), IBM
56. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
2. DECENTRALIZED SYSTEMS:
These are another type of systems which have been gaining a lot of
popularity, primarily because of the massive hype of Bitcoin.
Now many organizations are trying to find the application of such
systems.
In decentralized systems, every node makes its own decision.
The final behavior of the system is the aggregate of the decisions of
the individual nodes.
Note that there is no single entity that receives and responds to the
request.
57. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Characteristics of Decentralized System –
Lack of a global clock: Every node is independent of each other and
hence, have different clocks that they run and follow.
Multiple central units (Computers/Nodes/Servers): More than one
central unit which can listen for connections from other nodes
Dependent failure of components: one central node failure causes a
part of system to fail; not the whole system.
Scaling –
Vertical scaling is possible. Each node can add resources(hardware,
software) to itself to increase the performance leading to increase in
performance of the entire system.
58. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Components –
Components of Decentralized System are,
Node (Computer, Mobile, etc.)
Communication link (Cables, Wi-Fi, etc.)
59. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Architecture of Decentralized System –
peer-to-peer architecture – all nodes are peers of each other. No
one node has supremacy over other nodes.
master-slave architecture – One node can become a master by
voting and help in coordinating of a part of the system but this does
not mean the node has supremacy over the other node which it is
coordinating.
60. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Limitations of Decentralized System –
May lead to problem of coordination at the enterprise level – When
every node is owner of its own behavior, its difficult to achieve
collective tasks
Not suitable for small systems – Not beneficial to build and operate
small decentralized systems because of low cost/benefit ratio
No way to regulate a node on the system – no superior node
overseeing the behavior of subordinate nodes
61. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Applications of Decentralized System –
Private networks – peer nodes joined with each other to make a
private network.
Cryptocurrency – Nodes joined to become a part of a system in
which digital currency is exchanged without any trace and location
of who sent what to whom. However, in bitcoin we can see the
public address and amount of bitcoin transferred, but those public
addresses are mutable and hence difficult to trace.
62. DECENTRALIZED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Use Cases –
Blockchain
Decentralized databases – Entire database split in parts and
distributed to different nodes for storage and use. For example,
records with names starting from ‘A’ to ‘K’ in one node, ‘L’ to ‘N’ in
second node and ‘O’ to ‘Z’ in third node
Cryptocurrency
Organisations Using –
Bitcoin, Tor network
63. DISTRIBUTED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
3. DISTRIBUTED SYSTEMS: In decentralized systems, every
node makes its own decision.
The final behavior of the system is the aggregate of the decisions of
the individual nodes. Note that there is no single entity that receives
and responds to the request.
64. DISTRIBUTED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Example –
Google search system. Each request is worked upon by hundreds of
computers which crawl the web and return the relevant results.
To the user, the Google appears to be one system, but it actually is
multiple computers working together to accomplish one single task
(return the results to the search query).
Characteristics of Distributed System –
Concurrency of components: Nodes apply consensus protocols to
agree on same values/transactions/commands/logs.
Lack of a global clock: All nodes maintain their own clock.
Independent failure of components: In a distributed system, nodes fail
independently without having a significant effect on the entire system.
65. DISTRIBUTED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Components of Distributed System –
Node (Computer, Mobile, etc.)
Communication link (Cables, Wi-Fi, etc.)
Architecture of Distributed System –
peer-to-peer – all nodes are peer of each other and work towards a
common goal
client-server – some nodes are become server nodes for the role of
coordinator, arbiter, etc.
n-tier architecture – different parts of an application are distributed in
different nodes of the systems and these nodes work together to
function as an application for the user/client
66. DISTRIBUTED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Limitations of Distributed System –
Difficult to design and debug algorithms for the system.
These algorithms are difficult because of the absence of a common
clock; so no temporal ordering of commands/logs can take place.
Nodes can have different latencies which have to be kept in mind
while designing such algorithms.
The complexity increases with increase in number of nodes.
No common clock causes difficulty in the temporal ordering of
events/transactions
Difficult for a node to get the global view of the system and hence
take informed decisions based on the state of other nodes in the
system
67. DISTRIBUTED SYSTEMS
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Scaling –
Horizontal and vertical scaling is possible.
Applications of Distributed System –
Cluster computing – a technique in which many computers are
coupled together to work so that they achieve global goals. The
computer cluster acts as if they were a single computer
Grid computing – All the resources are pooled together for sharing in
this kind of computing turning the systems into a powerful
supercomputer; essentially.
Organisations Using –
Apple, Google, Facebook.
68. Advantages of Distributed Systems over
Centralized Systems:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Economics:
Microprocessors offer a better price/performance than mainframes
Speed:
A distributed system may have more total computing power than a
mainframe
Inherent distribution:
Some applications involve spatially separated machines
Reliability:
If one machine crashes, the system as a whole can still survive
Incremental growth:
Computing power can be added in small increments
69. Advantages of Distributed Systems over
Centralized Systems:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. Speed. When used to implement parallel processing where only
goal is to achieve maximum speed on a single problem, distributed
systems can achieve very high speed as compared to the centralized
ones.
2. Inherent Distribution- Another reason for building a distributed
system is that some applications are inherently distributed.
Banking, Airline reservation etc. are examples of the applications that
are inherently distribute .
When all the branches of a bank are connected, we have a commercial
distributed system.
3. Reliability- Another potential advantage of a distributed system
over a centralized one is higher reliability.
70. Advantages of Distributed Systems over
Centralized Systems:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
By distributing the workload over many machines, a single chip
failure will bring down at most one machine, leaving the rest intact.
Ideally, if 5 percent of the machines are down at any moment, the
system should be able to continue to work with a 5 percent loss in
performance.
For critical applications, such as control of nuclear reactors or aircraft,
using a distributed system to achieve high reliability may be a
dominant consideration
4. Incremental Growth: Finally, incremental growth is also
potentially a big plus.
Often a company will buy a mainframe with the intention of doing all
its work on it.
71. Advantages of Distributed Systems over
Centralized Systems:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
If the company prospers and the workload grows, at a certain point
the mainframe will no longer be adequate.
The only solutions are to either replace the mainframe with a larger
one (if it exists), or add a second mainframe.
Both of these can cause management difficulties with the company’s
operations.
In contrast, with a distributed system, it may be possible to simply add
more processors to the system, thus allowing it to expand gradually as
the need arises.
72. Advantages of Distributed Systems over Isolated
Computers:
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Data sharing:
Allow many users access to a common data base
Device sharing
Allow many users to share expensive peripherals like color printers
Communication
Make human to human communication easier, for example, by
electronic mail
Flexibility
Spread the workload over the available machines in the most cost
effective way
73. Advantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. Cost Effective
Although distributed systems consists of high implementation costs,
they are cost effective in the long run.
Compared to a mainframe computer, where a single system is
composed of several processors, the distributed system is made up of
several computers together.
This type of infrastructure is far more cost effective than a mainframe
system.
2. Efficiency
Distributed systems are made to be efficient in every aspect since they
posses multiple computers.
Each of these computers could work independently to solve problems.
74. Advantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
This not only considered to be efficient, it significantly saves time of
the user.
3. Scalability
Distributed systems are made on default to be scalable.
Whenever there is an increase in workload, users can add more
workstations.
There is no need to upgrade a single system.
Moreover, no any restrictions are placed on the number of machines.
Which means that, these machines will be able to handle high demand
workload easily.
75. Advantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
4. Reliability
The distributed systems are far more reliable than single systems in
terms of failures.
Even in the case of a single node malfunctioning, it does not pose
problems to the remaining servers.
Other nodes can continue to function fine.
5. Latency
Distributed systems results on low latency.
If a particular node is located closer to the user, the distributed system
makes sure that the system receives traffic from that node.
Thus, the user could notice much less time it takes to serve them.
76. Disadvantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. Startup Cost
Compared to a single system, the implementation cost of a distributed
system is significantly higher.
The infrastructure used in a distributed system makes it expensive.
In addition to that, constant transmission of information and
processing overhead further increases the cost.
2. Security
Distributed systems always comes with security risks since it contains
open system characteristics.
The data of the user is stored in different workstations.
Thus, the user needs to make sure that their data is secured in each of
these computers.
77. Disadvantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Moreover, unlike in a centralized computing system, it is not an easy
task to manage data access in a distributed system.
3. Complexity
The difficulty involved in implementation, maintenance and
troubleshooting makes distributed system a complex strategy.
Besides hardware complexity, distributed system posses difficulty in
software too.
The software used in distributed system needs to be well attentive
when handling communication and security.
4. Overheads
Overheading is a common problem faced by a distributed system.
This happens when all the workstations try to operate at once.
78. Disadvantages of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Even though this essentially brings desired results, eventually there
will be an increase in computing time.
This ultimately impacts the system's response time.
5. Network Errors
Distributed systems are prone to network errors which results in
communication breakdown.
The information may fail to be delivered or not in the correct
sequence.
And also, troubleshooting errors is a difficult task since the data is
distributed across various nodes.
79. Limitation of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Distributed System is a collection of self-governing computer systems
efficient of transmission and cooperation among each other by the
means of interconnections between their hardware and software.
It is a collection of loosely coupled processor that appears to its users
a single systematic system.
Distributed systems has various limitations such as in distributed
system there is not any presence of a global state.
This differentiates distributed system computing from databases in
which a steady global state is maintained.
Distributed system limitations has the impact on both design and
implementation of distributed systems.
80. Limitation of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
There are mainly two limitations of the distributed system which are
as following:
1. Absence of a Global Clock
2. Absence of Shared Memory
1. Absence of a Global Clock:
In a distributed system there are a lot of systems and each system has
its own clock.
Each clock on each system is running at a different rate or granularity
leading to them asynchronous.
In starting the clocks are regulated to keep them consistent, but only
after one local clock cycle they are out of the synchronization and no
clock has the exact time.
81. Limitation of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Time is known for a certain precision because it is used for the following in
distributed system:
Temporal ordering of events
Collecting up-to-date information on the state of the integrated system
Scheduling of processes
There are restrictions on the precision of time by which processes in a
distributed system can synchronize their clocks due to asynchronous message
passing.
Every clock in distributed system is synchronize with a more reliable clock,
but due to transmission and execution time lapses the clocks becomes
different.
Absence of global clock make more difficult the algorithm for designing and
debugging of distributed system.
82. Limitation of Distributed System
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
2. Absence of Shared Memory:
Distributed systems have not any physically shared memory, all computers in
the distributed system have their own specific physical memory.
As computer in the distributed system do not share the common memory, it is
impossible for any one system to know the global state of the full distributed
system.
Process in the distributed system obtains coherent view of the system but in
actual that view is partial view of the system.
As in distributed system there is an absence of a global state, it is challenging
to recognize any global property of the system.
The global state in distributed system is divided by many number of
computers into smaller entities.
83. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
INTRODUCTION TO SYSTEM MODELS
Systems that are intended for use in real-world environments should be
designed to function correctly in the widest possible range of circumstances
and in the face of many possible difficulties and threats .
Distributed System Models is as follows:
1. Architectural Models
2. Fundamental Models
(i) Interaction Models
(ii) Failure Models
(iii) Security Models
Each type of model is intended to provide an abstract, simplified but
consistent description of a relevant aspect of distributed system design:
84. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
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.
Architectural models describe a system in terms of the computational and
communication tasks performed by its computational elements; the computational
elements being individual computers or aggregates of them supported by
appropriate network interconnections.
Fundamental models take an abstract perspective in order to examine individual
aspects of a distributed system. The fundamental models that examine three
important aspects of distributed systems: interaction models, which consider the
structure and sequencing of the communication between the elements of the
system; failure models, which consider the ways in which a system may fail to
operate correctly and; security models, which consider how the system is
protected against attempts to interfere with its correct operation or to steal its data.
85. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Software layers:
The concept of layering is a familiar one and is closely related to
abstraction.
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.
86. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
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.
For example, a network time service is implemented on the Internet
based on the Network Time Protocol (NTP) by server processes
running on hosts throughout the Internet that supply the current time
to any client that requests it and adjust their version of the current
time as a result of interactions with each other.
Given the complexity of distributed systems, it is often helpful to
organize such services into layers. the important terms platform and
middleware
87. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
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.
– Remote Procedure Calls – Client programs call procedures in server programs
– Remote Method Invocation – Objects invoke methods of objects on distributed
hosts
– Event-based Programming Model – Objects receive notice of events in other
objects in which they have interest
88. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Middleware: software that allows a level of programming beyond
processes and message passing.
Uses protocols based on messages between processes to provide its
higher-level abstractions such as remote invocation and events
Supports location transparency
Usually uses an interface definition language (IDL) to define
interfaces
90. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Interfaces in Programming Languages
Current PL allow programs to be developed as a set of modules that
communicate with each other. Permitted interact ions between
modules are defined by interfaces.
A specified interface can be implemented by different modules
without the need to modify other modules using the interface.
Interfaces in Distributed Systems
A service interface allows a client to request and a server to provide
particular services.
A remote interface allows objects to be passed as arguments to and
results from distributed modules.
91. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. Architectural Models
Architectural model describes responsibilities distributed between
system components and how are these components placed.
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. A server can itself request services from other
servers; thus, in this new relation, the server itself acts like a client.
92. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
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.
93. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
b)Peer-to-peer
All processes (objects) play similar role.
Processes (objects) interact without 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.
It distributes shared resources widely share computing and
communication loads.
94. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Problems with peer-to-peer:
High complexity due to
Cleverly place individual objects, retrieve the objects
maintain potentially large number of replicas.
95. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Variations of the Basic Models
Client-server and peer-to-peer can be considered as basic models.
Several variations have been proposed, with considering factors such
as:
- multiple servers and caches
- mobile code and mobile agents
- mobile devices
96. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Proxy Server
A proxy server provides copies (replications) of resources which are
managed by other servers.
Proxy servers are typically used as caches for web resources.
They maintain a cache of recently visited web pages or other
resources.
When a request is issued by a client, the proxy server is first
checked, if the requested object (information item) is available there.
Proxy servers can be located at each client, or can be shared by
several clients.
The purpose is to increase performance and availability, by avoiding
frequent accesses to remote servers.
98. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Mobile Code
Mobile code: code sent from one computer to another and run at the
destination.
Advantage: remote invocations are replaced by local ones.
Typical example: Java applets.
Applets are a well-known and widely used example of mobile code –
the user running a browser selects a link to an applet whose code is
stored on a web server; the code is downloaded to the browser and
runs there, as shown in Figure.
An advantage of running the downloaded code locally is that it can
give good interactive response since it does not suffer from the
delays or variability of bandwidth associated with network
communication.
100. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Mobile agent:
a running program that travels from one computer to another
carrying out a task on someone’s behalf.
A mobile agent is a complete program, code + data, that can work
(relatively) independently.
The mobile agent can invoke local resources/data.
Typical tasks:
Collect information
Install/maintain software on computers
Compare prizes from various vendors bay visiting their sites.
Attention: potential security risk (like mobile code)!
101. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
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
102. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Fundamental Models
A model contains only the essential ingredients needed to understand
and reason about some aspects of a system’s behavior.
A system model has to address the following:
What are the main entities in the system?
How do they interact?
What are the characteristics that affect their individual and collective
behavior?
103. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Purpose
Make explicit all the relevant assumptions about the system we are
modeling
Make generalizations concerning what is possible or impossible,
given those assumptions.
General purpose algorithms
Desirable properties
Interaction
Communication takes place with delays
Maintaining the same notion of time across all nodes of a distributed
system is difficult.
Failure
104. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
2.Interaction Model
The behavior and state of distributed systems can be described by a
distributed algorithm.
A definition of the steps to be taken by each of the processes,
including the transmission of messages between them.
Messages are transmitted to transfer information between processes
and to coordinate their activity.
The computing rates of processes and the timing of the transmission
of messages cannot in general be predicted.
Each process has its own state, consisting of the set of data that it can
access and update (i.e., its local variables).
105. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Performance of Communication Channel
The communication channels in our model are realized in a variety of
ways in distributed systems –
for example, by an implementation of streams or by simple message
passing over a computer network. Communication over a computer
network has the following performance characteristics relating to
latency, bandwidth and jitter:
The delay between the start of a message’s transmission from one
process and the beginning of its receipt by another is referred to as
latency.
The latency includes: – The time taken for the first of a string of bits
transmitted through a network to reach its destination.
106. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
For example, the latency for the transmission of a message through a
satellite link is the time for a radio signal to travel to the satellite and
back.
The delay in accessing the network, which increases significantly
when the network is heavily loaded.
For example, for Ethernet transmission the sending station waits for
the network to be free of traffic.
The time taken by the operating system communication services at
both the sending and the receiving processes, which varies according
to the current load on the operating systems.
107. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The bandwidth of a computer network is the total amount of
information that can be transmitted over it in a given time.
When a large number of communication channels are using the same
network, they have to share the available bandwidth.
Jitter is the variation in the time taken to deliver a series of messages.
Jitter is relevant to multimedia data.
For example, if consecutive samples of audio data are played with
differing time intervals, the sound will be badly distorted.
108. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Computer Clocks and Timing Events:
Local clocks
Clock drifts from perfect time and their drift rates differ from one
another
Clock Drift Rate:
the relative amount that a computer clock differs from a perfect
reference clock.
Even if clocks are set at the same time initially, they would
eventually vary unless corrections are applied periodically.
109. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Two variants of the interaction model
In a distributed system it is hard to set limits on the time that can be
taken for process 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:
(i)Synchronous distributed systems: Hadzilacos and Toueg [1994]
define a synchronous distributed system to be one in which the
following bounds are defined:
The time to execute each step of a process has known lower and
upper bounds.
Each message transmitted over a channel is received within a known
bounded time.
•
110. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Each process has a local clock whose drift rate from real time has a
known bound.
(ii)Asynchronous distributed systems:
Many distributed systems, such as the Internet, are very useful
without being able to qualify as synchronous systems.
Therefore we need an alternative model.
An asynchronous distributed system is one in which there are no
bounds on:
Process execution speeds – for example, one process step may take
only a picosecond and another a century; all that can be said is that
each step may take an arbitrarily long time.
111. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Message transmission delays – for example, one message from
process A to process B may be delivered in negligible time and
another may take several years.
In other words, a message may be received after an arbitrarily long
time.
Clock drift rates – again, the drift rate of a clock is arbitrary.
The asynchronous model allows no assumptions about the time
intervals involved in any execution.
This exactly models the Internet, in which there is no intrinsic bound
on server or network load and therefore on how long it takes, for
example, to transfer a file using FTP.
Sometimes an email message can take days to arrive.
112. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
But some design problems can be solved even with these
assumptions.
For example, although the Web cannot always provide a particular
response within a reasonable time limit, browsers have been designed
to allow users to do other things while they are waiting.
Any solution that is valid for an asynchronous distributed system is
also valid for a synchronous one.
Actual distributed systems are very often asynchronous because of
the need for processes to share the processors and for communication
channels to share the network.
114. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Event ordering
as we will see later, in a distributed system it is impossible for any
process to have a view on the current global state of the system
possible to record timing information locally, and abstract from real
time (logical clocks)
event ordering rules
if e1 and e2 happen in the same process, and e2 happens after e1,
then e1 → e2.
if e1 is the sending of a message m and e2 is the receiving of the
same message m, then e1 → e2.
hence, → describes a partial ordering relation on the set of events in
the distributed system.
115. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
3. Failure Model
In a distributed system both processes and communication channels
may fail – that is, they may depart from what is considered to be
correct or desirable behaviour.
The failure model defines the ways in which failure may occur in
order to provide an understanding of the effects of failures.
Omission failures:
The faults classified as omission failures refer to cases when a
process or communication channel fails to perform actions that it is
supposed to do.
116. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Process omission failures:
The chief omission failure of a process is to crash. 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.
The design of services that can survive in the presence of faults can
be simplified if it can be assumed that the services on which they
depend crash cleanly – that is, their processes either function
correctly or else stop.
Other processes may be able to detect such a crash by the fact that the
process repeatedly fails to respond to invocation messages.
However, this method of crash detection relies on the use of timeouts
– that is, a method in which one process allows a fixed period of time
for something to occur.
117. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
In an asynchronous system a timeout can indicate only that a process
is not responding – it may have crashed or may be slow, or the
messages may not have arrived.
A process crash is called fail-stop if other processes can detect
certainly that the process has crashed.
Fail-stop behavior can be produced in a synchronous system if the
processes use timeouts to detect when other processes fail to respond
and messages are guaranteed to be delivered.
For example, if processes p and q are programmed for q to reply to a
message from p, and if process p has received no reply from process
q in a maximum time measured on p’s local clock, then process p
may conclude that process q has failed.
118. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Communication omission failures:
Consider the communication primitives send and receive.
A process p performs a send by inserting the message m in its
outgoing message buffer.
The communication channel transports m to q’s incoming message
buffer.
Process q performs a receive by taking m from its incoming message
buffer and delivering it (see Figure 2.14).
The outgoing and incoming message buffers are typically provided
by the operating system.
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.
120. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Arbitrary failures:
The term arbitrary or Byzantine failure is used to describe the worst
possible failure semantics, in which any type of error may occur.
For example, a process may set wrong values in its data items, or it
may return a wrong value in response to an invocation.
An arbitrary failure of a process is one in which it arbitrarily omits
intended processing steps or takes unintended processing steps.
Arbitrary failures in processes cannot be detected by seeing whether
the process responds to invocations, because it might arbitrarily omit
to reply.
Communication channels can suffer from arbitrary failures;
121. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
for example, message contents may be corrupted, nonexistent
messages may be delivered or real messages may be delivered more
than once.
Arbitrary failures of communication channels are rare because the
communication software is able to recognize them and reject the
faulty messages.
For example, checksums are used to detect corrupted messages, and
message sequence numbers can be used to detect nonexistent and
duplicated messages.
123. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Timing failures
Timing failures are applicable in synchronous distributed systems
where time limits are set on process execution time, message delivery
time and clock drift rate.
In an asynchronous distributed system, an overloaded server may
respond too slowly, but we cannot say that it has a timing failure
since no guarantee has been offered.
Real-time operating systems are designed with a view to providing
timing guarantees, but they are more complex to design and may
require redundant hardware.
Most general-purpose operating systems such as UNIX do not have
to meet real-time constraints.
124. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Timing is particularly relevant to multimedia computers with audio
and video channels.
Video information can require a very large amount of data to be
transferred.
Delivering such information without timing failures can make very
special demands on both the operating system and the
communication system.
125. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Masking failures
Each component in a distributed system is generally constructed from
a collection of other components.
It is possible to construct reliable services from components that
exhibit failures.
For example, multiple servers that hold replicas of data can continue
to provide a service when one of them crashes.
A knowledge of the failure characteristics of a component can enable
a new service to be designed to mask the failure of the components
on which it depends.
A service masks a failure either by hiding it altogether or by
converting it into a more acceptable type of failure.
126. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Security model
we described their architecture in terms of processes, potentially
encapsulating higher-level abstractions such as objects, components
orservices, and providing access to them through interactions with
other processes.
Protection is described in terms of objects, although the concepts
apply equally well to resources of all types.
1. Protecting objects:
Figure shows a server that 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.
127. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The server carries out the operation specified in each invocation and
sends the result to the client.
Objects are intended to be used in different ways by different users.
For example, some objects may hold a user’s private data, such as
their mailbox, and other objects may hold shared data such as web
pages.
To support this, access rights specify who is allowed to perform the
operations of an object –
for example, who is allowed to read or to write its state.
Thus we must include users in our model as the beneficiaries of
access rights.
129. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
We do so by associating with each invocation and each result the
authority on which it is issued. Such an authority is called a principal.
A principal may be a user or a process.
In our illustration, the invocation comes from a user and the result
from a server.
The server is responsible for verifying the identity of the principal
behind each invocation and checking that they have sufficient access
rights to perform the requested operation on the particular object
invoked, rejecting those that do not.
The client may check the identity of the principal behind the server to
ensure that the result comes from the required server.
130. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Securing processes and their interactions:
Processes interact by sending messages.
The messages are exposed to attack because the network and the
communication service that they use are open, to enable any pair of
processes to interact.
Distributed systems are often deployed and used in tasks that are
likely to be subject to external attacks by hostile users.
This is especially true for applications that handle financial
transactions, confidential or classified information or any other
information whose secrecy or integrity is crucial.
Integrity is threatened by security violations as well as
communication failures.
131. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The enemy:
To model security threats, we postulate an enemy (sometimes also
known as the adversary) that is capable of sending any message to
any process and reading or copying any message sent between a pair
of processes, as shown in Figure.
Such attacks can be made simply by using a computer connected to a
network to run a program that reads network messages addressed to
other computers on the network, or a program that generates
messages that make false requests to services, purporting to come
from authorized users.
The attack may come from a computer that is legitimately connected
to the network or from one that is connected in an unauthorized
manner.
132. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Threats to communication channels: An enemy can copy, alter or
inject messages as they travel across the network and its intervening
gateways.
Such attacks present a threat to the privacy and integrity of
information as it travels over the network and to the integrity of the
system.
For example, a result message containing a user’s mail item might be
revealed to another user or it might be altered to say something quite
different.
Another form of attack is the attempt to save copies of messages and
to replay them at a later time, making it possible to reuse the same
message over and over again.
133. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
For example, someone could benefit by resending an invocation
message requesting a transfer of a sum of money from one bank
account to another.
All these threats can be defeated by the use of secure channels, based
on cryptography and authentication.
Cryptography is the science of keeping messages secure, and
encryption is the process of scrambling a message in such a way as to
hide its contents.
Modern cryptography is based on encryption algorithms that use
secret keys
– large numbers that are difficult to guess
– to transform data in a manner that can only be reversed with
knowledge of the corresponding decryption key.
134. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Other possible threats from an enemy
It introduced very briefly two further security threats
– denial of service attacks and
the deployment of mobile code.
(i) Denial of service:
This is a form of attack in which the enemy interferes with the
activities of authorized users by making excessive and pointless
invocations on services or message transmissions in a network,
resulting in overloading of physical resources (network bandwidth,
server processing capacity).
Such attacks are usually made with the intention of delaying or
preventing actions by other users.
135. Distributed System Models
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
For example, the operation of electronic door locks in a building
might be disabled by an attack that saturates the computer controlling
the electronic locks with invalid requests.
(ii) Mobile code:
Mobile code raises new and interesting security problems for any
process that receives and executes program code from elsewhere,
code may easily play a Trojan horse role, purporting to fulfil an
innocent purpose but in fact including code that accesses or modifies
resources that are legitimately available to the host process but not to
the originator of the code.
requires executability privileges on target machine
code may be malicious (e.g., mail worms)
136. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Client-server model
The Client-server model is a distributed application structure that
partitions task or workload between the providers of a resource or
service, called servers, and service requesters called clients.
In the client-server architecture, when the client computer sends a
request for data to the server through the internet, the server accepts
the requested process and deliver the data packets requested back to
the client.
Clients do not share any of their resources.
Examples of Client-Server Model are Email, World Wide Web, etc.
137. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
How the Client-Server Model works ?
Client: When we talk the word Client, it mean to talk of a person or
an organization using a particular service.
Similarly in the digital world a Client is a computer (Host) i.e.
capable of receiving information or using a particular service from
the service providers (Servers).
Servers: Similarly, when we talk the word Servers, It mean a person
or medium that serves something.
Similarly in this digital world a Server is a remote computer which
provides information (data) or access to particular services.
So, its basically the Client requesting something and the Server
serving it as long as its present in the database.
139. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
How the browser interacts with the servers ?
There are few steps to follow to interacts with the servers a client.
User enters the URL(Uniform Resource Locator) of the website or
file.
The Browser then requests the DNS(DOMAIN NAME SYSTEM)
Server.
DNS Server lookup for the address of the WEB Server.
DNS Server responds with the IP address of the WEB Server.
Browser sends over an HTTP/HTTPS request to WEB Server’s IP
(provided by DNS server).
Server sends over the necessary files of the website.
140. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Browser then renders the files and the website is displayed.
This rendering is done with the help of DOM (Document Object
Model) interpreter, CSS interpreter and JS Engine collectively known
as the JIT or (Just in Time) Compilers.
141. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Clients and servers exchange messages in a request response
messaging pattern.
The client sends a request, and the server returns a response.
This exchange of messages is an example of inter-process
communication.
To communicate, the computers must have a common language, and
they must follow rules so that both the client and the server know
what to expect.
The language and rules of communication are defined in a
communication.
All client-server protocols operate in the application layer. The
application-layer protocol defines the basic patterns of the dialogue.
143. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
To formalize the data exchange even further, the server may
implement an API(such as a web service).
The API is an abstraction layer for such resources as databases and
custom software.
By restricting communication to a specific content format. By
abstracting access, it facilitate cross platform data exchange.
A server may receive requests from many different clients in a very
short period of time.
Because the computer can perform a limited number of tasks at any
moment, it relies on a scheduling system to prioritize incoming
requests from clients in order to accommodate them all in turn.
Structure : Group of servers offering service to clients
144. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Based on request/response paradigm
Techniques : Socket, RPC, RMI(Remote method invocation)
Client–server model of computing is a distributed application
structure that partitions tasks or workloads between service providers,
called servers, and service requesters, called clients.
Often clients and servers communicate over a computer network on
separate hardware, but both client and server may reside in the same
system. A server machine is a host that is running one or more server
programs which share its resources with clients.
A client does not share any of its resources, but requests a server's
content or service function.
Clients therefore initiate communication sessions with servers which
await (listen for) incoming requests.
145. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Example:-
When a bank customer accesses online banking services with a web browser
(the client), the client initiates a request to the bank's web server. The
customer’s login credentials may be stored in a database, and the web server
accesses the database server as a client.
An application server interprets the returned data by applying the bank’s
business logic, and provides the output to the web server. Finally, the web
server returns the result to the client web browser for display.
In each step of this sequence of client–server message exchanges, a
computer processes a request and returns data. This is the request-response
messaging pattern.
When all the requests are met, the sequence is complete and the web
browser presents the data to the customer.
146. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
There are three main methods to client/server communication.
1. Sockets
2. RPC
3. Pipes
1. Sockets:
Sockets facilitate communication between two processes on the same
machine or different machines.
They are used in a client/server framework and consist of the IP address and
port number.
Many application protocols use sockets for data connection and data transfer
between a client and a server.
147. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Socket communication is quite low-level as sockets only transfer an
unstructured byte stream across processes.
The structure on the byte stream is imposed by the client and server
applications.
A diagram that illustrates sockets is as follows −
148. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
(2) Remote Procedure Calls:
These are interprocess communication techniques that are used for client-
server based applications.
A remote procedure call is also known as a subroutine call or a function call.
A client has a request that the RPC translates and sends to the server. This
request may be a procedure or a function call to a remote server.
When the server receives the request, it sends the required response back to
the client.
A diagram that illustrates remote procedure calls is given as follows −
150. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
(3) Pipes
These are interprocess communication methods that contain two end points.
Data is entered from one end of the pipe by a process and consumed from
the other end by the other process.
The two different types of pipes are ordinary pipes and named pipes.
Ordinary pipes only allow one way communication.
For two way communication, two pipes are required.
Ordinary pipes have a parent child relationship between the processes as the
pipes can only be accessed by processes that created or inherited them.
Named pipes are more powerful than ordinary pipes and allow two way
communication.
151. Client Server Communication
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
These pipes exist even after the processes using them have terminated.
They need to be explicitly deleted when not required anymore.
A diagram that demonstrates pipes are given as follows −
152. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
A vendor-independent distributed computing environment, DCE was
defined by the Open Software Foundation (OSF), a consortium of
computer manufacturers, including IBM, DEC, and Hewlett-Packard.
It is not an operating system, nor is it an application.
Rather, it is an integrated set of services and tools that can be
installed as a coherent environment on top of existing operating
systems and serve as a platform for building and running distributed
applications.
A primary goal of DCE is vendor independence.
It runs on many different kinds of computers, operating systems, and
networks produced by different vendors.
153. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
For example, some operating systems to which DCE can be easily
ported include OSF/I, AIX, DOMAIN OS, ULTRIX, HP-UX,
SINIX, SunOS, UNIX System V, VMS, WINDOWS, and OS/2.
On the other hand, it can be used with any network hardware and
transport software, including TCPIIP, X.25, as well as other similar
products.
As shown in Figure 1.7, DCE is a middleware software layered
between the DCE applications layer and the operating system and
networking layer.
154. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The basic idea is to take a collection of existing machines (possibly
from different vendors), interconnect them by a communication
network, add the DCE software platform on top of the native
operating systems of the machines, and then be able to build and run
distributed applications.
Each machine has its own local operating system, which may be
different from that of other machines.
The DCE software layer on top of the operating system and
networking layer hides the differences between machines by
automatically performing data-type conversions when necessary.
Therefore, the heterogeneous nature of the system is transparent to
the applications programmers, making their job of writing distributed
applications much simpler.
155. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Goals of DCE:
It should run on different computers, operating systems and networks
in a distributed system.
It should provide a coherent seamless platform for distributed
applications.
It should provide a mechanism for clock synchronization on different
machines.
It should provide tools which make it easier to write distributed
applications where multiple users at multiple locations can work
together.
Provide extensive tools for authentication authorization.
156. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
DCE Components:
1. Threads package:- It provides a simple programming model for
building concurrent applications.
It includes operations to create and control multiple threads of
execution in a single process and to synchronize access to global data
within an application.
2. Remote Procedure Call (RPC)facility. It provides programmers
with a number of powerful tools necessary to build client-server
applications.
In fact, the DCE RPC facility is the basis for all communication in
DCE because the programming model underlying all of DCE is the
client-server model.
157. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
3. Distributed Time Service (DTS).
It closely synchronizes the clocks of all the computers in the system.
It also permits the use of time values from external time sources,
such as those of the U.S. National Institute for Standards and
Technology (NIST), to synchronize the clocks of the computers in
the system with external time.
This facility can also be used to synchronize the clocks of the
computers of one distributed environment with the clocks of the
computers of another distributed environment.
4. Name services. The name services of DCE include the Cell
Directory Service (CDS), the Global Directory Service (GDS), and
the Global Directory Agent (GDA).
158. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
These services allow resources such as servers, files, devices, and so
on, to be uniquely named and accessed in a location-transparent
manner.
5. Security Service.
It provides the tools needed for authentication and authorization to
protect system resources against illegitimate access.
6. Distributed File Service (DFS).
It provides a systemwide file system that has such characteristics as
location transparency, high performance, and high availability.
A unique feature of DCE DFS is that it can also provide file services
to clients of other file systems.
159. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
The DCE components listed above are tightly integrated. It is
difficult to give a pictorial representation of their interdependencies
because they are recursive.
For example, the name services use RPC facility for internal
communication among its various servers, but the RPC facility uses
the name services to locate the destination.
Therefore, the interdependencies of the various DeE components can
be best depicted in tabular form, as shown in Figure 1.8.
161. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
DCE Cells:
The DCE system is highly scalable in the sense that a system running
DCE can have thousands of computers and millions of users spread
over a worldwide geographic area.
To accommodate such large systems, DCE uses the concept of cells.
This concept helps break down a large system into smaller,
manageable units called cells.
In a DCE system, a cell is a group of users, machines, or other
resources that typically have a common purpose and share common
DCE services.
The minimum cell configuration requires a cell directory server, a
security server, a distributed time server, and one or more client
machines.
162. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
Each DCE client machine has client processes for security service,
cell directory service, distributed time service, RPC facility, and
threads facility.
A DCE client machine may also have a process for distributed file
service if a cell configuration has a DCE distributed file server.
Due to the use of the method of intersection for clock
synchronization it is recommended that each cell in a DCE system
should have at least three distributed time servers.
An important decision to be made while setting up a DCE system is
to decide the cell boundaries.
The following four factors should be taken into consideration for
making this decision.
164. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
1. Purpose.
The machines of users working on a common goa) should be put in
the same cell, as they need easy access to a common set of system
resources.
That is, users of machines in the same cell have closer interaction
with each other than with users of machines in different cells.
For example, if a company manufactures and sells various types of
products, depending on the manner in which the company functions,
either a product-oriented or a function-oriented approach may be
taken to decide cell boundaries.
165. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
In the product-oriented approach, separate cells are formed for each
product, with the users of the machines belonging to the same cell
being responsible for all types of activities (design, manufacturing,
marketing, and support services) related to one particular product.
On the other hand, in the function-oriented approach, separate cells
are formed for each type of activity, with the users belonging to the
same cell being responsible for a particular activity, such as design,
of all types of products.
2. Administration.
Each system needs an administrator to register new users in the
system and to decide their access rights to the system's resources.
166. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
To perform his or her job properly, an administrator must know the
users and the resources of the system.
Therefore, to simplify administration jobs, all the machines and their
users that are known to and manageable by an administrator should
be put in a single cell.
For example, all machines belonging to the same department of a
company or a university can belong to a single cell.
From an administration point of view, each cell has a different
administrator.
3. Security. Machines of those users who have greater trust in each
other should be put in the same cell.
That is, users of machines of a cell trust each other more than they
trust the users of machines of other cells.
167. Introduction to DCE
Mr. Sagar Pandya
sagar.pandya@medicaps.ac.in
In such a design, cell boundaries act like firewalls in the sense that
accessing a resource that belongs to another cell requires more
sophisticated authentication than accessing a resource that belongs to
a user's own cell.
4. Overhead. Several DCE operations, such as name resolution and
user authentication, incur more overhead when they are performed
between cells than when they are performed within the same cell.
Therefore, machines of users who frequently interact with each other
and the resources frequently accessed by them should be placed in
the same cell.
The need to access a resource of another cell should arise
infrequently for better overall system performance.
168. Summary
Mr. Sagar Pandya sagar.pandya@medicaps.ac.in
Distributed systems are everywhere.
Internet, intranet, wireless networks.
Resource sharing is the main motivating factor for constructing
distributed systems. The construction of distributed systems produces
many challenges like Secure communication over public networks.
Distributed computing helps improve the performance of large-scale
projects by combining the power of multiple machines.
It’s much more scalable and allows users to add computers according
to growing workload demands.
Although distributed computing has its own disadvantages, it offers
unmatched scalability, better overall performance and more
reliability, which makes it a better solution for businesses dealing
with high workloads and big data.
169. Summary
Mr. Sagar Pandya sagar.pandya@medicaps.ac.in
The operating systems commonly used for distributed computing
systems can be broadly classified into two types: network operating
systems and distributed operating systems.
As compared to a network operating system, a distributed operating
system has better transparency and fault tolerance capability and
provides the image of a virtual uniprocessor to the users.
The main issues involved in the design of a distributed operating
system are transparency, reliability, flexibility, performance,
scalability, heterogeneity, security, and emulation of existing
operating systems.