inter process communication in operating system ppt

1. 1
Interprocess Communications

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

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

4. 4
Unicast vs. Multicast
P2
P1 P1
P2 P3 P4
...
unicast m ulticast
m
m m m

5. 5
Process 1 Process 2
data
sender receiver
Interprocess Communications in Distributed
Computing

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

7. 7
Interprocess Communication in basic HTTP
C 1 C 2
S 3 S 4
C 4
W e b se rve r
W e b browse r
a pro ce ss
an o pe ra tion
data fl ow
ope ration s :
S 1 : acce pt co n n e ctio n
S 2 : re ce i ve (re qu e st)
S 3 : s e n d (re spon se )
S 3 : di sco n n e ct
C 1 : m ak e con n e cti on
C 2 : se n d (re qu e st)
C 3 : re ce ive (re s pon se )
C 4 : dis con n e ct
S 2
C 3
S 1
H TTP
re qu e st
H TTP
re s pon se
Processing order: C1, S1, C2, S2, S3, C3, C4, S4
s4

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

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

10. 10
Synchronous send and receive
pro cess 1
running on ho st 1
bloc king send starts
bloc king send returns
bloc king rec eive s tarts
bloc king rec eive ends
exec ution flow
suspended period
Synchro no us Send and R eceive
an operation
ac know ledgem ent of data rec eived
provided by the IP C fac ility
pro cess 2
running on ho st 2
Client Server
Sender Receiver
Event Diagram

11. 11
Asynchronous send and synchronous
receive
P ro ce ss 1
P ro c e ss 2
bloc k ing rec eive s tarts
bloc king rec eive return s
exec ution flow
s us pended period
Asynchro no us Se nd and
Sync hro no us R ece i ve
nonbloc king s en d
operation
Event Diagram
Client Server
Sender Receiver

12. 12
Synchronous send and Async. Receive - 1
P ro cess 1
P ro cess 2
nonbloc king rec eive is sued
exec ution flow
suspended period
Synchro no us Send and
Asynchro no us R ecei ve
bloc king s end issued
S ce n ario A
transparent ac know ledgem ent
provided by the IP C fac ility
Data from P1 was received by P2
before issuing a non-blocking receive op in P2

13. 13
Synchronous send and Async. Receive - 2
indefinite
bloc king
P ro c ess 1
P ro c ess 2
nonbloc king rec eive is s ued
and returned im m ediately
exec ution flow
s us pended period
Sync hro no us Se nd and
Async hro no us R ec e i ve
bloc king s end is s ued
S ce n ario B
P ro c ess 1
P ro ce ss 2
Data from P1 arrived to P2 after P2 issued a
non-blocking receive op

14. 14
Synchronous send and Async. Receive - 3
P ro cess 1
P ro cess 2
nonbloc king rec eive is s ued
and returned im m ediately
exec ution flow
s us pended period
Synchro no us Send and
Asynchro no us R ecei ve
bloc king s end is s ued
S ce n ario C
proc es s is notified
of the arrival of
data
transparent ac know ledgem ent
provided by the IP C fac ility
Data from P1 arrived to P2 before P2 issues a non-blocking
receive op. P2 is notified of the arrival of data

15. 15
Asynchronous send and Asynchronous
receive
P ro cess 1
P ro cess 2
nonbloc king rec eive is sued
and returned im m ediately
exec ution flow
suspended period
Asynchro no us Send and
Asynchro no us R ecei ve
bloc king s end is sued
S ce n ario C
proc es s is notified
of the arrival of
data
Does P1 need an acknowledgement from P2?

16. 16
Event diagram
Proce ss A
Proce ss B
interproc ess c om m unic ation
exec ution flow
proc ess bloc ked
Event diag ram for a pro tocol
request 1
response 1
response2
request 2
tim e
Synchronous send and receive

17. 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.
rec eive from proc ess 2 issued
rec eived from proc ess 1 issued
proc ess 1 bloc ked pending data
from proc ess 2.
proc ess 2 bloc ked pending data
from proc ess 1.
Proc ess 1 P roc ess 2
P1 is waiting for P2’s data; P2 is waiting for P1’s data.

18. 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.
proce s s
m ain thread
new th read is s u es a blo c king IP C o p eratio n
thread is blo c ked
thread is u nb loc k ed after the operatio n is fulfilled
m ain thread c o n tinu es w ith
oth er pro c es s in g

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

20. 20
Indefinite blocking due to a deadlock
"re ce ive from proce ss 2" issue d;
"re ce ive from proce ss 1" issue d;
proce ss 1 block e d pe nding data
from proce ss 2.
process 2 block e d pe nding data
from proce ss 1.
Proce ss 1 Proce ss 2
pro ce ss
e x e cu tin g
pro ce ss
blo ck e d
a n o pe rati on
P1 is waiting for P2’s data; P2 is waiting for P1’s data.

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

22. 22
Data Encoding Protocols
application specific data encoding language
generaldata encoding language
network data encoding standard
data encoding schemes Sample Standards
level of abstraction
XML:(Extensible Markup Language)
ASN.1(Abstract Syntax Notation)
Sun XDR(ExternalData Representation)

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

24. 24
Data Marshalling
"T his is a test."
"T his is a test."
1.2 7.3 -1.5
1.2
7.3
-1.5
110011 ... 10000100 ...
m arshalling
unm arshalling
1. flattening of struc tured data item s
2. c onverting data to external (netw ork)
representation
1. c onvert data to internal representation
2. rebuild data struc tures.
host A
host B
External to internal representation and vic e versa
is not required
- if the tw o sides are of the sam e host type;
- if the tw o sides negotiates at c onnec tion.

25. 25
The OSI (Open System Interconnection ) Seven-
layer network architecture
application layer
presentation layer
session layer
transport layer
netw ork layer
data link layer
physical layer
application layer
presentation layer
session layer
transport layer
netw ork layer
data link layer
physical layer
Message
Segment
Datagram
Frame
0/1

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

27. 27
Event diagram
Proce ss 1
Proce ss 2
interproc ess c om m unic ation
exec ution flow
proc ess bloc ked
Event di ag ram for a pro to co l
request 1
response 1
response2
request 2
tim e

28. 28
Event Diagram for a HTTP session
w eb server w eb brow ser
request
response
request is a message in 3 parts:
- <command> <document adddress> <HTTP version>
- an optional header
- optional data for CGI data using post method
response is a message consisting of 3 parts:
- a status line of the format <protocol><status code><description>
- header information, w hich may span several lines;
- the document itself.

29. 29
Sequence Diagram
Proce ss A Proce ss B
interproc ess c om m unic ation
request 1
response 1
request 2
response 2

30. 30
Sequence diagram for a HTTP session
Proce ss A Proce ss B
interproc ess c om m unic ation
request 1
response 1
request 2
response 2

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

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

33. 33
The Basic HTTP protocol
w eb server w eb brow ser
request
response
request is a message in 3 parts:
- <command> <document adddress> <HTTP version>
- an optional header
- optional data for CGI data using post method
response is a message consisting of 3 parts:
- a status line of the format <protocol><status code><description>
- header inform ation, w hich may span several lines;
- the docum ent itself.
We w ill explore HTTP in details later this quarter.

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

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

36. 36
IPC paradigms and implementations
Paradigms of IPC of different levels of abstraction have evolved,
with corresponding implementations.
remote procedure/method
socket API
data transmission serial/parallel communication
Unix socket API, Winsock
Remote Procedure Call (RPC), Java RMI
level of
abstraction
IPC paradigms Example IPC Implementations
UNIX Socket: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html