Chapter 2

Interprocess Communication (IPC)

Interprocess Communication (IPC) means that two or more processes can talk to
each other and share information.

In distributed computing, processes may be on different computers, but they still

need to communicate to complete a task.

Example:

 Process 1 sends data.

 Process 2 receives that data.

This sending and receiving happens through a network.

For communication to work correctly, both processes must follow a protocol.

A protocol is simply a set of rules for how to send and receive data.

A process can sometimes act as a sender, and sometimes as a receiver, depending

on the situation.

When one process follows a protocol, it can act as a sender at some times and a
receiver at other times.

Types of IPC Communication

1. Unicast
When one process communicates with only one other process, it is called
unicast.

2. Multicast
When one process communicates with a group of processes, it is called
multicast.
(Multicast will be studied in Chapter 6.)

Figure 2.2 shows the difference between unicast and multicast.

System-Level IPC (Inside the Operating System)

Modern operating systems like UNIX and Windows provide built-in features to help
processes communicate.
These are called operating system–level IPC facilities.

Some examples are:

 Message queues

 Semaphores

 Shared memory

(If you don’t know these terms, don’t worry. They are operating systems topics and
not required for this course.)
Using these system-level tools, programmers can build:

 Low-level network programs (like device drivers)

 Testing tools

 Very simple distributed applications

But normally, developers do not use these low-level tools because they are too
complex.

Higher-Level IPC – Using an API

An IPC API (Application Program Interface) provides an easier way to use IPC.
The API hides all the complicated system details, so the programmer can focus on
the main application logic instead of dealing with low-level IPC issues.

The rest of the chapter will explain IPC APIs in detail.

Archetypal IPC Program Interface

In distributed computing, programmers use an API (Application Program Interface) to

perform IPC.
This API provides simple operations so that processes can communicate without
dealing with complex system details.

A basic IPC API usually provides four main operations:

1. Send

 Used by the sending process.

 Its purpose is to send data to another process.

 It must allow the sender to:

o Identify which process will receive the data

o Specify what data is being sent

2. Receive

 Used by the receiving process.

 Its purpose is to accept data from a sender.

 It must allow the receiver to:

o Identify which process sent the data

o Provide a memory location where the data should be stored

3. Connect

 Used when the IPC system is connection-oriented.

 One process sends a connect request, and the other process issues an accept
connection.

 After this, a logical communication link is established between the two

processes.

4. Disconnect

 Used to close or end a previously established connection.

 Both sides release the resources used for communication.

How These Operations Work

Processes use these operations one after another, depending on what they want to
do.
Each operation causes a specific event:

 A send operation → data is transmitted to the receiver.

 A receive operation → data is delivered to the receiving process.

Both processes work independently.

They do not automatically know what the other process is doing unless the protocol
handles it.

IPC Operations in Distributed Computing

Every distributed computing model (paradigm) uses these basic operations in some
form.
In later chapters, you will see how these operations appear in real protocols and tools.

Example: How a Web Browser Uses IPC

A real protocol like HTTP (Hypertext Transfer Protocol) also uses these basic IPC
actions.

When a web browser opens a website:

1. The browser sends a connect request to the web server.

2. The browser sends a request (using send) to ask for a web page.

3. The server uses send to return the web page data.

4. After the communication is done, both sides disconnect.

Figure 2.3 in your book shows this sequence of operations.

2.2 Event Synchronization

In distributed computing, processes run independently, and they do not know what
the other process is doing.
This creates a problem:
How do two processes communicate in the correct order?

Example:
In HTTP communication (browser ↔ server):

 The browser must connect first

 Then it can send a request

 The server must wait until the browser is ready before sending data

 The browser must know exactly when the data arrives so it can show it to the
user

To manage this, we need event synchronization.

Blocking (Synchronous) Operations

The simplest way to do synchronization is using blocking.

What is blocking?

Blocking means:
A process stops and waits until an IPC operation is fully completed.

Example:
The browser performs actions in this order:

1. Blocking connect → wait until the connection is accepted

2. Blocking receive → wait until the server sends the data

3. After receiving data → continue processing and display it

The operating system automatically handles blocking and unblocking.

Blocked vs Unblocked

 When a process is waiting → it is in blocked state

 When the operation completes → it becomes unblocked, and execution

continues

If the operation never completes, the process stays blocked forever (unless
someone stops it).

Asynchronous (Nonblocking) Operations

A nonblocking or asynchronous operation does not cause the process to wait.

After issuing the operation, the process continues working.
Later, the IPC system will notify the process when the operation finishes.

Examples

 The browser’s receive must be blocking

o It cannot continue until data arrives

 The server’s send can be nonblocking

o It can send data and immediately continue serving other users

o No need to wait for confirmation

Why Synchronization Matters

The programmer must understand which operations are blocking and which are not.

If a programmer mistakenly uses nonblocking receive, the program may:

 Display incorrect data

 Crash

 Produce unexpected results

So, choosing the correct type of operation (blocking or nonblocking) is very important.

Program Flow Example

Browser Program

1. connect to web server

2. send request

3. receive data (blocking)

4. disconnect

5. process and display data

Web Server Program

1. accept connection

2. receive request

3. process request

4. send data

5. continue serving others

Synchronous Send and Synchronous Receive

 Both send and receive operations block the process until the operation
completes.
  Example:

1. Process 1 sends data → it waits until Process 2 receives it.

2. Process 2 receives data → it waits until the expected data is fully received.

 Use this method when both processes must get the data before
continuing.

 If Process 2 expects 300 bytes but receives only 200, it will keep waiting until
the remaining 100 bytes arrive.

Asynchronous Send and Synchronous Receive

 Send is asynchronous → sender does not wait; it continues its work.

 Receive is synchronous → receiver waits until the data arrives.

 Use this when the sender does not depend on the receiver receiving
data immediately, but the receiver must wait for the data.

Synchronous Send and Asynchronous Receive

 Send is synchronous → sender waits until the data is delivered.

 Receive is asynchronous → receiver does not wait and continues execution

immediately.

 Three possible scenarios for asynchronous receive:

1. Data has already arrived → delivered immediately

2. Data has not arrived → receiver must check repeatedly (polling)

3. IPC facility notifies the receiver when data arrives → process handles it
using a listener or event handler

 Important: If the IPC system does not store data, the receiver may miss it if it
isn’t ready.

Timeouts and Threading

 Blocking operations can sometimes make a process wait forever.

 To avoid this:

1. Timeouts → set a maximum waiting time for the operation.

 Example: connect request timeout = 30 seconds → if not completed,

operation is aborted.

2. Threading → issue a blocking operation in a separate thread or child

process.

 The main program can continue other work while the thread waits.
  Timeouts and threads are important to prevent processes from hanging
indefinitely, especially in network failures.

2.4 Deadlocks and Timeouts

Deadlocks

 Deadlock happens when two or more processes wait forever for each other.

 It usually occurs because of:

o Incorrect order of operations

o Programming mistakes

o Misunderstanding a protocol

 Example:

o Process 1 waits to receive data from Process 2

o Process 2 waits to receive data from Process 1

o Both are blocked forever → deadlock

Timeouts

 To prevent indefinite blocking, IPC systems provide timeouts.

 Timeout = maximum time a process will wait for an operation.

 Example:

o Browser sends a connect request with a 30-second timeout

o If no response in 30 seconds → operation is aborted, process continues

Threading

 Another way to avoid indefinite blocking is threading.

 The blocking operation can run in a child thread, while the main process
continues other tasks.

2.8 Request-Response Protocols – Easy Notes

 A request-response protocol is very common in networking.

 How it works:

1. One side sends a request

2. The other side waits and sends a response

3. This process may repeat until the task is complete

  Examples: HTTP, SMTP, FTP

Event Diagrams

 Show the exact sequence of events and blocking in a protocol.

 Active period → process is working (solid line)

 Blocked period → process is waiting (broken line)

Example of request-response:

1. Process A sends request 1 (nonblocking)

2. Process B receives request 1 (blocked until request arrives)

3. Process B sends response 1

4. Process A receives response 1 (blocked until it arrives)

5. Process A sends request 2, unblocking Process B

 Each request-response requires two pairs of send and receive operations.

 Important: Operations must happen in the correct order.

o If not, processes may wait forever → deadlock

Sequence Diagrams

 A simplified form of event diagram

 Shows message flow between processes

 Does not differentiate between blocked and active states

 Example: HTTP sequence:

1. Browser sends request

2. Server processes request

3. Server sends response

4. Browser receives response and displays document

Chapter 3

Distributed Computing Paradigms – Easy Notes

Introduction

 Distributed computing is a field where multiple computers (or processes) work

together over a network.

 It uses different paradigms (models or patterns) to simplify communication

and programming.

 There are many tools and technologies, but understanding the paradigms
first helps to make sense of them.

3.1 Paradigms and Abstraction

Abstraction

 Abstraction = hiding complex details and showing only what is needed.

 Example in programming:

o Java programmers use AWT to create graphics without worrying about

low-level details.

o In distributed computing, abstraction lets programmers focus on logic

rather than network communication details.

Paradigm

 Paradigm = pattern, model, or example.

 In distributed computing, it means how processes interact to achieve tasks.

 Paradigms are classified by level of abstraction:

o Low abstraction → message passing

o High abstraction → object space (most abstract)

3.2 Example Application

 To explain paradigms, we use an online auction system:

o One item is auctioned per session.

o Participants place bids.

o Auctioneer announces the winner.

 Focus: distributed computing aspects, not UI or database.

3.3 Paradigms for Distributed Applications

1. Message Passing

 Most basic paradigm in distributed applications.

 How it works:

1. Process A sends a message (request) to Process B.

2. Process B processes the request and sends a reply.

3. The reply may trigger further requests, continuing the cycle.

 Operations needed:

o send, receive

o For connection-oriented communication: connect, disconnect

 Abstraction: Programmer sends/receives messages like file I/O without

worrying about network details.

 Example (auction system):

1. Participant sends bid → server

2. Server sends confirmation → participant

3. Repeat as needed

2. Client-Server Paradigm

 Most common model for network applications.

 Two roles:

o Server: provides service, waits for requests

o Client: requests service, waits for response

 Operations:

o Server: listen, accept requests

o Client: send, receive responses

 Why it is useful:

o Simplifies synchronization

o Server waits for requests, client waits for responses

 Internet examples: HTTP, FTP, DNS, Gopher, SMTP

 Example (auction system):

o Server = auctioneer

o Client = participants placing bids

Key Points

 Message passing is simple, low-level communication.

 Client-server adds roles and structure, making synchronization easier.

 Both paradigms can be used to implement distributed auction system

Client-Server Paradigm – Auction Example

Session Control

 Server side (participant waiting):

o Waits for announcements from the auctioneer:

1. Session start

2. Updates on the current highest bid

3. Session end

 Client side (auctioneer sending):

o Sends requests to announce the above three events to participants

Accepting Bids

 Client side (participant sending bid):

o Sends a new bid to the server (auctioneer)

 Server side (auctioneer receiving bid):

o Accepts the bid

o Updates the current highest bid

Key Points

 Client-server model is used in most distributed applications.

 Programming APIs support this model:

o Socket API → operations for client and server

o Remote Procedure Call (RPC)

o Java Remote Method Invocation (RMI) → clients and servers are

clearly defined

Peer-to-Peer (P2P) Paradigm

Concept

 In client-server, roles are different:

o Client → sends requests

 o Server → waits for requests and responds

 Peer-to-peer (P2P) gives equal roles to all participants.

o Each participant can send requests and respond to others.

o Everyone is a peer.

Examples

 File sharing: [Link] (music sharing)

 Applications:

o Instant messaging

o File transfers

o Video conferencing

o Collaborative work

Auction System Example

 P2P makes it easier:

1. Participant contacts the auctioneer to register

2. Auctioneer contacts participants to start session

3. Participants can submit bids and get updates directly

4. Auctioneer announces winner

Key Points

 P2P can replace or combine with client-server

 High-level tools exist for P2P:

o JXTA project → for peer-to-peer networks

o Jabber → XML-based instant messaging

Message System Paradigm (Message-Oriented Middleware, MOM)

Concept

 An advanced version of message passing

 A message system acts as a middleman between processes

 Communication is asynchronous (non-blocking)

How it works

1. Sender deposits a message into the message system

2. Message system forwards it to the receiver’s message queue

3. Sender can continue working immediately, without waiting

Subtypes

1. Point-to-point message model → direct message between sender and

receiver

2. Publish/subscribe model → sender publishes messages, multiple subscribers

receive them

Key Takeaways

 P2P paradigm: all participants are equal, suitable for decentralized apps

 Message system paradigm: asynchronous communication using queues,

good for scalable and decoupled systems

Publish/Subscribe Message Model (Pub/Sub)

Concept

 Each message is linked to a topic or event.

 A process interested in an event subscribes to that topic.

 When the event occurs, the publisher announces it, and the middleware
delivers it to all subscribers.

Advantages

 Good for multicasting (sending messages to multiple processes at once).

 Decouples sender and receiver: the sender doesn’t need to know who will
receive the message.

Auction System Example

1. Each participant subscribes to event messages.

2. Auctioneer sends a start session event.

3. Participants receive start message and subscribe to new-bid events.

4. Participant sends a bid event, forwarded to auctioneer.

5. Auctioneer sends end-session event to all participants.

Examples of MOM Tools

 IBM MQ-Series

 Microsoft MSMQ

 Java Message Service (JMS)

Remote Procedure Call (RPC) Model

Concept
  RPC allows a process to call a procedure on a remote machine as if it were
local.

 Arguments are passed, procedure runs on remote process, result is returned.

Comparison with Message Passing

 Message passing → triggered by sending/receiving messages

 RPC → looks like local procedure call, hides communication details

Auction System Example

 Remote procedures:

1. Register participant

2. Make a bid

3. Notify highest bid

4. Announce session end

RPC Tools / APIs

 ONC RPC (Open Network Computing RPC)

 DCE RPC (Distributed Computing Environment RPC)

 SOAP for Web-based remote calls

Object-Oriented Paradigm: Remote Method Invocation (RMI)

Concept

 RMI is RPC for objects.

 A process calls a method on a remote object, which may reside on another

machine.

 Arguments are passed, and a value may be returned.

Auction System Example

 Remote methods replace RPC procedures:

1. Register participant

2. Place a bid

3. Notify new highest bid

4. Announce session end

Key Point

 RMI is useful for distributed object-oriented applications, while RPC is

procedura

Object Request Broker (ORB) Paradigm

Concept

 A process requests a service from an Object Request Broker (ORB).

 The ORB finds the right remote object that provides the service.

 Supports heterogeneous systems (objects on different platforms and APIs).

Auction System Example

1. Each participant and auctioneer object is registered with the ORB.

2. Participants request the auctioneer object to register and place bids.

3. Auctioneer uses the ORB to call methods on each participant to announce

start, update bids, and announce end.

Tools / Examples

 CORBA (Common Object Request Broker Architecture)

 VisiBroker, OrbiX, TAO

 Component-based tech like COM, DCOM, JavaBeans, EJB

Object Space Paradigm

Concept

 Assumes a shared logical space called an Object Space.

 Objects are placed into the space by providers and can be accessed by
requestors.

 Provides virtual meeting room for distributed objects.

 Mutual exclusion is inherent: an object retrieved by one participant is

unavailable to others until returned.

Auction System Example

1. Participants and auctioneer deposit objects in the common object space.

2. Object contains auction item info and bid history.

3. Participant retrieves object, updates bid, and returns it.

4. Auctioneer retrieves object at session end to contact highest bidder.

Tools

 JavaSpaces

Mobile Agent Paradigm

Concept

 A mobile agent is a transportable program or object.

  It travels host-to-host carrying its code and data.

 Can perform tasks at each stop without constant network communication.

Auction System Example

1. Each participant launches a mobile agent containing their identity.

2. Auctioneer launches an agent with itinerary and current highest bid.

3. Agent circulates among participants and auctioneer until the session ends.

4. Final agent round announces the winner.

Tools

 Concordia, Aglet

 Research systems: D’Agents, Licorna Project

Network Services Paradigm

Concept

 Service providers register themselves with the network.

 Any process can look up a service reference and interact with it.

 Supports dynamic discovery and interaction.

Auction System Example

1. Auctioneer registers as a service provider.

2. Participants lookup the auction service.

3. They interact with the service to place bids and get updates.

Network Services Paradigm

Concept

 Service providers register themselves with a directory or network.

 A process can look up the service and interact with it.

 Supports location transparency: you can access a service without knowing

where it is.

 Supports time transparency: you can access the service at any time.

Auction System Example

1. Auctioneer registers as a service.

2. Participants locate the auctioneer through the directory.

3. Participants provide callback methods so the auctioneer can announce the

start and end of the auction, and updates during bidding.

Tools / Examples
  Java RMI, Simple Object Access Protocol (SOAP)

Whiteboard / Collaborative Paradigm

Concept

 Participants share a virtual space (like a whiteboard) to read and write

information.

 Useful for real-time collaborative work.

 Multicasting or shared data allows participants to see updates immediately.

Auction System Example

1. Auctioneer writes an announcement on the whiteboard to start bidding.

2. Participants write their bids on the whiteboard.

3. Auctioneer writes a final announcement with the winner.

Tools / Examples

 Lotus QuickPlace, Java Multicast API, Java Shared Data Toolkit (JSDT)

 Applications: SMART Board, NetMeeting, Groove

 Notification Service Transfer Protocol (NSTP) for synchronous groupware

Trade-offs in Choosing Paradigms

1. Scalability

o Complexity increases as participants grow.

o Message passing requires manual management of addresses and

messages, which gets harder with more participants.

o High-level paradigms like object spaces or publish/subscribe handle

scalability automatically.

2. Cross-Platform Support

o Paradigms are platform-independent, but tools may not be.

o Java-based tools (RMI, JavaSpaces) require all participants to use Java.

o COM/DCOM works only on Microsoft platforms.

o CORBA supports different languages and platforms, making it more

flexible.

3. Other Software Engineering Considerations

o Maturity and stability of the tool

o Fault tolerance
 o Availability of developer tools

o Maintainability and code complexity

The Socket API

What it is

 A programming facility for interprocess communication (IPC).

 Provides a level of abstraction for sending and receiving messages between

processes on the same or different machines.

 Used by higher-level communication tools and sometimes directly when

fast response or low resource usage is needed.

History

 First appeared in Berkeley Unix in early 1980s.

 Now supported on all major OS: Linux, Windows, MacOS, Java.

 In Java, the Socket API is part of the language.

Socket Metaphor

 Think of a telephone socket: a process creates a socket to communicate

with another process.

 Two types:

1. Connectionless (UDP / Datagram)

2. Connection-oriented (TCP / Stream)

Datagram Socket API (UDP)

Key Concepts

 Uses User Datagram Protocol (UDP).

 Connectionless: no permanent connection is required.

 Each packet is called a datagram.

 Datagrams are individually addressed and may arrive out of order.

 Supports logical connections at the application layer if needed.

Key Classes in Java

1. DatagramSocket – the socket used to send/receive datagrams.

2. DatagramPacket – the actual data packet.

How it works

Sender Process:

1. Create a DatagramSocket and bind it to a local port.

2. Place data in a byte array.

3. Create a DatagramPacket specifying data, destination IP, and port.

4. Send the datagram using send() method.

Receiver Process:

1. Create a DatagramSocket bound to a local port.

2. Create a DatagramPacket with a byte array to receive data.

3. Use receive() method to get incoming datagrams.

Important Notes

 A single socket can communicate with multiple processes.

 If multiple processes send to the same socket, arrival order is unpredictable.

 Datagram sockets can also simulate connection-oriented communication if

needed.

Key Methods

DatagramPacket

Method / Constructor Description

DatagramPacket(byte[] buf, int length) Receives datagrams into buf of given

length.

DatagramPacket(byte[] buf, int length, Creates datagram for sending to a

InetAddress addr, int port) host IP (addr) and port.

DatagramSocket

Method / Description
Constructor

DatagramSocket(int Creates socket bound to specified

port) port.

close() Closes the socket.

receive(DatagramPack Receives a datagram into packet p.

et p)

send(DatagramPacket Sends a datagram p.

p)

setSoTimeout(timeout) Sets timeout for blocking receive

 operations.

Event Synchronization in Datagram Sockets

In datagram (UDP) sockets, the way sending and receiving work is different. This
creates a need for event synchronization.

1. Sending is Non-Blocking

 When a process sends a datagram using send(),

it does NOT wait for anything.

 It immediately continues its work.

 So sending is fast and non-blocking.

2. Receiving is Blocking

 When a process calls receive(),

it stops and waits until a datagram actually arrives.

 This means the program cannot continue until a message is received.

3. Problem: What if no message comes?

 The program will stay blocked forever.

 This is called indefinite blocking.

4. Solution: Use setSoTimeout()

 To avoid waiting forever, we can set a maximum waiting time.

 For example:
If we set timeout = 5 seconds:

o If a message comes within 5 seconds → receive normally.

o If no message comes → Java throws an InterruptedIOException.

5. What to do with this exception?

 The program can catch the exception and decide what to do:

o Try again

o Show error

o Stop receiving

o Do something else

Simple Example (Concept Only)

[Link](5000);

try {

[Link](packet);

} catch (InterruptedIOException e) {
 // Handle timeout here

Easy Summary

 send() = non-blocking (does not wait).

 receive() = blocking (waits until message arrives).

 setSoTimeout() = prevents infinite waiting.

 If timeout happens → InterruptedIOException is thrown.