Chapter 3: Interprocess Communication
Jan 02, 2016
Chapter 3: Interprocess
Communication
Objectives To study characteristics: interprocess
communication, datagram & stream communication in Internet.
To study Java applications that use the Internet protocols & Java serialization.
To be aware of design issues for Request-Reply protocols & how collections of data objects may be represented in messages.
Concern characteristic of protocols for communication between process in DS ~ many components & interconnections
Java API for interprocess communication provides datagram & stream communication~ discuss failure models.
Representation of collection of data objects in messages & references to remote objects.
Emphasis on logical relationship between components, e.g. client & server; group communication.
Introduction
TCP (Transport Control Protocol) and UDP (User Datagram Protocol) are layer protocols
TCP is a connection-oriented protocol with guaranteed delivery
UDP is a connectionless protocol without guaranteed message delivery
Socket is an endpoint for communication between processes with uniquely named.~ so other process can find, communicate, and access it
Introduction (Cont).
Figure 4.1Middleware layers
Applications, services
Middlewarelayers
request-reply protocol
marshalling and external data representation
UDP and TCP
Thischapter
RMI and RPC
Characteristics of interprocess communication
Message passing between process
2 message communication operations: i) send
ii) receive
A process send a message to a destination, another process at destination receive message
Communication between send & receive process:
i) synchronousii) asynchronous
API for Internet Protocols
Characteristics of interprocess communication (cont.)
Communicated data can be stream or datagram
a) stream – sequence of byteb) datagram – discrete packet contain header, data, and trailer information (error correction, etc)
Message destination: message are sent to (internet address, local port) pairs
API for Internet Protocols
Sockets UDP & TCP use socket Endpoint for communication between process Originate from BSD UNIX, but present in most
UNIX version such Linux; Windows & Macintosh OS
A process received message: ~ its sockets bound to a local port & 1 of the Internet addresses on which it runs
Process may use same socket for sending & receiving messages
Each computer has a large number (216) of possible port for use by local processes for receiving message.
API for Internet Protocols (cont.)
Figure 4.2Sockets and ports
message
agreed portany port
socketsocket
Internet address = 138.37.88.249Internet address = 138.37.94.248
other ports
client server
Interprocess communication: ~Transmitting a message between a socket in one process & a socket in another process message
Java API for Internet Addresses
IP packets underlying UDP & TCP are sent to Internet Addresses
Java provides class, InetAddress ~ represents Internet addresses
Method uses DNS to get corresponding Internet addresses.
Example: to get an object representing Internet Addresses of the host whose DNS name is bruno.dcs.qmul.ac.uk, use:
InetAddress aComputer = InetAddress.getByName(“bruno.dcs.qmul.ac.uk”);
API for Internet Protocols (cont.)
UDP Datagram Communication
A datagram sent by UDP is transmitted from a sending process to a receiving process
A datagram is transmitted between processes ~1 process sends its & another process receives it
Create a socket bound to an Internet address of the local host & local port
Server will bind its socket to a server port
Client bind its socket to any free local port
API for Internet Protocols (cont.)
UDP Datagram Communication (cont.)
Receive method return Internet Addresses & port of sender, allowing recipient to send reply.
Issue relating datagram communication:a) Message size; b) Blocking; c) Timeouts; d) Receiving from any
API for Internet Protocols (cont.)
Datagram communication is a useful building block for lightweight interprocess communication protocols ~ Example: Request-Reply protocol ~ Because it carries the minimum possible overheads for the resulting protocols.
Stream communication is a useful alternative ~ Because can simplify programming task
API for Internet Protocols (cont.)
Failure Model
Failure model can be used to provide a failure model for UDP datagram
Suffer from the following failures: Omission Failures: ~ Message may be dropped occasionally ~ Because checksum error or no buffer space is available at destination Ordering: ~ Messages can sometimes be delivered
out of sender order
API for Internet Protocols (cont.)
Fig. 4.3: UDP Client Sends A Message To 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 hostnameDatagramSocket 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();}
} }
Fig. 4.4: UDP Server Repeatedly Receives A Request And Sends It Back
To The Clientimport 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();}
}}
TCP Stream Communication Provide abstraction of a stream of bytes to
which data may be written and which data may be read
Characteristic of the network are hidden by the stream abstraction:
Message sizes Lost messages Flow control Message duplication and ordering Message destinations
API for stream communication assume that 1 of them play client role and other play server role, but they could be peers.
API for Internet Protocols (cont.)
TCP Stream Communication (cont.)
For a client, we need to connect to the server which we need to communicate
Client role: ~ creating a stream socket~ make a connect request asking for a connection to a server at its server port
For server there is a need to use listen & accept
Server role:~ create a listening socket bound to server port~ waiting for client to request connection
API for Internet Protocols (cont.)
TCP Stream Communication (cont.)
Outstanding issues for stream communication:
~ Matching of data item~ Blocking~ Threads
API for Internet Protocols (cont.)
Java API for TCP streams
Java interface to TCP streams is provided in classes ServerSocket and Socket ~ represents Internet addresses
ServerSocket: ~ intended use by server~ create a socket at a server port~ listening for connect request from client
Socket~ use by pair processes with a connection~ client uses a constructor to create socket, specifying DNS hostname & port of a server~ method getInputStream & getOutputStream for accessing 2 streams associated with socket
API for Internet Protocols (cont.)
Fig. 4.5: TCP Client Makes Connection To Server, Sends Request & Receives
Reply import java.net.*; import java.io.*; public class TCPClient {
public static void main (String args[]) {// arguments supply message and hostname of destinationSocket 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.3String 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());}} } }
Fig. 4.6: TCP Server Makes A Connection For Each Client & Then
Echoes Client’s Request
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
Fig. 4.6 continuedclass 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*/}}}
}
External Data Representation &
Marshalling Information stored in running programs is
represented as data structures
Example: sets of interconnected objects ~information in messages consist sequences of bytes
Method used to enable 2 computer to exchanges binary data values are:
i. Connected to an agreed external format before transmission
ii. Transmitted in sender format-with indication of format being used.
External Data Representation &
Marshalling (cont.)External data representation: An agreed
standard for representation of data structure and primitive values
Marshalling: process of taking collection of data items & assembling them into a form suitable for transmission in a messages
Unmarshalling: process of diassembling them on arrival to produce an equivalent collection of data items at destination
External Data Representation &
Marshalling (cont.)
Client & server programs:~ deal with data objects ~ marshalled into a standard form - before they can be passed in messages. ~ Standard form (or external data representation) deals with data structures & primitive data items. ~ CORBA's CDR is designed for use by a variety of programming languages.
External Data Representation & Marshalling (cont.)
3 approaches to external data representation & marshalling discusses:a) CORBA's Common Data Representation (CDR)~ concern for structured & primitive types ~ can be passed as argument and remote method invocation in CORBAb) Java object serialization~ concern with flattening & external data representation of any single object or tree of objects that need to be transferred in messagec) Extensible markup language (XML)~ define a textual format representation for structured data (ex: document access on Web)
Fig. 4.7: CORBA CDR for constructed types
Type Representation
sequence length (unsigned long) followed by elements in order
string length (unsigned long) followed by characters in order (can also
can have wide characters)
array array elements in order (no length specified because it is fixed)
struct in the order of declaration of the components
enumerated unsigned long (the values are specified by the order declared)
union type tag followed by the selected member
Fig. 4.10: XML definition of the Person structure
<person id="123456789"><name>Smith</name><place>London</place><year>1934</year><!-- a comment -->
</person >
Remote object reference must be unique in DS & over time. It should not be reused after the object is deleted. first 2 fields locate the object unless migration or re-activation in a new process can happen4th field identifies object within the processits interface tells the receiver what methods it has (e.g. class Method)a remote object reference is created by a remote reference module when a reference is passed as argument or result to another process– stored in the corresponding proxy– passed in request messages to identify
remote object whose method is to be invoked
External Data Representation & Marshalling (cont.)
Fig. 4.13: Representation Of Remote Object Reference
Internet address port number time object numberinterface of
remote object
32 bits 32 bits 32 bits 32 bits
Client Server
Communication Request-reply protocols
~ design to support client-server communication~ client asks server to perform an operation on an
object and return result. ~ relationship determines the protocol as follows: (i)client needs 1 primitive ( doOperation ), server
needs 2 ( getRequest and sendReply ); (ii) since clients normally wait for replies
doOperation is synchronous; (iii)server must be able to receive getRequest
messages while performing operations.
Client Server
Communication (cont.) Request-reply protocols
~ To deal with failure, requests are re-transmitted~ To ensure that operation is performed at most
once: - duplicate requests are filtered - replies are saved for re-transmission
Fig. 4.14:Request-reply communication
Request
ServerClient
doOperation
(wait)
(continuation)
Reply
message
getRequest
execute
method
message
select object
sendReply
Fig. 4.15: Operations of the request-reply protocol
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)
sends a request message to the remote object and returns the reply. The arguments specify the remote object, the method to be invoked and the arguments of that method.
public byte[] getRequest ();
acquires a client request via the server port.
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);
sends the reply message reply to the client at its Internet address and port.
Fig. 4.16: Request-reply message structure
messageType
requestId
objectReference
methodId
arguments
int (0=Request, 1= Reply)
int
RemoteObjectRef
int or Method
array of bytes
Fig. 4.17: RPC Exchange Protocols
R RequestRR Reply
RRA Acknowledge reply
Request
Request Reply
Client Server Client
Name Messages sent by
RPC exchange protocols originally identified by Spector [1982]
3 protocols which produced 3 different behavior in presence of communication failure: - request (R) protocol
- request-reply (RR) protocol- request-reply-acknowledge
(RRA) protocol
Group Communication
Pairwise exchange - not the best model for communication from 1 process to group of other processes
A multicast operation is more appropriate ~ operation send a single message from 1 process to each of members of a group processes
Membership of group transparent to sender
Group Communication (cont.)
Multicast messages provide useful infrastructure for constructing DS with characteristics:
Fault tolerance based on replicated services Finding discovery servers in spontaneous
networking Better performance through replicated data Propagation of event notification
IP Multicast
Allow sender to transmit single IP packet to set of computer
Allow computer to join or leave group at any time
Available only via UDPUnreliable multicast-doesn’t guarantee msg be
delivered do not specify time , thus issue in ordering.