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 Middleware layers

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 API for Internet Protocols (1): IPC characteristics zsynchronous and asynchronous communication yblocking send: waits until the corresponding receive is issued ynon-blocking send: sends and moves on yblocking receive: waits until the msg is received ynon-blocking receive: if the msg is not here, moves on ysynchronous: blocking send and receive yasynchronous: non-blocking send and blocking or non-blocking receive zMessage Destination yIP address + port: one receiver, many senders yLocation transparency xname server or binder: translate service to location xOS (e.g. Mach): provides location-independent identifier mapping to lower-lever addresses ysend directly to processes (e.g. V System) ymulticast to a group of processes (e.g. Chorus) zReliability zOrdering

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 API for the Internet Protocols (2): Sockets and ports zprogramming abstraction for UDP/TCP zoriginated from BSD UNIX 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 API for Internet Protocols (3): UDP Datagram zmessage size: up to 2 16, usually restrict to 8K zblocking: non-blocking send, blocking receive ztimeouts: timeout on blocking receive zreceive from any: doesn't specify sender origin (possible to specify a remote host for send and receive) zfailure model: yomission failures: can be dropped yordering: can be out of order zuse of UDP yDNS yless overhead: no state information, extra messages, latency due to start up

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 API for Internet Protocols (4): C and UDP 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 API for Internet Protocols (5): Java and UDP aSocket = new DatagramSocket(); … InetAddress aHost = InetAddress.getByName(…); … DatagramPacket request = new DatagramPacket(msg, length, aHost, serverPort); … aSocket.send(request); … DatagramPacket reply = new DatagramPacket(buffer, length); … aSocket.receive(reply); aSocket = new DatagramSocket(port); … DatagramPacket request = new DatagramPacket(buffer, length); … aSocket.receive(request); … DatagramPacket reply = new DatagramPacket(data, length, request.getAddress(), request.getPort()); … aSocket.send(reply);

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 API for Internet Protocols (6): TCP stream zmessage size: unlimited zlost messages: sequence #, ack, retransmit after timeout of no ack zflow control: sender can be slowed down or blocked by the receiver zmessage duplication and ordering: sequence # zmessage destination: establish a connection, one sender-one receiver, high overhead for short communication zmatching of data items: two processes need to agree on format and order (protocol) zblocking: non-blocking send, blocking receive (send might be blocked due to flow control) zconcurrency: one receiver, multiple senders, one thread for each connection zfailure model ychecksum to detect and reject corrupt packets ysequence # to deal with lost and out-of-order packets yconnection broken if ack not received when timeout xcould be traffic, could be lost ack, could be failed process.. xcan't tell if previous messages were received zuse of TCP: http, ftp, telnet, smtp

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

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 API for Internet Protocols (8): Java and TCP Socket s = new Socket(host, serverPort); … DataInputStream in = new DataInputStream(s.getInputStream()); DataOutputStream out = new DataOutputStream(s.getOutputStream()); … out.write(…); … in.read(…); ServerSocket listenSocket = new ServerSocket(serverPort); … Socket s = listenSocket.accept(); … DataInputStream in = new DataInputStream(s.getInputStream()); DataOutputStream out = new DataOutputStream(s.getOutputStream()); … in.read(…); … out.write(…);

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (1): zdifferent ways to represent int, float, char... (internally) zbyte ordering for integers ybig-endian: most significant byte first ysmall-endian: least significant byte first zstandard external data representation ymarshal before sending, unmarshal before receiving zsend in sender's format and indicates what format, receivers translate if necessary zExternal data representation ySUN's External data representation (XDR) yCORBA's Common Data Representation (CDR) yJava's object serialization yASCII (XML, HTTP)

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (2): CDR zPrimitive types (15): short, long... ysupport both big-endian and little-endian ytransmitted in sender's ordering and the ordering is specified yreceiver translates if needed zConstructed types

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (3): zCORBA IDL compiler generates marshalling and unmarshalling routines zStruct with string, string, unsigned long 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 External Data Representation (5): Java serialization zserialization and de-serialization are automatic in arguments and return values of Remote Method Interface (RMI) zflattened to be transmitted or stored on the disk ywrite class information, types and names of instance variables ynew classes, recursively write class information, types, names... yeach class has a handle, for subsequent references yvalues are in Universal Transfer Format (UTF)

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (6): Java 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; } The true serialized form contains additional type markers; h0 and h1 are handles/references to other objects within the serialized form 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 External Data Representation (7) zreferences to other objects yother objects are serialized yhandles are references to objects in serialized form yeach object is written only once ysecond or subsequent occurrence of the object is written as a handle z reflection yask the properties (name, types, methods) of a class yhelp serialization and de-serialization

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (8): XML zExtensible markup language (XML) yUser-defined tags (vs. HTML has a fixed set of tags) ydifferent applications agree on a different set of tags yE.g. SOAP for web services, tags are published yTags are in plain text (not binary format)—not space efficient

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (9) zPerson struct in XML  Tag names : person, name, place, year  Element: Smith  Attribute: id=" ” of person yBinary data need to be converted to characters (base64) Smith London 1934

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (10): XML namespace zName clashes within an application zNamespaces: a set of names for a collection of element types and attributes  xmlns : xml namespace  pers : name of the name space (used as a prefix)  : location of schema Smith London 1934

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (11): XML schema zDefines elements and attributes zSimilar to type definition zxsd: namespace for xml schema definition

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 External Data Representation (12): Remote object reference zcall methods on a remote object (CORBA, Java) yunique reference in the distributed system yReference = IP address + port + process creation time + local object # in a process + interface yPort + process creation time -> unique process yAddress can be derived from the reference yObjects usually don't move; is there a problem if the remote object moves? y name of interface: what interface is available Internet addressport numbertimeobject number interface of remote object 32 bits

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Client-server communication (1) zSynchronous: client waits for a reply zAsynchronous: client doesn’t wait for a reply 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 Client-server communication (2): Request-reply message structure messageType requestId objectReference methodId arguments int (0=Request, 1= Reply) int RemoteObjectRef int or Method array of bytes Why requestID?

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Client-server communication (3) zFailure model yUDP: could be out of order, lost... yprocess can fail... znot getting a reply ytimeout and retry zduplicate request messages on the server yHow does the server find out? zidempotent operation: can be performed repeatedly with the same effect as performing once. yidempotent examples? ynon-idempotent examples? zhistory of replies yretransmission without re-execution yhow far back if we assume the client only makes one request at a time?

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Client-server communication (4): 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 Client-server communication (5) zusing TCP increase reliability and also cost zHTTP uses TCP yone connection per request-reply yHTTP 1.1 uses "persistent connection" xmultiple request-reply xclosed by the server or client at any time xclosed by the server after timeout on idle time yMarshal messages into ASCII text strings yresources are tagged with MIME (Multipurpose Internet Mail Extensions) types: test/plain, image/gif... ycontent-encoding specifies compression alg

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Client-server communication (6): HTTP methods zGET: return the file, results of a cgi program, … zHEAD: same as GET, but no data returned, modification time, size are returned zPOST: transmit data from client to the program at url zPUT: store (replace) data at url zDELETE: delete resource at url zOPTIONS: server provides a list of valid methods zTRACE: server sends back the request

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Client-server communication (6): HTTP request/reply format zHeaders: e.g. latest modification time, acceptable content type, authorization credentials, … zHeaders: e.g. authentication challenge for the client, new URL (redirection), … GET// 1.1 URL or pathnamemethodHTTP versionheadersmessage body 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 (1) zmulticast zuseful for: yfault tolerance based on replicated services xrequests multicast to servers, some may fail, the client will be served ydiscovering services xmulticast to find out who has the services ybetter performance through replicated data xmulticast updates yevent notification xnew items arrived, advertising services

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Group communication (2): IP multicast zclass D addresses, first four bits are 1110 in IPv4 zUDP zJoin a group via socket binding to the multicast address zmessages arriving on a host deliver them to all local sockets in the group (note LAN is broadcast) zmulticast routers: route messages to out-going links that have members zmulticast address allocation ypermanent ytemporary: xno central registry by IP (one addr might have different groups) use (time to live) TTL to limit the # of hops, hence distance xtools like sd (session directory--registry) can help manage multicast addresses and find new ones

Instructor ’ s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Group communication (3): Reliability and ordering zUDP-level reliability: missing, out-of-order... zEffects on yfault tolerance based on replicated services xordering of the requests might be important, servers can be inconsistent with one another ydiscovering services xnot too problematic y better performance through replicated data xloss and out-of-order updates could yield inconsistent data, sometimes this may be tolerable yevent notification xnot too problematic