COMMUNICATION

INTER PROCESS COMMUNICATION

Inter process communication is the information sharing between two or more

processes running on different nodes for various reasons like Load Balancing etc. A
“Process” is a program in execution.

Two basic methods for information sharing are:

 Shared Data Approach: information is placed in common memory area that is shared
among processes.
 Message Passing Approach: information to be shared is copied form address space of
one process to address space of other process.

Message passing is the basic IPC mechanism in distributed system due to non
availability of common memory area in Distributed System.

Message Passing System : is a subsystem of Distributed Operating System that provides

a set of message based IPC protocols which are simple to use, hiding all complex n/w
protocols from user. It serves as infrastructure for building higher level IPC mechanisms
like RPC and Distributed shared memory
Features of Message Passing System

* Simplicity: simple and easy to use.

* Uniform Semantics: semantics of remote comm. should be as close as possible to local
comm. so that system is easy to use.
* Efficiency: application programmer try to avoid inefficient system. Issues to handle
are-
Avoid the cost of establishing & terminating connection
Minimize the cost of maintaining the connection
Piggybacking of acknowledgment of previous messages with next message.
* Reliability: Reliable IPC protocol handles message retransmission in case of failure &
node crashes and also capable of detecting and handling duplicate messages.
* Correctness: Applicable in group comm. in which sender sends message to group of
receivers and receiver to receive form several senders. Issues are Atomicity, Ordered
Delivery & Survivability.
* Flexibility: user should be able to choose & specify the level of reliability and
correctness required.
* Security: provide secure end to end comm. by authenticating sender & receiver of
message, encryption.
* Portability: easy to extend facility on another system.
Issues In IPC By Message Passing

Issues to be considered in design of IPC protocols are:

 Who is the sender ?

 Who is the receiver ?
 Is there one or many receiver?
 Is message guaranteed to be accepted by its receiver?
 Does sender need to wait for a reply ?
 What should be done in event of node crash or link failure?
 What should be done if receiver is not ready to accept or if its buffer is full?
 In case of several messages can receiver choose the order of receiving
message?
Message Structure in Message Passing

A typical message structure is:

The header of message consists of:

 Address: character that identifies process in a network.

 Sequence Number: message identifier that identifies the message
 Structural Information: It consists of two parts:
i. Data Type: determine whether the data is included in message or message contains the
pointer to data only
ii. Length of variable data type

.
 SYNCHRONIZATION

Communication primitive should provide synchronization of communicating

processes.

Synchronization are of two types:

 Blocking Synchronization [Synchronous]: after sending message sender is blocked
until it receives an Ack from the receiver. Similarly receiving process after execution
of receive statement is blocked until it receives a message. To avoid indefinite
blocking time-out primitive is used by sending & receiving processes.
 Non Blocking Synchronization [Asynchronous]: in this after execution of send
statement the sending process continue to execute as soon as message is copied to
buffer. Similarly receiving process proceeds with its execution after execution of the
receive statement.

Receiving process knows that message has arrived in buffer by two techniques:
• Polling- receiver periodically poll the kernel to check the buffer.
• Interrupt- when message arrives a software interrupt is used to notify receiving
process.
 SYNCHRONIZATION (Contd.)

Synchronous Communication:

* Synchronous comm. is simple and easy to implement and more reliable. But it
lacks concurrency and subject to deadlocks.
* Asynchronous comm. is complicated but provide better concurrency, reduced
message traffic and better flexibility.
 BUFFERING

Receiving process have buffer where OS can copy the messages such that the
receiving process can later use it for execution.

There are four types of buffering strategies:

 Null Buffer: there is no place to temporarily store the message. Execution of send is
delayed until receiver execute corresponding receive. After receiving ACK from
receiver the sender is unblocked causing the send to be executed once again.
Timeout mechanism is used to resend the message after a timeout period.

 Single Message Buffer: in this buffer having capacity to store single message is used
on the receivers node. So it keep message ready for use at receiver end.
 BUFFERING (Contd.)

 Unbounded Capacity Buffer: unbounded capacity message buffer is used to store

all unreceived message to support asynchronous comm.

 Finite Bound Buffer: unbounded capacity buffer is not practical so a finite message
buffer is used. Problem of buffer overflow arises in this and is tackled in two ways:
• Unsuccessful comm.- message transfer completely fail during buffer overflow.
• Flow controlled comm.- sender is blocked until the receiver accepts some
messages, thus creating space in the buffer for new messages.
Multi-Datagram Messages

All networks have an upper bound on size of data that can be transferred called
Maximum transfer unit (MTU).

Message greater than MTU are fragmented into multiple MTU and then
transferred.

* Sender:-
* Fragment message into multiple MTU.
* Each fragment along with some control info. is called packet/datagram is
sent to receiver.
* Message larger than MTU is converted into multi-datagram that bear
sequential relationship.

* Receiver:-
* Assembles the multi datagram after receiving.
Encoding & Decoding of Message Data

A message data should be meaningful to the receiving process.

Structure of object program should remain same when it is written from

address space of sender to address space of receiver.

Heterogeneous System-in which computer architecture are different.

Problems in transferring information in these system are:

 An absolute pointer value looses its meaning during transfer. For e.g.
Tree Structure. They must be transferred in some other form.
 Different program object occupy different amount of storage space
( long, short, integers, character string), so message must contain
information that which program object is stored where in message
buffer.
Encoding & Decoding of Message Data (Contd.)

Sender:
Do encoding i.e. convert program object to stream form that is easy to
transfer.

Receiver:
Do decoding i.e. reconstruction of original object program.

Two forms of representation are used for encoding and decoding:

 Tagged: type of program object with its value is encoded in message. More
expensive then untagged.

 Untagged: message data only contains program object. Receiving process

must have prior knowledge of data conversion
 PROCESS ADDRESSING

Addressing (or naming) of the parties involved in interaction.

Process Addressing

Explicit Addressing Implicit Addressing

Explicit Addressing: Process address is explicitly named as parameter in comm.

primitive.
For eg communication primitive are
 send( process_id, message) -> send a message to the process identified by
“process_id”
 receive( process_id, message) -> receive message from process identified by
“process_id"
 PROCESS ADDRESSING (Contd.)

Implicit Addressing: process name is not explicitly named for comm..

For eg communication primitive are

 send_any( service_id, message) -> send message to any process that provides
the service of type mentioned.
 receive_any( process_id, message) -> receive message for any process & then
return process_id from which it accept message.

Both the above primitive are useful in Client-Server communication.

There are three ways for Addressing Processes:

 Simple Addressing
 Link Based Addressing
 Two Level Naming
 PROCESS ADDRESSING (Contd.)

Simple Addressing:
Process willing to send message uses the primitive as:

send( machine_id@local_id, message)

In this process identifier is: machine_id@local_id

• machine_id : Used by sender’s kernel to locate the required machine.

• Local_id : Used by receiver’s kernel to forward message to required process.

Limitation:
 Doesn’t work if process is to be migrated to other machine for load balancing.
 Non-transparent.
 PROCESS ADDRESSING (Contd.)

Link Based Addressing:

Process willing to send message uses:
send(machine_id@local_id@machine_id, message)

In this process identifier is: machine_id@local_id@machine_id

• First field identifies node on which process created.

• Second field is process identifier generated by node on which process is created.
• Third field identifies last known location (node_id) of the process.

When process is migrated, a link info. is left on its previous node. And New
node maintains the address of previous address.
 At old node - machine_id@local_id@newnode_id
 At new node – machine_id@local_id@oldnode_id
 PROCESS ADDRESSING (Contd.)

Link Based Addressing:

Message may now easily travel over several nodes before reaching destination
process.

Limitations of Link based addressing:

• Overhead of locating process is large if process migration is more.

• Not possible to locate a process if intermediate node on which process once
reside is down.
• Non-transparent.

So to achieve location- transparency in distributed system two-level process

naming is used.
 PROCESS ADDRESSING (Contd.)

Two Level Naming:

Process using two level naming are unique globally.

In this each process has two identifier

High-level name & Low-level name

High-level name is machine independent & Low-level name is machine

dependent.
If process P1 wants to send message it uses primitive as:
send (High-level Name, message)

P1 P2
 PROCESS ADDRESSING (Contd.)

Two Level Naming:

NameServer is maintained centrally that maps High-level name to Low-level

name to find location.

P1 mention High-level name of P2 in primitive as:

send (High-level Name P2, message)

Now Kernel of senders contact NameServer to get Low-level name of receiving

process for sending messages.

Limitations of two level naming :

 Poor Reliability
 Low Scalability due to centralization of NameServer.
 FAILURE HANDLING

Failures are: Node Crash & Communication Link Failure.

These failure leads to following problems:

 Loss of request message: The request message lost in transit from sender to
receiver. It occurs due to communication failure or receiver node is down

Fig. Loss of request message due to failure

 FAILURE HANDLING(Contd.)

 Loss of response message: The response message in lieu of request is lost in

transit from receiver to sender.
It occurs due to communication failure or senders node is down

Fig. Loss of response message due to failure

 FAILURE HANDLING(Contd.)

 Unsuccessful execution of request: The receiver node may get crash during
execution of request.
It occurs due to crashing of receiver node during processing.

Fig. Unsuccessful execution of request

 FAILURE HANDLING (Contd.)

Various IPC Protocols are given for reliable communication b/w Client-Server .

 Four Level
 Three Level
 Two Level

Four Level Protocol:

In four level protocol there are four levels of communication between client and
server.

Level-1> Client send request message to server

Level-2> Server Kernel returns ACK to client. If client doesn’t get ACK within
time-out it retransmit request.
 FAILURE HANDLING (Contd.)

Level-3> Server after processing client request, returns reply message to client.

Level-4> Client kernel returns ACK after receiving to server kernel. If ACK is not
received within time-out by Server it retransmits the reply message.

Fig. Four level protocol between Client & Server

 FAILURE HANDLING (Contd.)

Three Level Protocol:

Result of processed request is sufficient that request message was received by
server. So it consist of only three levels.

Level-1> Client sends a request message to the server.

Level-2> Server after processing client request, returns reply message to client.
The client remains blocked until the reply is received.

Level-3> On receiving reply message kernel of Client returns ACK to Server

kernel. The Server retransmit reply message if ACK is not received within time-
out period.

If server takes much time to process client request then it sends ACK to client before
reply message. Otherwise it simply sends reply message as acknowledgment.
 FAILURE HANDLING (Contd.)

Three Level Protocol (Contd.):

Fig. Three level protocol between Client & Server

 FAILURE HANDLING (Contd.)

Two Level Protocol:

Sending ACK by client for reply message is not necessary.

Two level Protocol does not send ACK for a message.

Level-1> Client sends request message to server and remain blocked until reply
is received.

Level-2> Server after processing request, returns reply message to client. If

reply is not received by client within time-out period, the kernel of client
retransmits the request message to server.

It is possible that request from client is executed more than once by server.
 FAILURE HANDLING (Contd.)

Two Level Protocol (Contd.):

Fig. Two level protocol between Client & Server

 Summary
 IPC is Sub systems of DOS that should be simple, Efficient, reliable,
correct, flexible, secure, portable and have uniform semantic
 Sender and receiver may communicate in synchronous or
asynchronous mode. Asynchronous mode has buffer concurrency,
reduced message traffic and greater flexibility. It is more complex
due to buffering (Issues are to implement over flow of buffering)
 Message are transmitted in the form of packed (MTU with control
information)
 A message which is greater than MTU is disassembled in to multi
packet or datagram.
 Encoding is the process of converting the program objects of a
message to a stream form that is suitable for transmission.
 Decoding is the reverse process.
 Addressing of processes.
 Failure handing.
 References

* “Distributed Operating Systems: Concepts and Design”, P.K.Sihna, PHI, 2007.

* “Distributed Systems: Principles and Paradigms”, 2nd Ed., Andrew S.

Tanenbaum and Maarten Van Steen, Prentice Hall, 2007.