Chapter 4- Communication

Mulugeta M.
Fundamentals
 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 and 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
Layered protocols
 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
Layered Protocols (1)

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

4
Layered protocol
 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
Layered Protocols (2)
 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
Low level layers
 Physical layer: contains the specification and
implementation of bits, 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
Transport Layer
 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
Higher-Level Protocols
 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 synchronization
 Presentation layer is mainly concerned with the
meaning of the bits
 Application layer : Protocols for things like mail, file
transfer, communication terminals.
 Examples:
 FTP (File Transfer Protocol)
 HTTP (HyperText Transfer Protocol)

9
Drawbacks of OSI reference model
 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
Middleware
 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
Middleware Protocols
 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
Types of Communications
 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
Communication in Client/Server
 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 processes 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
Message-oriented middleware(MoM)
 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
 Remote procedure call
 RPC is a normal looking procedure call processed on a
remote 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 machine
 Conclusion
 Communication between caller & callee can be hidden by using
procedure-call mechanism.

16
RPC between Client and Server
 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
RPC steps

18
RPC Steps
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)
“The network is the computer”*
 Consider the following program organization:

method call
SomeClass AnotherClass
returned
computer 1 object 2
computer

 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
RMI and other technologies
 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 lot 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
What is needed for RMI
 Java makes RMI (Remote Method Invocation) fairly easy,
but there are some extra 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 transmission)
 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
23
Terminology
 A remote object is an object on another computer
 The client object is the object making the request
(sending a message to the other object)
 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
Interfaces
 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
 The class should only be on the server

25
Classes
 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 into a linear sequence of bits)
 Serializable objects can be transmitted from one computer to
another
 Instance of Remote class is serializable

26
Conditions for serializability
 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
Remote interfaces and class
 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
The server class
 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
Hello world server: interface
 import java.rmi.*;

public interface HelloInterface extends Remote {

public String say(String msg) throws RemoteException;
}

31
Interface implementation: class
 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
Registering the hello world server
 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
The hello world client program
 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
Trying RMI
 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”
message
 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 running

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

36
References
 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