Chapter 3: Interprocess Communication

Chapter 3: Interprocess

Communication

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.

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.

Introduction

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

Introduction (Cont).

Figure 4.1Middleware layers

Applications, services

Middlewarelayers

request-reply protocol

marshalling and external data representation

UDP and TCP

Thischapter

RMI and RPC

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) synchronousii) asynchronous

API for Internet Protocols

Characteristics of interprocess communication (cont.)

Communicated data can be stream or datagram

a) stream – sequence of byteb) datagram – discrete packet contain header, data, and trailer information (error correction, etc)

Message destination: message are sent to (internet address, local port) pairs

API for Internet Protocols

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.

API for Internet Protocols (cont.)

Figure 4.2Sockets and ports

message

agreed portany port

socketsocket

Internet address = 138.37.88.249Internet address = 138.37.94.248

other ports

client server

Interprocess communication: ~Transmitting a message between a socket in one process & a socket in another process message

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”);


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


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


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


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


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 hostnameDatagramSocket 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();}

} }

Fig. 4.4: UDP Server Repeatedly Receives A Request And Sends It Back

To The Clientimport 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();}

}}

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.


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


TCP Stream Communication (cont.)

Outstanding issues for stream communication:

~ Matching of data item~ Blocking~ Threads


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


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 destinationSocket 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.3String 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());}} } }

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

Fig. 4.6 continuedclass 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*/}}}

}

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:

i. Connected to an agreed external format before transmission

ii. Transmitted in sender format-with indication of format being used.


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


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.

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 CORBAb) Java object serialization~ concern with flattening & external data representation of any single object or tree of objects that need to be transferred in messagec) Extensible markup language (XML)~ define a textual format representation for structured data (ex: document access on Web)

Fig. 4.7: CORBA CDR for constructed types

Type Representation

sequence length (unsigned long) followed by elements in order

string length (unsigned long) followed by characters in order (can also

can have wide characters)

array array elements in order (no length specified because it is fixed)

struct in the order of declaration of the components

enumerated unsigned long (the values are specified by the order declared)

union type tag followed by the selected member

Fig. 4.10: XML definition of the Person structure

<person id="123456789"><name>Smith</name><place>London</place><year>1934</year>

</person >

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 happen4th field identifies object within the processits 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

External Data Representation & Marshalling (cont.)

Fig. 4.13: Representation Of Remote Object Reference

Internet address port number time object numberinterface of

remote object

32 bits 32 bits 32 bits 32 bits

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: (i)client needs 1 primitive ( doOperation ), server

needs 2 ( getRequest and sendReply ); (ii) since clients normally wait for replies

doOperation is synchronous; (iii)server must be able to receive getRequest

messages while performing operations.

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

Fig. 4.14:Request-reply communication

Request

ServerClient

doOperation

(wait)

(continuation)

Reply

message

getRequest

execute

method

message

select object

sendReply

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.

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

Fig. 4.17: RPC Exchange Protocols

R RequestRR Reply

RRA Acknowledge reply

Request

Request Reply

Client Server Client

Name Messages sent by

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

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

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

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 UDPUnreliable multicast-doesn’t guarantee msg be

delivered do not specify time , thus issue in ordering.

Documents

Chapter 3: Interprocess Communication