Transcript Notes Chapter 3

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.
Introduction
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 (Cont).
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
Figure 4.1
Middleware layers
Applications, services
RMI and RPC
This
chapter
request-reply protocol
marshalling and external data representation
UDP and TCP
Middlew are
layers
API for Internet Protocols
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) synchronous
ii) asynchronous
API for Internet Protocols
Characteristics of interprocess
communication (cont.)
Communicated data can be stream or
datagram
a) stream – sequence of byte
b) 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 (cont.)
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.
Figure 4.2
Sockets and ports
socket
any port
agreed port
socket
message
client
server
other ports
Internet address = 138.37.94.248
Internet address = 138.37.88.249
Interprocess communication:
~Transmitting a message between a socket in one
process & a socket in another process message
API for Internet Protocols (cont.)
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
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 hostname
DatagramSocket 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 Client
import 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();}
}
}
API for Internet Protocols (cont.)
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
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 destination
Socket 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.3
String 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 continued
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();
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 CORBA
b) Java object serialization
~ concern with flattening & external data
representation of any single object or tree of
objects that need to be transferred in message
c) 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 >
External Data Representation &
Marshalling (cont.)
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 happen
4th field identifies object within the process
its 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
Fig. 4.13: Representation Of
Remote Object Reference
32 bits
32 bits
Internet address
port number
32 bits
time
32 bits
object number
interface of
remote object
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
Client
doOperation
Server
Request
message
getRequest
select object
execute
(wait)
Reply
message
(continuation)
method
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
int (0=Request, 1= Reply)
requestId
int
objectReference
RemoteObjectRef
methodId
int or Method
arguments
array of bytes
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
Name
Messages sent by
Server
R
RR
Client
Request
Request
RRA
Request
Reply
Client
Reply
Acknowledge reply
Fig. 4.17: RPC Exchange Protocols
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 UDP
Unreliable multicast-doesn’t guarantee msg be
delivered
do not specify time , thus issue in ordering.