Message Passing Model – Interprocess Communication

By | September 26, 2021

Message Passing Model – Interprocess Communication

  • A message is a collection of information that may be exchanged between a sending and a receiving process.
  • A message may contain data, execution commands, or even some code to be transmitted between two or more process.
  • A message is characterized by its type, length, sender and receiver IDs and a data field.
  • A message format is flexible and negotiable by each sender-receiver pair.

Message Format

  • The format of a message depends upon two factors :
  1. The objectives of the message facility.
  2. Whether the facility runs on a single computer or on a distributed system.
  • In some operating systems short, fixed length messages are preferred in order to minimize processing and storage overhead.
  • In case, a large amount of data is to be sent, the data is placed in a file and the message then simply references that file.
  • It consists of two parts : message header and message body.
  • The header has a fixed format within a given operating system and contains the information about the message.
  • The message body is optional and contains the actual content of the message.

General Message Format in Message Passing Model - Interprocess Communication

  • The header may contain an identification of the source and intended destination of the message, a length field, and a type field to discriminate among various types of messages.
  • There may also be additional control information, such as pointer field so that a linked list of messages can be created, a sequence number, to keep track of the number and order of messages passed between source and destination; and a priority field.

Processes generally send and receive messages by using Send and Receive primitives :

Send (receiver process, message);

Receive (sender process, message);

  • The send and receive calls are normally implemented as operating system calls.
  • The send call sends a message to a given receiver process. The receiver call receives message from a given sender process.

The following four system calls are used for message transfer among processes:

msgget( ) : It returns (and possibly creates) message descriptor(s) to designate a message from queue for use in other system calls.

msgctl() : It has options to set and return parameters associated with a message descriptor. It also has an option to remove descriptors.

msgsnd() : It sends a message using a message queue.

msgrcv() : It receives a message using a message queue.

Implementation issues in messages

The various implementation issues that arise in interprocess communication using messages are:

1. Naming of the sender and receiver processes : Naming conventions used in the send and receive calls provide answers to some key questions

(i) How does the sender process know the name of the receiver ?

(ii) How does the receiver process know the name of sender ?

2. Message delivery protocols : Protocols are the set of rules that determine the message data formats and actions of processes while sending and receiving messages.

3. Operating system responsibilities : Buffering of messages, blocking and waking of processes etc.


  • Processes that want to communicate must have a way to refer to each other. Processes can name each other directly or indirectly.
  • If the processes use direct naming communication is known as direct communication. IE the processes use indirect naming, it is known as indirect communication.

1. Direct Communication

  • Direct Communication establishes a link between two processes. A communication link is a unidirectional path along which information flows.
  • Two processes use single communication link to share information.
  • In this method, there cannot be more than one link between two processes.
  • Each process that wants to communicate must explicitly name the recipient or sender of communication.

Direct communication in Message Passing Model - Interprocess Communication

  • Send and receive functions used in direct communication are given below :

Send (process name, message), Receive (process name, message)

Send (A, message)-Send a message to process A

Receive (B, message)-Receive a message from process B

2. Indirect Communication

  • In indirect communication, no direct communication link exists between two processes.
  • In this, messages are sent to and received from mailboxes.
  • A mailbox is a specialized repository where messages can be placed by processes and from which messages can be removed.
  • In indirect communication, more than two processes can share a mailbox.
  • No communication between two processes is possible if they do not share a mailbox.
  • Each mailbox has a unique identification.
  • A process can communicate with some other process via a number of different mailboxes.
  • Indirect Communication is depicted in figure. Processes A, B and C share the mailbox Q. Processes A and C share the mailbox P.
  • Processes A and C can communicate through both the mailboxes P and Q.

Indirect Communication Message Passing Model - Interprocess Communication

  • Whereas the processes B and C can communicate only via mailbox Q.
  • The send and receive primitives in indirect communication are:

Send (mailbox, message) and receive (mailbox, message)

Send (P, message)-Send a message to mailbox P.

Receive (P, message)-Receive a message from mailbox P

  • A strength of the use of indirect addressing is that, by decoupling other sender and receiver, it allows for greater flexibility in the use of messages.
  • The relationship between sender and receiver processes can be one-to-one, many-to-one, one-to-many, or many-to-many.
  • A one-to-one relationship allows a private communication link to be set up between two processes. In such a way, the interaction between these two processes is insulated from erroneous interference from other processes.

one-to-one relationship

  • A many-to-one relationship is used in client/server interaction. One process provide service to a number of other processes. In such a case, mailbox is called as port.

Many-to-one relationship

  • A one-to-many relationship allows for one sender and multiple receiver processes useful for applications where a message or some information is to be broadcast to a set processes.

One-to-Many relationship

  • A many-to-many relationship allows multiple server processes to provide concurrent service to multiple clients.

Many-to-Many relationship

  • A mailbox may be owned either by a process or by the operating system.
  • If the mailbox is owned by a process (that is, the mailbox is a part of the address space of the process), then we distinguish between the owner (who can only receive the messages through this mailbox) and the user (who can only send messages to the mailbox).
  • When a process that owns a mailbox terminates, the mailbox disappears.
  • A mailbox owned by operating system is independent and is not attached to any particular process. In such a case, operating system provides the mechanism that allows a process to create a mailbox, send and receive message through a mailbox and delete mailbox.
  • The process that creates a new mailbox is the owner of that mailbox by default.
  • Initially, the owner is the only process that can receive messages through that mailbox.
  • The ownership of a mailbox can be passed to another process by using appropriate system calls.

Message delivery protocols

  • A protocol is a set of rules and conventions shared by communicating entities.
  • Message passing can be blocking or non-blocking.

Message Passing Model - Interprocess Communication

In blocking protocol, a sender process is blocked till the message is delivered to the receiver. In this case, a sender process has a guarantee that the message sent by it is delivered before it continues its execution.

A blocking protocol normally includes:

  1. Blocking Send : The sender process is blocked until the message is received by the receiving process or by the mailbox.
  2. Blocking Receive : The receiver blocks until a message is available.
  • Thus when both sender as well as receiver is blocked, it is known as rendezvous. This combination allows for tight synchronization between processes.

In Non-blocking protocol, a sender continues the execution after performing a send operation irrespective of whether the message is delivered or not.

  • A non-blocking protocol has the advantage that a sender is free to continue its execution immediately after sending a message.
  • However, a sender has no means of knowing when (and whether) its message delivered to the receiver.

A non blocking protocol includes :

  1. Non-blocking send : The sending process sends the message and resumes operation.
  2. Non-blocking receive : The receiver retrieves either a valid message or a null.


Whether the communication is direct or indirect, messages exchanged by communicating processes reside in a temporary queue. There are three different ways of implementing such queues :

1. Zero Capacity

  • Zero capacity queue cannot keep any message waiting in it. Thus it has maximum length 0.
  • For this, a sending process must be blocked until the receiving process receives the message.
  • System with zero capacity queue is known as message system with no buffering.

2. Bounded Capacity

  • Bounded capacity queue has finite length n. Thus it can have n messages waiting in it.
  • If the queue is not full, new messages can be placed in the queue and the sending process is not blocked, it can continue execution without waiting.
  • If the link or queue is full, then the sender must be blocked until space is available in the queue.
  • This system is also known as automatic buffering.

3. Unbounded Capacity

  • Unbounded capacity queue has infinite length. Thus, any number of messages can wait in it.
  • In such a system, sending process is never blocked, it can continue execution without waiting.

Related Articles:

3 thoughts on “Message Passing Model – Interprocess Communication

  1. Rusty

    Hi there i am kavin, its my first occasion to commenting anyplace, when i read this post i thought i
    could also create comment due to this brilliant piece of writing.


Leave a Reply

Your email address will not be published. Required fields are marked *