Carnegie Mellon

Inter-Process Communications
 Carnegie Mellon

Communication between processes

 Processes live in different “worlds”; memory address spaces due to the

virtual memory.
 Communication between processes is needed
o e.g. killing a process from a shell command
o e.g. sending data between processes

Process B’s
address space
Process A’s
address space
Process C’s
address space
 Carnegie Mellon

Inter-process Communication (IPC)

 Independent process cannot affect or be affected by the execution of another
process. The cooperating process can affect or be affected by the execution of
another process. Cooperating processes or threads need inter-process
communication (IPC)
o Data transfer
o Sharing data
o Event notification
o Resource sharing
o Process control
 Processes may be running on one or more computers connected by a network
 The method of IPC used may vary based on the bandwidth and latency of
communication between the threads, and the type of data being communicated.
 IPC may also be referred to as inter-application communication
 Carnegie Mellon

IPC mechanisms
 Cooperating processes require an IPC mechanism that will allow them to
exchange data - that is, send data to and receive data from each other
 Two models of IPC
o Shared memory
o Message passing

Shared memory IPC: Two

(or more) processes share the
same region of memory

Message passing IPC: Two

processes may communicate
by exchanging messages with
one another

Shared Memory Message Passing

 Carnegie Mellon

IPC- Shared Memory

 Allows multiple processes to share virtual memory space.
 Fastest but not necessarily the easiest (synchronization-wise) way for
processes to communicate with one another.
 Carnegie Mellon

IPC in Shared-Memory Systems

▪ Producer-Consumer Problem
▪ Paradigm for cooperating processes: The two processes share a common
space or memory location known as a buffer where the item produced by
the Producer is stored and from which the Consumer consumes the item if
needed.
o unbounded-buffer in which the Producer can keep on producing items
and there is no limit on the size of the buffer
o bounded-buffer in which the Producer can produce up to a certain
number of items before it starts waiting for Consumer to consume it.
There is a fixed buffer size
 Carnegie Mellon

IPC in Shared-Memory Systems

▪ Producer-Consumer Problem
o Producer and the Consumer will share some
common memory
o Producer produces items
o If the total produced item is equal to the size
of the buffer, Producer will wait to get it
consumed by Consumer
o Consumer will first check for the availability
of the item.
o If no item is available, Consumer will wait
for Producer to produce it
o If there are items available, Consumer will
consume them
 Carnegie Mellon

IPC in Shared-Memory Systems

 An area of memory shared among the processes that wish to
communicate
 The communication is under the control of the users processes not the
operating system.
 Major issues is to provide a mechanism that will allow the user
processes to synchronize their actions when they access shared
memory.
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Message passing provides a mechanism to allow
processes to communicate and synchronize their
actions without sharing the same address space
▪ IPC facility provides two operations:
send(message)
receive(message)
▪ The message size is either fixed or variable
▪ A standard message can have two parts: header
and body
▪ The header consists of message type, destination
id, source id, message length, and control
information
 Carnegie Mellon

IPC in Message-Passing Systems

▪ If processes P and Q want to communicate, they must send messages to
and receive messages from each other: a communication link must exist
between them
▪ Logically implementing a link and the send()/receive() operations:
o Direct or indirect communication
o Synchronous or asynchronous communication
o Automatic or explicit buffering
▪ Physical implementation of communication link
o Shared memory
o Hardware bus
o Network
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Processes that want to communicate must have a way to refer to each
other (Naming)
▪ They can use either direct or indirect communication.
▪ Direct communication, each process that wants to communicate must
explicitly name the recipient or sender of the communication
▪ In this scheme, the send() and receive() primitives are defined as:
send(P, message) → Send a message to process P
receive(Q, message) → Receive a message from process Q
▪ Links are established automatically
▪ The link may be unidirectional but is usually bi-directional
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Indirect communication the messages are sent to and received from

mailboxes, or ports. A mailbox can be viewed abstractly as an object into
which messages can be placed by processes and from which messages
can be removed
o Each mailbox has a unique id
o Processes can communicate only if they share a mailbox
▪ Properties of communication link
o Link established only if processes share a common mailbox
o Link may be unidirectional or bi-directional
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Indirect communication
▪ The send() and receive() primitives are defined as follows:
o send(A, message) → Send a message to mailbox A
o receive(A, message) → Receive a message from mailbox A
▪ The operating system then must provide a mechanism that allows a
process to do the following:
o Create a new mailbox
o Send and receive messages through the mailbox
o Delete a mailbox
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Synchronization
▪ Communication between processes takes place through calls to send() and
receive() primitives. There are different design options for implementing
each primitive
▪ Message passing may be either blocking or nonblocking - also known as
synchronous and asynchronous
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Synchronization
▪ Blocking is considered synchronous
o Blocking send -- the sender is blocked until the message is received
o Blocking receive -- the receiver is blocked until a message is
available
▪ Non-blocking is considered asynchronous
o Non-blocking send -- the sender sends the message and continue
o Non-blocking receive -- the receiver receives:
• A valid message

• Null message
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Buffering
▪ Whether communication is direct or indirect, messages exchanged by
communicating processes reside in a temporary queue. Such queues can be
implemented in three ways:
o Zero capacity: The queue has a maximum length of zero; thus, the link
cannot have any messages waiting in it. In this case, the sender must block
until the recipient receives the message
o Bounded capacity: The queue has finite length n; thus, at most n messages
can reside in it. If the queue is not full when a new message is sent, the
message is placed in the queue and the sender can continue execution
without waiting
 Carnegie Mellon

IPC in Message-Passing Systems

▪ Buffering
o Unbounded capacity: The queue’s length is potentially infinite; thus,
any number of messages can wait in it
o The sender never blocks
 Carnegie Mellon

Examples of IPC Systems

▪ Windows
▪ Message-passing centric via advanced local procedure call (LPC) facility
o Only works between processes on the same system
o Uses ports (like mailboxes) to establish and maintain communication
channels
 Carnegie Mellon

Examples of IPC Systems

▪ Advanced local procedure calls (ALPC) in Windows
▪ Communication works as follows:

o The client opens a handle to the

subsystem’s connection port object
o The client sends a connection request
o The server creates two private
communication ports and returns the
handle to one of them to the client
o The client and server use the
corresponding port handle to send
messages or callbacks and to listen for
replies
 Carnegie Mellon

Examples of IPC Systems

▪ Pipes
o The pipe is a type of data channel that is unidirectional in nature
o A pipe acts as a channel allowing two processes to communicate
o A pipe can be constructed on the command line using the | character
o Communication is achieved by one process writing into the pipe and other
reading from the pipe
o To achieve the pipe system call, create two files, one to write into the file
and another to read from the file
 Carnegie Mellon

Examples of IPC Systems

▪ Ordinary pipes – cannot be accessed from outside the process that
created it
o Ordinary pipes provide a simple mechanism for allowing a pair of processes
to communicate
o Ordinary pipes allow two processes to communicate in standard producer-
consumer fashion: the producer writes to one end of the pipe (the write-
end) and the consumer reads from the other end (the read-end)
o If two-way communication is required, two pipes must be used, with each
pipe sending data in a different direction
 Carnegie Mellon

Examples of IPC Systems

▪ Ordinary pipes – cannot be accessed from outside the process that
created it
o Ordinary pipes exist only while the processes are communicating with one
another
o On both UNIX and Windows systems, once the processes have finished
communicating and have terminated, the ordinary pipe ceases to exist
 Carnegie Mellon

Examples of IPC Systems

▪ Ordinary pipes
o On UNIX systems, ordinary pipes are constructed using the function
pipe(int fd[])
o An ordinary pipe cannot be accessed from outside the process that created
it
o Typically, a parent process creates a pipe and uses it to communicate with
a child process that it creates via fork()

File descriptors for an ordinary pipe

 Carnegie Mellon

Examples of IPC Systems

▪ Pipes
▪ Named pipes – can be accessed without a parent-child relationship
 Carnegie Mellon

Examples of IPC Systems

▪ Ordinary pipes
▪ Named pipes
o CreateNamedPipe() function is used to create Named pipes.
o ConnectNamedPipe() function is used to connect a client
o ReadFile() and WriteFile() functions are used to accomplish a communication
over the named pipe
 Carnegie Mellon

Examples of IPC Systems

Ordinary Pipes Named Pipes
 Carnegie Mellon

Communication in Client–Server Systems

▪ Sockets
▪ A socket is defined as an end-point for communication
▪ A pair of processes communicating over a network employs a pair of
sockets-one for each process
▪ A socket is identified by an IP address concatenated with a port number
o The server waits for incoming client requests by listening to a specified
port. Once a request is received, the server accepts a connection from the
client socket to complete the connection
▪ Servers implementing specific services (such as SSH, FTP, and HTTP)
listen to well-known ports.
 Carnegie Mellon

Communication in Client–Server Systems

▪ Sockets
▪ The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8
▪ Communication consists of a pair of sockets
▪ All ports below 1024 are well known, used for standard services
o SSH server listens to port 22
o FTP server listens to port 21
o Web or HTTP server listens to port 80
 Carnegie Mellon

Communication in Client–Server Systems

Communication using sockets

 Carnegie Mellon

Communication in Client–Server Systems

▪ Sockets
▪ Three types of sockets
o Connection-oriented (TCP)
o Connectionless (UDP)
o MulticastSocket class-data can be
sent to multiple recipients
 Carnegie Mellon

Communication in Client–Server Systems

▪ Remote Procedure Calls (RPC)

▪ RPC abstracts procedure calls between processes on networked systems
o Uses ports for service differentiation
▪ Stubs - client-side proxy for the actual procedure on the server
▪ The client-side stub locates the server and marshalls the parameters
▪ The server-side stub receives this message, unpacks the marshalled
parameters, and performs the procedure on the server
▪ On Windows, stub code compiles from specifications written in Microsoft
Interface Definition Language (MIDL)