1. Chapter 3: Interprocess Communication

2. Objectives
To study characteristics: interprocess communication, datagram & stream communication in Internet.
To study Java applications that use the Internet protocols & Java serialization.
To be aware of design issues for Request-Reply protocols & how collections of data objects may be represented in messages.

3. Introduction
Concern characteristic of protocols for communication between process in DS
~ many components & interconnections
Java API for interprocess communication provides datagram & stream communication
~ discuss failure models.
Representation of collection of data objects
in messages & references to remote objects.
Emphasis on logical relationship between components, e.g. client & server; group communication.

4. TCP is a connection-oriented protocol with guaranteed delivery
Introduction (Cont).
TCP (Transport Control Protocol) and UDP (User Datagram Protocol) are layer protocols
TCP is a connection-oriented protocol with guaranteed delivery
UDP is a connectionless protocol without guaranteed message delivery
Socket is an endpoint for communication between processes with uniquely named.
~ so other process can find, communicate, and access it

5. Figure 4.1 Middleware layers

6. API for Internet Protocols
Characteristics of interprocess communication
Message passing between process
2 message communication operations:
i) send
ii) receive
A process send a message to a destination, another process at destination receive message
Communication between send & receive process:
i) synchronous
ii) asynchronous

7. API for Internet Protocols
Characteristics of interprocess
communication (cont.)
Communicated data can be stream or datagram
a) stream – sequence of byte
b) datagram – discrete packet contain header, data, and trailer information (error correction, etc)
Message destination: message are sent to (internet address, local port) pairs

8. API for Internet Protocols (cont.)
Sockets
UDP & TCP use socket
Endpoint for communication between process
Originate from BSD UNIX, but present in most UNIX version such Linux; Windows & Macintosh OS
A process received message:
~ its sockets bound to a local port & 1 of the Internet addresses on which it runs
Process may use same socket for sending & receiving messages
Each computer has a large number (216) of possible port for use by local processes for receiving message.

9. Figure 4.2 Sockets and ports
message
agreed port
any port
socket
Internet address =
Internet address =
other ports
client
server
Interprocess communication: ~Transmitting a message between a socket in one process & a socket in another process message

10. API for Internet Protocols (cont.)
Java API for Internet Addresses
IP packets underlying UDP & TCP are sent to Internet Addresses
Java provides class, InetAddress
~ represents Internet addresses
Method uses DNS to get corresponding Internet addresses.
Example: to get an object representing Internet Addresses of the host whose DNS name is bruno.dcs.qmul.ac.uk, use:
InetAddress aComputer = InetAddress.getByName(“bruno.dcs.qmul.ac.uk”);

11. API for Internet Protocols (cont.)
UDP Datagram Communication
A datagram sent by UDP is transmitted from a sending process to a receiving process
A datagram is transmitted between processes ~1 process sends its & another process receives it
Create a socket bound to an Internet address of the local host & local port
Server will bind its socket to a server port
Client bind its socket to any free local port

12. API for Internet Protocols (cont.)
UDP Datagram Communication (cont.)
Receive method return Internet Addresses & port of sender, allowing recipient to send reply.
Issue relating datagram communication:
a) Message size;
b) Blocking;
c) Timeouts;
d) Receiving from any

13. API for Internet Protocols (cont.)
Datagram communication is a useful building block for lightweight interprocess communication protocols
~ Example: Request-Reply protocol
~ Because it carries the minimum possible overheads for the resulting protocols.
Stream communication is a
useful alternative
~ Because can simplify
programming task

14. API for Internet Protocols (cont.)
Failure Model
Failure model can be used to provide a failure model for UDP datagram
Suffer from the following failures:
Omission Failures:
~ Message may be dropped occasionally
~ Because checksum error or no buffer
space is available at destination
Ordering:
~ Messages can sometimes be delivered
out of sender order

15. Fig. 4.3: UDP Client Sends A Message To Server And Gets A Reply
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
// args give message contents and server hostname
DatagramSocket aSocket = null;
try { aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, args[0].length(),
aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}
} }

16. Fig. 4.4: UDP Server Repeatedly Receives A Request And Sends It Back To The Client
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
DatagramSocket aSocket = null;
try{
aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply); }
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());}
}finally {if(aSocket != null) aSocket.close();}

17. API for Internet Protocols (cont.)
TCP Stream Communication
Provide abstraction of a stream of bytes to which data may be written and which data may be read
Characteristic of the network are hidden by the stream abstraction:
Message sizes
Lost messages
Flow control
Message duplication and ordering
Message destinations
API for stream communication assume that 1 of them play client role and other play server role, but they could be peers.

18. API for Internet Protocols (cont.)
TCP Stream Communication (cont.)
For a client, we need to connect to the server which we need to communicate
Client role:
~ creating a stream socket
~ make a connect request asking for a connection to a server at its server port
For server there is a need to use listen & accept
Server role:
~ create a listening socket bound to server port
~ waiting for client to request connection

19. API for Internet Protocols (cont.)
TCP Stream Communication (cont.)
Outstanding issues for stream communication:
~ Matching of data item
~ Blocking
~ Threads

20. API for Internet Protocols (cont.)
Java API for TCP streams
Java interface to TCP streams is provided in classes ServerSocket and Socket
~ represents Internet addresses
ServerSocket:
~ intended use by server
~ create a socket at a server port
~ listening for connect request from client
Socket
~ use by pair processes with a connection
~ client uses a constructor to create socket, specifying DNS hostname & port of a server
~ method getInputStream & getOutputStream for accessing 2 streams associated with socket

21. Fig. 4.5: TCP Client Makes Connection To Server, Sends Request & Receives Reply
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
// arguments supply message and hostname of destination
Socket s = null;
try{ int serverPort = 7896;
s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream( s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3
String data = in.readUTF();
System.out.println("Received: "+ data) ;
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){System.out.println("EOF:"+e.getMessage());
}catch (IOException e){System.out.println("IO:"+e.getMessage());}
}finally {if(s!=null) try {s.close();}catch (IOException e){System.out.println("close:"+e.getMessage());}}
} }

22. Fig. 4.6: TCP Server Makes A Connection For Each Client & Then Echoes Client’s Request
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket); }
} catch(IOException e) {System.out.println("Listen :"+e.getMessage());}
// this figure continues on the next slide

23. Fig. 4.6 continued class Connection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e) {System.out.println("Connection:"+e.getMessage());} }
public void run(){
try { // an echo server
String data = in.readUTF();
out.writeUTF(data);
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
} finally{ try {clientSocket.close();}catch (IOException e){/*close failed*/}}

24. External Data Representation & Marshalling
Information stored in running programs is represented as data structures
Example: sets of interconnected objects ~information in messages consist sequences of bytes
Method used to enable 2 computer to exchanges binary data values are:
Connected to an agreed external format before transmission
Transmitted in sender format-with indication of format being used.

25. External Data Representation & Marshalling (cont.)
External data representation: An agreed standard for representation of data structure and primitive values
Marshalling: process of taking collection of data items & assembling them into a form suitable for transmission in a messages
Unmarshalling: process of diassembling them on arrival to produce an equivalent collection of data items at destination

26. External Data Representation & Marshalling (cont.)
Client & server programs:
~ deal with data objects
~ marshalled into a standard form - before they can be passed in messages.
~ Standard form (or external data representation) deals with data structures & primitive data items.
~ CORBA's CDR is designed for use by a variety of programming languages.

27. External Data Representation & Marshalling (cont.)
3 approaches to external data representation & marshalling discusses:
a) CORBA's Common Data Representation (CDR)
~ concern for structured & primitive types
~ can be passed as argument and remote method invocation in CORBA
b) Java object serialization
~ concern with flattening & external data representation of any single object or tree of objects that need to be transferred in message
c) Extensible markup language (XML)
~ define a textual format representation for structured data (ex: document access on Web)

28. Fig. 4.7: CORBA CDR for constructed typesRe pr s n ta t i o q ue ce l g th ( u si ed ) fo ll ow b el m nt r d ri ch a ra c te rs
n o ca al so h av w de
rs) rr ay le
s i
r (
o l en
h s ci f ie
d b
eca us is x ru ct
n t he or
r o la at co mp v
s a re pe
y t
r d ec ar ni
g f we
e s
cte
d m mb er

29. Fig. 4.10: XML definition of the Person structure
<person id=" ">
<name>Smith</name>
<place>London</place>
<year>1934</year>
<!-- a comment -->
</person >

30. External Data Representation & Marshalling (cont.)
Remote object reference
must be unique in DS & over time. It should not be reused after the object is deleted.
first 2 fields locate the object unless migration or re-activation in a new process can happen
4th field identifies object within the process
its interface tells the receiver what methods it has (e.g. class Method)
a remote object reference is created by a remote reference module when a reference is passed as argument or result to another process
stored in the corresponding proxy
passed in request messages to identify remote object whose method is to be invoked
mention that uniqueness is formed from first 3 fileds •

31. Fig. 4.13: Representation Of Remote Object Reference
Internet address
port number
time
object number
interface of
remote object
32 bits

32. Client Server Communication
Request-reply protocols
~ design to support client-server communication
~ client asks server to perform an operation on an object and return result.
~ relationship determines the protocol as follows:
client needs 1 primitive ( doOperation ), server needs 2 ( getRequest and sendReply );
since clients normally wait for replies doOperation is synchronous;
server must be able to receive getRequest messages while performing operations.

33. Client Server Communication (cont.)
Request-reply protocols
~ To deal with failure, requests are re-transmitted
~ To ensure that operation is performed at most once:
- duplicate requests are filtered
- replies are saved for re-transmission

34. Fig. 4.14: Request-reply communication
Server
Client
doOperation
(wait)
(continuation)
Reply
message
getRequest
execute
method
select object
sendReply

35. Fig. 4.15: Operations of the request-reply protocol
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)
sends a request message to the remote object and returns the reply.
The arguments specify the remote object, the method to be invoked and the arguments of that method.
public byte[] getRequest ();
acquires a client request via the server port.
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);
sends the reply message reply to the client at its Internet address and port.

36. Fig. 4.16: Request-reply message structure
messageType
requestId
objectReference
methodId
arguments
int (0=Request, 1= Reply)
int
RemoteObjectRef
int or Method
array of bytes

37. Fig. 4.17: RPC Exchange Protocols
originally identified by Spector [1982]
3 protocols which produced 3 different behavior in presence of communication failure: request (R) protocol request-reply (RR) protocol - request-reply-acknowledge (RRA) protocol R
Request
Reply A
Acknowledge reply
Client
Server
Name
Messages sent by
Fig. 4.17: RPC Exchange Protocols

38. Group Communication
Pairwise exchange - not the best model for communication from 1 process to group of other processes
A multicast operation is more appropriate ~ operation send a single message from 1 process to each of members of a group processes
Membership of group transparent to sender

39. Group Communication (cont.)
Multicast messages provide useful infrastructure for constructing DS with characteristics:
Fault tolerance based on replicated services
Finding discovery servers in spontaneous networking
Better performance through replicated data
Propagation of event notification

40. IP Multicast
Allow sender to transmit single IP packet to set of computer
Allow computer to join or leave group at any time
Available only via UDP
Unreliable multicast-doesn’t guarantee msg be delivered
do not specify time , thus issue in ordering.