Inter Process Communication

Rituparna Chaki
 Message Passing

• Message passing is a general method

used for IPC:
– for processes inside the same computer.
– for processes in a networked/distributed
system.
• In both cases, the process may or may not
be blocked while sending a
message or attempting to
receive a message.
• Fixed-length messages:
– simple to implement - can have pool of standard-sized
buffers
• low overheads and efficient for small lengths
– copying overheads if fixed length too long
– can be inconvenient for user processes with variable amount
of data to pass
• may need a sequence of messages to pass all the data
• long messages may be better passed another way e.g. FTP
– copying probably involved, sometimes multiple copying into kernel and out

• Variable-length messages:
– more difficult to implement - may need a heap with garbage
collection
• more overheads and less efficient, memory fragmentation
– more convenient for user processes
• Communication links between processes
– not concerned with physical implementation e.g. shared memory,
processor bus, network etc.
– rather with issues of its logical implementation
• Issues:
– how are links established?
– can a link be associated with more than two processes?
– how many links can there be between every pair of processes?
– what is the capacity of a link?
• i.e. buffer space and how much
– fixed v. variable length messages
– unidirectional v. bidirectional ?
• can messages flow in one or both directions between two linked
processes
• unidirectional if each linked process can either send orreceive but not
both and each link has at least one receiver process connected to it
Basic Message-passing Primitives

A. Frank - P. Weisberg
 Message format

• Consists of header and

body of message.
• In Unix: no ID, only
message type.
• Control info:
– what to do if run out of
buffer space.
– sequence numbers.
– priority.
• Queuing discipline: usually
FIFO but can also include
priorities.
 IPC Requirements

• If P and Q wish to communicate, they need

to:
– establish communication link between them.
– exchange messages via send/receive.
• Implementation of communication link:
– physical (e.g., shared memory, hardware bus)
– logical (e.g., logical properties)

A. Frank - P. Weisberg
 Implementation Questions

• How are links established?

• Can a link be associated with more than two
processes?
• How many links can there be between every
pair of communicating processes?
• What is the capacity of a link?
• Is the size of a message that the link can
accommodate fixed or variable?
• Is a link unidirectional or bi-directional?
A. Frank - P. Weisberg
 Message Passing Systems

1.Direct or Indirect communications (Naming)

2.Symmetric or Asymmetric communications
3.Automatic or Explicit buffering
4.Send-by-copy or send-by-reference
5.fixed or variable sized messages
 Direct/Indirect Communication

• Direct communication:
– when a specific process identifier is used for
source/destination.
– but it might be impossible to specify the source
ahead of time (e.g., a print server).
• Indirect communication (more convenient):
– messages are sent to a shared mailbox which
consists of a queue of messages.
– senders place messages in the mailbox, receivers
pick them up.
 Direct Communication
• Processes must name each other explicitly:
– send(P, message) – send a message to process P
– receive(Q, message) – receive a message from Q
• Properties of communication link:
– Links are established automatically.
– A link is associated with exactly one pair of
communicating processes.
– Between each pair there exists exactly one link.
– The link may be unidirectional, but is usually
bi-directional.
 Direct Addressing
– Symmetric Addressing
• send (P, message) – send to process P
• receive(Q, message) – receive from Q
– Asymmetric Addressing
• send (P, message) – send to process P
• receive(id, message) – rx from any; system sets id =
sender
 Indirect Communication (1)
• Messages are directed and received from
mailboxes (also referred to as ports).
– Each mailbox has a unique id.
– Processes can communicate only if they share a
mailbox.
• Properties of communication link:
– Link established only if processes share a common
mailbox.
– A link may be associated with many processes.
– Each pair of processes may share several
communication links.
– Link may be unidirectional or bi-directional.
 Indirect Communication (2)

• Operations
– create a new mailbox
– send and receive messages through mailbox
– destroy a mailbox
• Primitives are defined as:
send(A, message) – send a message to mailbox A.
receive(A, message) – receive a message from
mailbox A.
 Indirect Communication (3)

• Mailbox sharing
– P1, P2, and P3 share mailbox A.
– P1, sends; P2 and P3 receive.
– Who gets the message?
• Possible solutions:
– Allow a link to be associated with at most two
processes.
– Allow only one process at a time to execute a
receive operation.
– Allow the system to select arbitrarily the receiver.
Sender is notified who the receiver was.
 Messages and Pipes Compared

A. Frank - P. Weisberg
 Synchronization in message passing (1)
• Message passing may be blocking or non-blocking.
• Blocking is considered synchronous
– Blocking send has the sender block until the message is
received
– Blocking receive has the receiver block until a message is
available
• Non-blocking is considered asynchronous
– Non-blocking send has the sender send the message and
continue
– Non-blocking receive has the receiver receive a valid
message or null
 Synchronizing Message Flow

• Message passing may be either blocking or non-

blocking.
– blocking send: sender blocked until message received by
mailbox or process
– nonblocking send: sender resumes operation immediately
after sending
– blocking receive: receiver blocks until a message is
available
– nonblocking receive: receiver returns immediately with
either a valid or null message.
 Synchronization in message passing (2)
• For the sender: it is more natural not to be
blocked after issuing send:
– can send several messages to multiple
destinations.
– but sender usually expect acknowledgment of
message receipt (in case receiver fails).
• For the receiver: it is more natural to be
blocked after issuing receive:
– the receiver usually needs the information before
proceeding.
– but could be blocked indefinitely if sender process
fails before send.
 Synchronization in message passing (3)

• blocking send, blocking receive:

– both are blocked until the message is
received.
– occurs when the communication link is
unbuffered (no message queue).
– provides tight synchronization (rendezvous).
 Synchronization in message passing (4)

Nonblocking send, Blocking receive – most

popular – example:
• Server process that provides
services/resources to other processes. It will
need the expected information before
proceeding.
 Link Capacity – Buffering
• Queue of messages attached to the link;
implemented in one of three ways:
1. Zero capacity – 0 messages
Sender must wait for receiver (rendezvous).
2. Bounded capacity – finite length of n messages
Sender must wait if link full.
3. Unbounded capacity – infinite length
Sender never waits.
 Mailboxes and Ports
• A mailbox can be private to one
sender/receiver pair.
• The same mailbox can be
shared among several senders
and receivers:
– the OS may then allow the
use of message types (for
selection).
• Port: is a mailbox associated
with one receiver and multiple
senders
– used for client/server
applications: the receiver is
the server.
 Ownership of ports and mailboxes
• A port is usually own and created by the
receiving process.
• The port is destroyed when the receiver
terminates.
• The OS creates a mailbox on behalf of a
process (which becomes the owner).
• The mailbox is destroyed at the owner’s
request or when the owner terminates.
• Mailbox Ownership
– process mailbox ownership :
• only the process may receive messages from the mailbox
• other processes may send to the mailbox
• mailbox can be created with the process and destroyed
when the process dies
– process sending to a dead process’s mailbox will need to be
signalled
• or through separate create_mailbox and
destroy_mailbox calls
– possibly declare variables of type ‘mailbox’
– system mailbox ownership :
• mailboxes have their own independent existence, not
attached to any process
• dynamic connection to a mailbox by processes
– for send and/or receive
 Mutual Exclusion – Message Passing

• create a mailbox mutex Process Pi:

shared by n processes. var msg: message;
• send() is non-blocking. repeat
receive(mutex,msg);
• receive() blocks when CS
mutex is empty. send(mutex,msg);
• Initialization: send(mutex, RS
“go”); forever
• The first Pi who executes
receive() will enter CS.
Others will be blocked
until Pi resends msg.
 Bounded-Buffer – Message Passing

• The producer place items (inside messages) in the

mailbox mayconsume.
• mayconsume acts as our buffer: consumer can
consume item when at least one message present.
• Mailbox mayproduce is filled initially with k null
messages (k= buffer size).
• The size of mayproduce shrinks with each
production and grows with each consumption.
• Solution can support multiple
producers/consumers.
• Buffering - the number of messages that can reside in a
link temporarily
– Zero capacity - queue length 0
• sender must wait until receiver ready to take the message
– Bounded capacity - finite length queue
• messages can be queued as long as queue not full
• otherwise sender will have to wait
– Unbounded capacity
• any number of messages can be queued - in virtual space?
• sender never delayed
• Copying
– need to minimise message copying for efficiency
– copy from sending process into kernel message queue space
and then into receiving process?
• probably inevitable in a distributed system
• advantage that communicating processes are kept separate
– malfunctions localised to each process

Operating Systems: IPC 29

 – direct copy from one process to the other?
• from virtual space to virtual space?
• message queues keep indirect pointers to message in process virtual space
• both processes need to be memory resident i.e. not swapped out to disc,
at time of message transfer
– shared virtual memory
• message mapped into virtual space of both sender and receiver processes
• one physical copy of message in memory ever
• no copying involved beyond normal paging mechanisms
• used in MACH operating system
Aside : Mach’s Copy-on-Write mechanism (also used in Linux
forks) :
• single copy of shared material mapped into both processes virtual space
• both processes can read the same copy in physical memory
• if either process tries to write, an exception to the kernel occurs
• kernel makes a copy of the material and remaps virtual space of writing
process onto it
• writing process modifies new copy and leaves old copy intact for other
process
Stream-Oriented Communication
 Stream-Oriented Communication
• RPC and message-oriented communication are
based on the exchange of discrete messages
– Timing might affect performance, but not
correctness

• In stream-oriented communication the message

content (multimedia streams) must be delivered
at a certain rate, as well as correctly
– e.g., music or video
 Discrete and Continuous Media
• Media: means by which information is conveyed
• Types of media
– Discrete media
• No temporal dependence between data items
• ex) text, still images, object code or executable files
– Continuous media
• Temporal dependence between data items
• ex) Motion - series of images
 Data Streams
• Data stream = sequence of data items
• Can apply to discrete, as well as continuous
media
– e.g. UNIX pipes or TCP/IP connections which are
both byte oriented (discrete) streams
– Messages are related by send order
• Audio and video require continuous time-
based data streams
 A continuous data stream is a connection
oriented communication facility that supports
isochronous communication.

Streams are
•Unidirectional -Generally a single source and one or more
destinations
•Simple Stream
•Complex Stream
 Streams
• Simple streams have a single data sequence
• Complex streams have several substreams,
which must be synchronized with each other;
for example a movie with
– One video stream
– Two audio streams (for stereo)
– One stream with subtitles
 Data Streaming
• Asynchronous transmission mode: the order is
important, and data is transmitted one after the
other, no restriction to when data is to be delivered
• Synchronous transmission mode defines a maximum
end-to-end delay for individual data packets
• Isochronous transmission mode has a maximum and
minimum end-to-end delay requirement (jitter is
bounded)
– Not too slow, but not too fast either
 Distributed System Support
• Data compression, particularly for video
• Quality of the transmission
• Synchronization
 Multicast Communication
• Multicast: sending data to multiple receivers.
• Network- and transport-layer protocols for
multicast bogged down at the issue of setting up
the communication paths to all receivers.
• Peer-to-peer communication using structured
overlays can use application-layer protocols to
support multicast
 Application-Level Multicasting
• The overlay network is used to disseminate
information to members
• Two possible structures:
– Tree: unique path between every pair of nodes
– Mesh: multiple neighbors ensure multiple paths
(more robust)
Multicasting a stream to several receivers