MessagePassing_1_

1

Message passing

2

Message passing

Process Resourse manager (balancing the sys. Load) Interprocess commu. ( IPC) Two methods of info. Sharing Original sharing (shared data approach) copy sharing msg. passing approach

p1p2

p1p2

Shared common memory area

Message passing system is a subsystem of a D.O .S that provides a set of msg. based IPC protocols and does so by shielding the details of a complex n/w protocols and multiple heterogenous platforms.

Form the basis of

RPC

DSM

3

Desirable features of a good Message passing system

Simplicity ( to const. new applns. and to communicate with existing ones) Uniform Semantics Local commu. (communicating processes r on the same node) Remote commu.(communicating processes r on diff. nodes ) Efficiency ( critical issue, cost efective) optimizations : reducing the no. of msg. exchanges min. the cost of maintaining the connections piggybacking of acks. Reliability (D.S is prone to node crashes or commu. link failure) lost msgs. duplicate msgs. ( A reliable IPC protocol is reqd.) Correctness ( a characteristic for group commu.) Atomicity Ordered delivery survivability Flexibility ( not all applns. require same degree of correctness and reliability; catering to

diff. applications e;g c/s appln.)

4

Desirable features of a good Message passing system

Security Authentication Encryption etc. Portability ( two aspects) msg. passing sys. should itself be portable ( on another sys.) applns. written by using the primitives of the IPC protocols should be

portable. Heterogenity ( architectures) should be taken care of.

Actual dataOr pointer

to the data

Structural information

Sequence numberOr msg. id

Number of bytes/

elements

type Receiving process add.

sending process add.

addresses

variable Fixed length header

5

Design issues of an IPC protocol for message passing system

Who is the sender Who is the sender Is there one or many senders / receivers Guarantee of receiving the msg. Does the sender wait for the reply What if failure occurs What if the receiver is not ready to receive i;e stored or rejected ,what if

buffer is full Order of receiving outstanding msgs.

6

Design issues of an IPC protocol for message passing system are addressed as

Synchronization Buffering Multidatagram messages Encoding and decoding of message data Process Addressing Failure Handling Group communication

7


Synchronization When both send and receive primitives of a commu. between two

processes use blocking semantics , the commu. is said to be synchronous ; otherwise it is asynch.

Senders exe

Receivers exe

Receive msg.

Exe. resumed

Send (ack.

Msg.

Ack.

Send msg.

Exe. resumed

Blocked stateExecution suspended

Blocked stateExecution suspended

8


Blocking and non Blocking communication Blocking communication

TCP, UDP, and other communication packages Client: blocked only when the destination buffer is full Server: blocked if no message has arrived from the

client. Non-blocking communication A primitive is said to have non blocking semantics if its invocation

does not block the exe. of its invoker Server does not want to be blocked when

It may receive a message from a different client. It has another jobs to be done such as computation or

message transmission. Therefore some synchronization is necessary later.

9

Synchronization in Non-Blocking Communication Polling (checking the buffer status)

Periodically check if a socket is ready to read data: Example:

sd = socket( AF_INET, SOCKET_STREAM, 0); set_fl(sd, O_NONBLOCK); // set the socket as non-blocking struct pollfd pfd; pfd.fd = sd; poll( &pfd, 1, timeout ) // poll the socket status

Interrupt (when the msg. has been filled in the buffer and is ready for use a s/w interrupt is used to notify the receiving process) Notified from the system when a socket is ready to read data; Example:

sd = socket(AF_INET, SOCKET_STREAM, 0); signal(SIGIO, sigio_func); // set a future interrupt to call sigio_func( ) fcntl(sd, F_SETOWN, getpid( )); // ask OS to deliver this fd interrupt to me fcntl(sd, F_SETFL, FASYNC); // set this fd asynchronous int sigio_func( ) { // invoked upon an interrupt }


10


A synchronized communication Compare / limitations of the two Concurrency/commu. deadlocks

11


No Buffering A message remains on the sender until the

receiver issues receive( ). Rendezvous Performance drawback

Single Message Buffer The sender can send at most one message

even if the receiver has not issued receive( ). Stop-and-wait protocol A message can be kept read in advance. What if the sender has multiple messages?

Finite-Bound Buffer Buffer overflow

Unsuccessful communication (send returns an error msg.)

Go-Back-N Technique ( less reliable) Flow-controlled communication - sliding

window in TCP Socket: capable of changing its buffer size

with setsockopt( )Issue (buffer mnmgt.)

message

message

message

message

message

message

e

Two copy ope.

Two copy ope.

0ne copy ope.

•Buffering

12


Multidatagram messages (MTU, fragmentation and reassembly)

Encoding and decoding of message data tagged representation (type) ASN.1 Mac DOS untagged representation(only program objects) Sun XDR Courier

13


Process Addressing Explicit address

machine id + local id( for the process) Example: TCP/IP and UDP/IP use IP + port Demerit: No process migration allowed( from one m/c to

another) machine id + local id + the last machine id

Process migration allowed Messages forwarded along links to the final destination Receiver informing sender of its last machine id Sender using this info from the following messages

Implicit addressing System-wide id (function name)

Example: RPC Name server required( but replication reqd. so increase in overhead)

Send(process_id,msg)receive(process_id,msg)

Send_any(service_id,msg)

Primitives for explicit&implicit add. Of processes

14


Loss of request message Loss of response message Unsuccessful execution of

request Do we really need

acknowledgment messages?

client clientserver server

timeout

request request

response

ack

response timeout

request

ack

response

request

ack

request 2

response 2

request 2timeout

•Failure Handling

Partial failures like node crash or commn. link crash

15

Design issues of an IPC protocol for message passing system are addressed

Four msg. Reliable IPC protocol for c/s commun.

•Failure Handlingclient server

request

ack

reply

ack

Executing state

Blocked state

request

reply

ack

client server

three msg. Reliable IPC protocol for c/s commun.

16

Design issues of an IPC protocol for message passing system are addressed as Failure Handling

A pair of request and response is enough to handle faults

Idempotency assumed: At-least one semantics Last-one semantics

client server

client server

Timeout

Timeout

Timeout

request

request 2

request 3

request 4

response

response 2

request

response

two msg. Reliable IPC protocol for c/s commun.

fault tolerant sys.l for c/s commun.

17


• Idempotency Repeatability does not change the value e;g sqrt 81• Nonidempotency e;g

debit ( amount) if(balance>=amount)

{balance=balance-amount; return ( “success” balance);

else return ( failure” balance); end;

18


What if errors in the banking system

New semantics required: Exactly-one

semantics Server must

keep track of the request sequence

Withdraw $100

$1000-$100= $900

Not receivedWithdraw $100

$900-$100=$800!

$100 received

Exactly-One Semantics

Timeout

client ServertBal=1000

Return(success,900)

Return(success,800)

19


Exactly-One Semantics contd..

client ServerBal=1000

Request 1

Debit(100)

reponse

Return(success,900)

(success,900)

Retransmit Request 1

Debit(100)

reponse

(success,900)

Receive bal=900

Send req 1

Send req 2

timeout

check reply chache for req 1

Req 1

Request identifierReply to be sent

(success,900)

No match found ,so process Req 1

Save reply check reply chache for req 1

Match found Extract reply

Return(success,900)

20

Exercises

1. Why do we need layered network protocols?2. When implementing TCP with datagram, what do we have to take care of?3. Consider the pros and cons of polling and interrupt in non-blocking communi

cation.4. Consider an example inducing an accidental system hang-up (named a deadl

ock) in no-buffering communication.5. Which of the following operations are idempotent?

1. cin >> data;2. ifstream infile(“input.txt”); infile.seek( );3. cout << data;4. int a = 1, b = 2, c; c = a + b;5. int c = 1; c++;

21


Group Communication Communication types:

One-to-many: broadcast/multicast , asynchronous commn. mech. buffered and unbuffered multicast

Many-to-one: synchronization, collective communication Many-to-many: gather and scatter

One-to-many: broadcast/multicast : closed group open group

Group addressing High level group name :ASCII string ( independent of location info.) Low level group name : multicast add. ( dependent upon the h/w Emulating a broadcast with one-to-one communication User appln. use high level group name in progs.

Performance drawback on bus-type networks Simpler for switching-based networks

22


Ahamad and Bernstien suggested two types of semantics Send-to-all: msg is buffered bulletin-board semanticsDegree of reliability is expressed as 0- reliable:asynch. no response e;g time signal generator 1- reliable :e;g first server that responds m-out-of-n- reliable I;e majority consensus used for consistency

cntrl. of replicated info. all-reliable e; g updating the replica of a file

23


Atomic Multicast Send-to-all semantics and all-reliable Simple emulation:

A repetition of one-to-on communication with acknowledgment What if a receiver fails

Time-out retransmission What if a sender fails before all receivers receive a message

All receivers forward the message to the same group. A receiver discard the 2nd or the following messages.

24


Group Communication Communication types:

One-to-many: broadcast/multicast , asynchronous commn. mech. buffered and unbuffered multicast

Many-to-one: synchronization, collective communication Many-to-many: gather and scatter

One-to-many: broadcast/multicast : closed group open group Group addressing High level group name :ASCII string ( independent of location info.) Low level group name : multicast add. ( dependent upon the h/w Emulating a broadcast with one-to-one communication User appln. use high level group name in progs.

Performance drawback on bus-type networks Simpler for switching-based networks

25


Ahamad and Bernstien suggested two types of semantics Send-to-all: msg is buffered bulletin-board semanticsDegree of reliability is expressed as 0- reliable:asynch. no response e;g time signal generator 1- reliable :e;g first server that responds m-out-of-n- reliable I;e majority consensus used for consistency

cntrl. of replicated info. all-reliable e; g updating the replica of a file

26


Atomic Multicast Send-to-all semantics and all-reliable Simple emulation:

A repetition of one-to-on communication with acknowledgment What if a receiver fails

Time-out retransmission What if a sender fails before all receivers receive a message

All receivers forward the message to the same group. A receiver discard the 2nd or the following messages.

MessagePassing_1_

Documents

Transcript of MessagePassing_1_