Slides for Chapter 4: Interprocess Communication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 4, © Addison-Wesley 2005

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.1 Middleware layers

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Characteristics of inter-process communication zSynchronous communication yThe sending and receiving processes synchronize at every message. Both send and receive are blocking operations. zAsynchronous communication yThe use of the send operation is non-blocking in that the sending process is allowed to proceed as soon as the message is copied to a local buffer. yThe receive operation can have blocking and non-blocking variants. ySupporting multithreading, blocking receive has no disadvantage.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Characteristics of inter-process communication zMessage destination y(Internet address, lcal port) zReliability yA point-to-point message service can be described as reliable if messages are guaranteed to be delivered despite a reasonable number of packets being dropped or lost. zOrdering ySome application require that messages be delivered in sender order.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Sockets zBoth forms of communication (UDP and TCP) use the socket abstraction, which provides an endpoint for communication between processes. zSockets originate from BSD UNIX bust are also present in most version of UNIX, including Linux as well as Windows and Mac OS. zEach computer has a large number (2 16 ) of possible port numbers for uses by local processes.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 UDP datagram communication zA datagram sent by UDP is transmitted from a sending process to a receiving process without acknowledgement or retries. If a failure occurs, the message may not arrive.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Issues relating to UDP datagram communication zMessage size: The receiving process needs to specify an array of bytes of a particular size in which to receive a message. zBlocking: normally non-blocking send and blocking receive zTimeouts: To avoid infinitely waiting. zReceive from any: The receive method does not specify an origin for messages. zFailure model: yOmission failures: Messages may be dropped occasionally, either because of a checksum error or because no buffer space is available at the source or destination. yOrdering: Messages can sometimes be delivered out of sender order.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 TCP stream communication zThe API of TCP provides the abstraction of a stream of bytes to which data may be written an from which data may be read.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Characteristics relating to TCP stream communication zMessage size y The underlying implementation of a TCP stream decides how much data to collect before transmitting it as one or more packets. If necessary, the applications can force data to be send immediately. zLost Messages y Ack. and Retransmission zFlow control yThe TCP protocol attempts to match the speeds of the processes that read from or write to a stream. zMessage duplication and ordering zMessage destinations: yA pair of communicating processes establish a connection before they can communicate over a stream.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Issues related to TCP stream communication zMatching of data items yTwo communicating processes need to agree as to the contents of the data transmitted over a stream. zBlocking yBlocking sending due to flow control, and blocking receiving zThreads zFailure model yIntegrity : checksums to detect and reject corrupt packets and sequence numbers to detect and reject duplicate packets. yValidity : timeout and retransmissions to deal with lost packets yHowever, if the sender does not receive acks from the receivers for a time, it the TCP software will declare the connection is broken. As a result, it is not guaranteed to deliver messages in face of all possible difficulties.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.2 Sockets and ports message agreed port any port socket Internet address = Internet address = other ports client server

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.3 UDP client sends a message to the 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();} }

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 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();} }

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.5 TCP client makes connection to server, sends request and 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());}} }

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.6 TCP server makes a connection for each client and then echoes the 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

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 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*/}} }

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data representation and marshalling zAn agreed standards for the representation of data structures and primitives values is called external data representation. zMarshalling is the process of taking a collection of data items and assembling them into a form suitable for transmission in a message. zUnmarshalling is the process of disassembling them on arrival to produce an equivalent collection of data items at destination.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Three alternative approaches to external data representation and marshalling zCORBA’s common data representation (Chapter 20) zJava’s object serialization zXML (Chapter 19)

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.7 CORBA CDR for constructed types

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.8 CORBA CDR message The flattened form represents aPerson struct with value: {‘Smith’, ‘London’, 1934} 0–3 4–7 8–11 12–15 16– –27 5 "Smit" "h___" 6 "Lond" "on__" 1934 index in sequence of bytes4 bytes notes on representation length of string ‘Smith’ length of string ‘London’ unsigned long

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.9 Indication of Java serialized form The true serialized form contains additional type markers; h0 and h1 are handles Serialized values Person byte version number int year 5 Smith java.lang.String name: 6 London h0 java.lang.String place: h1 Explanation class name, version number number, type and name of instance variables values of instance variables

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Java Object Serialization public class Person implements Serializable{ private String name; private String place; private int year; public Person(String aName, String aPlace, int aYear){ name=aName; place=aPlace; year=aYear; } Person p = new Person(“Smith”, “London”, 1934);

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.10 XML definition of the Person structure Smith London 1934

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.11 Illustration of the use of a namespace in the Person structure Smith London 1934

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.12 An XML schema for the Person structure

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.13 Representation of a remote object reference Internet addressport numbertimeobject number interface of remote object 32 bits A remote object reference is an identifier for a remote object that is valid throughout a distributed system. A remote object reference is passed in the invocation message to specify which Object is to be invoked.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.14 Request-reply communication Request ServerClient doOperation (wait) (continuation) Reply message getRequest execute method message select object sendReply

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 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.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.16 Request-reply message structure messageType requestId objectReference methodId arguments int (0=Request, 1= Reply) int ( ) RemoteObjectRef int or Method array of bytes

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Failure mode of the request-reply protocol zdoOperation, getRequest and sendReply are implemented over UDP datagrams ythey suffer from omission failure ymessages are not guaranteed to be delivered in sender order zTimeout zDiscarding duplicate request messages zLost Reply Message yAn idempotent operation is an operation that can be performed repeatedly with the same effect as if it had been performed exactly once. zHistory

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.17 RPC exchange protocols R Request RRReply RRAAcknowledge reply Request Reply Client Server Client NameMessages sent by

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.18 HTTP request message GET// 1.1 URL or pathnamemethodHTTP versionheadersmessage body HEAD : information about data such as the time of last modification, its type or sizes POST: specify the URL of a resource ( a program) that can deal with the data supplied with the request PUT : requests that the data supplied in the request is stored with the given URL as its identifier. DELETE : Server may not always allow this operation.

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.19 HTTP reply message HTTP/1.1200OK resource data HTTP versionstatus codereasonheadersmessage body

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Group Communication zMulticast messages provide a useful infrastructure for constructing distributed systems with the following characteristics yFault tolerance based on replicated services yFinding the discovery servers in spontaneous networking yBetter performance through replicated data yPropagation of even notifications

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.20 Multicast peer joins a group and sends and receives datagrams import java.net.*; import java.io.*; public class MulticastPeer{ public static void main(String args[]){ // args give message contents & destination multicast group (e.g. " ") MulticastSocket s =null; try { InetAddress group = InetAddress.getByName(args[1]); s = new MulticastSocket(6789); s.joinGroup(group); byte [] m = args[0].getBytes(); DatagramPacket messageOut = new DatagramPacket(m, m.length, group, 6789); s.send(messageOut); // this figure continued on the next slide

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.20 continued // get messages from others in group byte[] buffer = new byte[1000]; for(int i=0; i< 3; i++) { DatagramPacket messageIn = new DatagramPacket(buffer, buffer.length); s.receive(messageIn); System.out.println("Received:" + new String(messageIn.getData())); } s.leaveGroup(group); }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage());} }finally {if(s != null) s.close();} }

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.21 Sockets used for datagrams ServerAddress and ClientAddress are socket addresses Sending a messageReceiving a message bind(s, ClientAddress) sendto(s, "message", ServerAddress) bind(s, ServerAddress) amount = recvfrom(s, buffer, from) s = socket(AF_INET, SOCK_DGRAM, 0)

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 4.22 Sockets used for streams Requesting a connectionListening and accepting a connection bind(s, ServerAddress); listen(s,5); sNew = accept(s, ClientAddress); n = read(sNew, buffer, amount) s = socket(AF_INET, SOCK_STREAM,0) connect(s, ServerAddress) write(s, "message", length) s = socket(AF_INET, SOCK_STREAM,0) ServerAddress and ClientAddress are socket addresses