Lecture 7 - The tele Research Group

farflungconvyancerSoftware and s/w Development

Dec 2, 2013 (3 years and 7 months ago)

84 views

tele
Distributed Systems -Fall 2001
II -92
© Stefan Leue 2001
Interprocess Communication

Distributed Systems rely on exchanging dataand achieving
synchronizationamongst autonomous distributed processes
8Inter process communication (IPC)
shared variables
message passing
8message 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)
8Concurrent programs: collections of two or more sequential programs
executing concurrently
8Concurrent processes: collection of two or more sequential programs in
operation, executing concurrently
tele
Distributed Systems -Fall 2001
II -93
© Stefan Leue 2001
Interprocess Communication

Synchronization
8concurrent processes on different computers execute at differentspeeds
8need 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
8sendexpression_listtodestination_designator
evaluates expression_list
adds a new message instance to channel destination_designator
8receivevariable_listfromsource_designator
assignes received values to variables in variable_list
destroys received message

Central questions
8how are destination designators specified?
8how is communication synchronized?
tele
Distributed Systems -Fall 2001
II -94
© Stefan Leue 2001
Interprocess Communication

Destination Designation
8direct naming: source and destination process names serve as designators
(a pair of source and destination designators defines a channel)
sendcur_statustomonitor ormonitor!cur_status
receivemessagefromhandler orhandler?message
easy to implement and use
allows a process easy control whento receive which messagefrom
which otherprocess
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 clientat any time, and a client should be allowed to invoke many
servicesat a time if more than one server available
tele
Distributed Systems -Fall 2001
II -95
© Stefan Leue 2001
Interprocess Communication

Destination Designation
8global namesor 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 themup
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
8ports: 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
8Message destinations in Internet programming
hybrid direct naming/port scheme
(Internet_address, port_number)
port corresponds to many sender/one receiver concept
tele
Distributed Systems -Fall 2001
II -96
© Stefan Leue 2001
Interprocess Communication

Channel Naming
8static(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 entireruntime
of the sending programme
8dynamic(at runtime)
administrative overhead at runtime
more flexible allocation of communication resources
tele
Distributed Systems -Fall 2001
II -97
© Stefan Leue 2001
Interprocess Communication

Semantics of message passing primitives
8Blocking
non-blocking: the execution will never delay the invoking process
blocking: otherwise
8Synchronization
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
bufferedmessage 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
tele
Distributed Systems -Fall 2001
II -98
© Stefan Leue 2001
Interprocess Communication

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

Distributed Applications
8availability of a set of pre-implemented application services, like email, ftp,
http, etc.
8what if you want to build your own, customized Internet application?
8access to Transport Layer services

Services provided by Internet Transport Layer
8UDP: message passing (datagram)
8TCP: data stream
L7 Application
L6 Presentation
L5 Session
L4 Transport
L3 Network
L2 Data Link Control
L1 Physical
smtp
ftp
telnet
http
TCP
IP
LAN
(M)WAN
proprietary netwoks
OSI-BRMInternet
© Pearson Education 2001
tele
Distributed Systems -Fall 2001
II -100
© Stefan Leue 2001
Interprocess Communication

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

IPC based on UDPdatagrams
8UDP datagram properties: no guarantee of order preservation, message loss
and duplications are possible
8necessary steps
createsocket
bindsocket to a port and local Internet address
iclient: arbitrary free port
iserver: server port
8receive method: returns Internet address and port of sender, plus message
8message 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
8send: non-blocking
blocks only until message given to UDP/IP
upon arrival placed in per-port queue
8receive: blocking
pre-emption by timeout possible
if process wishes to continue while waiting for packet, use separate
thread
tele
Distributed Systems -Fall 2001
II -102
© Stefan Leue 2001
Interprocess Communication

Java API for UDP datagrams
8Classes
–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
*sendandreceive
*setSoTimeout
*connect for connecting a socket to a particular remote Internet
address and port
tele
Distributed Systems -Fall 2001
II -103
© Stefan Leue 2001
Interprocess Communication

Java API for UDP datagrams
8Example
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
}
tele
Distributed Systems -Fall 2001
II -104
© Stefan Leue 2001
Interprocess Communication

IPC based on TCP streams
8abstract service: stream of bytes to be written to or received from
8features
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
8connection 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
tele
Distributed Systems -Fall 2001
II -105
© Stefan Leue 2001
Interprocess Communication

Java API for TCP streams
8Classes
–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 andport
of a server
imethods for accessing input and output stream
tele
Distributed Systems -Fall 2001
II -106
© Stefan Leue 2001
Interprocess Communication

Example
8TCP-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());}
}
}
tele
Distributed Systems -Fall 2001
II -107
© Stefan Leue 2001
Interprocess Communication

Example
8TCP-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());}
}
}
tele
Distributed Systems -Fall 2001
II -108
© Stefan Leue 2001
Interprocess Communication

Data Representation
8data representation problem
use agreed external representation, two conversions necessary
use senders or receivers format and convert at the other end
8transmission 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)
8data representation formats
SUN Microsystems XDR
CORBA CDR
ASN.1 (OSI layer 6)
8marshalling/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
tele
Distributed Systems -Fall 2001
II -109
© Stefan Leue 2001
Interprocess Communication

CORBA Common Data Represenation (CDR)
8CORBA: Common Object Request Broker Architecture
middleware architecture standardized by the Object Management Group
see www.omg.org
8CORBA 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
tele
Distributed Systems -Fall 2001
II -110
© Stefan Leue 2001
Interprocess Communication

CORBA Common Data Represenation (CDR)
8CORBA CDR
structured types
idefinitions
iexample: struct with value {‘Smith’, ‘London’, 1934}
© Pearson Education 2001
© Pearson Education 2001
tele
Distributed Systems -Fall 2001
II -111
© Stefan Leue 2001
Interprocess Communication

CORBA Common Data Represenation (CDR)
8CORBA marshalling/unmarshalling
CORBA Interface Definition Language (IDL)
IDL compilers will generate marshalling and unmarshalling operations
(stubs) that transforms data objects into CDR format
tele
Distributed Systems -Fall 2001
II -112
© Stefan Leue 2001
Interprocess Communication

Java Object Serialization
8example: class Person
8serialization:
flattening an object into a linear formsuch that it can be stored in a file or
transmitted in a message
linear format must be such that deserializationroutine 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.)
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;}
... }
tele
Distributed Systems -Fall 2001
II -113
© Stefan Leue 2001
Interprocess Communication

Java Object Serialization
8example: class Person
8serialization 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
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
tele
Distributed Systems -Fall 2001
II -114
© Stefan Leue 2001
Interprocess Communication

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

Client-Server Communication
8often 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
8generic protocol example (for RPC or RMI communication)
© Pearson Education 2001
tele
Distributed Systems -Fall 2001
II -116
© Stefan Leue 2001
Interprocess Communication

Client-Server Communication
8format 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
8if implemented over UDP: failure recovery
omission failures
iuse timeout and resend request when timeout expires and reply
hasnt arrived
iserver receives repeated request
*indempotentoperations: same result obtained on every
invokation
*non-indempotent operations: re-send result stored from previous
request, requires maintenance of a historyof replies
iloss of replies: request -reply -ack reply protocol
message duplication: return request ID with reply
tele
Distributed Systems -Fall 2001
II -117
© Stefan Leue 2001
Interprocess Communication

Client-Server Communication
8example: 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
tele
Distributed Systems -Fall 2001
II -118
© Stefan Leue 2001
Interprocess Communication

Client-Server Communication
8example: Hypertext Transfer Protocol (HTTP)
request
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
© Pearson Education 2001
tele
Distributed Systems -Fall 2001
II -119
© Stefan Leue 2001
Interprocess Communication

Client-Server Communication
8example: Hypertext Transfer Protocol (HTTP)
reply
© Pearson Education 2001