DISTRIBUTED OPERATING SYSTEMS

UNIT 1
Evolution to Group Communication

Dr.K.Geetha
Associate Professor of Computer Science
Periyar Arts College
Cuddalore
Syllabus
 SEMESTER –III MAIN PAPER -9 DISTRIBUTED OPERATING SYSTEMS
 UNIT-I
Evolution –Models – Popularity - Distributed Operating System – Issues –
Distributed Computed Environment - Features of a Good Message Passing – Issues-
Synchronization –Buffering - – Multi data gram Messages – Encoding and Decoding of
Message Data – Process Addressing – Failure Handling – Group Communication.
 UNIT-II
The RPC Model –Transparency – Implementation – Stub – Messages –
Marshaling – Server Management –Parameter Passing Semantics – Call Semantics –
Communication protocols – Complicated – Client server Binding – Exception Handling
– Security – Special types – Heterogeneous – Light Weight – Optimization
 UNIT-III
Clock Synchronization – Event Ordering – Mutual Exclusion – Deadlock –
Election Algorithms - Process Migration – Threads.
 UNIT–IV
Meet Hadoop: Data - Data Storage and Analysis - Comparison with Other
Systems - A Brief History of Hadoop - The Apache Hadoop Project – Map Reduce: A
Weather Dataset - Analyzing the Data with UNIX Tools - Analyzing the Data with
Hadoop - Scaling Out – Hadoop Streaming - Hadoop Pipes

Dr.K.Geetha 2
Syllabus
 UNIT-V
The Configuration API - Configuring the Development Environment - Running Locally
on Test Data - Running on a Cluster - The Map Reduce Web UI - Using a Remote
Debugger - Tuning a Job - Map Reduce Workflows

 TEXT BOOKS

1. Pradeep K. Sinha, “Distributed Operating

System Concepts and Design”, PHI, New
Delhi,2007.
2. Tom White, “Hadoop: The Definitive Guide”,
Published by O’Reilly Media, Third Edition, 2009

Dr.K.Geetha 3
 Operating systems
Memory Management
◦Allocation
◦De Allocation
◦Keeping track of memory space
◦Handling free areas
◦Processor Management
Process status
Allocation
Release
Dr.K.Geetha 4
Operating Systems
Device Management
Hardware devices
Allocation
Release
Keeping track
 Information Management
◦ keeps the track of information its location.
◦ Who gets what data, when
◦ Open,read,write and close files

Dr.K.Geetha 5
Operating Systems
 Protection and Security
 Networking
 Accounting
 Error Detection
 Resource Allocation
 Sharing
 Resource Manager

Dr.K.Geetha 6
Distributed Operating System
To make it possible
 A collection of independent computers
appears to be as a single computer

Dr.K.Geetha 7
Computer Architecture
Multiprocessors
1. Tightly Coupled Systems(Parallel
Processing Systems)
◦ Single System Memory Shared by all
Processors

CPU CPU CPU MEMORY

INTERCONNECTION HARDWARE

Dr.K.Geetha 8
Computer Architecture
2. Loosely Coupled Systems(Distributed
Computing Systems)
Processors have their own local memory
and communicate between them

Dr.K.Geetha 9
Distributed Computing System
 Collection of processors interconneted
by Network
 Each processor has local memory and
peripherals
 Communicate by message passing

Dr.K.Geetha 10
Evolution of Distributed Computing
Systems
Early Computers
 Job SetUp Time
 Batch Processing
 Time Sharing
 Mini Computers
 MicroProcessors
 LANs/WANs
◦ Merging of Computers and Networking-
Distributed Computing Systems(1970s)

Dr.K.Geetha 11
Distributed Computing System
Models
Distributed Computing Systems

Mini Computer

Work Station

Work Station-Server
Processor Pool

Hybrid

Dr.K.Geetha 12
Mini Computer Model

Dr.K.Geetha 13
Mini Computer Model
 Different databases on different remote
machines
 Extension of time sharing systems
 Multiple users simultaneous login

Example
ARPANET

Dr.K.Geetha 14
Work Station Model

Dr.K.Geetha 15
 Work Station Model
 Idle workstation in big campus

 Issues
◦ Finding idle ws
◦ How to transfer job
◦ Suppose if it starts working?

Dr.K.Geetha 16
Work station model -issues
Third issue solving
Simultaneous performance
kill the remote process
migrate the remote process to home

Dr.K.Geetha 17
Work Station Server Model

Dr.K.Geetha 18
Work-Station Server Model
 Diskful workstations
 Diskless workstations
 Cheaper
 Fast
 No process migration needed
 Request Response protocol

Dr.K.Geetha 19
Processor Pool Model

Dr.K.Geetha 20
 Processor Pool Model
 Most of the time user does not need
computing power
 Processors are gathered
 Users share whenever needed
 Terminals are diskless workstations
 Better utilization of processors
 Greater Flexibility
 Unsuitable for graphics or window system
 Low speed

Dr.K.Geetha 21
 Hybrid Model
 Out of the four models WS-Server model is
popular
Because
Suitable for interactive jobs
Processor-pool model is suitable for
Massive applications which need
computations

Dr.K.Geetha 22
Hybrid Model

Processor Ws-server
pool model model

Hybrid
model
Dr.K.Geetha 23
Distributed Systems & Its Popularity
 Traditional centralized systems
 Distributed systems
DS are difficult to design and implement
 Effectively using the resources
 Security and Communication is a
problem
 Performance is network dependent

Dr.K.Geetha 24
Distributed Systems & Its Popularity
 Special softwares needed to
◦ Handle loss of messages
◦ Prevent overloading of messages
◦ Handle shared resources
◦Inherently Distributed systems
◦Air line reservation system
◦Banking systems

Dr.K.Geetha 25
Distributed Systems & Its Popularity
Information Sharing among Distributed
Users
 Efficient Person-Person Communication
 Sharing information over great distances
 Eg Proje
 Computer Supported co operative
work(CSCW) or groupware
Resource Sharing
 Sharing of S/W libraries and database

Dr.K.Geetha 26
 Distributed Systems & Its Popularity
Better Price-Performance Ratio
Important reason for popularity
Increased power
Decreased price of processors
Increasing speed of networks
Resource sharing

Dr.K.Geetha 27
Distributed Systems & Its Popularity
Shorter Response time and higher
Throughput
 Response time
 Throughput
Higher Reliability
 Degree of tolerance against errors
 Increased Availability
 But reliability comes at the cost of
performance
Dr.K.Geetha 28
Distributed Systems & Its Popularity
Extensibility and Incremental Growth
Gradually extended to include resources
Called open Distributed Systems
Better Flexibility
Combination of different types of computers
Flexible to do any task

Dr.K.Geetha 29
What is a Distributed OS?

os

Network Distributed
OS OS
Dr.K.Geetha 30
Differences
Metrics Network OS Distributed OS
System The Users are aware that Virtual Uniprocessor
Image multiple systems are used
The User knows in which Unaware of this information
machine his job is executed
User know where his Does not know
information is stored
Explicit commands for file Same Commands
transfer
Control over file placement is Automatic
manual

Dr.K.Geetha 31
Differences
Metrics Network OS Distributed OS
Autonomy Each Computer is independent Not independent
Have local OS Common OS
Degree of autonomy is high Low

Fault Little or No fault tolerance High Fault tolerance

Tolerance capability
Capability

Dr.K.Geetha 32
 ISSUES IN DESIGNING
DISTRIBUTED OS
 Differences in the complexity of the Design between
traditional system and Distributed system
 A Centralized Os can request status information and
is available
A distributed OS cannot have Complete information
about the system is not available
 Centralized Os- Resources are nearer
Distributed Os-Faraway
 Centralized Os- Common Clock
Distributed OS- No Common clock, Lack of UP to
date information

Dr.K.Geetha 33
ISSUES
Transparency
Reliability
Flexibility
Performance
Scalability
Heterogeneity
Security
Dr.K.Geetha 34
ISSUES IN DESIGNING
DISTRIBUTED OS
A lot of issues
But
 flexible,
 efficient,
 reliable,
 secure, and
 easy to use.

Dr.K.Geetha 35
 Transparency
 Single Virtual Uniprocessor image
 Eight forms of transparency
 Access transparency
 Location transparency,
 Replication transparency,
 Failure transparency,
 Migration transparency
 Concurrency transparency,
 Performance transparency, and
 Scaling transparency
Dr.K.Geetha 36
 Transparency
Access transparency
 user cannot recognize a resource local or
remote
 Remote resources in the same way as
local
 Uniform system calls
 Distributed shared memory concept
 Suitable for limited types
 Performance limitation

Dr.K.Geetha 37
 Transparency

Name
Transparency
Location
Transparency
User
Mobility

Dr.K.Geetha 38
Transparency
Name Transparency
Name does not reveal location
Movement of files need not change
the names
Resource names are unique
User Mobility
Same name for accessing from
different locations
Users access without any extra effort

Dr.K.Geetha 39
Transparency
 Replication Transparency
Creating Replicas of files
on another systems
Should be transparent
Issues
Naming of replicas and
Replication control.
Dr.K.Geetha 40
 Transparency
 Failure Transparency
 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
possible

Dr.K.Geetha 41
 Transparency
Migration Transparency
 Migration decisions should be automatic
 Migration should not require any change
in name
 If the receiver moves to another location
the sender need not resend it.
Concurrency Tranparency
 Using the system concurrently
 Concurrent update of the same file should
not be allowed

Dr.K.Geetha 42
Transparency
Event Ordering
Property

Concurrncy
No Deadlock Resource No Starvation
Property sharing Property
mechanism

Mutual Exclusion
Property

Dr.K.Geetha 43
 Transparency
Performance Transparency
Loads vary dynamically
Processors should be uniformly distributed
To allow system to reconfigure
Intelligent resource allocation and migration
facility
Scaling Transparency
To allow system to expand
Open System Architecture
Use of scalable algorithms
Dr.K.Geetha 44
Reliability
Fault
Avoidance

Reliability

Fault Fault
Tolerance Detection/Recovery

Dr.K.Geetha 45
Reliability
Fault Avoidance
To design to minimize the occurrence of faults
The Designers should test.
Fault Tolerance
Ability of the system to function in the event
of partial failure
Techniques to improve fault tolerance
Redundancy Techniques
To avoid single point of failure
Hardware and software components are
replicated.
Additional system overhead is needed to
maintain replicas.
Dr.K.Geetha 46
Reliability
 said to be k-fault tolerant if it can continue to
function even in the event of the failure of k
components
Distributed Control
 Distributed control mechanism to avoid single
points of failure.
1. Fault Detection and Recovery
Use of H/W and S/W to detect failure and
recover from it.
Techniques:
Atomic Transactions
Collection of operations that takes place in a failure

Dr.K.Geetha 47
Reliability

2. Stateless Servers

Client -
server

Stateful Stateless
Dr.K.Geetha 48
Reliability
3. Acknowledgements and time-outs based
retransmissions
Duplicate messages are a problem
here
Detection and handling of
Duplicate messages
Generating and assigning Sequence
Numbers
Extra Overhead to detect these
Integrate all these things in a cost-
effective manner Dr.K.Geetha 49
Flexibility
 Why Di s.Os should be flexible?
Ease of modification
Ease of enhancement
The important design factor is
Designing the kernel of the OS
Kernel Monolithic Kernel

Micro Kernel

Dr.K.Geetha 50
Flexibility
 Monolithic Kernel
◦ All functions are provided by such kernel
◦ Big structure
◦ UNIX
◦ Micro Kernel
To Keep Kernel as small as possible
OS provides minimum facilities
Services provided is inter process
communication
Low Device mgmt
Mem. Management
other services as user level server
processes.
Dr.K.Geetha 51
Flexibility

Node1 Node 2 Node n

User User User

Applications Applications Applications
• Monolithic • Monolithic • Monolithic
Kernel Kernel Kernel
Network Hardware

MONOLITHIC KERNEL

Dr.K.Geetha 52
 Microkernel
Node 1 Node 2 Node n

User User User

Applications Applications Applications
Server Manager Server Manager Server Manager
Modules Modules Modules

Microkernel Microkernel Microkernel

Network Hardware

Dr.K.Geetha 53
Flexibility
Monolithic Model Microkernel Model

Major OS services are provided by the kernel Only minimal facilities and services
are provided
Kernel has a large monolithic structure Size of the kernel is small
No such thing User level server processes services
Large size reduces flexibility Increased flexibility
Reduced Configurability Highly modular in nature
complex Easy to modify
complex Easy to add services
Changes can be done by interrupting users Without interrupting users, the
changes can be performed In the OS
No the servers have to use some form of
message-based interprocess
communication mechanism
No Message passing requires context
switches
Dr.K.Geetha 54
Performance
 Design principles in order to achieve Good Performance are
 1. Batch if possible
◦ Large pages transfer instead of small
◦ Piggybacking acknowledgement
◦ 2. Cache whenever possible
◦ Makes data available
◦ Saving large amount of Computing time and bandwidth
◦ 3.Minimize copying data
 Data path
 Senders Stack Message buffer Kernels
message buffer
 Network Interface Board

Dr.K.Geetha 55
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
◦ concurrency control of simultaneous
accesses by multiple processes to a shared
resource
Dr.K.Geetha 56
Scalability
 capability of a system to adapt to increased
service load.
 Principles for designing scalable systems
1. Avoiding centralized entities
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 increases
network traffic.
The increased users increases the complexity
Dr.K.Geetha 57
 Scalability
 2. Avoid centralized algorithms.
◦ This algorithm collects information from all
nodes
 The complexity of the algorithm is O(n2)
◦ It creates heavy network traffic and quickly
◦ consumes network bandwidth. Therefore, in
the design of a distributed operating system,
only decentralized algorithms should be used.

 3. Perform Most operations on a client

network
Dr.K.Geetha 58
 Heterogeneity
 Interconnected set of dissimilar hardware
and software
 The following things are different
◦ Communication protocols
◦ Topologies
◦ Servers
We need translation servers
Intermediate standard data format

Dr.K.Geetha 59
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
◦ Whether message received by the receiver
◦ Message sent by a genuine sender
◦ The content of the message is not altered
Cryptography and integrity(Trusting smaller
servers rather than clients)
Dr.K.Geetha 60
 Emulation of Existing
Operating Systems

 New OS should allow the old features of old

OS also

Dr.K.Geetha 61
DISTRIBUTED COMPUTING
ENVIRONMENT (DCE)
 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.
DCE APPLICATIONS
DCE SOFTWARE
OPERATING SYSTEMS
NETWORKING

Dr.K.Geetha 62
DCE Creation
 Middleware software layer
 Request for Technology
DCE components
Threads Package
Provides a simple model for concurrent
applications
RPC facility
Basis for all communication facility
Easy to use
Network independent
Protocol independent
Provides Secure Communication

Dr.K.Geetha 63
 DCE Creation
 Distributed Time Service
Synchronizes clocks of all systems
Permits the use of time values
Clocks of one DCE can be synchronized with the other
 Name Services
 Cell Directory Service(CDS)
 Global Directory Service(GDS)
 Global Directory Agent(GDA)
 Allow resources such as servers, files and devices files
with unique name.
 Security Service
 Provides tools needed for authentication and authorization
 Distributed File Service(DFS)
 Provides services such as availability, transparency

Dr.K.Geetha 64
DCE Components

Reference:Pradeep K.Sinha, Distributed operating System Concepts and

Design Dr.K.Geetha 65
DCE CELLS
 DCE uses the concept of cells.
 Breaks down a large system into smaller,
manageable units called cells
 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
cell directory server,
security server,
a distributed time server,
and one or more client machines.
Dr.K.Geetha 66
DCE CELLS
 Boundaries
Purpose:
◦ Machines of common goal will be put in the
same cell.
◦ Product oriented or function oriented cells
Administration: Each system needs an
administrator
All the Machines and administrators are put in
same 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.
Dr.K.Geetha 67
 DCE CELLS
Security
 users who have trust in each other should be
put in the same cell.
 In such a design, cell boundaries act like
firewalls in the sense that accessing a resource
that belongs to another cell requires
authentication than accessing a resource that
belongs to a user's own cell
Overhead.
 machines of users who frequently interact
 and the resources frequently accessed by them
should be placed in the same cell..

Dr.K.Geetha 68
 Distributed Computing System

 A collection of processors inter

connected by a communication
network in which each processor has
its own local memory and other
peripherals and communication
between any two processors of the
system takes place by message passing
over the communication network

Dr.K.Geetha 69
Why Di-OS?
 (a) Suitability for applications which are
distributed in nature
 (b) Sharing of information
 (c) Sharing of resources,
 (d) Better Performance-price ratio,
 (e) Shorter response times
 (f) Higher throughput
 (g) Higher reliability,
 (h) Extensibility and incremental growth
 (i) Flexible in meeting users' needs
Dr.K.Geetha 70
MESSAGE PASSING

Dr.K.Geetha 71
 Introduction
Processes communicating with each other
 Distributed operating systems provide IPC
Methods for sharing information are
1. Original sharing, or shared-data approach
2. Copy sharing, or message-passing approach
Message
Sharing

Original Copy
Sharing sharing

Dr.K.Geetha 72
Basic Methods for sharing data

Original Sharing

Copy sharing
Dr.K.Geetha 73
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.

Dr.K.Geetha 74
Desirable Features of a Good Message
Passing System
Simplicity
Uniform Semantics
Efficiency
Reliability
Correctness
Flexibility
Security
Portability

Dr.K.Geetha 75
 Simplicity
Message Passing System should be
 Simple
 Easy to Use
 Straight forward to construct new
applications
 Clean and Simple Semantics of IPC
Protocols

Dr.K.Geetha 76
Uniform Communications

Local
Communication

Inter process
communication

Remote
Communication

Dr.K.Geetha 77
 Efficiency
If MPS not Efficient is cost increases
Avoiding the costs of establishing
and terminating connections
Minimizing the costs of maintaining
the connections
 Piggybacking of acknowledgment of
previous messages with the next
message

Dr.K.Geetha 78
 Reliability
Acknowledgments and
retransmissions on the basis of
timeouts
Detecting and handling
duplicates
Generating and assigning
appropriate sequence numbers
to messages
Dr.K.Geetha 79
 Correctness
Issues related to correctness are
Atomicity Message sent to every
receivers
Ordered delivery Messages are in
sequence
Survivability Messages will be
delivered in spite of failures.

Survivability is a difficulty property to achieve.

Dr.K.Geetha 80
 Flexibility
IPC primitives should be such that the
users have the flexibility to choose
and specify the types and levels of
reliability
have the flexibility to permit any kind
of control flow between the
cooperating processes, including
synchronous and asynchronous
send/receive.

Dr.K.Geetha 81
 Security
Secure end-to-end communication.
 Authentication of the receiver of a
message by the sender
 Authentication of the sender of a
message by its receiver
 Encryption of a message before sending
it over the network

Dr.K.Geetha 82
 Portability

Message passing
should be portable
Portability
The applications
should be portable

Dr.K.Geetha 83
Issues in IPC Message Passing
Header and messages
Actual Structral information Sequence Addresses
Data or Number of Type No Sending Receiving
Pointer bytes address Address
to data

Who is the sender?

Who is the receiver?
One or more receivers?
Message guaranteed?
Sender waits for reply?
Node crash? What to do?
Buffering?
Outstanding Messages?

Dr.K.Geetha 84
 SYNCHRONIZATION
Semantics
Synchronization Communication
Primitives

Blocking

Non
Blocking

Dr.K.Geetha 85
SYNCHRONIZATION
Non blocking
◦ Invocation does not does not block the
execution of the invoker
 Blocking
◦ blocks
 Send primitive

Dr.K.Geetha 86
 SYNCHRONIZATION
Sender--Blocked Receiver
send

Blocked Blocked

receive

Ack
Continue
Dr.K.Geetha 87
SYNCHRONIZATION
How the receive process know the message
has arrived?
Polling
Interrupt
 conditional receive primitive, returns
control to the invoking process almost
immediately, either with a message or
with an indicator that no message is
available.
Dr.K.Geetha 88
SYNCHRONIZATION

Ref: P.K.Sinha “ Distributed Os Concepts and Design”

Dr.K.Geetha 89
DIFFERENCES
SYNCHRONOUS ASYNCHRONOUS
Simple & Easy to implement Not a simple method
Reliable Not reliable
If the message gets lost, no Error recovery is needed
backward error recovery is
required
It limits concurrency No such limitation
Subject to communication No
Deadlocks
Less Flexible Flexible

Dr.K.Geetha 90
Buffering
copying the body of the message from the
address space of the sending process to
the address space of the receiving
process.
Types
a null buffer, or no buffering,
and a buffer with unbounded capacity.
single-message and finite-bound,
multiple-message, buffers.
Dr.K.Geetha 91
 Buffering
Null Buffer or No Buffering
No place for the temporary storage of
message
Message remains in the senders address
space until receiver executes the receive

Message

Dr.K.Geetha 92
 Buffering

Sender sends
the message Receiver

Sender is
blocked Executes
receive
Ack

Sender
unblocked Sender can
send message

Message
Transferred
Dr.K.Geetha 93
 Buffering
 Single Message Buffer- suitable for synchronous

Single Message
Message Buffer

Node Boundary

Dr.K.Geetha 94
 Buffering
 Multiple Message Buffer
Message 1

Message 2
Sender Receiver

Message3

Message n

Dr.K.Geetha 95
 Buffering
Finite Buffer- When Message transfer fails
Buffer overflow without buffers. Send
indicates error message. Less
reliable method

Unsuccessful
Communication

Flow Senders blocked.

Creates space
Controlled
Communication

Dr.K.Geetha 96
 Buffering
 Create_buffer system call
 Creates a buffer of size specified by
receiver.
 Receivers mail box or kernels address
space located
 More complex to design
 Overhead involved for creation, deletion
and maintenance of buffers

Dr.K.Geetha 97
MUlTIDATAGRAM MESSAGES
 MTU-Maximum Transfer Unit
 If Message > MTU segmented and
fragmented messages
Single
Datagram
Messages
Multi
Datagram

Dr.K.Geetha 98
MUlTIDATAGRAM MESSAGES
 Single Datagram
Messages <MTU of the network can be
sent in a single packet
Multi Datagram
Messages> MTU sent in multiple packets.
 The disassembling into multiple packets
on the sender side and the
reassembling on the receiver side is
the responsibility of the message-
passing system.
Dr.K.Geetha 99
ENCODING AND DECODING OF
MESSAGE DATA
 structure of program objects should be
preserved while they are being
transmitted
 not possible in a heterogeneous
 in homogeneous systems, it is very
difficult to achieve this goal mainly
because of two reasons
-An absolute pointer value loses its meaning
during transfer. Example tree object
-Varying amount of storage space.

Dr.K.Geetha 100
ENCODING AND DECODING OF
MESSAGE DATA
 problems are there in transferring
program objects in their original form,
 they are first converted to a stream form
that is suitable for transmission
 This conversion process takes place on
the sender side and is known as encoding
of a message data.
 This conversion process takes place on
the receiver side and is known as
decoding of a message data.
Dr.K.Geetha 101
ENCODING AND DECODING OF
MESSAGE DATA

Encoding and Decoding of

Type of
each
Program
Tagged object
Representation
Data

Untagged
Representation 1.Program
object only
2.Prior
knowledge

Dr.K.Geetha 102
 PROCESS ADDRESSING
 Naming of the Parties involved in communication

Explicit
Process Addressing
Addressing Implicit
Addressing

Dr.K.Geetha 103
PROCESS ADDRESSING
 Explicit addressing. The process with which
communication is desired is explicitly
given as a parameter in the
communication primitive used.
send (process_id, message)
receive (process_id, message)

Dr.K.Geetha 104
PROCESS ADDRESSING
 Implicit addressing. Does not explicitly
name
a process for communication.
Also known as functional addressing
e.g Client server communication
 send_any (service_id, message)
 receive_any (process_id, message)

Dr.K.Geetha 105
PROCESS ADDRESSING
 identify a process is by a combination of
machine_id and local_
id, such as machine_id@local_id.
 processes can be identified by a
 combination of the following three fields:
machineld, local_id, and machineid.

Dr.K.Geetha 106
PROCESS ADDRESSING
 The first field identifies the node on
which the process is created
 The second field is a local indentifier
generated by the node on which the
process is created
 The third field identifies the last known
location (node) of the process

Dr.K.Geetha 107
FAILURE HANDLING
 Partial failures such as a node crash
 Loss of request message.
◦ due to the failure of communication link between
the sender and receiver
◦ receiver's node is down at the time the request
message reaches
 Loss of response message.
◦ due to the failure of communication link
◦ sender's node is down at the time the response
message reaches there.
 Unsuccessful execution of the request.
◦ crashing while the request is being processed.

Dr.K.Geetha 108
 SENDER • RECEIVER

Request Message

• Send Req

Lost

LOSS OF REQUEST MESSAGE

Dr.K.Geetha 109
• SENDER • RECEIVER
REQUEST

REQ
SUCESSS

SEND
RESPONSE

RESPONSE

LOST
LOSS OF RESPONSE
Dr.K.Geetha 110
 SENDER RECEIVER

SEND
REQ
REQUEST
MESSAGE
UNSUCCESSFUL
REQUEST

CRASH

RESTARTED

Dr.K.Geetha 111
 FOUR WAY PROTOCOL

• SENDER • RECEIVER
REQUEST

REQ
SUCESSS
SEND
ACK
ACK

REPLY

ACK

Dr.K.Geetha 112
 THREE WAY PROTOCOL

• SENDER • RECEIVER
REQUEST

REQ
SUCESSS
SEND
ACK

REPLY

ACK

Dr.K.Geetha 113
 TWO WAY PROTOCOL

• SENDER • RECEIVER
REQUEST

REQ
SUCESSS
SEND
ACK

REPLY

Dr.K.Geetha 114
CLIENT SERVER

SEND REQUEST

LOST

RETRANSMIT

RETRANSMIT REQ

RESPONSE MESSAGE Fault tolerant Communication Between

client- Server

RETRANSMIT REQ

RESPONSE MESSAGE
Dr.K.Geetha 115
Idempotency and Handling or
Duplicate Request Messages
 Repeatability
 produces the same results with same
arguments.
 Eg. Sqrt finding
Not the same results
Eg. Debit(amount)

Dr.K.Geetha 116
 client server

1000 Debit 100

Success debit 100 =900

Time Out

Retransmit Request

Balance 800

Dr.K.Geetha 117
 client server
Request Id Reply to be
sent
1000 Debit 100 Request 1 900

Success debit 100 =900

Time Out

Retransmit Request

Balance 800

Dr.K.Geetha 118
 lost and Out-of-Sequence Packets
 For successful completion of a
multidatagram message transfer, reliable
delivery of every packet is important.
 Reliability Ack for
each pkt
◦ Stop and Wait Protocol
◦ Called Blast Protocol
 link failure leads to Ack for all
◦ Message Loss
◦ Out of sequence

Dr.K.Geetha 119
 lost and Out-of-Sequence Packets
 Selective Repeat
 Header Part two extra fields
◦ First field buffer size
◦ Second Position of packet
◦ After timeout not received pakets will be sent
using bitmap

Dr.K.Geetha 120
Group Communications
One to many

Group
Many to one
Communications

Many to Many

Dr.K.Geetha 121
Group Communications
 One-to-Many Communication
◦ Also known as multicasting
◦ Broadcasting is a special case
• Group Management
closed and open.

only members can

communicate
Any member can
communicate

Dr.K.Geetha 122
 Group Addressing
 A special network address to which
multiple machines can listen. Such a
network address is called a Multicast
Address.
 A packet sent to a broadcast address is
automatically delivered to all machines on
the network.
 Otherwise one-one communication.

Dr.K.Geetha 123
 Group Addressing
 Buffered and Un-Buffered Multicast
1. A sending process cannot wait until all
the receiving processes that belong to the
multicast group are ready to receive the
multicast message.
2. The sending process may not be aware of
all the receiving processes that belong to
the multicast group.

Dr.K.Geetha 124
 Group Addressing
Semantics for one-to many
communications:
1. Send-to-all semantics. A copy of the
message is sent to each process of the
multicast group and the message is buffered
until it is accepted by the process.
2. Bulletin-board semantics. A message to be
multicast is addressed to a channel instead
of being sent to every individual process of
the multicast group. From a logical

Dr.K.Geetha 125
 Flexible Reliability in Multicast
Communication
 Degree of Reliability depends on
 The O-Reliable. asynchronous multicast in
which the sender does not wait for any
response after multicasting the message.
 The 1-Reliable. The sender expects a
response from any of the receivers. The
first server that responds is an example of
l-reliable multicast communication.

Dr.K.Geetha 126
Flexible Reliability in Multicast
Communication
3. M-out-of-N-Reliable. The multicast group
consists of n receivers and the sender
expects a response from m (1<m<n) of
the n receivers.
4. All-reliable. The sender expects a
response message from all the receivers
of the multicast group

Dr.K.Geetha 127
GROUP COMMUNICATION
PRIMITIVES
 Send
 Send-group
Many-One Communication
 Non-Determinism. The receiver may
want to wait for information from any of
a group of senders
Many-Many Communication
Issues
Ordered Delivery
Message sequencing
Dr.K.Geetha 128
GROUP COMMUNICATION PRIMITIVES
 Absolute Ordering
 Consistent Ordering
 Casual Ordering
Absolute ordering
Messages are delivered in exact order
Global time stamps are used
Consistent order
 This order may be different from the
order in which messages were sent

Dr.K.Geetha 129
GROUP COMMUNICATION PRIMITIVES

 Casual Order
 If two message sending events are not
causally related, the two messages may be
delivered to the receivers in any order.
 Happened before relation-One event
should happen before the another in the
time domain.

Dr.K.Geetha 130
REFERENCE
Pradeep K. Sinha, “Distributed Operating
System Concepts and Design”, PHI, New
Delhi,2007.

Dr.K.Geetha 131