Chapter - 4

Arba Minch University
Institute of Technology
Faculty of Computing & Software Engineering
Intro to Distributed
Intro to Distributed System

System
(CoSec4038)
Mr. Addisu M. (Asst. Prof) G4 CS - Ext
1
Chapter 4

Communication
in DS
2
Introduction
 The most important difference between a Distributed and Non-DS
(uniprocessor system) is the inter-process commn (IPC) (The way
to create commn b/n processes)
 In Non-DS, inter-process commn - by the existence of shared memory
whereas
 In DS, there's no shared memory, so the entire nature of IPC must be
completely reframed from scratch

 Communication in DS is based on message passing as offered by
the underlying network which is harder as opposed to using shared
memory
 Modern DSs often consist of thousands or even millions of processes
spread across a network with unreliable commn such as the Internet
 Unless the primitive commn facilities of networks are replaced by
something else (more advanced ones), development of large-scale
distributed applications is extremely difficult 3
Introduction
 In a DS, each entity (Component) may want to share infn with other
distributed entities to create coherent single & consistent system
 Successfulness of DSs is depend on commn models that shows how
processes on the different machine can communicate each other
or simplify message passing b/n processes.
 In general, scientifically designing, implementing and managing
inter-process communication is at the heart of all DSs

4
Why Communication?
 There are two reasons for processes communication:
1. Synchronization
 Processes synchronize in order to coordinate their activities
 Includes:
• finding out whether another process is alive,
• determining how much of a task a process has executed,

• acquiring exclusive access to a resource,
• requesting another process to perform a certain task
2- sharing of data
 Processes share data about tasks that they are cooperatively working on
 Include:
• sending data as part of a request
• returning the results of a calculation
• requesting particular data 5
Communication Protocols
 Protocol – a set of rules that governs data commns and defines
 what (message) is communicated,
 how (media/channel) it is communicated, and
 when (Time/Synchronization) it is communicated
 Example: TCP, UDP, FTP, Telnet, SMTP, POP etc

 Protocols can be connection oriented or connectionless
 TCP: Connection-oriented protocol
 provides a reliable flow of data between two computers but slow
 Guarantees delivery of data, acknowledgement is send by receiver
 UDP: Enables connectionless communication
 Sends independent packets of data, called datagrams, between two
 Arrival of datagrams is not guarantees
 Acknowledgement is not sent by receiver – not reliable but fast 6
 In a layered network model, when a message is sent over
network, each layer adds its own header and trailer infn
 Open Systems Interconnection (OSI) Reference Model is
a conceptual framework that describes functions of the
networking or telecommunication system independently from

the underlying technology infrastructure.
 It divides data commn into seven abstracted layers and
standardizes protocols into appropriate groups of networking
functionality to ensure interoperability within the commn
system regardless of the technology type, vendor, and model
(Ensure heterogeneity in hardware and Software etc.)
7
 When a message is sent from device A to device B, it may pass
through many intermediate nodes

8
Specific Function of Each Layer

 Lower-level protocols
• Physical layer – the actual transmission of bits on Network
[using WiFi/cable], in other words it says what is the medium
of communication;
• Data Link layer – creates ‘frames’ (groups bits into frames )

and ensure are correctly received;
• Network Layer – describes how packet are routed
 Transport protocols
• Transport Layer – Transfer messages b/n clients, including
breaking them into packets (TCP & UDP)
• usually is end to end communication 10
 High-level protocols
• Session Layer – provides dialog control and synchronization
• looks at the user session;
• Presentation Layer – resolves differences in formats among
sites

• looks at how is the data presented to the application;
• Application Layer – originally to contain a set of standard
apps
• Things like HTTP, FTP which are applications using this
protocol stack for communication
11
Types of Communication
 Persistent or transient
• Persistent commn: Message submitted for transmission stored
by the system (commn middleware) as long as it takes to deliver
it to the receiver
• Example: email
• Transient commn: Message stored by commn system only as

long as sending and receiving application are executing (e.g. if
transmission is interrupted, msg is lost)
• Message discarded if cannot be delivered to receiver immediately
• A message will only be delivered if a receiver is active.
• If there is no active receiver process (i.e., no one interested in or able to
receive messages) then an undelivered message will simply be dropped
• Example: HTTP request
12
Types of Communication
 Asynchronous or synchronous
• Asynchronous commn: Sender continues immediately after
submitting message for transmission.
• Message may be queued if receiver not active
• Message temporarily stored by middleware on submission
• Message may be proceed later at receiver’s convenience

• Synchronous commn : Sender blocks until message
received & processed and receiver returns acknowledgement
• Sender and receiver must be active at the same time
• Client-server generally uses synchronous commn
13
Communication Models
 Four popular models of communication in DSs:
1. Remote Procedure Call
2. Message-Oriented Communication
3. Stream-Oriented Communication
4. Multicast Communication

Remote Procedure Call (RPC)
 A high-level network communication interface
 Based on the single-process procedure call model.
 Client request: formulated as a procedure call to a
function on the server.
 Server’s reply: formulated as function return
14
Conventional Procedure Call
 Initiated when a process calls a function or procedure
 The caller is “suspended” until the called function completes.
 Parameters & return address are count = read(fd, buf, nbytes);
pushed onto the process stack

 Variables local to the called
function are pushed on the stack
Figure. (a) Parameter passing in a local procedure

call: the stack before the call to read. (b) The stack
while the called procedure is active.
15
Conventional Procedure Call
 Control passes to the called function
 The called function executes, returns value(s) either through
parameters or in registers. The stack is popped.
 Calling function resumes executing

 replace the explicit message passing model with the model of
executing procedure call on remote node
 A programmer simply performs a procedure call, while behind the
scenes messages are transferred between client and server
 In theory, programmer is unaware of any commn taking place
 Goal: to make DS look like centralized computing
 Communication happens through parameter passing and by
obtaining return values
16
 RPC concept - to make a remote procedure call appear like
a local procedure call.
 Goal: to hide the details of the network communication
(namely, sending & receiving of messages)
 The calling procedure should not be aware that the called

procedure is executing on a different machine.
 RPC vs OSI
• User does not open connection, read, write, then close
connection – client may not even know they are using
network
• RPC may omit protocol layers for efficiency. (e.g. diskless
Sun workstations will use RPC for every file access) 17
 When making a remote procedure call (RPC):
 RPC abstraction assumes synchronous or blocking commn
 This means that clients invoking RPCs are blocked until the
procedure has been executed remotely and a reply returned
 When the procedure finishes and produces its results, its

results are transferred back to calling env’t, where execution
resumes as if returning from regular procedure call
Figure. Principle of RPC between a client

and server program 18
 Fundamental concepts of the distributed object model:
• Remote objects: objects that can receive remote invocations
• Remote Object References other objects can invoke the
methods of a remote object if they have access to its remote
object reference

• Remote Interfaces every remote object has a remote interface
that specifies which of its methods can be invoked remotely
• Procedure: In computer programming, it is an independent code
component that fulfills some concrete task and is referenced
within a larger body of source code.
 procedural language is a type of programming language that
specifies a series of well-structured steps and procedures within its
programming context to compose a program 19
 Fundamental concepts of the distributed object model:
 Stub
 a piece of code that converts parameters passed between client
and server
 client and server use different address spaces, so parameters

used in a function (procedure) call have to be converted,
otherwise the values of those parameters could not be used,
 Because pointers to parameters in one computer's memory
would point to different data on the other computer.
20
 RPC occurs in the following steps:
1. client procedure calls the client stub in the normal way.
2. client stub pack (marshals) the parameters, builds a message and calls the
local OS
3. client’s OS sends the message to the remote OS.

4. remote OS gives the message to the server stub.
5. server stub unpacks (demarshals) the parameters and calls the desired
server routine
6. server does the work and returns the result to the stub
7. server stub pack (marshals) the return values into the message and calls
its local OS
8. server’s OS sends the message to the client’s OS
9. client’s OS gives the message to the client stub
10.client stub unpacks (demarshals) the result and returns to the client 21

22
 The following steps take place during an RPC:
1.client invokes a client stub procedure, passing
parameters in the usual way
 Client stub resides within the client's own address space
2.Client stub marshalls the parameters into a message.

 Marshalling includes converting the representation of the
parameters into a standard format, and copying each parameter
into message
3.Client stub passes the message to the transport layer,
which sends it to the remote server machine
23
 The following steps take place during an RPC:
4. On the server, the transport layer passes the message to
a server stub, which demarshalls the parameters and calls the
desired server routine using the regular procedure call
mechanism

5. When the server procedure completes, it returns to the server
stub, which marshalls the return values into a message
 server stub then hands the message to the transport layer
6. Transport layer sends the result message back to the client
transport layer, which hands the message back to client stub
7. Client stub demarshalls the return parameters and execution
returns to the caller 24
Example

E.g., consider a remote procedure add(i, j),
Passing Value Parameters
where i and j are integer parameters 25
Remote Method Invocation(RMI)
 RPC disadvantages:
1. Programmers must explicitly specify the server on which
they want to perform the call.
 Using RMI: programmers invoke methods on remote

objects
2. It is complicated for a server to keep track of the different
state belonging to different clients and their invocations.
 More natural resource management and error handling
 These problems with RPC lead to the remote method
invocation (RMI) abstraction 26
 RMI - allows an object to access data and invoke methods on an
remote object (object running in another remote virtual machine
(JVM))
 Object oriented version of RPC
 Remote object is an object whose method

can be invoked from another JVM
27
 When using RMI
1. Objects can be passed as arguments or received as results
in RMI. This helps to relieve many of the problems
associated with passing pointers in RPC
2. Programmers invoke methods on remote objects.

 The object associates all operations with the data that they
operate on, meaning that state is encapsulated in the remote
object and much easier to keep track of
3. The concept of remote object, improves location
transparency: once a client is bound to a remote object, it no
longer has to worry about where that object is located
28

 A proxy is an implementation of the object's interface.
 A proxy is analogous to a client stub in RPC systems.
 The actual object resides at a server machine, where it offers the
same interface as it does on the client machine. 29
 RMI Layering: RMI has 3 layers on the client and server side
• Stub layer: Interface between client application (caller)
and server object
• Remote reference layer: Connects clients to remote service objects
• Transport layer: Makes connections between client VM and

server VM, formats the data using JRMP (Java Remote Method
Protocol) or RMI-IIOP(Internet-Inter-ORB-Protocol)
30
 RMI Stub and Skeleton
 Stub - an object, acts as a gateway for client side so, all the outgoing
requests are routed through it
 It resides at client side and represents the remote object and when caller
invokes method on stub object, it does the ff tasks:
1. It initiates a connection with remote JVM,

2. It writes & transmits (marshals) parameters to the remote JVM,
3. It waits for the result of requests sent to server operation,
4. It reads (unmarshals) the return value or exception, and
5. It finally, returns the value to the caller
 Skeleton - an object, acts as a gateway for the server side object so, all
the incoming requests are routed through it
 When the skeleton receives the incoming request, it does ff tasks:
1.It reads the parameter for the remote method,
2.It invokes the method on the actual remote object, and 31
3.It writes and transmits (marshals) the result to the caller
 RMI Registry
 RMI registry function:
• RMI registry is a server registration and client lookup service
• Default port for RMI registry: 1099 (may run on another port as well)
 Server registration:
• Servers register objects that implement the service interface using bind() or

rebind():
• E.g.: RemServer localObject = new RemServer();
Naming.rebind(“MyServ”, localObject);
 Client references:
• Clients obtain references to server objects (=proxy objects) through the
RMI registry using a URL scheme (with an optional port):
URL: rmi://<host_name>[:<name_service_port>]/service_name>
E.g: RemIf remObject = (RemIf)Naming.lookup(“rmi://” + host + “/MyServ”);
32
 RMI Registry
 To invoke a remote object,

client needs a reference of that
object
 At that time, client usfetches
the object from registry ing its
bind name (using lookup()
method)
33
 RMI Java Packages
Packages Description
Core RMI package with classes and interfaces used by both client and
java.rmi.* server. Contains interface Remote, classes Naming and
RMISecurityManager and some basic exception classes
Classes and interfaces for dynamic activation of remote objects together

java.rmi.activation with RMI daemon (rmid).
java.rmi.dgc.* Classes and interfaces for distributed garbage collection (DGC)
Registry and LocateRegistry classes for directly interacting with a
java.rmi.registry.* (remote or local) registry. Registry class provides lookup(), rebind(), list()
and other methods
Classes for use on the server side like class loader (RMIClassLoader) and
java.rmi.server.* UnicastRemoteObject (base class for remote objects)
javax.rmi.* APIs for RMI-IIOP (interoperability between RMI and CORBA)
34
 General RMI Architecture Remote Machine
bind
 The server must first bind its name RMI Server
to the registry Registry
 The client lookup the server name skeleton

in the registry to establish remote
references. return call lookup
 The Stub serializing the parameters

to skeleton, the skeleton invoking stub
the remote method and serializing

the result back to the stub RMI Client
Local Machine
35

 RMI uses stub and skeleton object for commn with remote object
 remote object is an object whose method can be invoked 36
 Key components/class definitions in RMI:
 Name server (provides location information of services)
 Interface definition of server code
 Implementation of server
 Implementation of client

 Steps to write the RMI program
1. Defining a remote interface
2. Implementing the remote interface
3. Creating Stub and Skeleton objects from the implementation class
using rmic (RMI compiler)
4. Start the rmiregistry
5. Create and execute the server application program
6. Create and execute the client application program 37
Step 1: Defining the Remote Interface - b/n client & server objects
 an interface that will provide the description of the methods that
can be invoked by remote clients
 This interface should extend Remote interface and the method
prototype within the interface should throw RemoteException

import java.rmi.*;
public interface Adder extends Remote{
public int add(int x,int y) throws RemoteException;
} 38
Step 2: Implementing the remote interface
 To implement the remote interface, the class should extend to
UnicastRemoteObject class of java.rmi package
Allows objects to
import java.rmi.*; be exported.

import java.rmi.server.*;
public class AdderRemote extends UnicastRemoteObject implements Adder{
// Default constructor to throw RemoteException from its parent
constructor
AdderRemote()throws RemoteException{
super(); Superclass constructor exports objects,
} and this constructor must be able to
// Implementation of add interface throw RemoteException.
public int add(int x,int y){
return x+y;
} 39
Step 3: Creating Stub and Skeleton objects from the
implementation class using rmic
 rmic tool is used to invoke rmi compiler that creates Stub and
Skeleton objects

 For above program the following command need to be executed at
the command prompt
rmic AdderRemote //generates AdderRemote_Stub.class
//From Java 6 onwards skeleton class is not required
Step 4: Start the rmiregistry
 start the registry service by using the rmiregistry tool.
 If you don't specify port number, it uses a default port number
start rmiregistry 40
Step 5: Create and execute server application program
 server program uses createRegistry() method of
LocateRegistry class to create rmiregistry within the server
JVM with the port number passed as an argument
 rebind method of Naming class is used to bind the remote

object to the new name
 Create the object of remote class.
 static method bind/rebind (class Naming)
 Binds object to rmiregistry
 Object named to be used by client
 rebind replaces any previous objects with same name
• Method bind does not 41
Step 5: Create and execute server application program
import java.rmi.*;
import java.rmi.registry.*;
public class MyServer{
public static void main(String args[]){
try{

// Create an object of interface implementation class
Adder stub = new AdderRemote();
// rmiregistry within server JVM with port number 1900
LocateRegistry.createRegistry(5000);
// Binds the remote object by the name sonoo
Naming.rebind("rmi://localhost:5000/sonoo", stub);
}
catch(Exception e){System.out.println(e);}
}
} 42
Step 5: Create and execute client application program
 lookup() method of the Naming class is used to get the reference of the
Stub object
 In this example, we are running the server and client applications, in the
same machine so we are using localhost

import java.rmi.*;
public class MyClient{
public static void main(String args[]){
try{
// lookup method to find reference of remote object
Adder stub = (Adder)Naming.lookup("rmi://localhost:5000/sonoo");
System.out.println(stub.add(34,4));
} catch(Exception e){}
} 43
// Java program for client application
}
RPC Vs. RMI
RPC (Remote Procedure Call) RMI (Remote Method Invocation)
is a library and OS dependent platform. is a platform based on Java
supports procedural programming. supports object-oriented programming.
is less efficient in comparison to RMI. is more efficient in comparison to RPC.
creates more overhead. creates less overhead in comparison to RPC.

parameters passed to RPC is normal data. In this, objects are passed as parameters.
is the older version of RMI. is the successor of RPC.
is easy to program in RPC. is not easy to program in RMI.
doesn’t provide any security. provides client level security.
cost of development is high. cost of development is inexpensive.
Versioning is a complicated process in RPC. Versioning is possible using RDMI.
Multiple codes will be needed to build a Multiple codes are not required to build a
simple application in RPC. simple application in RMI
44
Message-Oriented Communication (MOC)
 Due to
 RPC and RMI contribute to hiding commn in DSs
 When it is assumed that the receiving side is executed at the time
a request is issued,
 Inherent synchronous nature RPCs, by which a client is blocked

until its request has been processed,
alternative communication services are needed/replaced
 Message-oriented communication abstraction is one of the
alternatives does not attempt to hide the fact that
communication is taking place.
 Goal: to make the use of flexible message passing easier
45
 MOC in DS is one of the most popular communications
paradigm that allows us to achieve high performance,
scalability, and fault tolerance simultaneously
 MOC is provided by message-oriented middleware

(MOM)
 MOM is software or hardware infrastructure supporting
sending and receiving messages between DSs
 MOM allows application components to be distributed over
heterogeneous platforms and reduces the complexity of
developing applications that span multiple OS and network
protocols 46
 Message Passing refers to the communication between
processes, whereas message queues refer to a linked list of
messages stored within the kernel.
 Messages are put into the queue by a message producer and

retrieved from it by a consumer.
 Message queue is software-engineered for sending
messages between processes, applications, and servers in
the distributed computing.
 A message queue receives and sends messages between
loosely coupled microservices, applications, sockets, and
other endpoints. 47

48
Stream-Oriented Communication
 Streams - deals with continuous communication, and in particular
with the sending and receiving of continuous media.
• a form of communication in which timing plays an important role
 The main characteristic of continuous media is:
• a spatial relationship between data (i.e., ordering of the data),

• a temporal relationship between the data
 Streams of continuous media are examples of isochronous
communication that is communication that has minimum and
maximum end-to-end time delay requirements
 It is usually used in audio and video streaming where message
communication can be thought of as a request-response.
 In Stream communication, you might start receiving data without it 49

 Choosing among commn strategies, used for delivering message
between entities, therefore becomes crucial in order to efficiently
utilize available resources.
• Systems where identical data is delivered to many recipients are
common nowadays, but may apply an underlying commn strategy based
on direct interaction b/n sender & receiver which is insufficient 50
Multicast Communication
 Multicasting refers to a technique for group commn where messages
can be distributed to participating nodes in a single transmission
• messages goes from one sender to multiple receivers
• messages are replicated on network elements, i.e. routers and

switches
 This technique is developed to avoid the problem of high workload
on sender side and redundant traffic in the network, and constitutes
the focus
• This means that only one message needs to be sent on each link in the
network which can decrease the amount of copies on the outgoing
link for this thesis 51
MOC Vs. SOC
Message oriented communication (MOC) Stream oriented communication (SOC)
It is the one in which the sender sends a stream of data
It is the one in which the sender sends a message
and the receiver receives a continuous flow of data till
and the receiver will receive it.
the sender stops sending data.
UDP (user datagram protocol) uses manage TCP (transmission contact protocol) uses stream-oriented
oriented communication communication
Data is sent by application in discrete packages

Data is sent with no particular structure.
called messages.
Communication is connectionless, data is sent Communication is oriented, and the connection is
without any setup. established before comm.
It is unreliable best effort delivery without
It is reliable, data is acknowledged.
acknowledgment.
Retransmission is not performed. Lost data is reframed automatically.
No flow control. Flow control using sent protocol like sliding
Transmission speed is very high as compared to Transmission speed is lower as compared to message
stream-oriented. orientation.
Suitable for applications like audio, and video
Suitable for applications like e-mail systems where data
52
The End!
Questions, Ambiguities,

Doubts, … ???
53

Chapter - 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter - 4

Uploaded by

Copyright:

Available Formats

Arba Minch University

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Figure. (a) Parameter passing in a local procedure

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Figure. Principle of RPC between a client

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

 To invoke a remote object,

Intro to Distributed System

Intro to Distributed System

to the registry Registry

 The client lookup the server name skeleton

Intro to Distributed System

 The Stub serializing the parameters

the remote method and serializing

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

Intro to Distributed System

You might also like