interprocess communication -...

28
tele Distributed Systems - Fall 2001 II - 92 © Stefan Leue 2001 Interprocess Communication 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

Upload: others

Post on 22-May-2020

25 views

Category:

Documents


0 download

TRANSCRIPT

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

teleDistributed Systems - Fall 2001 II - 119 © Stefan Leue 2001

Interprocess Communication

♦ Client-Server Communication� example: Hypertext Transfer Protocol (HTTP)

– reply

© Pearson Education 2001