Distributed Systems: Coordination models and languages

1. Distributed Systems: Coordination models and languages Distributed systems: coordination models and languages

2. Overview of chapters • Introduction • Coordination models and languages • Ch 4: Interprocess communication • Ch 5: Distributed objects and remote invocation • Ch 20: Corba Case study • General services • Distributed algorithms • Shared data • Building distributed services Distributed systems: coordination models and languages

3. Data transfer Synchronization Introduction • Communication • data representation • Synchronization • how express cooperation? Distributed systems: coordination models and languages

4. This chapter: overview • Data representation • Message passing • Remote procedure calls • Object request brokers • Generative communication • Event Systems Distributed systems: coordination models and languages

5. This chapter: overview Applications, services RMI and RPC Middleware request-reply protocol layers marshalling and external data representation UDP and TCP Distributed systems: coordination models and languages

6. int int System A System B int = 2-complement, 32 bits int = 1-complement, 40 bits Data representation • Problem on the wire: int = ?? Distributed systems: coordination models and languages

7. Data representation (cont.) • Problem: • program data: typed, structured, object • message data: bit/byte stream • different representations of data in heterogeneous systems • mapping to data items in messages: • flattened before transmission • rebuilt on arrival Distributed systems: coordination models and languages

8. Data representation (cont.) • Conversion: different approaches • agreed form for transmission • e.g. int = 2-complement, 32 bits • both partners have full knowledge of transmitted data • e.g.: Sun XDR, Corba CDR • full data description transmitted • type, length, value coding on the wire • interpretation at receiving site possible • e.g. ASN + BER, Java serialized form • Conversion to ASCII text • XML Distributed systems: coordination models and languages

9. 5 Length of string ‘Smith’ Length of string ‘London’ Cardinal “Smit” “h___” 6 “Lond” “on__” 1934 4 bytes Data representation (cont.) • Sun XDR • Fixed representation of primitive & constructed types • Message: ‘Smith’, ‘London’, 1934 Distributed systems: coordination models and languages

10. 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 Data representation (cont.) • CORBA CDR • Fixed representation of primitive & constructed types • int: little- or big-endian: representation of sender • Value of size n is placed at relative position that is a multiple of n Distributed systems: coordination models and languages

11. Data representation (cont.) Struct Person{ string name; string place; unsigned long year; }; • CORBA CDR 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} Distributed systems: coordination models and languages

12. Data representation (cont.) • ASN.1: abstract syntax notation • application syntax • type identifiers ( 4 classes) • standard types • constructors: sequence, sequenceof, set, setof • encoding: TLV • Type: defines ASN.1 type • Length • Value Distributed systems: coordination models and languages

13. Data representation (cont.) • Java: supports transfer of objects and primitive data values Public class Person implements Serializable{ private String name; private String place; private int year; public Person(String aName, String aPlace, int aYear){ … } … } Distributed systems: coordination models and languages

14. 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 Data representation (cont.) • Java serialized form • Handles: references to objects • Primitive types: portable binary format Person p = new Person(“Smith”, “London”, 1934); The true serialized form contains additional type markers; h0 and h1 are handles Distributed systems: coordination models and languages

15. Data representation (cont.) • XML • Markup language defined by World Wide Web consortium • Data items tagged with ‘markup’ strings • Users can define their own tags <person id=‘123456789”> <name>Smith</name> <place>London</place> <year>1934</year> <…> </person> Distributed systems: coordination models and languages

16. Data representation (cont.) • Definitions: • marshalling = assembling a collection of data items into a form suitable for transmission • unmarshalling = disassembling a message on arrival to produce the equivalent collection of data items • operations can be generated from specification Distributed systems: coordination models and languages

17. This chapter: overview • Data representation • Message passing • Remote procedure calls • Object request brokers • Generative communication • Event Systems Distributed systems: coordination models and languages

18. Message passing • Basic functionality • Procedure Send (p: PortId; m: Message); • Procedure Receive (p: PortId; VAR m: Message); Distributed systems: coordination models and languages

19. Message passing (cont.) • Semantics:synchronous <> asynchronous communication • synchronous = blocking • send: wait for corresponding receive • receive: wait for message arrival • asynchronous = no waiting for completion • send: no wait for message arrival • receive: announce willingness to accept or check for message arrival Distributed systems: coordination models and languages

20. Message passing (cont.) • Semantics:synchronous <> asynchronous Distributed systems: coordination models and languages

21. Message passing (cont.) • Semantics:synchronous <> asynchronous Example: Occam style Sender: ….. Send(p, m); {message is accepted!!!} ….. Receiver: …. Receive(p, b); {sender after send } …. Communication  Synchronisation point b := m Distributed systems: coordination models and languages

22. m  b ? Message passing (cont.) • Semantics:synchronous <> asynchronous Send (p, m) Receive(p, b)  Distributed systems: coordination models and languages

23. Sender: ….. send(….); {message is in buffer!!! arrival??} Receiver: …. receive(….); {message available } …. Message passing (cont.) • Semantics:synchronous <> asynchronous Example: Mach style Communication  NOsynchronisation point Distributed systems: coordination models and languages

24. Port p Message passing (cont.) • Semantics:synchronous <> asynchronous Send (p, m) Distributed systems: coordination models and languages

25. Port p Message passing (cont.) • Semantics:synchronous <> asynchronous Send(p, m) receive(p,b) Distributed systems: coordination models and languages

26. Message passing (cont.) • Semantics:message destinations • message destination = communication identifier • preference for location independent identifiers • types of message destination: • process • port • mailbox Distributed systems: coordination models and languages

27. Send (p, m) Message passing (cont.) • Semantics:message destinationsprocess Process p Distributed systems: coordination models and languages

28. Message passing (cont.) • Semantics:message destinationsport port q Send (p, m) port p Distributed systems: coordination models and languages

29. Message passing (cont.) • Semantics:message destinationsmailbox mailbox q Send (p, m) mailbox p Distributed systems: coordination models and languages

30. Message passing (cont.) • Semantics:message destinations • types of message destination: • process: • single entry point per process for all messages • port • one receiver, many senders • may have a message queue • many ports per process • mailbox • may have many receivers • message queue Distributed systems: coordination models and languages

31. Message passing (cont.) • Semantics:reliability • possible failures • Corrupted messages • Duplicate messages • Omission: loss of messages • Messages out of order • Receiver process failure • Reliable communication • Delivered uncorrupted, in order, without duplicates • Despite a reasonable number of packets dropped or lost • Perfectly reliable communication can not often be guaranteed Communication failure Distributed systems: coordination models and languages

32. Message passing (cont.) • How to implement reliable communication: • Avoiding corruption • Include checksum in message • Avoids order mistakes and duplicates • Include a message number which identifies the message • Avoiding omission • Sender stores message in buffer, sends it and sets a time-out • Receiver replies with acknowledgement • Sender retransmits messages after timeout Distributed systems: coordination models and languages

33. Message passing (cont.) • Semantics:reliability • sender of message gets no reply?no distinction between • process failure • communication failure Distributed systems: coordination models and languages

34. agreed port any port socket socket message client server other ports Internet address = 138.37.94.248 Internet address = 138.37.88.249 Message passing (cont.) • Case study: UDP/TCP • Sockets <> ports • Socket bound to (TCP) port + Internet address Distributed systems: coordination models and languages

35. Message passing (cont.) • Case study UDP • Messages: • Restricted packet size: < 216 , < 213 (8Kbytes), truncation • No conversion: bit transmission • Blocking: • Non-blocking send • Blocking receive • Timeouts: user can set timeout on receive operation • Receive from any: receive returns port + Internet address • But sockets can be bound to remote (IP address+port) • Unreliable message service • lost, out of order, duplicates • no message corruption: checksum Distributed systems: coordination models and languages

36. Message passing (cont.) • Case study UDP: Java API • Class InetAddress • getByName(string) (underlying name server!) • Class DatagramPacket • (bufferlength, buffer, InetAddress, PortID) • Class DatagramSocket • Send(DatagramPacket) • Receive(DatagramPacket) • Close() Distributed systems: coordination models and languages

37. Message passing (cont.) • Case study UDP: example in Java • UDP client sends a message to the server and gets a reply (Figure 4.3) • UDP server repeatedly receives a request and sends it back to the client (Figure 4.4) Distributed systems: coordination models and languages

38. 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();} } } Distributed systems: coordination models and languages

39. 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();} } } Distributed systems: coordination models and languages

40. Message passing (cont.) • Case study TCP • Stream communication: (<> message passing?) • Connect: create a communication channel through communicating sockets • Communication: read and write through channel • Close • Implementation: • TCP handles all communication • Uses buffers at sender and receiver side • No conversion: bit transmission • Synchronization semantics: • Non-blocking send, except for flow control (when buffers of sender or receiver are full) • Blocking receive Distributed systems: coordination models and languages

41. Message passing (cont.) • Case study TCP • Setting up a client server connection: • Client sends request for communication to Server port • Server accepts client request • Typically, server creates new thread which handles communication with client • Reliable message service • Except broken connections • Overhead compared to UDP: • Buffering • Creating a connection: 2(?) extra messages • Sending a message, returning an acknowledgement • May create unacceptable overhead if goal is to send a single message. Distributed systems: coordination models and languages

42. Message passing (cont.) • Case study TCP: Java API • Class ServerSocket • Socket Accept() • Class Socket • getInputStream() • getOutputStream() • Class DataInputStream • readUTF, … (Universal Transfer Format) • Class DataOutputStream • writeUTF, … Distributed systems: coordination models and languages

43. Message passing (cont.) • Case study TCP: example • TCP client makes connection to server, sends request and receives reply (Figure 4.5) • TCP server makes a connection for each client and then echoes the client’s request (Figure 4.6) Distributed systems: coordination models and languages

44. 4.5 TCP client makes connection, 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());}} } } Distributed systems: coordination models and languages

45. 4.6 TCP server makes a connection for each client and then echoes the request of the client 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 Distributed systems: coordination models and languages

46. 4.6 TCP server … 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*/}} } } Distributed systems: coordination models and languages

47. Message passing (cont.) • Conclusion: UDP, TCP • general purpose communication protocols • primitive, low level operations: • Setting up a communication • No transfer of structured data • Difficult to use • efficient implementation • building blocks used for more complex interactions Distributed systems: coordination models and languages

48. Message passing (cont.) • Conclusion: message passing • primitive, low level operations • difficult, hard to use • efficient implementation • building blocks used for more complex interactions • From message passing • to Client-server • to RPC, RMI Distributed systems: coordination models and languages

49. Client Server Request doOperation getRequest message select object execute (wait) method Reply sendReply message (continuation) Message passing (cont.) • Client-server communication Distributed systems: coordination models and languages

50. Message passing (cont.) • Client-server messages/operations • Designed to support roles and message exchanges in typical client-server interactions • Acks redundant (replies are used) • Connections not necessary • No flow control • Basic operations: • Client: doOperation: sends request and returns answer to application program • Server: getRequest, sendReply Distributed systems: coordination models and languages