Interprocess Communication

Size: px

Start display at page:

Download "Interprocess Communication"

Robert Newton
6 years ago
Views:

1 Distributed Systems rely on exchanging data and achieving synchronization amongst autonomous distributed processes 8 Inter process communication (IPC) shared variables message passing 8 message passing in concurrent programming languages language extensions API calls Principles of IPC (see also [Andrews and Schneider 83] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March 1983) 8 Concurrent programs: collections of two or more sequential programs executing concurrently 8 Concurrent processes: collection of two or more sequential programs in operation, executing concurrently Distributed Systems - Fall 2001 II - 92 Stefan Leue 2001

2 Synchronization 8 concurrent processes on different computers execute at different speeds 8 need for one process to influence computation in another process specify constraints on the ordering of events in concurrent processes message passing isend message happens before receive message Message Passing Primitives 8 send expression_list to destination_designator evaluates expression_list adds a new message instance to channel destination_designator 8 receive variable_list from source_designator assignes received values to variables in variable_list destroys received message Central questions 8 how are destination designators specified? 8 how is communication synchronized? Distributed Systems - Fall 2001 II - 93 Stefan Leue 2001

3 Destination Designation 8 direct naming: source and destination process names serve as designators (a pair of source and destination designators defines a channel) send cur_status to monitor or monitor!cur_status receive message from handler or handler?message easy to implement and use allows a process easy control when to receive which message from which other process use to implement client/server applications iwell suited to implement client/server paradigm if there is one client and one server iotherwise: server should be capable of accepting invocations from any client at any time, and a client should be allowed to invoke many services at a time if more than one server available Distributed Systems - Fall 2001 II - 94 Stefan Leue 2001

4 Destination Designation 8 global names or mailboxes: process name-independent destination designator shared by many processes messages sent to a mailbox can be received by any process that executes a receive referring to that mailbox name to implement Client/Server applications iclients send requests to mailbox, an available server picks them up drawback: costly implementation imessage sent to mailbox irelayed to all other sites that could potentially receive from that mailbox iif one site decides to receive, inform all other sites that message is no longer available for receipt imutual exclusion for concurrent access 8 ports: mailbox, but only one process is permitted to receive from that mailbox easy to implement: receives can occur in only one process, no distribution and coordination necessary suitable for multiple clients / single server applications 8 Message destinations in Internet programming hybrid direct naming/port scheme (Internet_address, port_number) port corresponds to many sender/one receiver concept Distributed Systems - Fall 2001 II - 95 Stefan Leue 2001

5 Channel Naming 8 static (at compile time) impossible for a program to communicate along a channel not known at compile time inflexibility: if a process might ever need to communicate with a receipient, that channel must be available throughout the entire runtime of the sending programme 8 dynamic (at runtime) administrative overhead at runtime more flexible allocation of communication resources Distributed Systems - Fall 2001 II - 96 Stefan Leue 2001

6 Semantics of message passing primitives 8 Blocking non-blocking: the execution will never delay the invoking process blocking: otherwise 8 Synchronization asynchronous message passing: message passing using buffers with unbounded capacity isender may race ahead an unbounded number of steps isender never blocks ireceiver blocks on empty queue synchronous message passing: no buffering between sender and receiver isender blocks until receiver ready to receive ireceiver blocks until sender ready to send buffered message passing: buffers with bounded, finite capacity isender may race ahead a finite, bounded number of steps isender blocks on full buffer ireceiver blocks on empty buffer Distributed Systems - Fall 2001 II - 97 Stefan Leue 2001

7 Non-blocking primitives for asynchronous or buffered message passing 8 receive background variant: process continues, receives interrupt upon arrival ioverhead for implementation ignoring variant: programm polls for availability 8 send sending process waits for empty buffer or drops message to be sent Distributed Systems - Fall 2001 II - 98 Stefan Leue 2001

OSI-BRM L7 Application L6 Presentation L5 Session L4 Transport L3 Network L2 Data Link Control L1 Physical Internet smtp ftp telnet http TCP IP LAN (M)WAN proprietary netwoks Pearson Education 2001

8 OSI-BRM L7 Application L6 Presentation L5 Session L4 Transport L3 Network L2 Data Link Control L1 Physical Internet smtp ftp telnet http TCP IP LAN (M)WAN proprietary netwoks Pearson Education 2001 Distributed Applications 8 availability of a set of pre-implemented application services, like , ftp, http, etc. 8 what if you want to build your own, customized Internet application? 8 access to Transport Layer services Services provided by Internet Transport Layer 8 UDP: message passing (datagram) 8 TCP: data stream Distributed Systems - Fall 2001 II - 99 Stefan Leue 2001

Pearson Education 2001 Sockets 8 Internet IPC mechanism of Unix and other operating systems (BSD Unix, Solaris, Linux, Windows NT, Macintosh OS) 8 processes in these OS can send and receive messages

9 Pearson Education 2001 Sockets 8 Internet IPC mechanism of Unix and other operating systems (BSD Unix, Solaris, Linux, Windows NT, Macintosh OS) 8 processes in these OS can send and receive messages via a socket 8 sockets are duplex 8 sockets need to be bound to a port number and an internet address in order to be useable for sending and receiving messages 8 each socket has a transport protocol attribute (TCP or UDP) 8 messages sent to some internet address and port number can only be received by a process using a socket that is bound to this address and port number 8 UDP socket can be connected to a remote IP address and port number 8 processes cannot share ports (exception: TCP multicast) Distributed Systems - Fall 2001 II Stefan Leue 2001

10 IPC based on UDP datagrams 8 UDP datagram properties: no guarantee of order preservation, message loss and duplications are possible 8 necessary steps create socket bind socket to a port and local Internet address iclient: arbitrary free port iserver: server port 8 receive method: returns Internet address and port of sender, plus message 8 message size: IP allows for messages of up to 2 16 bytes most implementations restrict this to around 8 kbytes larger application messages: application s responsibility to perform fragmentation/reassembling if arriving message is too big for array allocated to receive message content, truncation occurs 8 send: non-blocking blocks only until message given to UDP/IP upon arrival placed in per-port queue 8 receive: blocking pre-emption by timeout possible if process wishes to continue while waiting for packet, use separate thread Distributed Systems - Fall 2001 II Stefan Leue 2001

11 Java API for UDP datagrams 8 Classes DatagramPacket constructor generating message for sending from array of bytes imessage content (byte array) ilength of message iinternet address and port number (destination) similar constructor for receiving a message DatagramSocket class for sending and receiving of UDP datagrams ione constructor with port number as argument, another without ino-argument constructor to use free local port imethods * send and receive * setsotimeout * connect for connecting a socket to a particular remote Internet address and port Distributed Systems - Fall 2001 II Stefan Leue 2001

12 Java API for UDP datagrams 8 Example process creates socket, sends message to server at port 6789, and waits to receive reply import java.net.*; import java.io.*; public class UDPClient{ public static void main(string args[]){ // args give message contents and destination hostname try { DatagramSocket asocket = new DatagramSocket(); // create socket byte [] m = args[0].getbytes(); InetAddress ahost = InetAddress.getByName(args[1]); // DNS lookup int serverport = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), ahost, serverport); asocket.send(request); //send nessage byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); asocket.receive(reply); //wait for reply System.out.println("Reply: " + new String(reply.getData())); asocket.close(); }catch (SocketException e){system.out.println("socket: " + e.getmessage()); }catch (IOException e){system.out.println("io: " + e.getmessage());} } // can be caused by send } Distributed Systems - Fall 2001 II Stefan Leue 2001

13 IPC based on TCP streams 8 abstract service: stream of bytes to be written to or received from 8 features message size: no constraint, TCP decides when to send a transport layer message consisting of multiple application messages, immediate transmission can be forced connection oriented retransmission to recover from message lost (timeout-bounded) queue at destination socket blocked on receive flow control to block sender when overflow might occur need to agree on data sent and received server generates new thread for new connection API for streams 8 connection establishment using client/server approach, afterwards peer communication client: issue connect requests server: has listening port to receive connect request messages accept of a connection: create new stream socket for new connection Distributed Systems - Fall 2001 II Stefan Leue 2001

14 Java API for TCP streams 8 Classes ServerSocket class: create socket at server side to listen for connect requests Socket class: for processes with connections iconstructor to create a socket and connect it to remote host and port of a server imethods for accessing input and output stream Distributed Systems - Fall 2001 II Stefan Leue 2001

15 Example 8 TCP-based server for stream communication import java.net.*; import java.io.*; public class TCPServer { public static void main (String args[]) { try{ int serverport = 7896; // the server port ServerSocket listensocket = new ServerSocket(serverPort); // new server port generated while(true) { Socket clientsocket = listensocket.accept(); // listen for new connection Connection c = new Connection(clientSocket); // launch new thread } } catch(ioexception e) {System.out.println("Listen socket:"+e.getmessage());} } } Distributed Systems - Fall 2001 II Stefan Leue 2001

16 Example 8 TCP-based server for stream communication 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(); // read a line of data from the stream out.writeutf(data); // write a line to the stream clientsocket.close(); } catch (EOFException e){system.out.println("eof:"+e.getmessage()); } catch (IOException e) {System.out.println("readline:"+e.getMessage());} } } Distributed Systems - Fall 2001 II Stefan Leue 2001

17 Data Representation 8 data representation problem use agreed external representation, two conversions necessary use sender s or receiver s format and convert at the other end 8 transmission of structured data types data types may not change during transmission usage of a commonly understood flattened transfer format (structured types are reduced to their primitive components) 8 data representation formats SUN Microsystems XDR CORBA CDR ASN.1 (OSI layer 6) 8 marshalling/unmarshalling marshalling: assembling a collection of data items in a form suitable for transmission unmarshalling: disassembling and recovery of original data items usually performed automatically by middleware layer ihand-programming error-prone iuse of compilers for programs working directly at transport API Distributed Systems - Fall 2001 II Stefan Leue 2001

18 CORBA Common Data Represenation (CDR) 8 CORBA: Common Object Request Broker Architecture middleware architecture standardized by the Object Management Group see 8 CORBA CDR supports types allowed in CORBA remote object invocations primitive types ilittle/big endian according to sender s representation format iprimitive values start at indexed byte positions (multiples of 1, 2, 4 or 8) ifloating point according to IEEE standard icharacters using an agreed character set Distributed Systems - Fall 2001 II Stefan Leue 2001

19 CORBA Common Data Represenation (CDR) 8 CORBA CDR structured types idefinitions iexample: struct with value { Smith, London, 1934} Pearson Education 2001 Pearson Education 2001 Distributed Systems - Fall 2001 II Stefan Leue 2001

20 CORBA Common Data Represenation (CDR) 8 CORBA marshalling/unmarshalling CORBA Interface Definition Language (IDL) IDL compilers will generate marshalling and unmarshalling operations ( stubs ) that transforms data objects into CDR format Distributed Systems - Fall 2001 II Stefan Leue 2001

21 Java Object Serialization 8 example: class Person Interprocess Communication 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;}... } 8 serialization: flattening an object into a linear form such that it can be stored in a file or transmitted in a message linear format must be such that deserialization routine is capable of recovering the complete object structure and state iinclusion of * handles (references to other objects) * name of class that an object belongs to * version number of class note: mark objects as non-serializable ( transient ) if they are not supposed to be serialized (e.g., socket references, files, etc.) Distributed Systems - Fall 2001 II Stefan Leue 2001

22 Java Object Serialization 8 example: class Person Interprocess Communication 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;}... } 8 serialization example: Person p = new Person( Smith, London, 1934) iserialization: create instance of class ObjectOutputStream and invoke writeobject method, passing object to be serialized as argument ideserialization: open ObjectInputStream on the serialized structure and use readobject method Pearson Education 2001 Distributed Systems - Fall 2001 II Stefan Leue 2001

23 Remote Object References 8 needed when a client invokes an object that is located on a remote server 8 reference needed that is unique over space and time space: where is the object located time: correct version of an undeleted object 8 a generic format proposal Pearson Education 2001 internet address/port number: process which created object time: creation time object number: local counter, incremented each time an object is created in the creating process interface: how to access the remote object (if object reference is passed from one client to another) 8 extension object references that are location transparent Distributed Systems - Fall 2001 II Stefan Leue 2001

Client-Server Communication 8 often built over UDP datagrams client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary avoidance of

24 Client-Server Communication 8 often built over UDP datagrams client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary avoidance of connection establishment overhead no need for flow control due to small amounts of data tranfered 8 generic protocol example (for RPC or RMI communication) Pearson Education 2001 Distributed Systems - Fall 2001 II Stefan Leue 2001

25 Client-Server Communication 8 format of protocol messages message type (request/reply) request ID isending process identifier (e.g., IP address/port number) iinteger sequence number incremented by sender with every request object reference method ID and arguments 8 if implemented over UDP: failure recovery omission failures iuse timeout and resend request when timeout expires and reply hasn t arrived iserver receives repeated request * indempotent operations: same result obtained on every invokation * non-indempotent operations: re-send result stored from previous request, requires maintenance of a history of replies iloss of replies: request - reply - ack reply protocol message duplication: return request ID with reply Distributed Systems - Fall 2001 II Stefan Leue 2001

26 Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) lightweight request - reply protocol for the exchange of network resources between web clients and web servers protocol steps iconnection establishment between client and server (likely TCP, but any reliable transport protocol is acceptable) iclient sends request iserver sends reply iconnection closure inefficient scheme, therefore HTTP 1.1 allows persistent transport connections (remains open for successive request/reply pairs) Resources can have mime-type data types, e.g. itext/plain itext/html iimage/jpeg data is marshalled into ASCII transfer syntax Distributed Systems - Fall 2001 II Stefan Leue 2001

27 Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) request Pearson Education 2001 iget: request of resource, identified by URL, may refer to * data: server returns data * program: server runs program and returns output data ihead: request similar like GET, but only meta data on resource is returned (like date of last modification) ipost: specifies resource (for instance, a server program) that can deal with the client data provided with previous request iput: supplied data to be stored in given URL idelete: delete an identified resource on server Distributed Systems - Fall 2001 II Stefan Leue 2001

28 Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) reply Pearson Education 2001 Distributed Systems - Fall 2001 II Stefan Leue 2001

Transport layer protocols. Lecture 15: Operating Systems and Networks Behzad Bordbar

Transport layer protocols. Lecture 15: Operating Systems and Networks Behzad Bordbar Transport layer protocols Lecture 15: Operating Systems and Networks Behzad Bordbar 78 Interprocess communication Synchronous and asynchronous comm. Message destination Reliability Ordering Client Server