ipc

36
1 Interprocess Communications

Upload: mohd-tousif

Post on 25-May-2015

546 views

Category:

Education


2 download

TRANSCRIPT

Page 1: Ipc

1

Interprocess Communications

Page 2: Ipc

2

Interprocess Communications

- Exchange of data between two or more separate, independent processes/threads.

- Operating systems provide facilities/resources for inter-process communications (IPC), such as message queues, semaphores, and shared memory.

- Distributed computing systems make use of these facilities/resources to provide application programming interface (API) which allows IPC to be programmed at a higher level of abstraction. (e.g., send and receive)

- Distributed computing requires information to be exchanged among independent processes.

Page 3: Ipc

3

IPC – unicast and multicast

In distributed computing, two or more processes engage in IPC using a protocol agreed upon by the processes. A process may be a sender at some points during a protocol, a receiver at other points.

When communication is from one process to a single other process, the IPC is said to be a unicast, e.g., Socket communication. When communication is from one process to a group of processes, the IPC is said to be a multicast, e.g., Publish/Subscribe Message model, a topic that we will explore in a later chapter.

Page 4: Ipc

4

Unicast vs. Multicast

P 2

P 1 P 1

P 2 P 3 P 4...

uni c as t m ul t i c as t

mm m m

Page 5: Ipc

5

P r o c es s 1 P r o c es s 2

d ata

s en d er r ec e iv er

Interprocess Communications in Distributed Computing

Page 6: Ipc

6

Operations provided in an archetypal Interprocess Communications API

• Receive ( [sender], message storage object)• Connect (sender address, receiver address), for

connection-oriented communication.• Send ( [receiver], message)• Disconnect (connection identifier), for

connection-oriented communication.

Page 7: Ipc

7

Interprocess Communication in basic HTTP

C 1 C 2

S 3 S 4

C 4

W e b s e rv e r

W e b bro ws e r

a p r o c e s s

a n o p e r a t i o n

d a t a f l o w

o p e r a t i o n s :S 1 : a c c e p t c o n n e c t i o nS 2 : r e c e i ve ( r e q u e s t )S 3 : s e n d ( r e s p o n s e )S 3 : d i s c o n n e c tC 1 : m a k e c o n n e c t i o nC 2 : s e n d ( r e q u e s t )C 3 : r e c e i ve ( r e s p o n s e )C 4 : d i s c o n n e c t

S 2

C 3

S 1

H TTPr e q u e s t

H TTPr e s p o n s e

Processing order: C1, S1, C2, S2, S3, C3, C4, S4

s4

Page 8: Ipc

8

Event Synchronization

Interprocess communication may require that the two processes synchronize their operations: one side sends, then the other receives until all data has been sent and received.

Ideally, the send operation starts before the receive operation commences.

In practice, the synchronization requires system support.

Page 9: Ipc

9

Synchronous vs. Asynchronous Communication

The IPC operations may provide the synchronization necessary using blocking. A blocking operation issued by a process will block further processing of the process until the operation is fulfilled.

Alternatively, IPC operations may be asynchronous or nonblocking. An asynchronous operation issued by a process will not block further processing of the process. Instead, the process is free to proceed with its processing, and may optionally be notified by the system when the operation is fulfilled.

Page 10: Ipc

10

Synchronous send and receive

pr o c e s s 1r unni ng o n ho s t 1

b lo c k in g s en d s ta r ts

b lo c k in g s en d r e tu r n s

b lo c k in g r ec e iv e s ta r ts

b lo c k in g r ec e iv e en d s

ex ec u tio n f lo w

s u s p en d ed p er io d

Sync hr o no us Se nd and R e c e i ve

an o p er a t io n

ac k n o w led g em en t o f d a ta r ec e iv edp r o v id ed b y th e I P C f ac ility

pr o c e s s 2r unni ng o n ho s t 2

Client ServerSender Receiver

Event Diagram

Page 11: Ipc

11

Asynchronous send and synchronous receive

P r o c e s s 1

P r o c e s s 2

b lo c k in g r ec e iv e s ta r ts

b lo c k in g r ec e iv e r e tu r n s

ex ec u tio n f lo w

s u s p en d ed p er io d

As ync hr o no us Se nd and Sync hr o no us R e c e i ve

n o n b lo c k in g s en d

o p er a tio n

Event Diagram

Client ServerSender Receiver

Page 12: Ipc

12

Synchronous send and Async. Receive - 1

P r o c e s s 1

P r o c e s s 2

n o n b lo c k in g r ec e iv e is s u ed

ex ec u tio n f lo w

s u s p en d ed p er io d

Sync hr o no us Se nd and As ync hr o no us R e c e i ve

b lo c k in g s en d is s u ed

S ce n a rio A

t r an s p ar en t ac k n o w led g em en tp r o v id ed b y th e I P C f ac ility

Data from P1 was received by P2 before issuing a non-blocking receive op in P2

Page 13: Ipc

13

Synchronous send and Async. Receive - 2

in d ef in iteb lo c k in g

P r o c e s s 1

P r o c e s s 2

n o n b lo c k in g r ec e iv e is s u edan d r e tu r n ed im m ed ia te ly

ex ec u tio n f lo w

s u s p en d ed p er io d

Sync hr o no us Se nd and As ync hr o no us R e c e i ve

b lo c k in g s en d is s u ed

S ce n a rio B

P r o c e s s 1

P r o c e s s 2

Data from P1 arrived to P2 after P2 issued a non-blocking receive op

Page 14: Ipc

14

Synchronous send and Async. Receive - 3

P r o c e s s 1

P r o c e s s 2

n o n b lo c k in g r ec e iv e is s u edan d r e tu rn ed im m ed ia te ly

ex ec u tio n f lo w

s u s p en d ed p er io d

Sync hr o no us Se nd and As ync hr o no us R e c e i ve

b lo c k in g s en d is s u ed

S ce n a rio C

p ro c es s is n o tif iedo f th e a r r iv a l o fd ata

tr an s p ar en t ac k n o w led g em en tp ro v id ed b y th e I P C f ac ility

Data from P1 arrived to P2 before P2 issues a non-blocking receive op. P2 is notified of the arrival of data

Page 15: Ipc

15

Asynchronous send and Asynchronous receive

P r o c e s s 1

P r o c e s s 2

n o n b lo c k in g r ec e iv e is s u edan d r e tu r n ed im m ed ia te ly

ex ec u tio n f lo w

s u s p en d ed p er io d

As ync hr o no us Se nd and As ync hr o no us R e c e i ve

b lo c k in g s en d is s u ed

S ce n a rio C

p r o c es s is n o tif iedo f th e a r r iv a l o fd a ta

Does P1 need an acknowledgement from P2?

Page 16: Ipc

16

Event diagram

Pro ce s s APro ce s s B

in te rp r o c es s c o m m u n ic a tio n

ex ec u tio n f lo w

p ro c es s b lo c k ed

E ve nt di ag r am fo r a pr o to c o l

r eq u es t 1

r es p o n s e 1

r es p o n s e2

r eq u es t 2

t im e

Synchronous send and receive

Page 17: Ipc

17

Blocking, deadlock, and timeouts

Blocking operations issued in the wrong sequence can cause deadlocks.

Deadlocks should be avoided. Alternatively, timeout can be used to detect deadlocks.

r ec e iv e f r o m p r o c es s 2 is s u ed

r ec e iv ed f r o m p r o c es s 1 is s u ed

p r o c es s 1 b lo c k ed p en d in g d a taf r o m p r o c es s 2 .

p r o c es s 2 b lo c k ed p en d in g d a taf r o m p r o c es s 1 .

P r o c es s 1 P r o c es s 2

P1 is waiting for P2’s data; P2 is waiting for P1’s data.

Page 18: Ipc

18

Using threads for asynchronous IPC

When using an IPC programming interface, it is important to note whether the operations are synchronous or asynchronous.

If only blocking operation is provided for send and/or receive, then it is the programmer’s responsibility to using child processes or threads if asynchronous operations are desired.

pro ce s s

m ain th r ead

n ew th r ead is s u es a b lo c k in g I P C o p er a tio n

th r ead is b lo c k ed

th r ead is u n b lo c k ed af te r th e o p er a tio n is f u lf illed

m ain th r ead c o n tin u es w itho th er p r o c es s in g

Page 19: Ipc

19

Deadlocks and Timeouts

Connect and receive operations can result in indefinite blocking

For example, a blocking connect request can result in the requesting process to be suspended indefinitely if the connection is unfulfilled or cannot be fulfilled, perhaps as a result of a breakdown in the network .

It is generally unacceptable for a requesting process to “hang” indefinitely. Indefinite blocking can be avoided by using timeout.

Indefinite blocking may also be caused by a deadlock

Page 20: Ipc

20

Indefinite blocking due to a deadlock

" re ce iv e f ro m pro ce s s 2 " is s u e d;

" re ce iv e f ro m pro ce s s 1 " is s u e d;

pro ce s s 1 blo ck e d pe n din g da tafro m pro ce s s 2 .

pro ce s s 2 blo ck e d pe n din g da tafro m pro ce s s 1 .

Pro ce s s 1 Pro ce s s 2

p r o c e s se x e c u t i n g

p r o c e s sb l o c k e d

a n o p e r a t i o n

P1 is waiting for P2’s data; P2 is waiting for P1’s data.

Page 21: Ipc

21

Data Representation

Data transmitted on the network is a binary stream. An interprocess communication system may provide the

capability to allow data representation to be imposed on the raw data.

Because different computers may have different internal storage format for the same data type, an external representation of data may be necessary—standard format.

Data marshalling is the process of (I) flattening a data structure, and (ii) converting the data to an external representation.

Some well known external data representation schemes are: Sun XDR (External Data Representation) ASN.1 (Abstract Syntax Notation One) XML (Extensible Markup Language)

Page 22: Ipc

22

Data Encoding Protocols

ap p lic a tio n s p ec if ic d a ta en c o d in g lan g u ag e

g en era l d a ta en c o d in g lan g u ag e

n etw o rk d a ta en c o d in g s tan d ard

da ta e n co din g s ch e m e s S a m ple S ta n da rdsle v e l o f a bs tra ct io n

X M L :( Ex ten s ib le M ark u p L an g u ag e)

AS N .1 (Ab s tr ac t S y n tax N o ta tio n )

S u n X D R (E x ter n a l D ata R ep res en ta tio n )

Page 23: Ipc

23

Sample XML filehttp://java.sun.com/xml/docs/tutorial/overview/1_xml.html#intro

XML is a text-based markup language that is fast becoming the standard for data interchange on the Web.

XML has syntax analogous to HTML. Unlike HTML, XML tags tell you what the

data means, rather than how to display it. Example:

<message> <to>[email protected]</to>

<from>[email protected]</from> <subject>XML Is Really Cool</subject> <text> How many ways is XML cool? Let me count the

ways... </text> </message>

Page 24: Ipc

24

Data Marshalling

"T h is is a tes t . "

"T h is is a tes t . "

1 .2 7 .3 - 1 .5

1 .2

7 .3

- 1 .5

1 1 0 0 1 1 . . . 1 0 0 0 0 1 0 0 . . .

m arsh a llin g

u n m arsh a llin g

1 . f la t ten in g o f s tr u c tu r ed d a ta item s2 . c o n v er tin g d a ta to ex ter n a l ( n e tw o r k ) r ep r es en ta tio n

1 . c o n v er t d a ta to in te r n a l r ep r es en ta tio n2 . r eb u ild d a ta s tr u c tu r es .

h o s t A

h o s t B

E x ter n a l to in te r n a l r ep r es en ta tio n an d v ic e v er s ais n o t r eq u ir ed - if th e tw o s id es a r e o f th e s am e h o s t ty p e ; - if th e tw o s id es n eg o tia tes a t c o n n ec tio n .

Page 25: Ipc

25

The OSI (Open System Interconnection ) Seven-layer network architecture

ap p lic a tio n lay er

p r es en ta tio n lay er

s es s io n lay er

tr an s p o r t lay er

n e tw o r k lay er

d a ta lin k lay er

p h y s ic a l lay er

ap p lic a tio n lay er

p r es en ta tio n lay er

s es s io n lay er

tr an s p o r t lay er

n e tw o r k lay er

d a ta lin k lay er

p h y s ic a l lay er

Message

Segment

Datagram

Frame

0/1

Page 26: Ipc

26

Text-based protocols

Data marshalling is at its simplest when the data exchanged is a stream of characters, or text.

Exchanging data in text has the additional advantage that the data can be easily parsed in a program and displayed for human perusal. Hence it is a popular practice for protocols to exchange requests and responses in the form of character-strings. Such protocols are said to be text-based.

Many popular network protocols, including FTP (File Transfer Protocol), HTTP, and SMTP (Simple Mail Transfer Protocol), are text-based.

Page 27: Ipc

27

Event diagram

Pro ce s s 1Pro ce s s 2

in te rp r o c es s c o m m u n ic a tio n

ex ec u tio n f lo w

p ro c es s b lo c k ed

E ve nt di ag r am fo r a pr o to c o l

r eq u es t 1

r es p o n s e 1

r es p o n s e2

r eq u es t 2

t im e

Page 28: Ipc

28

Event Diagram for a HTTP session

w eb s er v er w eb b r o w s er

r eq u es t

r es p o n s e

r eq u es t is a m es s ag e in 3 p ar ts : - < c o m m an d > < d o c u m en t ad d d r es s > < HT T P v er s io n > - an o p tio n al h ead er - o p tio n a l d a ta f o r C G I d a ta u s in g p o s t m eth o d

r es p o n s e is a m es s ag e c o n s is t in g o f 3 p ar ts : - a s ta tu s lin e o f th e f o r m at < p r o to c o l> < s ta tu s c o d e> < d es c r ip tio n > - h ead er in f o r m atio n , w h ic h m ay s p an s ev er a l lin es ; - th e d o c u m en t its e lf .

Page 29: Ipc

29

Sequence Diagram

Pro ce s s A Pro ce s s B

in te r p r o c es s c o m m u n ic a tio n

r eq u es t 1

r es p o n s e 1

r eq u es t 2

r es p o n s e 2

Page 30: Ipc

30

Sequence diagram for a HTTP session

Pro ce s s A Pro ce s s B

in te r p r o c es s c o m m u n ic a tio n

r eq u es t 1

r es p o n s e 1

r eq u es t 2

r es p o n s e 2

Page 31: Ipc

31

Protocol

In a distributed application, two processes perform interprocess communication in a mutually agreed upon protocol.

The specification of a protocol should include

(i) the sequence of data exchange, which can be described using a time event diagram.

(ii) the format of the data exchange at each step.

Page 32: Ipc

32

HTTP: A sample protocol

The HyperText Transfer Protocol is a protocol for a process (the browser) to obtain a document from a web server process.

It is a request/response protocol: a browser sends a request to a web server process, which replies with a response.

Page 33: Ipc

33

The Basic HTTP protocol

w eb s er v er w eb b r o w s er

r eq u es t

r es p o n s e

r eq u es t is a m es s ag e in 3 p ar ts : - < c o m m an d > < d o c u m en t ad d d r es s > < HT T P v er s io n > - an o p tio n a l h ead er - o p tio n a l d a ta f o r C G I d a ta u s in g p o s t m eth o d

r es p o n s e is a m es s ag e c o n s is t in g o f 3 p ar ts : - a s ta tu s lin e o f th e f o r m at < p r o to c o l> < s ta tu s c o d e> < d es c r ip tio n > - h ead er in f o r m atio n , w h ic h m ay s p an s ev er a l lin es ; - th e d o c u m en t its e lf .

W e w ill ex p lo r e HT T P in d e ta ils la te r th is q u ar te r .

Page 34: Ipc

34

A sample HTTP session

Script started on Tue Oct 10 21:49:28 2000 9:49pm telnet www.csc.calpoly.edu 80 Trying 129.65.241.20... Connected to tiedye2-srv.csc.calpoly.edu. Escape character is '̂ ]'. GET /~mliu/ HTTP/1.0 HTTP Request HTTP/1.1 200 OK HTTP response status line Date: Wed, 11 Oct 2000 04:51:18 GMT HTTP response header Server: Apache/1.3.9 (Unix) ApacheJ Serv/1.0 Last-Modified: Tue, 10 Oct 2000 16:51:54 GMT ETag: "1dd1e-e27-39e3492a" Accept-Ranges: bytes Content-Length: 3623 Connection: close Content-Type: text/html <HTML> document content <HEAD> <TITLE> Mei-Ling L. Liu's Home Page </TITLE> </HEAD> <BODY bgcolor=#ffffff> …

Page 35: Ipc

35

HTTP Session

1. Telnet to your favorite Web server:

Opens a TCP connection to port 80 at ise.gmu.edu. (default HTTP server port)

unix> telnet ise.gmu.edu 80

2. Type in a GET HTTP request:GET /~yhwang1/ HTTP/1.1Host: ise.gmu.edu

Type above commands and hit carriage return twice, you send this minimal but complete GET request to HTTP server

3. See what you have in response message sent by HTTP server!

Page 36: Ipc

36

IPC paradigms and implementations

Paradigms of IPC of different levels of abstraction have evolved, with corresponding implementations.

re mo te p ro ce d u re /me th o d

so cke t API

d a ta tra n smiss io n s er ia l/p ar a lle l c o m m u n ic a tio n

Un ix s o c k et AP I , W in s o c k

R em o te P r o c ed u r e C all ( R P C ) , J av a R M I

le v e l o fa bs tra ct io n

I PC pa ra dig m s Ex a m ple I PC I m ple m e n ta t io n s

UNIX Socket: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html