19Z603-DISTRIBUTED COMPUTING

SYLLABUS
INTRODUCTION, MESSAGE PASSING AND RPC : Definition -
System models - Design issues of distributed operating systems - Message
Passing: Features and Issues–Buffering - Process addressing - Failure handling
RPC: Model - Implementation - Stub generation - RPC Messages - Marshaling -
Server management – Call semantics (10)

SYNCHRONIZATION : Clock synchronization - Physical clocks - Logical

clocks - Election algorithms – Mutual exclusion- Deadlocks (8)

PROCESS AND RESOURCE MANAGEMENT: Process migration:

Features - Mechanism. Resource Management: Load balancing approach -
Load sharing approach (9)
CLOUD AS A DISTRIBUTED ENVIRONMENT : The Vision of
Cloud Computing - Defining a Cloud - Historical Developments -Cloud
Computing Reference Model –Cloud Deployment Models - Public, Private,
Community, Hybrid Clouds - Cloud Delivery Models - IaaS, PaaS, SaaS -
Characteristics and Benefits - Challenges. (8)

CLOUD TECHNOLOGIES : Technologies for Infrastructure as a service -

Platform as a Service– Software as a service – Cloud Storage: MapReduce, GFS,
HDFS - Cloud container: Docker. (10)
 TEXT BOOKS AND REFERENCES

TEXT BOOKS:
1. Pradeep K Sinha , "Distributed Operating Systems: Concepts and Design",
Prentice Hall of India, New Delhi, 2009.
2. Rajkumar Buyya, Christian Vecchiola, Thamarai Selvi S , "Mastering Cloud
Computing", Tata McGraw Hill Education Private Limited,, New Delhi, 2013.

REFERENCES:
1. Andrew S Tanenbaum, Marteen Van Steen , "Distributed Systems
Principles and Paradigms", Pearson Education / Prentice Hall of India, New
Delhi, 2007.
2. George Coulouris, Jean Dollimore , "Distributed Systems Concept and
Design", Pearson Education, New Delhi, 2006.
3. David S Linthicium , "Cloud Computing and SOA Convergence in your
Enterprise", Pearson, USA, 2010.
4. Sébastien Goasguen , "Docker in the Cloud -Recipes for AWS, Azure,
Google, and More", O‘Reilly Media, USA, 2016.
 COURSE OUTCOMES

CO1: Depict the issues, models of distributed systems

and Describe message passing and develop RPC based
client-server programs
CO2:Analyze and apply synchronization, deadlock
management techniques
CO3:Paraphrase, apply process management and
resource management in distributed systems
CO4:Understand the concepts, key technologies and
strengths of cloud computing
CO5: Explore different cloud programming tools and
technologies and deploy cloud based application
Computer Architecture

Multiprocessors
1. Tightly Coupled

Systems(Parallel
Processing Systems)
Single System Memory
Shared by all Processors
Small and
CPU CPU limited
CPU MEMORY

bandwidth

INTERCONNECTION HARDWARE
Computer Architecture

2. Loosely Coupled
Systems(Distributed Computing
Systems)
Processors
and have their own local
communicate
memorythem
between
Expandable and
Unlimited no of
processor
 Distributed Computing System

— A of int
processors connected er
communicat
collection
by a
network ion
inwhicheach
processorhas
its own memory and
local
peripherals other and
communication between any
two processors of the system
takes place by message
passing over the
communication network
Evolution of Distributed
Computing Systems
Early Computers
Job SetUp Time
Batch Processing
Multiprogramming
Multiple user can access
Time Sharing (resource share and
access from different place)
Mini Computers
Workstation
MicroProcessors
LANs/WANs
Merging of Computers and
Networking-
Distributed Computing Systems(1970s)
Distributed Computing
System Models
Distributed Computing
Systems

Mini Computer

Work Station
Work Station-Server
Processor Pool
Hybrid
Mini Computer Model
Mini Computer Model

Different databases on
different remote machines
Extension of time sharing
systems
Multiple users simultaneous
login
Exam
ple
ARPA
NET
Work Station Model
Work Station Model
—Idle workstation in big
campus
Issues
Finding idle ws
How to transfer job
Suppose if it starts working?
Allow remote process to share
the resources of the
workstation along with its own
logged on users processes.
Kill the remote process
Migrate remote process back to
its home workstation
Work Station Server Model
 Work-Station Server Model
- Consists of few minicomputers and several
workstations interconnected by a communication
network.

Diskful workstations-Work station model is a

Network of personal workstations, each with its own disk
and a local file system
Diskless workstations
Cheaper-few minicomputers equipped with large, fast
disks that are accessed over the network
Diskless Workstation are preferred-Backup and H/W
maintenance are easier
No process migration needed
Request Response protocol is used to access the
services of the server machines
Processor Pool Model
Termin
als
Processor Pool Model
Most of the time user does not need
computing power but
once in a while user needs a very
large amount of computing power
for a short time.
In workstation server model, processor is
allocated to each user but in Processor
poor model
Processors are gathered-Users share
whenever needed
Terminals are diskless workstations
Run Server- Special server manages and
allocated the processors in the pool to
different users on a demand basis
 Processor Pool Model

As compared to workstation -server

model , Processor Pool Model
Allows Better utilization of processors
Provides Greater Flexibility- System
services can be easily expanded without
the need to install any more computers
Considered to be unsuitable for high
performance interactive applications –
especially those using graphics or
window systems
- due to slow speed of communication
between the computer on which the
application program is executed and the
Hybrid Model
Out of the four models WS-Server
model is widely used for building
distributed computing systems
Because Suitable for interactive jobs

Processor-pool model is suitable for

Massive applications which need
computations
Hybrid model is based on the WS-
Server model but with the addition
of a pool of processors
Processors in the pool can be
allocated dynamically for
Hybrid Model

Process Ws-
or pool server
model model
Hybrid
model
What is a Distributed OS?

o
s

Net Distri
wor bute
k d
Differences
A network operating system is made up of software and
associated protocols that allow a set of computer network to be
used together.
A distributed operating system is an ordinary centralized
operating system but runs on multiple independent CPUs.
Differences
 ISSUES IN DESIGNING
DISTRIBUTED
OS
Differences in the complexity of the
Design between traditional system and
Distributed system
Centralized Os-User can request status
information and it is available
Distributed OS- cannot
about the system have
and not Complete
available to the
information
user.
Centralized Os- Resources
are nearer Distributed Os-
Far away
Centralized Os- Common Clock
Distributed OS- No Common clock, Lack
ISSUES

Transpare
ncy
Reliability
Flexibility
Performan
ce
Scalability
Heteroge
ISSUES IN
DESIGNING
DISTRIBUTED
A lot of OS
issues But
flexible,
efficien
t,
reliable
,
secure,
 Transparency
} Single Virtual Uniprocessor image
} Eight forms of transparency - ISO
1992 Reference Model for Open
Distributed Processing
Access transparency
Location transparency,
Replication transparency,
Failure transparency,
Migration transparency
Concurrency transparency,
Performance transparency, and
Scaling transparency
 Transparency
} Access transparency
} User should not be able to
recognize a resource as local or
remote
Remote resources in the same
way as local
Uniform system calls
Suitable for limited types of
application due to its
Performance limitations
 Transpare
ncy
Name
Transparency
Locatio
n
Transpare User
ncy
Mobili
ty
Transparency

Name Transparency
Name of resource does not reveal
physical location of the resource
Movement of files need not change
the names
Resource names are unique
User Mobility
Same resources from different
locations are accessed with
same name.
Users access to resources without any
extra effort
Transpare
ncy
—Replication Transparency
Creating Replicas of files and
resources on different nodes of
distributed systems –Better
performance and reliability
Should be transparent to users
Issues
Naming of replicas (name of replica
should be mapped to user supplied
name by the system)
Replication control (No.of copies?
When to create? Where to place?)
 Transparency
} Failure Transparency
Masking from users- partial failure in
the system
DOS will continue to function in
degraded form when failure occurs.
communication link failure,
a machine failure, or
storage device crash
} All types of failures cannot be
handled in a user transparent
manner.
} Theoretically possible,
Practically not justified
Transparency
Migration Transparency –
(Performance ,Reliability, Security)
Migration decisions should be automatic
Migration should not require any change
in name
If the receiver process migrates to
another location before receiving
messages from the sender , IPC should
ensure that migrated process receives
the message.
Concurrency Tranparency
Multiple user- spatially separated use the
system concurrently
Concurrent update of the same file by two
processes should not be allowed
Transparency
Access request to
Event resources -> properly
ordered
Ordering

Property
Concurren
cy
No Resource No
Deadloc sharing Starvati
k mechanis on
Propert m Propert
y
y
Mutual
Exclusion
Property
 Transparency
Performance Transparency
To allow the system to be automatically
reconfigured
Processor – Loads should be distributed(No
Idle Processors)
Processing capability should be uniformly
distributed among the available jobs
Requirement
Intelligent resource allocation and migration
facility
Scaling Transparency
To allow system to expand without disturbing
the user activities.
Requirement
 DS expected to be more
2.Reliability reliable – Due to Multiple
instances of resources

Reliabi Fault-Mechanical or
algorithmic defect
lity that may generate an
error.

Fault Fault Fault

Detection/Reco
very
Avoida Tolera
nce nce
Fault-
>Failure
Reliability
System Failure
Fail-stop –System stop functioning
after changing to the state in
which failure can be detected
Byzantine –System continues to
function but produces wrong
result.
System bugs causes this failure.
Reliability
1. Fault Avoidance
Designing the components to minimize
the occurrence of faults
Use high reliability components
The Designers of software components
has to test to make the hardware
components highly reliable .
2.Fault Tolerance
Ability of the system to function in the
event of partial system failure
Techniques to improve fault
tolerance
i. Redundancy Techniques
To avoid single point of failure -
Hardware and software components are
Reliability

How much replication is enough?

System is said to be k-fault tolerant
if it can continue to function even in
the event of the failure of k
components.
K fail stop failures – k+1 replicas
K byzantine failure - min 2k+1 replicas
(voting mechanism)
ii. Distributed Control
Distributed control mechanism is used
in name servers, scheduling algo to
avoid single points of failure.
3.Fault Detection and Recovery
Use of H/W and S/W mechanism
to determine the occurrence of failure
and then to correct system to an
acceptable state.
Techniques:
i. Atomic Transactions
Collection of operations that takes
place indivisibly in presence of failure
All operations goes to completion or
none- incase of failure data object
restore to original state if system
supports trans mechanism
Reliabil
ity
ii. Stateless Servers

Client -
server

State Statel
ful ess
Stateful Server: Depends on
history of serviced request.
Stateless Server – Crash
Recovery- Easy- No client state
info is maintained.
Reliability
iii. Acknowledgements and
time-outs based
retransmissions
Node crash/Communication link
failure-message lost

Duplicate messages are a

problem here
Detection and
handling of
Duplicate
messages
3.Flexibility
—Why DOS should be flexible?
Ease of modification - Some
parts of design needs to be
replaced/modified if bugs
detected or not suitable for
changed system
Ease of enhancement –User
should have the flexibility to add
new service or the change the
existing style.
Monolithic Kernel
KernThe important design factor is
el DesigningMicro
the kernel of the OS
Flexibility
Kernel of an OS is its central controlling
part that provides basic system facilities
with separate address space inaccessible
to user processes. User cant replace or
modify
Monolithic Kernel
All functions are provided by the kernel
Big structure
UNIX
Micro Kernel
To Keep Kernel as small as possible
OS provides minimum facilities -
Services provided is IPC -Low Device
mgmt and Mem. Management
other services are implemented as
Flexibility

Nod Nod Nod

e1 e2 en

MONOLITHIC
KERNEL
 Microkernel
Nod Nod Nod
e1 e2 en
User User User
Applicati Applicati Applicati
ons ons ons
Server / Server / Server /
Manager Manager Manager
Modules Modules Modules

Microker Microker Microker

nel nel nel

Network
Hardware
 Performance
Design principles in order to achieve Good
Performance are
1. Batch if possible

Large chunks of data- transfer instead of

small across network
Piggybacking acknowledgement (Message
Exchange)
2. Cache whenever possible
Makes data available
Saving large amount of Computing time and
bandwidth
Senders Stack to Message buffer
3.Minimize
Messagecopying
buffer data
in sender address space to
message
– Data buffer
path to send in
thekernel address space
message
From kernel to Network Interface Board
Receiving Same in reverse
Performance
4. Minimize network traffic.
migrating a process closer to the
resources
to cluster two or more
processes that frequently
communicate with each other
on the same node of the system
5. Take advantage of fine-grain
parallelism for multiprocessing
Threads-used for structuring the
server processes- Simultaneously
service requests from clients
concurrency control of
Scalability
capability of a system to adapt to
increased service load.
PRINCIPLES FOR DESIGNING SCALABLE
SYSTEMS
1. Avoiding centralized entities (such as
single file server or single database)
The failure of the centralized entity
often brings the entire system down.
Hence, the system cannot tolerate faults
Even if the centralized entity has
enough processing and storage
capacity, the capacity of the network
saturated
In a wide-area network consisting
several interconnected LAN increases
Scalability
2. Avoid centralized algorithms.
This algorithm collects information
from all nodes.
Processing info on single node and
distributing the results to rest of
the nodes- Not acceptable from a
scalable point of view.
Eg: Scheduling algo – selects
lightly loaded node -host
selection time too long.
— The complexity of the algorithm is O(n2)
It creates heavy network traffic and
quickly
consumes network
bandwidth.Therefore, in the design of
Heterogeneity

Interconnected set of dissimilar

hardware and software
Incompatibilities in heterogeneous
DS:
Communication protocols
Topologies
Servers operating at different
node of system may be different.
Pros
-Provides Flexibility – Different
computer platforms for different
applications.
Heterogeneity
We need translator which converts
each format in the system to the
format used in receiving node.
n formats – (n-1) pieces of
translation software at each node
– n(n-1) pieces of translation
software in the system.
Complex
Intermediate standard data format –
Less no. of conversions
 Security
In a centralized system, all users are
authenticated by the system at login
time.
- system can easily check whether a user
is authorized to perform the requested
operation on an accessed resource.
In a distributed system this is not
possible.
So Design should include to know
Sender of the message should know
that the message was received by the
intended receiver
Message sent by a genuine sender
The content of the message is not
MESSAGE PASSING
 Introduction

Processes communicating with each

other
Distributed operating systems
provide IPC Methods for sharing
information are
1. Original sharing, or shared-data
Messag
approach e
Sharing
2. Copy sharing,
Origina or message-passing
Copy
l
approach sharing
Sharing
Basic Methods for sharing data

Original
Sharing

Copy
sharing
Message Passing System

subsystem of a distributed
operating system
provides a set of message-
based IPC protocols.
enables processes to
communicate by exchanging
messages
simple communication
primitives, such as send and
receive.
Desirable Features of a Good
Message Passing System
Simplicity
Uniform
Semantics
Efficiency
Reliability
Correctness
Flexibility
Security
Portability
 Simplicity

Message Passing System

should be
Simple
Easy to Use
Straight forward to construct new
applications
Should be easier for the
programmers to designate
different modules of the
distributed systems to send and
receive messages
Clean and Simple Semantics of
IPC Protocols
Uniform Semantics

Local
Communic
ation

Inter
process
communica
tion
Remote
Communic
ation
 Efficiency

If MPS is not Efficient – IPC

expensive
Optimization techniques to improve
efficiency
Avoiding the costs of
establishing and terminating
connections between same
pair of processes for each
message exchange.
Minimizing the costs of
maintaining the connections
 Reliability

Ds are prone to different

catastrophic events such as node
crash or communication link
failure.
Handling of lost messages usually
involves Acknowledgments and
retransmissions on the basis of
timeouts
Detecting and handling
duplicates
Generating and assigning
Correctness
MPS has IPC protocols for group communication

Issues related to
correctness
Atomicity -are
Message sent to
every
Receivers or none
Ordered delivery - Messages
arrive at all receiver in order
acceptable to the appln
Survivability -Messages will be
Delivered correctly despite of
partial failure.
 Flexibility

Not all applications require the

same degree of reliability and
correctness of the IPC protocols.
IPC primitives should be such that
the users have the flexibility to
choose and specify the types and
levels of reliability and correctness
requirements
IPC Primitives must have the
flexibility to permit any kind of
control flow between the
cooperating processes, including
synchronous and asynchronous
send/receive.
 Security
Secure end-to-end
communication.
Message in Transit should not
be accesible to any other user
than those whom it is
addressed.
STEPS :
Authentication of the
receiver of a message by
the sender
Authentication of the
 Portability

Message
passing
system should
Portabi be portable
lity The
Use of external data
representation formats applications
Design of high level
primitive for IPC protocol written using
for MPS - To hide primitives of
heterogeneous nature of
network IPC protocol
 Issues in IPC Message Passing

Message- Block of Information

formatted by a sending process such
that its meaningful to the receiving
process

It consist of fixed length header and

a variable size collections of typed
data object
Issues in IPC Message Passing
FIXED LENGTH HEADER

For identifying lost

and duplicate
Specifies messages
whether data
to be passed
on to receiver
is included
within the
message or it
contains a
pointer to the
data.
 Issues in IPC Message Passing

Who is the sender?

Who is the receiver?
Is there One or more receivers?
Message guaranteed to have been accepted by its receivers?
Does the Sender needs to waits for reply?
Node crash? What to do?
If the receiver not ready to accept the message? Will the message
be discarded or stored in a buffer? - Buffering? (Buffer is full)
Outstanding Messages? – how to choose the order to service the
outstanding message?
These issues are addressed by the semantics of the set of
communication primitives provided by the IPC Protocol