CHAPTER 4: Communication

Course Code: CoSc 4038

 Distributed
Fundamentals Systems

 Inter-process communication is at the heart of all distributed systems.

 As such systems are made up of several processes running on different machines
 How processes on different machines can exchange information?
 Given, these processes do not have shared memory and clock
1. Traditional approach
 Use low-level message-passing primitives offered by the transport layer (send an
d receive).
 However, these are difficult to use for large-scale distributed Apps.
2. Use middleware systems that offer a higher level of abstraction
 Easier to express communication between processes

2
 Distributed
Layered protocols Systems

 Communication often requires agreement at different levels

 From the low-level details of bit transmission to the high-level
details of how information is to be expressed.
 Thus, communication protocols are often organized as layered
protocols
 Examples
 Open Systems Interconnection Reference Model (ISO OSI)
 TCP/IP

3
 Distributed
Layered Protocols (1) Systems

 Figure 4-1. Layers, interfaces, and protocols in the OSI model.

4
 Distributed
Layered protocol Systems

 Each layer deals with one specific aspect of the communication.

 Each layer provides an interface to the one above it.
 When process A on machine 1 wants to communicate with process B on machine 2
 It builds a message and passes the message to the application layer on its machine.
 Application layer add a header information and pass it to the next layer (presentation
layer)
 Every layer does same up until data link layer
 Finally, the physical layer sends out the packet
 When the message arrives at machine 2, it is passed upward, with each layer stripping
off and examining its own header.

5
 Distributed
Layered Protocols (2) Systems
 Every layer adds a header to the front of the message
 But some put trailer either

 Figure 4-2. A typical message as it appears on the network.

6
 Distributed
Low level layers Systems

 Physical layer: contains the specification and implementation of b

its, and their transmission between sender and receiver
 Data link layer: prescribes the transmission of a series of bits into
a frame to allow for error and flow control
 Network layer: describes how packets in a network of computers
are to be routed.
 Note:
 For many distributed systems, the lowest-level interface is that of the
network layer.

7
 Distributed
Transport Layer Systems

 The transport layer provides the actual communication

facilities for most distributed systems.
 Turn the underlying network into something that a developer
can easily use
 Example transport layer protocols
 TCP: connection-oriented protocol, reliable communication
 UDP: connectionless protocol,
 Unreliable,
 Application has to handle error
8
 Distributed
Higher-Level Protocols Systems

 OSI has three additional layers above transport layer

 In TCP/IP suite, everything above transport layer is grouped together
 Session layer is an enhanced version of transport layer
 Provides dialog control, e.g., keeps track of who is talking and provide syn
chronization
 Presentation layer is mainly concerned with the meaning of the bits
 Application layer : Protocols for things like mail, file transfer, communic-
ation terminals.
 Examples:
 FTP (File Transfer Protocol)
 HTTP (HyperText Transfer Protocol)
9
 Distributed
Drawbacks of OSI reference model Systems

 Focus on message-passing only

 Contained often unneeded or unwanted functionality
 Session and presentation layers are not effectively used and in practice only the application layer is ever
used.

 Accordingly, the TCP/IP has merged everything above transport layer into application layer

10
 Distributed
2. Middleware Systems

 Middleware communication protocols support high-level communication

services.
 Example: Remote Method Invocation(RMI)
 Middleware is invented to provide common services and protocols that can
be used by many different applications
 A rich set of communication protocols
 (Un)Marshaling of data
 Naming protocols, to allow easy sharing of resources
 Security protocols for secure communication
 Scaling mechanisms, such as for replication and caching

11
 Distributed
Middleware Protocols Systems
 The session and presentation layer have been replaced by a single middleware layer that contains application-independent protocols.
 Supports
 Communication protocols, Naming protocols, Security protocols, Scaling mechanisms, such as replication and caching

 Figure 4-3. An adapted reference model for networked communication.

12
 Distributed
Types of Communications Systems

 Persistent communication
 A message is stored at a communication server as long as it takes to deliver it.
 The sending application can exit after submitting
 The receiving application does not have to be active
 Transient communication-message is stored as long as the sending/receiving is executing
 Comm. server discards message when it cannot be delivered at the next server, or at the receiver.
 Asynchronous communication
 Sender continues immediately after submitting a message
 Synchronous communication
 Sender will wait until it is certain that the message is received

13
 Distributed
Communication in Client/Server Systems

 Client/Server computing is generally based on a model of transient synchronous

communication:
 Client and server have to be active at time of communication
 Client issues request and blocks until it receives reply
 Server essentially waits only for incoming requests, and subsequently processe
s them
 Drawbacks of synchronous communication
 Client cannot do any other work while waiting for reply
 Failures have to be handled immediately: the client is waiting
 The model may simply not be appropriate for some applications (mail, news)

14
 Distributed
Message-oriented middleware(MoM) Systems

 Aims at high-level persistent asynchronous communication:

 Processes send each other messages, which are queued
 Sender need not wait for immediate reply, but can do other
things
 Middleware often ensures fault tolerance

15
 Distributed
Remote procedure call Systems

 RPC is a normal looking procedure call processed on a remot

e machine
 Motivations
 Application developers are familiar with simple procedure model
 Well-engineered procedures operate in isolation (black box)
 Hence, there is no fundamental reason not to execute procedures on separate ma
chine

 Conclusion
 Communication between caller & callee can be hidden by using procedure-call
mechanism. 16
 Distributed
RPC between Client and Server Systems

 RPC achieves transparency through client and server stubs

 Client stub packs parameters into a message to the server, and inspect the result from server and
copy it to the caller
 Server stub unpacks parameters, calls the procedure, and packs the result to the client

Figure 4-4. Principle of RPC between a client and server program.

17
 Distributed
RPC steps Systems

18
 Distributed
RPC Steps Systems

1) The client procedure calls the client stub in the normal way.
2) The client stub builds a message and calls the local OS.
3) The client’s OS sends the message to the remote OS.
4) The remote OS gives the message to the server stub.
5) The server stub unpacks the parameters and calls the server.
6) The server does the work and returns the result to the stub.
7) The server stub packs it in a message and calls its local OS.
8) The server’s OS sends the message to the client’s OS.
9) The client’s OS gives the message to the client stub.
10) The stub unpacks the result and returns to the client.

19
 Case Study:
Remote Method Invocation (RMI)
 Distributed
“The network is the computer” Systems

 Consider the following program organization:

method call
SomeClass AnotherClass
returned object

computer 1 computer 2

 If the network is the computer, we ought to be able to put the two classes on different
computers

 RMI is one technology that makes this possible

21
 Distributed
RMI and other technologies Systems

 CORBA (Common Object Request Broker Architecture) has long been king
for RPC.
 CORBA supports object transmission between virtually any languages
 Objects have to be described in IDL (Interface Definition Language), which looks a l
ot like C++ data definitions
 CORBA is complex and flaky
 Microsoft supported CORBA, then COM, now .NET
 RMI is purely Java-specific
 Java to Java communications only
 As a result, RMI is much simpler than CORBA
22
 Distributed
What is needed for RMI Systems

 Java makes RMI (Remote Method Invocation) fairly easy, but there are some ex
tra steps
 To send a message to a remote “server object,”
 The “client object” has to find the object
 Do this by looking it up in a registry
 The client object then has to marshal the parameters (prepare them for trans-
mission)
 Java requires Serializable parameters
 The server object has to unmarshal its parameters, do its computation, and marshal its response
 The client object has to unmarshal the response
 Much of this is done for you by special software implemented as part of
rmi package
23
 Distributed
Terminology Systems

 A remote object is an object on another computer

 The client object is the object making the request (sending a message to the other ob
ject)
 The server object is the object receiving the request
 As usual, “client” and “server” can easily trade roles (each can make requests of the other)

 RMI requires
 For RMI, you need to be running two processes
 The Client
 The Server
 You also need TCP/IP active

24
 Distributed
Interfaces Systems

 Interfaces define behavior

 Classes define implementation

 Therefore,
 In order to use a remote object, the client must know its behavior (interface), but
does not need to know its implementation (class)
 In order to provide an object, the server must know both its interface (behavior)
and its class (implementation)
 In short,
 The interface must be available to both client and server processes
 The class should only be on the server
25
 Distributed
Classes Systems

 A Remote class is one whose instances can be accessed remotely

 On the computer where it is defined, instances of this class can be
accessed just like any other object
 On other computers, the remote object can be accessed via object
handles
 A Serializable class is one whose instances can be marshaled (turned int
o a linear sequence of bits)
 Serializable objects can be transmitted from one computer to another
 Instance of Remote class is serializable

26
 Distributed
Conditions for serializability Systems

 If an object is to be serialized:
 The class must be declared as public
 The class must implement Serializable
 The class must have a no-argument constructor
 All fields of the class must be serializable: either primitive types or
serializable objects

27
 Distributed
Remote interfaces and class Systems

 The interface class (used by both client and server):

 Must be public
 Must extend the interface java.rmi.Remote
 Every method in the interface must declare that it throws java.rmi.
RemoteException (other exceptions may also be thrown)
 Interface Implementation class:
 Must implement a Remote interface
 Should extend java.rmi.server.UnicastRemoteObject
 May have locally accessible methods that are not in its Remote interface

28
 Distributed
The server class Systems

The server class needs to register its server object on the registry:
 Registry reg= LocateRegistry.createRegistry(port);
 reg.rebind(“HelloServer”, new Hello());

Note:
• We can use unused port The default port is 1099
• “HelloServer” is just a name we use to refer to the remote object from the client
The above code snippet requires the following:
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

30
 Distributed
Hello world server: interface Systems

• Step 1: Create interface class that imports java.rmi.*; and extends the Remot
e class

import java.rmi.*;

public interface HelloInterface extends Remote {

public String say(String msg) throws RemoteException;
}

31
 Distributed
Interface implementation: class Systems

Step 2: Create class that implements the interface defined in prevous step and extends
UnicastRemoteObject

import java.rmi.*;
import java.rmi.server.*;

public class Hello extends UnicastRemoteObject

implements HelloInterface {

public Hello () throws RemoteException {

super();
}

public String say(String msg) throws RemoteException {

return “Hello, “+msg;
}
}
32
 Distributed
Registering the hello world server Systems

Step 3: Create server class that register an instance of implementation classs defined in the prevous step.

class HelloServer {
public static void main (String[] argv) {
try {
Registry reg= LocateRegistry.createRegistry(5555);
reg.rebind(“HelloServer”, new Hello());
System.out.println("Hello Server is ready.");
}
catch (Exception e) {
System.out.println("Hello Server failed: " + e);
}
}
}
33
 Distributed
The hello world client program Systems

Step 4: Create client program that consumes services provided by the server
class HelloClient {
public static void main (String[] args) {
HelloInterface hello;
try {
Registry r= LocateRegistry.getRegistry(“localhost”,5555);
hello = (HelloInterface)r.lookup(HelloServer);
System.out.println(hello.say(“Mulugeta”));
}
catch (Exception e) {
System.out.println("HelloClient exception: " + e);
}
}
}

34
 Distributed
Trying RMI Systems

 In different terminal windows:

1. Run the server program first
2. Run the client program then:
 If all goes well, you should get the “Hello, Mulugeta” mess
age
 To try this on two machines
 Move client and a copy of HelloInterface to client machine
 Change localhost by the ip address of the machine on which server is ru
nning

35
 Distributed
Summary Systems

1. Start the object server

 The object server registers an object, with a name, with the registry server
2. Start the client
 The client looks up the object in the registry server
3. The client makes a request
 The request actually goes to the Stub class
 The Stub classes on client and server talk to each other
 The client’s Stub class returns the result

36
 Distributed
References Systems

 Trail: RMI
by Ann Wollrath and Jim Waldo
 http://java.sun.com/docs/books/tutorial/rmi/index.html

 Fundamentals of RMI Short Course

by jGuru
 http://developer.java.sun.com/developer/onlineTraining/
rmi/RMI.html

 Java RMI Tutorial

by Ken Baclawski
 http://www.ccs.neu.edu/home/kenb/com3337/rmi_tut.html
37
End of Chapter-4

38