Distributed Computing

Subject code : CSC 801

Subject In-charge
Nidhi Gaur
Assistant Professor
email: nidhigaur@[Link]

1
 Topics
• Interprocess Communication
• Remote Procedure Call
• Remote Method Invocation

• Message Oriented Communication

• StreamOriented Communication
• Group communication
Interprocess Communication

• Inter process Communication is a process of exchanging the data

between two or more independent process in a distributed
environment.
Information Sharing

There are two basic approach for information sharing

[Link] Passing
[Link] memory approach
Message Passing vs Shared Memory
IPC message format
IPC Message
Remote Communication
• Communication Distributed applications are difficult to build with IPC
protocols tailored only for specific applications.
• Distributed systems use explicit message passing (send and receive
primitives) for communication.
• The programmer handles these primitives and hence, this model fails
to achieve access transparency, which is an essential feature of any
distributed system.
• Hence, it was felt that there was a need for a generalized protocol
which would serve the purpose.

• With this Remote Procedural Call (RPC) and Remote Object Invocation
(RMI) programming models for distributed applications was
introduced.
Introduction

• Middleware is a software that provides a programming model one

level above the basic building block of processes and also provides
message passing.

• This layer uses protocols such as the request-reply protocol between

processes to provide higher-level abstraction.
• Middleware provides location transparency and independence from
the details of communication protocols, operating system, and
hardware.

• RPC and RMI are examples of middleware. Figure shows the role of
middleware in remote communication.
Introduction (contin…)

Middleware
Remote Procedure Call
Basic RPC operation
Basic RPC Operation

1. In RPC, the caller process and the server process execute on different
machines.
2. First, the caller process sends a call message with parameters to the
server process.
3. Then, the caller process suspends itself and waits for a reply
message.
4. A process on the server side extracts the parameters, computes the
result, and sends a reply message back to the caller process.
• only one process is active at a time.

• The client process is in the blocked state and may do other useful
work while waiting for reply from the server.

• In RPC, the calling and the called procedures run on different

machines and execute in different address spaces.
Introduction ………
• RPC is a protocol that one program can use to request a
service from a program located in another computer.

• RPC is an IPC technology that allows a program to cause a

procedure to execute in another address space.

• When this mechanism is implemented using object-oriented

principles, it is called Remote Method Invocation (RMI)

• RPC is a popular way of implementing client-server model of

Distributed Computing
where, Requesting program is a Client
Service providing program is a Server

RPC is used by both, an O.S. & by applications…..

• RPC is an extension of procedure call mechanism
• It enables a call to be made to a procedure that does not reside in the address
space of the calling procedure
• The called procedure (remote) can be on the same computer as that of the calling
procedure or on a different computer
• In this case, as the caller and callee processes have different address spaces , there
is no shared data
• Hence, RPC uses message passing scheme for communication.

25
Caller Callee
(Client) (Server)

Caller
Proc blocked
Proc
executes

Resume
Exec.

26
Implementation of RPC……
• To achieve the goal of transparency, implementation of RPC is
based on concept of STUBs
• Which provide a normal procedure call abstraction by
concealing from programs the interface to the underlying
RPC system.

RPC involves two processes : Client & Server

• Hence to achieve transparency, a separate stub process is
associated with each of the two processes
• Also, to hide the existence and functional details of the
underlying network, RPC communication package called
RPC Runtime is used on both the sides.

28
• Elements involved in implementation of RPC Mechanism :

• The Client
• The Client Stub
• RPC Runtime
• The Server Stub
• The Server

29
 Client Server

Return Call Call Return

Client stub Server stub

Unpack Pack Unpack Pack

RPC Runtime RPC Runtime

Receive Send Receive Send

30
• Client :
• A user process that initiates a remote procedure call
• Client Stub :
• Responsible for two jobs :
• On receipt of a request call from client,
• It packs specifications of the target procedure &
arguments into a message
• Then asks the local RPC Runtime routine to send it
to the server stub
• On receipt of result of procedure execution,
• it unpacks the result and passes it to the client.

31
• RPC Runtime:
• Responsible for transmission of messages across the network
between the client and server.
• On Client Machine --
• It receives a call request message from the client stub &
sends it to the server machine.
• It also receives message containing result of procedure
execution from server machine & passes it to the client
stub.
• On Server Machine --
• It receives message containing the result of procedure
execution from server stub & sends it to the client
machine.
• It also receives call request message from the client
machine & passes it to the server stub.

32
• Server Stub :
• Responsible for two jobs :
• On receipt of a request call message from local RPC
runtime,
• It unpacks it and makes a normal call to invoke
appropriate procedure in the server.
• On receipt of result of procedure execution,
• it packs the result into a message and then asks the
local RPC Runtime to send it to the client stub.
• Server :
• It executes appropriate procedure & returns result of
procedure execution to the server stub

33
 RPC Messages :

• Types of messages involved in implementation of RPC :

• Call Messages: sent by client to server requesting

execution of a remote procedure

• Reply Messages: sent by server to client for returning result

of remote procedure execution

37
Call Messages:

• Components of a call message :-

• Identification information of the remote procedure to be
executed i.e. Remote procedure identifier.
• The arguments necessary for execution of the procedure

Additional Fields:-
• Message identification field : has a sequence no. for
identifying lost messages and duplicate messages.

• Client identification field : to allow the server to identify

the client.

38
 • Message Type field : used to distinguish call message from reply message
• 0 call message
• 1  reply message

• RPC call message format:

39
Reply Messages:

• When the server of an RPC receives a call message, it could be

faced with one of the following conditions:

• Call message violates RPC protocol

• Action: Server rejects such a call.

• Server detects by scanning client’s id. Finds that it is not

authorized to use the service
• Action: Server returns an unsuccessful reply.

• Remote procedure specified in the remote procedure id.

Field of the call message is not available with it
• Action: Server returns an unsuccessful reply.

40
• Incompatible RPC interface being used by the client and server.
• Action: Server returns an unsuccessful reply.

• An exception condition (Division by zero) occurs during

execution of remote procedure
• Action: Server returns an unsuccessful reply.

• The specified procedure is executed successfully

• Action: Successful reply.

41
Fields in the Reply Message :

• Message Identifier Field : same as call message.

• Message Type :Indicates it is a reply message.

• Reply status : 0 Successful reply

• 1 / non-zero value  Unsuccessful reply

• Result : Result of procedure execution.

• Reason : Reason for failure

42
• A successful reply message:

• An unsuccessful reply message:

43
 Marshalling arguments and results:

• Implementation of RPC involves

• transfer of arguments from the client process to the server process and,
• Transfer of results from server process to client process.

• These arguments and results are transferred in form of message

data between two computers.

• In RPC, packing parameters into a message is known as

marshalling

44
Steps in Marshalling :

1. Taking arguments (of client) or result (of server) that will

form message data to be sent to remote process.

2. Encoding the message data.

3. Decoding the message data.

For successful marshalling, the client & server ,both should

know the methods used.

45
2.5 Server Implementation :

• Based on the style of implementation used, servers can be

of two types:

• Stateful servers

• Stateless servers

47
Stateful server:

• A stateful server maintains the client’s state

information from one remote procedure call to the
next.

• i.e. in case of two subsequent calls, some state info.

related to service performed for the client as a result of
first service call execution is stored by the server
process.

• This client’s state information is subsequently used at the

time of execution of second call

48
Stateless server:

• A stateless server does not maintain any client state

information.

• Hence, every request from the client MUST be

accompanied with all necessary parameters to
successfully carry out the desired operation.

• Server doesn’t keep track of any information

resulting from previous operation….client has to
keep the track

49
Advantage of Stateful over stateless server:

• They relieve the clients from keeping track of the

state information

50
Advantage of Stateless over stateful:

• They have an advantage in terms of failure.

• E.g. with stateful server, if the server crashes, & then
restarts, the state information that it was holding may be
lost and, client process might continue its task unaware
of the crash, producing unwanted results.
• Hence, the client of a stateful server should be designed
to detect server crashes , to do necessary error handling.
• Whereas, with stateless, a client has to only retry a
request until the server responds; it does not need to
know that the server has crashed.
• The choice is purely APPLICATION DEPENDENT.

51
Client-Server Binding:

• It is necessary for a client to know the location of a

server before a remote procedure call can take
place between them.

• The process by which a client becomes associated

with a server so that calls can take place is known
as Binding

52
Issues in Client-server binding process:

• How does a client specify a server to which it wants to get

bound?

• How does the binding process locate the specified server ?

• When is it proper to bind a client to a server?

• Is it possible for a client to change a binding during

execution ?

• Can a client be simultaneously bound to multiple servers

that provide the same service ?

53
 How does a client specify a server to which it wants to get
bound?

Server Naming :
• The specification of a client by a server with which it wants
to communicate has a naming issue.
• Solution….Use of Interface.
• Two parts of Interface name:
• Type
• Instance.

54
How does the binding process locate the specified
server ?

Server Locating :
• When a client specifies the interface name of a
server for making a RPC, the server must be
located before the client’s request message can be
sent to it.
• Two methods:
• Broadcasting
• Binding Agent

55
Broadcasting:

• In this method, a message to locate the desired server is

broadcast to all the nodes
• The nodes on which the desired server is located return a
response message
• The desired server may be replicated on several nodes, so
the client node will receive a response from all these nodes.
• Normally, the first response that is received at the client’s
node is given to the client process & all the subsequent
responses are discarded

56
• Advantage:
• Easy to implement
• Suitable for small networks
• Disadvantage:
• Expensive for large networks…….because of the
increase in message traffic due to involvement of
all nodes in the broadcasting process.

57
Binding Agent:

• It is a name server used to bind a client to a server

by providing the client with the location
information of the desired server.
• A binding agent maintains a binding table , which
is mapping of a server’s interface name to its
locations.
• All the servers register themselves as a part of their
initialization process.
• To register with the binding agent, a server gives
the binder its identification information& a handle
used to locate it.
58
• A server can also deregister with the binding agent
when it is no longer prepared to offer service.
• The binding agent can even poll the servers
periodically , automatically deregistering any
server that fails to respond

59
Locating process:

• To locate a server, a client contacts the binding

agent…..lookup
• If the server is registered with the agent, it returns the
handle of the server to the client.
• To begin with, the binding agent’s location is known to
all the nodes.

60
 Binding Agent

Client process Server process

61
When is it proper to bind a client to a server?

Binding Time:
• A client may be bound to the server at
• Compile time
• Link time
• Call time

64
REMOTE METHOD INVOCATION(RMI)

70
 RMI
It is a set of protocols developed by sun Microsoft that
enables java objects to communicate remotely with
other java objects. It is based on RPC and works only
with java objects
• In terms of remote execution, it is similar to RPC with the
difference that RPC works with procedures, while method
invocation works with objects and methods.
• Each process contains a collection of objects; some of these can
receive both local and remote invocations, whereas others can
receive only local invocations.
• Method invocation between objects in the same process is called
local invocation, whereas those between different processes are
called remote invocations.

71
RMI vs LMI

As seen in Figure , objects A and F are remote objects.

All objects can receive local invocation as long as they hold reference to them.
For example, B has a reference to C to invoke its method.
RMI Implementation
Level of Transparency
75
• Client invokes method on the remote object, which
is sent to the client stub.

• Just like RPC Runtime in RPC, the remote reference

layer in RMI converts the method into a message
and sends it over TCP/IP network.

• When the RMI message reaches the server, it is sent

to the remote reference layer at the server.
• Now the server skeleton converts this message into
a remote object and RMI is invoked.

• Once the RMI is executed, the object results are

transferred back through the same path to the
client.
There are four layers in RMI:
 Application Layer
 Proxy Layer
 Remote Reference Layer
 Transport Layer
Application Layer
 Responsible for running client and server applications.
 Here client application invokes methods defined by
server application
 When client invokes a method then request is passed to
proxy server

Proxy layer
 Responsible for creating client stub at client side by packing the
request msgs sent by client process
 Responsible for creating skeleton by packing response
 Once stub and skeleton are created they are passed to RRL
Remote Reference Layer
 Checks semantics and remote references used by client process using
remote reference protocol
 Finally RRL transmits messages and data to RMI transport layer.

Transport Layer
 Responsible for establishing and maintaining stream oriented connection
between client and server.
 Also responsible for managing send/receive of request reply messages
between client and server.
81
 RMI
The RMI (Remote Method Invocation) is an API that provides a
mechanism to create distributed application in java. The RMI allows an
object to invoke methods on an object running in another JVM

Stub
The stub is an object, acts as a gateway for the client side. All the outgoing requests
are routed through it. It resides at the client side and represents the remote object.
When the caller invokes method on the stub object, it does the following tasks:
It initiates a connection with remote Virtual Machine (JVM),
• It writes and transmits (marshals) the parameters to the remote Virtual Machine
(JVM),
• It waits for the result
• It reads (unmarshals) the return value or exception, and
• It finally, returns the value to the caller.
Skeleton
The skeleton is an object, acts as a gateway for the server side object. All the
incoming requests are routed through it. When the skeleton receives the incoming
request, it does the following tasks:
• It reads the parameter for the remote method
• It invokes the method on the actual remote object, and
• It writes and transmits (marshals) the result to the caller.
RMI Registry
RMI registry is a namespace on which all server objects are placed. Each time
the server creates an object, it registers this object with the RMIregistry
(using bind() or reBind() methods). These are registered using a unique name
known as bind name.
To invoke a remote object, the client needs a reference of that object. At that
time, the client fetches the object from the registry using its bind name
(using lookup() method).
The following illustration explains the entire process −
RMI Process:
RMI PROCESS:

1. The server registers the object references of all methods defined in the
procedure.

2. The client invokes a method and searches the object references into the
registry.

3. If the references are available, only then the client packs the data and
creates the client stub, else, it generates an error message.

4. Client stub is generated.

5. The client stub is passed to the RPC transport at client side:

6. RPC transport at client side forwards it to server side.

7. Transport layer at server side forwards client stub to remote reference

layer.
8. The remote reference layer receives the client stub and after checking semantics,
forwards it to the server skeleton.

9. The server skeleton unpacks the client stub and locates the invoked method.

10. The server executes the client's invoked method, generates the result and packs it into
the skeleton.

11. The skeleton is passed to the Remote Reference Layer (RRL).

12. RRL forwards skeleton to transport layer.

13. The RPC transport forwards the skeleton to the client srub.

14. The client stub receives the server skeleton and unpacks it.

15. The client stub returns result back to the client obtained from the server through the
skeleton.
Java RMI Example (LAB)

The RMI application is composed of Four Programs:

[Link] Program: It contains the declaration of methods to
be called by client and defined by the server program:.
[Link] program: It contains the definition of method
which is declared in interface.
[Link] Program: It contains statement like [Link] to
bind the objects called by the client.
[Link] program: It contains method calling and
[Link] method to locate the object in the registry.
 Message oriented communication
• Different processes in DS communicate by message passing
than shared memory as computer systems in a network do
not share memory
• A message passing system is a subsystem of DOS that offers
a set of message based inter process communication
protocols.
• A message passing system allows processes to
communicate by passing messages between respective
processes.

90
Features of good message passing
system.
• Simplicity
• Uniform semantics
• Efficiency
• Reliability
• Correctness
• Flexibility
• Security
• Portability

91
 Message passing interface
• It was first announced by NPI forum in 1994.
• Two different operations send and receive are used in
message passing mechanism for proper communication
and coordination

92
 Message-Oriented Communication
Message Oriented Communication can be viewed along 2 axes: persistence (whether the
system is persistent or transient); and synchronicity (whether it is synchronous or
asynchronous).
1. Synchronicity : In synchronous communication, the sender blocks further
operations until some sort of an acknowledgement or response is received,
hence the name blocking communication.
2. In asynchronous or non-blocking communication, the sender continues
execution without waiting for any acknowledgement or response. This form
needs a local buffer at the sender to deal with it at a later stage.
3. Persistency : In persistent communication, messages are stored at each
intermediate hop along the way until the next node is ready to take delivery of
the message. It is also called a store-and-forward based delivery paradigm.
Example: Email.
4. In transient communication, messages are buffered only for small periods
of time (as long as sending/receiving applications are executing). If the
message cannot be delivered or the next host is down, it is discarded.
Example: General TCP/IP communication.
 Classification:
Synchronous communication:
The sender is blocked until its message is stored in local buffer at the receiver’s
end or the messages has been delivered
Asynchronous communication:
Sender continues immediately after message sent.
The message either stored in local buffer or at the first communication server
example: Answering machine.
Persistent communication:
Message that has been submitted is stored by communication system as long as it
takes to deliver it to receiver
Example: Email, SMS
Transient communication:
Messages submitted are stored as long as sending and receiving applications are
running .
Example: Router
 Message-Orient Transient Communication

Message-Oriented Model

Many distributed systems and applications are built

on top of the simple message-oriented model
These models are offered by Transport Layer
Message-oriented models
1. Berkeley Sockets: Socket interface as introduced in
Berkeley UNIX
2. The Message-Passing Interface(MPI): designed for
parallel applications and as such in tailored to transient
communication

Real-Time &
 Message-Orient Transient Communication

Berkeley Sockets
Meaning of Socket: a communication endpoint to
which an application can write data (be sent to
network) and read incoming data
The socket primitives
Primitive Meaning for TCP/IP
Socket Create a new communication endpoint

Bind Attach a local address to a socket

Listen Announce willingness to accept connections

Accept Block caller until a connection request arrives

Connect Actively attempt to establish a connection

Send Send some data over the connection

Receive Receive some data over the connection

Close Release the connection Real-Time &

 Message-Orient Transient Communication
Berkeley Sockets
Connection-oriented communication pattern using sockets
Sockets considered insufficient because:
Support only send and receive primitives
Designed for communication using general-purpose protocol such as TCP/IP

Create a new Associate Waiting Block waiting for

endpoint endpoint connection reqs

Real-Time &
 Message-Orient Transient Communication

The Message-Passing Interface

• Designed for multiprocessor machines and high-
performance parallel programming .
• Provides a high-level of abstraction than sockets
• Support diverse forms of buffering and synchronization
(over 100 functions)
• Solve the problem of heterogeneity.
• MPI assume that communication taken place within known
group of process.
• Each process has (GroupID and ProcessID)

Real-Time &
 Message-Orient Transient Communication
The Message-Passing Interface(MPI)(2)

Some of the most intuitive message-passing primitives of MPI

Primitive Meaning

MPI_bsend Append outgoing message to a local send buffer

MPI_send Send a message and wait until copied to local or remote buffer

MPI_ssend Send a message and wait until receipt starts

MPI_sendrecv Send a message and wait for reply

MPI_isend Pass reference to outgoing message, and continue

MPI_issend Pass reference to outgoing message, and wait until receipt starts

MPI_recv Receive a message; block if there are none

MPI_irecv Check if there is an incoming message, but do not block

Real-Time &
 Message-Queuing Model
• Message queuing in
distributed systems enables
asynchronous, decoupled
communication between
services by using a mediator
(broker) to store messages.
• Key components include
producers, consumers, and
message brokers
• Producers send data to a
queue, allowing consumers to
process tasks at their own
pace, which boosts
scalability, fault tolerance,
and load balancing.

101
Message-Queuing Model

[Link]/Publisher: The entity that sends messages to the queue.

Producers push messages into the queue without worrying about the
consumer's state.
2. Consumer/Subscriber: The entity that reads messages from the
queue. Consumers pull messages from the queue and process them.
3. Queue: The data structure that stores messages until they are
consumed.
4. Broker/Queue Manager: The software or service that manages the
message queue, handles the delivery of messages, and ensures that
messages are routed correctly between producers and consumers.
5. Message: The unit of data sent through the queue. A message
typically contains the payload (the actual data being sent) and metadata
(such as headers, timestamps, and priority).

102
103
 The basic workflow of a message queue:
[Link] Creation: A producer generates a message containing the
necessary data and metadata.
[Link] Enqueue: The producer sends the message to the queue, where it
is stored until a consumer retrieves it.
[Link] Storage: The queue stores the message in a persistent or transient
manner based on its configuration.
[Link] Dequeue: A consumer retrieves the message from the queue for
processing. Depending on the queue's configuration, messages can be
consumed in order, based on priority, or even in parallel.
[Link]: Once the consumer processes the message, it may send
an acknowledgment back to the broker, confirming that the message has
been successfully handled.
[Link] Deletion: After acknowledgment, the broker removes the message
from the queue to prevent it from being processed again.

104
Stream oriented communication

• Stream-oriented communication in distributed systems involves

sending continuous flows of data, crucial for real-time media like
audio/video, focusing heavily on timing (latency, jitter) and Quality of
Service (QoS).
• It contrasts with message-oriented communication by treating data as
an ongoing stream, often using protocols like TCP(reliable,
connection-oriented) or UDP (unreliable, faster)

105
Stream oriented communication

Characteristics
• Continuous Data: Transmits data as a continuous flow, not discrete
messages.
• Timing Critical: Timing (delay, jitter) is a primary concern, often
requiring synchronous or isochronous delivery.
• Unidirectional (Often): Typically flows from a single source to one
or more sinks (e.g., camera to viewer).
• Supports Continuous Media: Ideal for audio, video, and sensor data.
• Connection-Oriented: Often uses connection-oriented protocols like
TCP for reliability

106
Stream oriented communication

Modes of Transmission
• Synchronous: Specifies maximum variance in end-to-end
delay (jitter).
• Asynchronous: Sets a maximum end-to-end delay but with
no specific variance limit.
• Isochronous: Guarantees both maximum delay and a specific
lower bound, ensuring regular delivery.

107
Stream oriented communication

Examples in Distributed Systems

• Video Conferencing: Real-time audio and video streams.
• Live Streaming: Delivering live events or on-demand media.
• Sensor Networks: Continuous data feeds from IoT devices.

108
Group communication

• Group communication in distributed systems refers to the process

where multiple nodes or entities communicate with each other as a
group.
• Instead of sending messages to individual recipients, group
communication allows a sender to transmit information to all
members of a group simultaneously.
• This method is essential for coordinating actions, sharing data, and
ensuring that all participants in the system are informed and
synchronized.

109
 Group Communication
One to One Communication, point to point or unicast

Group Communication. A group is a collection of interconnected processes

with abstraction. This abstraction is to hide the message passing so that the
communication looks like a normal procedure call. Group communication
also helps the processes from different hosts to work together and perform
operations in a synchronized manner, therefore increasing the overall
performance of the system.
Types of Group Communication
1. Unicast – one to one communication
2. Many-to-one group communication
3. One-to-many or multicast group
communication
4. Broadcast communication
1. Unicast group communication
Unicast Communication : When the host process tries to communicate with a
single process in a distributed system at the same time. Although, same
information may be passed to multiple processes. This works best for two
processes communicating as only it has to treat a specific process only.
However, it leads to overheads as it has to find exact process and then
exchange information/data.
2. Many to one communication
3. Multi cast communication
Multicast Communication : When the host process tries to communicate with
a designated group of processes in a distributed system at the same time.
This technique is mainly used to find a way to address problem of a high
workload on host system and redundant information from process in
system. Multitasking can significantly decrease time taken for message
handling.
4. Broadcast communication
Broadcast Communication : When the host process tries to communicate with
every process in a distributed system at same time. Broadcast communication
comes in handy when a common stream of information is to be delivered to
each and every process in most efficient manner possible. Since it does not
require any processing whatsoever, communication is very fast in comparison
to other modes of communication. However, it does not support a large
number of processes and cannot treat a specific process individually.