Introduction The API for the Internet protocols External data representation and marshalling

Chapter 4: Interprocess Communication • Introduction • The API for the Internet protocols • External data representation and marshalling • Client-Server communication • Group communication • Case study: interprocess communication in UNIX • Summary

Introduction • Middleware layers • TCP ( UDP) from a programmers point of view • TCP : two stream • UDP : datagram, message passing • Java interface, UNIX Socket • marshalling and demarshalling • data form translation • Client-Server communication • Request-Reply protocols • Java RMI, RPC • Group communication

Middleware layers

The characteristics of interprocess communication • Synchronous and asynchronous • a queue associated with message destination, Sending process add message to remote queue, Receiving process remove message from local queue • Synchronous: send and receive are blocking operations • asynchronous: send is unblocking, receive could be blocking or unblocking (receive notification by polling or interrupt) • Message destination • Internet address + local port • service name: help by name service at run time • location independent identifiers, e.g. in Mach • Reliability • validity: messages are guaranteed to be delivered despite a reasonable number of packets being dropped or lost • Integrity: messages arrive uncorrupted and without duplication • Ordering • the messages be delivered in sender order

agreed port any port socket socket message client server other ports Internet address = 138.37.94.248 Internet address = 138.37.88.249 Socket • Endpoint for communication between processes • Both forms of communication (UDP and TCP ) use the socket abstraction • Originate from BSD Unix, be present in Linux, Windows NT and Macintosh OS etc • be bound to a local port (216 possible port number) and one of the Internet address • a process cannot share ports with other processes on the same computer

UDP datagram communication • UDP datagrams are sent without acknowledgement or retries • Issues relating to datagram communication • Message size: not bigger than 64k in size, otherwise truncated on arrival • blocking: non-blocking sends (message could be discarded at destination if there is not a socket bound to the port ) and blocking receives (could be timeout) • Timeout: receiver set on socket • Receive from any: not specify an origin for messages, but could be set to receive from or send to particular remote port by socket connection operation • Failure model • omission failure: message be dropped due to checksum error or no buffer space at sender side of receiver side • ordering: message be delivered out of sender order • application maintains the reliability of UDP communication channel by itself

Java API for UDP datagrams • DatagramPacket • DatagramSocket • send and receive : transmit datagram between a pair of sockets • setSoTimeout : receive method will block for the time specified and then throw an InterruptedIOexception • connect: connect to a particular remote port and Internet address • Examples • be acceptable to services that are liable to occasional omission failures, e.g. DNS

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

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

TCP stream communication • The API to the TCP • provide the abstraction of a stream of bytes to which data may be written and from which data may be read • Hidden network characteristics • message sizes • lost messages • flow control • message duplication and ordering • message destinations • issues related to stream communication • Matching of data items: agree to the contents of the transmitted data • Blocking: send blocked until the data is written in the receiver’s buffer, receive blocked until the data in the local buffer becomes available • Threads: server create a new thread when it accept a connection

TCP stream communication … continued • failure model • integrity and validity have been achieved by checksum, sequence number, timeout and retransmission in TCP protocol • connection could be broken due to unknown failures • Can’t distinguish between network failure and the destination process failure • Can’t tell whether its recent messages have been received or not

Java API for TCP Streams • ServerSocket • accept: listen for connect requests from clients • Socket • constructor • not only create a socket associated with a local port, but also connect it to the specified remote computer and port number • getInputStream • getOutputStream • Examples

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

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

TCP Server … 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 and marshalling introduction • Why does the communication data need external data representation and marshalling? • Different data format on different computers, e.g., big-endian/little-endian integer order, ASCII (Unix) / Unicode character coding • How to enable any two computers to exchange data values? • The values be converted to an agreed external format before transmission and converted to the local form on receipt • The values are transmitted in the sender’s format, together with an indication of the format used, and the receipt converts the value if necessary • External data representation • An agreed standard for the representation of data structures and primitive values • Marshalling (unmarshalling) • The process of taking a collection of data items and assembling them into a form suitable for transmission in a message • Usage: for data transimission or storing in files • Two alternative approaches • CORBA’s common data representation / Java’s object serialization

CORBA’s Common Data Representation (CDR) • Represent all of the data types that can be used as arguments and return values in remote invocations in CORBA • 15 primitive types • Short (16bit), long(32bit), unsigned short, unsigned long, float, char, … • Constructed types • Types that composed by several primitive types • A message example • The type of a data item is not given with the data representation in message • It is assumed that the sender and recipient have common knowledge of the order and types of the data items in a message. • RMI and RPC are on the contrary

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

notes index in on representation sequence of bytes 4 bytes length of string 5 0–3 "Smit" 4–7 ‘Smith’ "h___" 8–11 12–15 6 length of string "Lond" 16–19 ‘London’ "on__" 20-23 1934 24–27 unsigned long The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934} CORBA CDR message Struct Person { string name; string place; long year; };

Java object serialization • Serialization (deserialization) • The activity of flattening an object or a connected set of objects into a serial form that is suitable for storing on the disk or transmitting in a message • Include information about the class of each object • Handles: references to other objects are serialized as handles • Each object is written once only • Example • Make use of Java serialization • ObjectOutputStream.writeObject, ObjectInputStream.readObject • The use of reflection • Reflection : The ability to enquire about the properties of a class, such as the names and types of its instance variables and methods • Reflection makes it possible to do serialization (deserialization) in a completely generic manner • Remote object reference • An identifier for a remote object that is valid throughout a distributed system • Must ensure uniqueness over space and time • Example

Explanation Serialized values Person 8-byte version number h0 class name, version number java.lang.String java.lang.String number, type and name of int year 3 name: place: instance variables 1934 5 Smith 6 London h1 values of instance variables The true serialized form contains additional type markers; h0 and h1 are handles Indication of Java serialized form 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; } // followed by methods for accessing the instance variables } Person p = new Person(“Smith”, “London”, 1934);

32 bits 32 bits 32 bits 32 bits interface of Internet address port number time object number remote object Representation of a remote object reference

The request – reply protocol • The request-reply protocol • Always be implemented over UDP but not TCP • Acknowledgements are redundant since requests are followed by replies • Establishing a connection involves two extra pairs of messages in addition to the pair required for a request and a reply • Flow control is redundant for the majority of invocations, which pass only small arguments and results • Request-reply message structure • requestID: prevent duplicated request and delayed reply

Client Server Request doOperation getRequest message select object execute (wait) method Reply sendReply message (continuation) Request-reply communication • 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.

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

The request – reply protocol … continued • Failure model • Timeout • doOperation return exception when repeatedly issued requests are all timeout • Duplicate request messages: filter out duplicates by requestID • if the server has not yet sent the reply, transmit the reply after finishing operation execution • If the server has already sent the reply, execute the operation again to obtain the result. Note idempotent operation, e.g., add an element to a set, and a contrary example, append an item to a sequence • History: server contains a record of reply messages that have been transmitted to avoid re-execution of operations • Implement the request-reply protocol on TCP • Costly, but no need for the request-reply protocol to deal with retransmission and filtering • Successive requests and replies can use the same stream to reduce connection overhead

HTTP: an example of a request – reply protocol • Over TCP • Each client-server interaction consists of the following steps • The client requests and the server accepts a connection at the default server port or at a port specified in the URL • The client sends a request message to the server • The server sends a reply message to the client • The connection is closed • Persistent connection • Connections that remain open over a series of request-reply exchanges between client and server • Marshalling • Request and replies are marshalled into messages as ASCII text string • Resources are represented as byte sequences and may be compressed • HTTP Methods • GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE • HTTP Request and reply messages

HTTP version status code reason headers message body method URL or pathname HTTP version headers message body HTTP/1.1 200 OK resource data GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1 HTTP request / reply messages

The usage of Multicast • Fault tolerance based on replicated services • Client request are multicast to all the members of the group, each of which performs an identical operation • Finding the discovery servers in spontaneous networking • Multicast message can be used by servers and clients to locate available discovery services to register their interfaces or to look up the interfaces of other services • Better performance through replicated data • Data are replicated to increase the performance of a service, e.g., Web Cache. Each time the data changes, the new value is multicast to the processes managing the replicas • Propagation of event notification • Multicast to a group may be used to notify processes when something happens, e.g., the Jini system uses multicast to inform interested clients when new lookup services advertise their existence

IP Multicast – an implementation of group communication • A multicast group is specified by a class D Internet address • Built on top of IP • Available only via UDP • The membership of a group is dynamic • It is possible to send datagram to a multicast group without being a member • IPv4 • Multicast routers • use the broadcast capability of the local network • MTTL - specify the number of routers a multicast message is allowed to pass • Multicast address allocation • Permanent group – 224.0.0.1 to 224.0.0.255 • Temporary group – the other addresses, set TTL to a small value • Failure model: due to UDP, so it is a unreliable multicast • Java API to IP multicast

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. "228.5.6.7") 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

Multicast peers example… 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();} } }

Reliability and ordering of multicast • Failures • Router failure prevent all recipients beyond it receiving the message • Members of a group receive the same array of messages in different orders • Some examples of the effects of reliability and ordering • Fault tolerance based on replicated services • if one of them misses a request, it will become inconsistent with the others • Finding the discovery servers in spontaneous networking • an occasional lost request is not an issue when locating a discovery server • Reliable multicast or unreliable multicast? • According to application’s requirement

UNIX socket • Datagram communication • Datagram Socket • Bind • Sendto • recvfrom • Stream communication • stream socket , bind • Accept • Connect • Write and read

Sending a message Receiving a message s = socket(AF_INET, SOCK_DGRAM, 0) s = socket(AF_INET, SOCK_DGRAM, 0) bind(s, ClientAddress) bind(s, ServerAddress) sendto(s, "message", ServerAddress) amount = recvfrom(s, buffer, from) ServerAddress and ClientAddress are socket addresses Sockets used for datagrams

Requesting a connection Listening and accepting a connection s = socket(AF_INET, SOCK_STREAM,0) s = socket(AF_INET, SOCK_STREAM,0) bind(s, ServerAddress); listen(s,5); connect(s, ServerAddress) sNew = accept(s, ClientAddress); write(s, "message", length) n = read(sNew, buffer, amount) ServerAddress and ClientAddress are socket addresses Sockets used for streams

Summary • Two alternative building blocks • Datagram Socket: based on UDP, efficient but suffer from failures • Stream Socket: based on TCP, reliable but expensive • Marshalling • CORBA’s CDR and Java serialization • Request-Reply protocol • Base on UDP or TCP • Multicast • IP multicast is a simple multicast protocol

Introduction The API for the Internet protocols External data representation and marshalling