Interprocess Communication -...
Transcript of Interprocess Communication -...
teleDistributed Systems - Fall 2001 II - 92 © Stefan Leue 2001
Interprocess Communication
♦ Distributed Systems rely on exchanging data and achieving synchronization amongst autonomous distributed processes� Inter process communication (IPC)
– shared variables– message passing
� 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)
� Concurrent programs: collections of two or more sequential programs executing concurrently
� Concurrent processes: collection of two or more sequential programs in operation, executing concurrently
teleDistributed Systems - Fall 2001 II - 93 © Stefan Leue 2001
Interprocess Communication♦ Synchronization
� concurrent processes on different computers execute at different speeds� need for one process to influence computation in another process
– specify constraints on the ordering of events in concurrent processes– message passing
�send message happens before receive message♦ Message Passing Primitives
� send expression_list to destination_designator– evaluates expression_list– adds a new message instance to channel destination_designator
� receive variable_list from source_designator– assignes received values to variables in variable_list– destroys received message
♦ Central questions� how are destination designators specified?� how is communication synchronized?
teleDistributed Systems - Fall 2001 II - 94 © Stefan Leue 2001
Interprocess Communication
♦ Destination Designation� 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
�well suited to implement client/server paradigm if there is one client and one server
�otherwise: 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
teleDistributed Systems - Fall 2001 II - 95 © Stefan Leue 2001
Interprocess Communication♦ Destination Designation
� 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�clients send requests to mailbox, an available server picks them up
– drawback: costly implementation�message sent to mailbox�relayed to all other sites that could potentially receive from that
mailbox�if one site decides to receive, inform all other sites that message is
no longer available for receipt�mutual exclusion for concurrent access
� 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
� Message destinations in Internet programming– hybrid direct naming/port scheme
(Internet_address, port_number) – port corresponds to many sender/one receiver concept
teleDistributed Systems - Fall 2001 II - 96 © Stefan Leue 2001
Interprocess Communication
♦ Channel Naming� 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
� dynamic (at runtime)– administrative overhead at runtime– more flexible allocation of communication resources
teleDistributed Systems - Fall 2001 II - 97 © Stefan Leue 2001
Interprocess Communication
♦ Semantics of message passing primitives� Blocking
– non-blocking: the execution will never delay the invoking process – blocking: otherwise
� Synchronization– asynchronous message passing: message passing using buffers with
unbounded capacity�sender may race ahead an unbounded number of steps�sender never blocks�receiver blocks on empty queue
– synchronous message passing: no buffering between sender and receiver�sender blocks until receiver ready to receive�receiver blocks until sender ready to send
– buffered message passing: buffers with bounded, finite capacity�sender may race ahead a finite, bounded number of steps�sender blocks on full buffer�receiver blocks on empty buffer
teleDistributed Systems - Fall 2001 II - 98 © Stefan Leue 2001
Interprocess Communication
♦ Non-blocking primitives for asynchronous or buffered message passing� receive
– background variant: process continues, receives interrupt upon arrival�overhead for implementation
– ignoring variant: programm polls for availability� send
– sending process waits for empty buffer or drops message to be sent
teleDistributed Systems - Fall 2001 II - 99 © Stefan Leue 2001
Interprocess Communication
♦ Distributed Applications� availability of a set of pre-implemented application services, like email, ftp,
http, etc.� what if you want to build your own, customized Internet application?� access to Transport Layer services
♦ Services provided by Internet Transport Layer� UDP: message passing (datagram)� TCP: data stream
L7 Application
L6 Presentation
L5 Session
L4 Transport
L3 Network
L2 Data Link Control
L1 Physical
smtpftp
telnethttp
TCP
IPLAN
(M)WANproprietary netwoks
OSI-BRM Internet
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 100 © Stefan Leue 2001
Interprocess Communication
♦ Sockets� Internet IPC mechanism of Unix and other operating systems (BSD Unix,
Solaris, Linux, Windows NT, Macintosh OS)� processes in these OS can send and receive messages via a socket� sockets are duplex� sockets need to be bound to a port number and an internet address in order
to be useable for sending and receiving messages� each socket has a transport protocol attribute (TCP or UDP)� 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
� UDP socket can be connected to a remote IP address and port number� processes cannot share ports (exception: TCP multicast)
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 101 © Stefan Leue 2001
Interprocess Communication♦ IPC based on UDP datagrams
� UDP datagram properties: no guarantee of order preservation, message loss and duplications are possible
� necessary steps– create socket– bind socket to a port and local Internet address
�client: arbitrary free port�server: server port
� receive method: returns Internet address and port of sender, plus message� message size: IP allows for messages of up to 216 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� send: non-blocking
– blocks only until message given to UDP/IP– upon arrival placed in per-port queue
� receive: blocking– pre-emption by timeout possible– if process wishes to continue while waiting for packet, use separate
thread
teleDistributed Systems - Fall 2001 II - 102 © Stefan Leue 2001
Interprocess Communication
♦ Java API for UDP datagrams� Classes
– DatagramPacket constructor generating message for sending from array of bytes�message content (byte array)�length of message�Internet address and port number (destination)
– similar constructor for receiving a message– DatagramSocket class for sending and receiving of UDP datagrams
�one constructor with port number as argument, another without�no-argument constructor to use free local port�methods
* send and receive* setSoTimeout
* connect for connecting a socket to a particular remote Internet address and port
teleDistributed Systems - Fall 2001 II - 103 © Stefan Leue 2001
Interprocess Communication
♦ Java API for UDP datagrams� 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 hostnametry {
DatagramSocket aSocket = new DatagramSocket(); // create socketbyte [] m = args[0].getBytes();InetAddress aHost = InetAddress.getByName(args[1]); // DNS lookupint serverPort = 6789;DatagramPacket request =
new DatagramPacket(m, args[0].length(), aHost, serverPort);aSocket.send(request); //send nessagebyte[] buffer = new byte[1000];DatagramPacket reply = new DatagramPacket(buffer, buffer.length);aSocket.receive(reply); //wait for replySystem.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
}
teleDistributed Systems - Fall 2001 II - 104 © Stefan Leue 2001
Interprocess Communication
♦ IPC based on TCP streams� abstract service: stream of bytes to be written to or received from� 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� 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
teleDistributed Systems - Fall 2001 II - 105 © Stefan Leue 2001
Interprocess Communication
♦ Java API for TCP streams� Classes
– ServerSocket class: create socket at server side to listen for connect requests
– Socket class: for processes with connections�constructor to create a socket and connect it to remote host and port
of a server�methods for accessing input and output stream
teleDistributed Systems - Fall 2001 II - 106 © Stefan Leue 2001
Interprocess Communication
♦ Example� 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 portServerSocket listenSocket = new ServerSocket(serverPort);
// new server port generatedwhile(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());}}
}
teleDistributed Systems - Fall 2001 II - 107 © Stefan Leue 2001
Interprocess Communication
♦ Example� 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 serverString data = in.readUTF();
// read a line of data from the streamout.writeUTF(data);
// write a line to the streamclientSocket.close();
} catch (EOFException e){System.out.println("EOF:"+e.getMessage());} catch (IOException e) {System.out.println("readline:"+e.getMessage());}
}}
teleDistributed Systems - Fall 2001 II - 108 © Stefan Leue 2001
Interprocess Communication
♦ Data Representation� data representation problem
– use agreed external representation, two conversions necessary– use sender’s or receiver’s format and convert at the other end
� 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)� data representation formats
– SUN Microsystems XDR– CORBA CDR– ASN.1 (OSI layer 6)
� 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
�hand-programming error-prone�use of compilers for programs working directly at transport API
teleDistributed Systems - Fall 2001 II - 109 © Stefan Leue 2001
Interprocess Communication♦ CORBA Common Data Represenation (CDR)
� CORBA: Common Object Request Broker Architecture– middleware architecture standardized by the Object Management Group– see www.omg.org
� CORBA CDR– supports types allowed in CORBA remote object invocations– primitive types
�little/big endian according to sender’s representation format�primitive values start at indexed byte positions (multiples of 1, 2, 4 or
8) �floating point according to IEEE standard�characters using an agreed character set
teleDistributed Systems - Fall 2001 II - 110 © Stefan Leue 2001
Interprocess Communication♦ CORBA Common Data Represenation (CDR)
� CORBA CDR– structured types
�definitions
�example: struct with value {‘Smith’, ‘London’, 1934}
© Pearson Education 2001
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 111 © Stefan Leue 2001
Interprocess Communication♦ CORBA Common Data Represenation (CDR)
� CORBA marshalling/unmarshalling– CORBA Interface Definition Language (IDL)– IDL compilers will generate marshalling and unmarshalling operations
(“stubs”) that transforms data objects into CDR format
teleDistributed Systems - Fall 2001 II - 112 © Stefan Leue 2001
Interprocess Communication
♦ Java Object Serialization� example: class Person
� 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�inclusion 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.)
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;}
... }
teleDistributed Systems - Fall 2001 II - 113 © Stefan Leue 2001
Interprocess Communication
♦ Java Object Serialization� example: class Person
� serialization example: – Person p = new Person(“Smith”, “London”, 1934)
�serialization: create instance of class ObjectOutputStream and invoke writeObject method, passing object to be serialized as argument
�deserialization: open ObjectInputStream on the serialized structure and use readObject method
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;}
... }
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 114 © Stefan Leue 2001
Interprocess Communication
♦ Remote Object References� needed when a client invokes an object that is located on a remote server� reference needed that is unique over space and time
– space: where is the object located– time: correct version of an undeleted object
� a generic format proposal
– 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)� extension
– object references that are location transparent
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 115 © Stefan Leue 2001
Interprocess Communication
♦ Client-Server Communication� 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
� generic protocol example (for RPC or RMI communication)
© Pearson Education 2001
teleDistributed Systems - Fall 2001 II - 116 © Stefan Leue 2001
Interprocess Communication
♦ Client-Server Communication� format of protocol messages
– message type (request/reply)– request ID
�sending process identifier (e.g., IP address/port number)�integer sequence number incremented by sender with every request
– object reference– method ID and arguments
� if implemented over UDP: failure recovery– omission failures
�use timeout and resend request when timeout expires and reply hasn’t arrived
�server 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�loss of replies: request - reply - ack reply protocol
– message duplication: return request ID with reply
teleDistributed Systems - Fall 2001 II - 117 © Stefan Leue 2001
Interprocess Communication
♦ Client-Server Communication� example: Hypertext Transfer Protocol (HTTP)
– lightweight request - reply protocol for the exchange of network resources between web clients and web servers
– protocol steps�connection establishment between client and server (likely TCP, but
any reliable transport protocol is acceptable)�client sends request�server sends reply�connection 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.�text/plain�text/html�image/jpeg
– data is marshalled into ASCII transfer syntax
teleDistributed Systems - Fall 2001 II - 118 © Stefan Leue 2001
Interprocess Communication
♦ Client-Server Communication� example: Hypertext Transfer Protocol (HTTP)
– request
�GET: request of resource, identified by URL, may refer to* data: server returns data* program: server runs program and returns output data
�HEAD: request similar like GET, but only meta data on resource is returned (like date of last modification)
�POST: specifies resource (for instance, a server program) that can deal with the client data provided with previous request
�PUT: supplied data to be stored in given URL�DELETE: delete an identified resource on server
© Pearson Education 2001