Interprocess Communications

Interprocess Communications
-

Exchange of data between two or more separate,

independent processes/threads.
Operating systems provide facilities/resources for interprocess 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.

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.

Unicast vs. Multicast

P

unicast
4

...

m u ltic ast

Interprocess Communications in Distributed

Computing

P ro c ess 1

P ro c ess 2
d a ta

sender
5

r e c e iv e r

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.

Interprocess Communication in basic HTTP

W e b serve r
S 2

S1

S3
H TTP
re qu e st

a proce ss
a n o p e ra tio n
d a ta flo w

S 4

H TTP
re spon se
C 1

C 2

C 3

C 4

o p e ra tio n s:
S 1 : a cce p t co n n e ctio n
S 2 : re ce ive (re q u e st)
S 3 : se n d (re sp o n s e )
Ss43 : d i s c o n n e c t
C 1 : m a k e co n n e ctio n
C 2 : se n d (re q u e st)
C 3 : re ce ive (re sp o n se )
C 4 : disco n n e ct

W e b brow se r

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

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.
8

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.

Synchronous send and receive

pro cess 1
running o n ho st 1

process 2
running o n ho st 2

Event Diagram

b lo c k in g r e c e iv e s t a r t s

b lo c k in g s e n d s t a r t s

a n o p e r a t io n
e x e c u t io n f lo w

b lo c k in g s e n d r e t u r n s

a c k n o w le d g e m e n t o f d a t a r e c e iv e d
p r o v id e d b y t h e I P C f a c ilit y

s u s p e n d e d p e r io d
b lo c k in g r e c e iv e e n d s

Synchro no us Send and R eceive

10

Client
Sender

Server
Receiver

Asynchronous send and synchronous

receive
P ro cess 2

Event Diagram

P ro cess 1

b lo c k in g r e c e iv e s t a r t s

n o n b lo c k in g s e n d
o p e r a t io n
e x e c u t io n f lo w
s u s p e n d e d p e r io d
b lo c k in g r e c e iv e r e t u r n s

A synchro no us Send and

Synchro no us R eceive

11

Client
Sender

Server
Receiver

Synchronous send and Async. Receive - 1

P rocess 2
P rocess 1

b lo c k in g s e n d is s u e d

t r a n s p a r e n t a c k n o w le d g e m e n t
p r o v id e d b y t h e I P C f a c ilit y

n o n b lo c k in g r e c e iv e is s u e d
e x e c u t io n f lo w
s u s p e n d e d p e r io d

Synchronous Send and

A synchro no us R eceive
S c e n a r io A

12

Data from P1 was received by P2

before issuing a non-blocking receive op in P2

Synchronous send and Async. Receive - 2

P rocess 2
P rocess 1

n o n b lo c k in g r e c e iv e is s u e d
a n d r e t u r n e d im m e d ia t e ly
b lo c k in g s e n d is s u e d

in d e f in it e
b lo c k in g

e x e c u t io n f lo w
s u s p e n d e d p e r io d

P ro cess 2
P rocess 1

Synchronous Send and

A synchro no us R eceive
S c e n a r io B

13

Data from P1 arrived to P2 after P2 issued a

non-blocking receive op

Synchronous send and Async. Receive - 3

P rocess 2
P ro cess 1

n o n b lo c k in g r e c e iv e is s u e d
a n d r e t u r n e d im m e d ia t e ly
b lo c k in g s e n d is s u e d
t r a n s p a r e n t a c k n o w le d g e m e n t
p r o v id e d b y t h e I P C f a c ilit y

p r o c e s s is n o t if ie d
o f t h e a r r iv a l o f
d a ta

e x e c u t io n f lo w
s u s p e n d e d p e r io d

Synchronous Send and

A synchro no us R eceive
S c e n a r io C

14

Data from P1 arrived to P2 before P2 issues a non-blocking

receive op. P2 is notified of the arrival of data

Asynchronous send and Asynchronous

receive
P rocess 2
P rocess 1

n o n b lo c k in g r e c e iv e is s u e d
a n d r e t u r n e d im m e d ia t e ly
b lo c k in g s e n d is s u e d
p r o c e s s is n o t if ie d
o f t h e a r r iv a l o f
d a ta

e x e c u t io n f lo w
s u s p e n d e d p e r io d

A synchronous Send and

A synchro no us R eceive
S c e n a r io C

15

Does P1 need an acknowledgement from P2?

Event diagram
Proce ss B
P roce ss A
t im e
req u est 1

resp o n se 1

req u est 2
in t e r p r o c e s s c o m m u n ic a t io n
e x e c u t io n f lo w
p r o c e s s b lo c k e d

resp o n se2

E v e n t d i a g r a m fo r a p r o t o c o l

16

Synchronous send and receive

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.
P ro c ess 1
P ro c ess 2
r e c e iv e f r o m p r o c e s s 2 is s u e d
p r o c e s s 1 b lo c k e d p e n d in g d a t a
fro m p ro c ess 2 .
r e c e iv e d f r o m p r o c e s s 1 is s u e d
p r o c e s s 2 b lo c k e d p e n d in g d a t a
fro m p ro c ess 1 .

17

P1 is waiting for P2s data; P2 is waiting for P1s data.

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 programmers responsibility to using child processes or threads if
asynchronous operations are desired.
proce ss

m a in t h r e a d

new

m a in t h r e a d c o n t in u e s w it h
o t h e r p r o c e s s in g

t h r e a d is s u e s a b lo c k in g I P C o p e r a t io n

t h r e a d is b lo c k e d

t h r e a d is u n b lo c k e d a f t e r t h e o p e r a t io n is f u lf ille d

18

Deadlocks and Timeouts

19

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

Indefinite blocking due to a deadlock

P roce ss 1

P roce ss 2

" r e c e iv e fr o m p r o c e s s 2 " is s u e d ;
p r o c e s s 1 b lo c k e d p e n d in g d a ta
fro m pro ce ss 2 .
a n o p e ra tio n

" r e c e iv e f r o m p r o c e s s 1 " is s u e d ;
p r o c e s s 2 b lo c k e d p e n d in g d a ta
fro m pro ce ss 1 .

proce ss
e x e cu tin g
proce ss
blo ck e d

20

P1 is waiting for P2s data; P2 is waiting for P1s data.

Data Representation

21

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 necessarystandard 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)

Data Encoding Protocols

le v e l o f a b s t r a c t io n

d a t a e n c o d in g s c h e m e s
a p p lic a tio n s p e c if ic d a ta e n c o d in g la n g u a g e
g e n e r a l d a ta e n c o d in g la n g u a g e

n e tw o r k d a ta e n c o d in g s ta n d a r d
22

S a m p le S t a n d a r d s
X M L :( E x te n s ib le M a r k u p L a n g u a g e )

A S N .1 ( A b s tr a c t S y n ta x N o ta tio n )
S u n X D R ( E x te r n a l D a ta R e p r e s e n ta tio n )

Sample XML file

http://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>you@yourAddress.com</to>
<from>me@myAddress.com</from>
<subject>XML Is Really Cool</subject>
<text> How many ways is XML cool? Let me count the
ways... </text>

23

</message>

Data Marshalling
" T h is i s a t e s t . "

1 .2

7 .3

-1 .5

m a rsh a llin g

host A

1 . f la t t e n i n g o f s t r u c t u r e d d a t a i t e m s
2 . c o n v e r t in g d a t a t o e x t e r n a l ( n e t w o r k )
r e p r e s e n t a t io n

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

u n m a rsh a llin g
" T h is is a t e s t . "

-1 .5
7 .3
1 .2

24

host B

1 . c o n v e r t d a t a t o in t e r n a l r e p r e s e n t a t i o n
2 . r e b u il d d a t a s t r u c t u r e s .
E x t e r n a l t o in t e r n a l r e p r e s e n t a t io n a n d v ic e v e r s a
is n o t r e q u ir e d
- if t h e t w o s id e s a r e o f t h e s a m e h o s t t y p e ;
- if t h e t w o s id e s n e g o t ia t e s a t c o n n e c t io n .

The OSI (Open System Interconnection ) Sevenlayer network architecture

a p p lic a t io n la y e r

a p p lic a t io n la y e r

p r e s e n t a t io n la y e r

p r e s e n t a t io n la y e r

s e s s io n la y e r

25

Message

s e s s io n la y e r

t r a n s p o r t la y e r

Segment

t r a n s p o r t la y e r

n e t w o r k la y e r

Datagram

n e t w o r k la y e r

d a t a lin k la y e r

Frame

d a t a lin k la y e r

p h y s ic a l la y e r

0/1

p h y s ic a l la y e r

Text-based protocols

26

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 textbased.

Event diagram
P roce ss 2

P roce ss 1

t im e
req u est 1

resp o n se 1

request 2
in t e r p r o c e s s c o m m u n ic a t io n
e x e c u t io n f lo w
p r o c e s s b lo c k e d

resp o n se2

E v e n t d i a g r a m fo r a p r o t o c o l

27

Event Diagram for a HTTP session

w eb serv er

w eb b ro w ser

req u est

resp o n se

28

r e q u e s t is a m e s s a g e in 3 p a r t s :
- < c o m m a n d > < d o c u m e n t a d d d r e s s > < H T T P v e r s io n >
- a n o p t io n a l h e a d e r
- o p t io n a l d a t a f o r C G I d a t a u s in g p o s t m e t h o d
r e s p o n s e is a m e s s a g e c o n s is t in g o f 3 p a r t s :
- a s t a t u s lin e o f t h e f o r m a t < p r o t o c o l> < s t a t u s c o d e > < d e s c r ip t io n >
- h e a d e r in f o r m a t io n , w h ic h m a y s p a n s e v e r a l lin e s ;
- t h e d o c u m e n t it s e lf .

Sequence Diagram
Process A

P roce ss B

req u est 1

resp o n se 1

req u est 2
in t e r p r o c e s s c o m m u n ic a t io n
resp o n se 2

29

Sequence diagram for a HTTP session

Process A

P roce ss B

req u est 1

resp o n se 1

req u est 2
in t e r p r o c e s s c o m m u n ic a t io n
resp o n se 2

30

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.

31

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.

32

The Basic HTTP protocol

w eb serv er

w eb b ro w ser

req u est

resp on se

r e q u e s t is a m e s s a g e in 3 p a r t s :
- < c o m m a n d > < d o c u m e n t a d d d r e s s > < H T T P v e r s io n >
- a n o p t io n a l h e a d e r
- o p t io n a l d a t a f o r C G I d a t a u s in g p o s t m e t h o d
r e s p o n s e is a m e s s a g e c o n s is t in g o f 3 p a r t s :
- a s t a t u s lin e o f t h e f o r m a t < p r o t o c o l> < s t a t u s c o d e > < d e s c r ip t io n >
- h e a d e r in f o r m a t io n , w h ic h m a y s p a n s e v e r a l lin e s ;
- t h e d o c u m e n t it s e lf .
W e w ill e x p lo r e H T T P in d e t a ils la t e r t h is q u a r t e r .

33

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/1.1 200 OK
Date: Wed, 11 Oct 2000 04:51:18 GMT
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>
<HEAD>
<TITLE>Mei-Ling L. Liu's Home Page
</TITLE>
</HEAD>
<BODY bgcolor=#ffffff>

34

HTTP Request
HTTP response status line
HTTP response header

document content

HTTP Session
1. Telnet to your favorite Web server:
unix> telnet ise.gmu.edu 80
Opens a TCP connection to port 80 at ise.gmu.edu.
(default HTTP server port)

2. Type in a GET HTTP request:

GET /~yhwang1/ HTTP/1.1
Host: 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!

35

IPC paradigms and implementations

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

le v e l o f
a b s tr a c tio n

I P C p a r a d ig m s
r e m o te p ro c e d u re /m e th o d
socket API
d a t a t r a n s m is s io n

36

E x a m p le I P C I m p le m e n t a tio n s
R e m o t e P r o c e d u r e C a ll ( R P C ) , J a v a R M I
U n ix s o c k e t A P I , W in s o c k
s e r ia l/ p a r a lle l c o m m u n ic a t io n

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