1 / 177

Distributed Systems: Coordination models and languages

Distributed Systems: Coordination models and languages. 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

ranaer
Télécharger la présentation

Distributed Systems: Coordination models and languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related