Chapter - 2

Communication
 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 is called as Interprocess
communication.
• A diagram that illustrates interprocess
communication is as follows −
A diagram that demonstrates message queue and shared memory methods of interprocess
communication is as follows
Protocols for Network Systems
 Protocols for network systems
• Protocol is a formal set of rules and
conventions that governs how computers
exchange information over the network
medium.
• Protocol supports transparency
• Protocols for networks
–ISO/OSI
–IP
ISO/OSI Reference Model
Functions of OSI layers
Functions of OSI Layers
 Information Sharing
There are two basic approach for information
sharing
1. Message Passing
2. Shared memory approach
Message Passing
Message Passing
Message Passing vs Shared Memory
 Desirable Features of Message
Passing Systems
• Hardware approach
• Functionality
• Performance
• Uniform semantics
• Efficiency
• Reliability
• Correctness
• Flexibility
• Portability
• Security
Message passing process
1. The application on the sending host wants to
carry out a message transfer operation.
2. The messaging interface formats the message
and passes it to the local buffer.
3. The operating system sends it across the local
network to the communication server where it is
queued.
4. The routing program sends the message to the
remote communication server based on the
destination address specified in the message.
• 5. This server passes the message to the
required destination where it is stored in the
local buffer and later accepted by the
application.

• 6. Very often, the message transfer operation

is not so simple. There are many issues
involved along the communication path, which
are described in the next section.
•
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 these Remote Procedural Call (RPC) and

Remote Object Invocation (RMI)
programming models for distributed
applications was introduced.
Introduction to Remote
Communication
 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 4-1 shows the role of middleware in
remote communication.
 Introduction (contin…)
• Middleware
Following features are provided
1. Location transparency
2. Communication Protocols
3. Computer hardware (hides the
heterogeneous nature of hardware)
4. Operating System
5. Use of programming language
Remote Procedural Call Basics
 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.
• Figure 4-4 shows how 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.
RPC operation
• Message passing carries out information
exchange between the two processes and is
transparent to the programmer.

• RPC is the popularly used communication

mechanism for distributed applications
because of its simple syntax and semantics.
 Elements of RPC mechanism
implementation
1. Client
2. Client stub
3. RPC Runtime
4. Server stub
5. Server
RPC Execution
 The following ten steps explain a complete RPC
execution process:
1. The client calls a local procedure, the client
stub. For the client, it appears as if the client
stub is the actual server procedure, which it
has called. A stub packages the arguments for
the remote procedure by putting them into
some standard format and builds one or
more network messages. Marshalling is the
process of packaging the client's arguments
into a network message.
• 2. The client stub sends the network messages to
the remote system via a system call to the local
kernel.

• 3. A connection-oriented or a connection-less
protocol transfers the network messages to the
remote system.

• 4. The server stub procedure waits on the remote

system for the client's request. It unmarshals the
arguments from the network message and
converts them.
• 5. The server stub executes a local procedure
call to invoke the actual server function,
passing it the arguments that it received from
the client stub.

• 6. When the server procedure is completed, it

sends the return values to the server stub.
• 7. The server stub converts the return values,
marshals them into one or more network
messages, and sends them back to the client stub.

• 8. The messages are transmitted across the

network back to the client.

• 9. The RPC runtime reads the network messages

from the local kernel and hands them over to the
client stub.
• 10. The client stub unmarshals the messages,
converts the return values, and returns it to
the client procedure.

• The client and the server stub hide the actual

details of message passing.
 Parameter Passing Semantics in RPC:

1. Call-by-Value:
In pass by value the actual parameters and their data types copied into the
stack and passed to the called procedure
• Value parameter

2. Call-by-Reference:
In call by reference, the pointer to the data is passed instead of value to the
called procedure at the server side.
It is very difficult to implement as the server needs to keep the track of the
pointer to the data at the clients address space
Reference parameter (array buf).
Synchronous and Asynchronous RPC
Remote Invocation Basics
 Remote Invocation Basics (Continu..)

• Object-oriented models are efficient for

developing non-distributed applications.
• The object interface hides the internal
structure from the outside world.
• Therefore, it is easy to replace objects by
maintaining the same interface.
• The principle of RPC can be applied to handle
objects, i.e., invocation of remote objects.
 Remote Invocation Basics (Continu..)

• With this concept, objects in different

procedures can communicate with each other
through Remote Object Invocation (RMI).
• It is an extension of local method invocation,
which allows objects in one process to invoke
methods of an object in another process on
the same machine.
 Remote Object Invocation
• Distributed object concept
– Remote objects reference
– Remote interface
• Figure 4-23 shows how processes across the
network share objects.
• A distributed system uses the client-server
architecture.
• The server manages the objects and clients
invoke the methods called the RMI.
• The RMI technique sends the request as a
message to the server which executes the
method of the object and returns the result
message to the client.
RMI
• We will now take an example to explain the RMI
operation.
• The RMI process is similar to Local Method Invocation
(LMI).
• 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.
RMI vs LMI
• As seen in Figure 4-24, objects B 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
• 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.
Level of Transparency
• As shown in Figure 4-26, when the client binds to
the distributed object, the object interface called
the proxy is loaded in the client address space.
• A proxy is similar to the client-server stub of RPC.
• It marshals the RMI request into a message
before sending it to a server through the client
and server communication modules.
• Then it unmarshals the reply message of method
invocation when it arrives at the client site.
• The server-side machine invokes the object and
offers the same interface as if it resides on the client
machine.
• The other function of the server stub- skeleton is to
marshal replies, convert them into a message, and
send it to the client-side proxy.
• The object state resides on a single machine, while
the interfaces are available on another machine.
Hence in a distributed object, the state and interface
are distributed across the machins, but it is
transparent to the user by hiding behind the object’s
interface.
Components of RMI
 RMI execution components
1. Communication module
2. Remote reference module
3. RMI software
i. Proxy
ii. Dispatcher
iii. Skeleton
4. Server program and Client program
i. Binder
 RMI binding
• The concept of binder can be explained with
an example. The object A request remote
object reference for object B.
• The binder is a service which maintains a
table of textual names to be remote
object-referenced.
• Server uses this services to look up remote
object reference.
 RMI binding
• Implicit binding
• Explicit binding
RMI execution
Types of objects
Case study: Java RMI
Java RMI layer
 Remote Method Invocation (RMI).

Example:
 Remote Method Invocation (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 Process:
• 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:
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:

1. Interface Program: It contains the declaration of methods
to be called by client and defined by the server program:.
2. Implementation program: It contains the definition of
method which is declared in interface.
3. Sever Program: It contains statement like [Link] to
bind the objects called by the client.
4. Client program: It contains method calling and
[Link] method to locate the object in the registry.
 The is given the 6 steps to write the RMI program.

The is given the 6 steps to write the RMI program.

1. Create the remote interface
2. Provide the implementation of the remote
interface
3. Compile the implementation class and create the
stub and skeleton objects using the rmic tool
4. Start the registry service by rmiregistry tool
5. Create and start the remote application
6. Create and start the client application
 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. 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.
2. 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: (pony Postal system express), email, etc. 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 messages is stored in local buffer at the
receivers 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:
• Messages has been submitted is stored by communication system as long
as it takes to deliver it to receiver
• Example: Email, SMS
• Transient communication:
• Messages has been submitted is stored as long as sending and receiving
applications are running .
• Example: Router
 Types of Communication:

1. Persistent and transient communication

2. Synchronous and Asynchronous
Communication
3. Persistent Synchronous and Persistent
Asynchronous
4. Transient synchronous and Transient
Asynchronous
1. Receipt based transient synchronous communication
2. Delivery based transient synchronous communication
3. Response based transient synchronous communication
Synchronous and Asynchronous Communication
Persistence and Synchronicity in Communication (3)

2-22.1

a) Persistent asynchronous communication

b) Persistent synchronous communication
 Transient asynchronous communication

2-22.2

TCP

c) Transient asynchronous communication

d) Receipt-based transient synchronous communication
• Transient synchronous: In Transient synchronous
communication the sender is blocked until the messages are
stored on temporary buffer.

• Transient Asynchronous (c) explains this form of

communication. A sends the message and continues execution
(nonblocking). B has to be running, because if it is not running
the message will be discarded. Even if any router along the
way is down, the message will be discarded. UDP
communication is an example of transient asynchronous
communication. The function MP I bsend() is an
implementation of this.
Persistence and Synchronicity in Communication
(5)

RPC/RMI

e) Delivery-based transient synchronous communication at message delivery

f) Response-based transient synchronous communication
• Receipt-based Transient Synchronous Figure 10.1 (d) explains receipt-based
transient synchronous communication. A’s message to B is blocking
(synchronous) until an ack is received. This ack simply tells us that the
message was received at the other end. It does not tell us anything about
whether the process has started.
• Delivery-based Transient Synchronous This is an extension of receipt-based
transient synchronous communication. As shown in figure 10.1 (e), A will
resume running when B takes the delivery of the message. The ack comes a
little bit later than the previous method. This is essentially asynchronous RPC
because from the perspective of an RPC, we are not blocking for the reply.
• Response-based Transient Synchronous Figure 10.1 (f) explains this type of
communication. A resumes execution upon receiving a response. That is, not
only has the message been delivered, but it has been processed and the ack
comes back in the form of a reply. This is traditional RPC. The client is
blocked for the entire duration the reply comes back.
 Message-Orient Transient Communication(1)

• 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 & MultiMedia

Lab
 Message-Orient Transient Communication(2)

• Berkeley Sockets(1)
– Meaning of Socket: a communication endpoint to
which an application can write data (be sent to
network) and read incoming data
–Primitive
The socketMeaning
primitives 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

Real-Time & MultiMedia
Close Release the connection Lab
 Message-Orient Transient Communication(3)
• Berkeley Sockets(2)
– 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 & MultiMedia

Lab
 Message-Orient Transient Communication(4)

• The Message-Passing Interface(MPI)(1)

– 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 group assigned identifire,
– Each process have (GroupID and ProcessID)

Real-Time & MultiMedia

Lab
 Message-Orient Transient Communication(5)
• 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 & MultiMedia
Lab
Message-Queuing Model
 Message-Orient Persistent Communication(2)

• Message-Queuing Model(2)
• ‘

– Four combinations for loosely-coupled

communication using queues:

Real-Time & MultiMedia

Lab
 Message-Queuing Model
❑ Source queue- messages can put only in queue that are local to the sender ,
queue on same machine

❑ Destination queue- specification of destination queue to which it should be

transferred

❑ Mapping of queues to n/w - database of queue names to network locations

❑ queue managers- Queue manager interacts directly with the applications

that is sending or receiving a message

❑ relay- special queue manager, secondary processing of message,

multicasting, build scalable message queuing system
General Architecture ofmanager
Queue a Message-Queuing System (2)

The general organization of a message-queuing system with

routers.

2-29
 Message-Orient Persistent Communication

• General–purpose of a Message-Queuing
System
– Enable persistent communication between
processes
– Handling access to database
– In wide range of application, include:
• Email
• Groupware
• Batch processing

Real-Time & MultiMedia

Lab
 Message-Orient Persistent Communication(6)
• Message Broker
Message Broker

The general organization of a message broker in a message-queuing system

Real-Time & MultiMedia

Lab
 Summary & Conclusion
• Summary
– Two different communication concept ‘Transient vs. Persistent’
• Persistent messages are stored as long as necessary
• Transient messages are discarded when they cannot be delivered
– Message-Oriented Transient Comm.
• Berkeley socket and MPI
– Message-Oriented Persistent Comm.
• Message-Queuing Model and Message Broker

• Conclusion
– Message-Oriented communication solve the blocking problems that
may occur in general communication between Server/Client
– Message-Queuing systems can users(including applications) to do
Persistent communication

Real-Time & MultiMedia

Lab
2.5 Stream-Oriented Communication

Real-Time & MultiMedia

Lab
 Support for Continuous Media(1)
• Types of media
– Continuous media
• Temporal dependence between data items
• ex) Motion - series of images

– Discrete media
• No temporal dependence between data items
• ex) text, still images, object code or executable files

Real-Time & MultiMedia

Lab
 Support for Continuous Media(2)
Data Stream
Sequence of data units
Discrete data stream: UNIX pipes or TCP/IP connection
Continuous data stream: audio file (connection between file
and audio devices)
Transmission modes
Asynchronous: no timing constraints
Synchronous: upper bound on propagation delay
Isochronous: upper and lower bounds on propagation delay
(transfer on time)

Real-Time & MultiMedia

Lab
 Support for Continuous Media(3)
• Types of stream
– Simple stream
• consist of only a single sequence of data
– Complex stream
• consist of several related simple stream
• ex) stereo audio, movie
– Sub stream
• related simple stream
• ex) stereo audio channel

Real-Time & MultiMedia

Lab
 Streams and Quality of Service(1)
• Specifying QoS(1)
– Flow specification
– To provide a precise factors(bandwitdh,
transmission rates and delay, etc.)
– Example of flow specification developed by
Figure. 2-37 A flow specification
Partridge
Characteristics of the Input Service Required

Loss sensitivity (bytes)

Maximum data unit size (bytes) Loss interval (microsec)
Token bucket rate (bytes/sec) Burst loss sensitivity (data units)
Token bucket size (bytes) Minimum delay noticed (microsec)
Maximum transmission rate (bytes/sec) Maximum delay variation (microsec)
Quality of guarantee

Real-Time & MultiMedia

Lab
 Streams and Quality of Service(2)
• Specifying QoS(2)
– Token bucket algorithms
• Tokens are generated at a constant rate
• Token is fixed number of bytes that an application is
allowed to pass to the network
Figure. 2-38
The Principle of a
token bucket
algorithm

Real-Time & MultiMedia

Lab
 Streams and Quality of Service(3)

Setting up a stream
Resource reSerVation Protocol(RSVP)
Transport-level control protocol for enabling resource
reservation in network router
Used to provide QoS for continuous data streams by reserving
resources (bandwidth, delay, jitter and so on)
Issue: How to translate QoS parameters to resource usage?
Two ways to translate
1. RSVP translates QoS parameters into data link layer parameters
2. Data link layer provides its own set of parameters (as in ATM)

Real-Time & MultiMedia

Lab
Streams and Quality of Service(4)
Figure. 2-39
The basic organization of RSVP for
resource reservation in a distributed
system

Real-Time & MultiMedia

Lab
Group communication
 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.
 Types of Groups
1. Closed group
2. Open group
3. Peer group
4. Hierarchical group
Case Study: CBCAST protocol in ISIS
 CBCAST protocol
• S: vector of the sending process attached to
the message
• R : vector of the receiving process
• i: sequence number of the sender process
• Runtime system tests following conditions
–S[i] = R [i] + 1
–S[j] <= R[j] for j <> i
CBCAST protocol in ISIS
• THE END