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.

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.

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

Figure 4.1 Middleware layers

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

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

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.

Figure 4.2 Sockets and ports message agreed port any port socket Internet address = 138.37.88.249 Internet 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

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

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

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

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

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

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

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

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.

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

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

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

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

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 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*/}}

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.

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

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.

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)

Fig. 4.7: CORBA CDR for constructed types Re 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

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

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 •

Fig. 4.13: Representation Of Remote Object Reference Internet address port number time object number interface of remote object 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: 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.

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 Server Client doOperation (wait) (continuation) Reply message getRequest execute method 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 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

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 UDP Unreliable multicast-doesn’t guarantee msg be delivered do not specify time , thus issue in ordering.