Interprocess Communications

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

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

3
 Unicast vs. Multicast

P2 P2 P3 ... P4

m
m m m

P1 P1

uni c as t m ul ti c as t

4
 Interprocess Communications in Distributed
Computing

P roc es s 1 P roc es s 2

data

s ender rec eiver

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

6
 Interprocess Communication in basic HTTP

W e b s e rv e r

S1 S2 S3 S4
o pe ra ti o n s :
H TTP S 1 : a cce pt co n n e cti o n
a pro ce s s S 2 : r e c e i ve ( r e q u e s t )
re qu e s t
S 3 : s e n d (re s po n s e )
a n o pe ra ti o n Ss43 : d i s c o n n e c t
H TTP
C 1 : m a k e co n n e cti o n
re s po n s e
C 2 : s e n d (re qu e s t)
da ta fl o w C 3 : r e c e i ve ( r e s p o n s e )
C1 C2 C3 C4
C 4 : di s co n n e ct

W e b bro ws e r

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

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

9
 Synchronous send and receive
pr o c e s s 1 pr o c e s s 2
r unni ng o n ho s t 2
r unni ng o n ho s t 1
Event Diagram

b lo c k in g r ec eiv e s tar ts

b lo c k in g s en d s tar ts an o p er atio n

ex ec u tio n f lo w
ac k n o w led g em en t o f d ata r ec eiv ed s u s p en d ed p er io d
b lo c k in g s en d r etu r n s p r o v id ed b y th e I P C f ac ility b lo c k in g r ec eiv e en d s

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

Client Server
Sender Receiver
10
 Asynchronous send and synchronous
receive
P rocess 2
P rocess 1
Event Diagram

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

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

o p e r a tio n
e x e c u tio 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 tu r n s

As yn c h r o n o u s S e n d an d
S yn c h r o n o u s R e c e i ve

Client Server
Sender Receiver
11
 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 ed

n o n b lo c k in g r e c e iv e is s u e d
tr 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 th e I P C f a c ility e x e c u tio n f lo w
s u s p e n d e d p e r io d

S yn c h r o n o u s S e n d an d
As yn c h r o n o u s R e c e i ve
S ce n a rio A

Data from P1 was received by P2

12 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 tu r n e d im m e d ia te ly
b lo c k in g s e n d is s u e d

in d e f in ite
b lo c k in g e x e c u tio n f lo w
s u s p e n d e d p e r io d

P rocess 2
P rocess 1 S yn c h r o n o u s S e n d an d
As yn c h r o n o u s R e c e i ve
S c e n a r io B

Data from P1 arrived to P2 after P2 issued a

13 non-blocking receive op
 Synchronous send and Async. Receive - 3

P ro cess 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 tu r n e d im m e d ia te 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 tif ie d
tr a n s p a r e n t a c k n o w le d g e m e n t o f th e a r r iv a l o f
p r o v id e d b y th e I P C f a c ility d a ta
e x e c u tio n f lo w
s u s p e n d e d p e r io d

S yn c h r o n o u s S e n d an d
As yn c h r o n o u s R e c e i ve
S ce n a rio C

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

14 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 tu r n e d im m e d ia te 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 tif ie d
o f th e a r r iv a l o f
d a ta
e x e c u tio n f lo w
s u s p e n d e d p e r io d

As yn c h r o n o u s S e n d an d
As yn c h r o n o u s R e c e i ve
S ce n a rio C

Does P1 need an acknowledgement from P2?

15
 Event diagram
P ro ce s s B
P ro ce s s A

t im e
r eq u es t 1

r es p o n s e 1

r eq u es t 2
in ter p r o c es s c o m m u n ic atio n
ex ec u tio n f lo w
r es p o n s e2
p r o c es s b lo c k ed

E ve nt di ag r am fo r a pr o to 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 r o c es s 1 P r o c es s 2

r ec eiv e f r o m p r o c es s 2 is s u ed
p r o c es s 1 b lo c k ed p en d in g d ata
f r o m p r o c es s 2 .
r ec eiv ed f r o m p r o c es s 1 is s u ed
p r o c es s 2 b lo c k ed p en d in g d ata
f r o m p r o c es s 1 .

17 P1 is waiting for P2’s data; P2 is waiting for P1’s 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 programmer’s responsibility to using child processes or threads if
asynchronous operations are desired.
pr o c e s s

m a in th r e a d

n e w th r e a d is s u e s a b lo c k in g I P C o p e r a tio n

th r e a d is b lo c k e d
m a in th r e a d c o n tin u e s w ith
o th e r p r o c e s s in g
th r e a d is u n b lo c k e d a f te r th e o p e r a tio n is f u lf ille d

18
 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

19
 Indefinite blocking due to a deadlock

Pro ce s s 1 Pro ce s s 2

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

pro ce s s 1 blo ck e d pe n din g da ta
fro m pro ce s s 2 .
" re ce iv e fro m pro ce s s 1 " is s u e d;
pro ce s s 2 blo ck e d pe n din g da ta
a n o pe ra ti o n
fro m pro ce s s 1 .
pro ce s s
e x e cu ti n g
pro ce s s
bl o ck e d

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

20
 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)
21
 Data Encoding Protocols

level of abstraction
data encoding schem es Sam ple Standards

application specific data encoding language XML:(Extensible Markup Language)

general data encoding language

ASN.1(Abstract Syntax Notation)

Sun XDR(External Data Representation)

netw ork data encoding standard

22
 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>
</message>

23
 Data Marshalling

"T h is is a tes t."

1 .2 7 .3 -1 .5
1 . flatten in g o f s tru c tu red d ata item s
host A m arsh allin g
2 . c o n v ertin g d ata to ex tern al (n etw o rk )
rep res en tatio n
1 1 0 0 1 1 ... 1 0 0 0 0 1 0 0 ...

1 . c o n v ert d ata to in tern al rep res en tatio n

u n m arsh allin g
2 . reb u ild d ata s tru c tu res .

"T h is is a tes t."

-1 .5 Ex tern al to in tern al rep res en tatio n an d v ic e v ers a
is n o t req u ired
7 .3 - if th e tw o s id es are o f th e s am e h o s t ty p e;
1 .2 - if th e tw o s id es n eg o tiates at c o n n ec tio n .

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

ap p lic atio n lay er ap p lic atio n lay er

p res en tatio n lay er p res en tatio n lay er

s es s io n lay er
Message
s es s io n lay er

tran s p o rt lay er tran s p o rt lay er

Segment
n etw o rk lay er
Datagram n etw o rk lay er

d ata lin k lay er Frame d ata lin k lay er

p h y s ic al lay er 0/1 p h y s ic al lay er

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

26
 Event diagram
P ro ce s s 2
P ro ce s s 1

t im e
r eq u es t 1

r es p o n s e 1

r eq u es t 2
in ter p r o c es s c o m m u n ic atio n
ex ec u tio n f lo w
r es p o n s e2
p r o c es s b lo c k ed

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

27
 Event Diagram for a HTTP session
w eb server w eb brow ser

request is a m essage in 3 parts:

request
- <c om m and> <doc um ent adddress> <HT T P version>
- an optional header
- optional data for CG I data using post m ethod

response response is a m essage c onsisting of 3 parts:

- a status line of the form at <protoc ol><status c ode><desc ription>
- header inform ation, w hic h m ay span several lines;
- the doc um ent itself.

28
 Sequence Diagram
Pro ce s s A Pro ce s s B

req u es t 1

res p o n s e 1

req u es t 2

in terp ro c es s c o m m u n ic atio n
res p o n s e 2

29
 Sequence diagram for a HTTP session
Pro ce s s A Pro ce s s B

req u es t 1

res p o n s e 1

req u es t 2

in terp ro c es s c o m m u n ic atio n
res p o n s e 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 s erver w eb brow s er

reques t is a m es s age in 3 parts :

reques t
- < c om m and> < doc um ent adddres s > < HT T P vers ion>
- an optional header
- optional data for C G I data us ing pos t m ethod

res pons e res pons e is a m es s age c ons is ting of 3 parts :

- a s tatus line of the form at < protoc ol> < s tatus c ode> < des c ription>
- header inform ation, w hic h m ay s pan s everal lines ;
- the doc um ent its elf.

W e w ill explore HT T P in details later this quarter.

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 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) ApacheJServ/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>
…

34
 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 ve l of
IPC paradigm s Exam ple IPC Im ple m e ntations
abstraction
remote procedure/method Rem ote Proc edure Call (RPC), Java RM I
socket API Unix soc ket API, W insoc k

data transmission serial/parallel c om m unic ation

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

36