chapter 4: interprocess communication
DESCRIPTION
Chapter 4: Interprocess communication. Introduction The API for the internet protocols External data representation and marshalling Client-server communication Group communication. Introduction. The middleware : Design of the components: Request-replay protocol - PowerPoint PPT PresentationTRANSCRIPT
Chapter 4: Interprocess communication
IntroductionThe API for the internet protocolsExternal data representation and
marshallingClient-server communicationGroup communication
IntroductionThe middleware :
Design of the components:Request-replay protocolMarshalling and external data representation
Integrating communication into a programming language paradigm, for example:Remote method invocation.(RMI)Remote procedure calling.(RPC)
Figure 4.1Middleware layers
Applications, services
Middlewarelayers
request-reply protocol
marshalling and external data representation
UDP and TCP
Thischapter
RMI and RPC
The API for the internet protocols
The characteristics of interprocess communication
Synchronous and
asynchronous
communication
Message destinations
Reliability
Ordering
Sockets
Java API for internet
addresses
UDP datagram communication
Failure model
Use of UDP
Java API for UDP
datagram
TCP stream communication
Failure model
Use of TCP
Java API for TCP streams
The API for the internet protocols
Synchronous and asynchronous communicationIn the synchronous form of communication, the
sending and receiving process synchronize at every message
In the synchronous form of communication, Send and receive are blocking operations.
In the asynchronous form of communication, the use of send operation is non-blocking .
In the asynchronous form of communication, the transmission of the message proceed in parallel with the sending process
In the asynchronous form of communication, the receive operation can have blocking and non-blocking variants
The characteristics of interprocess communication
Message destinationsEach port has one receiver and could be many
sendersProcess may use multiple ports to receive messagesIf the client uses a fixed internet address to refer to
a service, then that service must always run on the same computer
That can be avoided by providing location transparency as follows:Client programs refer to service by name and use
a name server or binder to translate their names into server locations at run time.(service relocate)
The operating system. E.g.: Mach ( how does it work?).(service relocate and migrate)
The characteristics of interprocess communication
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
Reliability:validity
A point-to-point message service can be described as reliable if messages are guaranteed to be delivered
A point-to-point message service can be described as unreliable if messages are not guaranteed to be delivered
IntegrityMessages must arrive uncorrupted and without
duplicationOrdering
Some applications require that messages be delivered in sender order
The characteristics of interprocess communication
Sockets
For process to receive messages, its socket must be bound to a local port and one of the internet addresses of the computer
Java API for internet addressesInetAddress classInetAddress aComputer=
InetAddress.getByName(“bruno.dcs.qmul.ac.uk”);
UDP datagram communication
Some issues related to datagram communication: Message size: the receiving process needs to specify
an array of bytes of a particular size. (message size is restricted)
Blocking: non-blocking sends and blocking receives Timeouts : timeouts can be set on sockets and it
should be fairly large in comparison with the time required to transmit a message.
Receive from any : invocation of receive method gets a message addressed to its socket from any origin.
Failure model Omission failures : messages could be dropped
Send-omission failure Receive-omission failure
Ordering : out of order
Use of UDPIn DNSIn VOIP: Voice over IP
Java API for UDP datagramDatagramPacket:
Message Length of message IPPort #
DatagramSocket:Send and receivesetSoTimeoutconnect
UDP datagram communication
Figure 4.3UDP client sends a message to the 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();}
} }
Figure 4.4UDP 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();}
}}
Figure 4.3UDP client sends a message to the 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();}
} }
TCP stream communicationThe following characteristics of the network
are hidden by the stream abstraction:Message size : the underlying implementation of a
TCP stream desides how much data to collect before transmitting it as one or more IP packets.
Lost message : using ACK schemeFlow control : matching the speed of processesMessage duplication and ordering : using message
IDMessage destination : the processes simply read
from and write to the stream without needing to use IP addresses and ports.
Some outstanding issues related to stream communication:Matching of data items : two communicating
processes need to agree as to contents of the data transmitted over a stream.
Blocking : The process that reads data may be blocked until
data becomes availableThe process that writes data to a stream may be
blocked by the TCP flow control mechanism Threads: when a server accepts a connection, it
creates a new thread which to communicate with the new client.
TCP stream communication
Failure model Checksum & sequence# for integrity.Timeout & retransmissions for validity.Some times TCP does not provide reliable
communication . (how?)When a connection is broken, a process will
be notified if it attempts to read or write and this has the following effects:The process cannot distinguish between
network failure and process failureThe processes cannot tell whether the
messages they sent have been received or not.
TCP stream communication
Use of TCPHTTPFTPTelnetSMTP
Java API for TCP streamsServerSocketSocket
It provides methods such as:o getInputStream returns InputStreamo getOutputStream returns OutputStreamo WriteUTF of DataInputStream o ReadUTF of DataOutputStream
TCP stream communication
Figure 4.4UDP 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();}
}}
Figure 4.5 TCP client makes connection to server, sends request and receives replyimport 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());}} }}
Figure 4.6 TCP server makes a connection for each client and then echoes the 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
Figure 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 and marshalling
Motivation:Different data typesDifferent floating-point representations
Big-endian orderLittle-endian order
The set of codes used to represents character:ASCIIUnicode standard
Methods:Agreed external formatSender format + indication
External data representation and marshalling External data representation:
An agreed standard for the representation of data structures and primitives values
MarshallingIs the process of taking a collection of data items and
assembling them into a form suitable for transmission in a message
UnmarshallingIs the process of disassembling data items on arrival to
produce an equivalent collection of data items at the destination
www-01.ibm.com
External data representation and marshalling
CORBA’s CDR
Marshalling in CORBA
Java object serialization
The use of reflection
XML
XML element and attributes
Parsing and well-formed documents
XML namespaces
XML schemas
API for accessing
XML
Remote object references
approaches
availability
Primitive data
Marshalled data
Type informatio
n representa
tion
CORBA CDR
Carried out by a
middleware layer
without any involvemen
t on the part of the application programme
r
Marshalled into a binary form
Includes just the
values of objects
Java’s object
serialization
Include type
information
Serialized form
XML
Is available for all
commonly used
platforms and
programming
environments
Represented
textually namespaces
CORBA CDRCORBA’s Common Data Representation
CORBA CDR can represent all of the data types that can be used as arguments and returned values and these include 15 primitive types: Short (16-bit) Long(32-bit) Unsigned short (32-bit) Unsigned long(32-bit) Float(32-bit) Double(64-bit) Char(8-bit) Boolean(8-bit) Octet(8-bit) Any ( basic or constructed types) Composite types
Primitive typeso CDR defines a representation for big-
endian and little-endian orderingo Values are transmitted in the sender’s
orderingo The recipient translates if it requires a
different orderingo Floating-point values follow the IEEE
standardso Characters are represented by a code set
agreed between client and serverConstructed types
o The primitive values are added to a sequence of bytes in particular order
CORBA CDR
Figure 4.7CORBA CDR for constructed types
Type Representation
sequence length (unsigned long) followed by elements in orderstring 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 componentsenumerated unsigned long (the values are specified by the order declared)union type tag followed by the selected member
Figure 4.8CORBA CDR message
The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934}
0–34–78–1112–15
16–19
20-23
24–27
5
"Smit""h___"
6"Lond"
"on__"
1934
index in sequence of bytes 4 bytes
notes on representation
length of string
‘Smith’
length of string
‘London’
unsigned long
The type of a data items is not given with the data representation in the message ( why?)
Marshalling in CORBA: It can be generated automatically from the
specification of the data types The types are described in CORBA IDL (interface
definition language )
Struct Prerson {
string name;
string place;
unsigned long year;
};
CORBA CDR
JavaJava object serialization
Serialization: the activity of flattening an object or a connected set of objects into a serial form that is suitable for storing on disk or transmitting in a message
Deserialization: restoring the state of an object or a set of objects from their serialized form.
The information about a class consists of the name & the version
Handle: is a reference to an object within serialized form
Serialization procedure must ensure that:1. There is a 1-1 correspondence between object
references and handles2. Each object is written once only
Figure 4.9Indication of Java serialized form
The true serialized form contains additional type markers; h0 and h1 are handles
Serialized values
Person
3
1934
8-byte version number
int year
5 Smith
java.lang.Stringname:
6 London
h0
java.lang.Stringplace:
h1
Explanation
class name, version number
number, type and name of instance variables
values of instance variables
Java (con.)The use of reflection:
Reflection:
1. It is the ability to Enquire about the properties of a class, such as the names and types of the instance variables and methods.
2. It enables classes to be created from their names
3. It enables a constructor with given argument types to be created for a given class
4. By using reflection, there is no need to generate special marshalling functions for each type of object
Java (con.) In Java:1. Java object serialization uses reflection to
find out the class name of the object to be serialized and the names, types and values of the instance variables
2. For deserialization, the class name in the serialized form is used to create a class. This is then used to create a new constructor with argument types corresponding to these specified in the serialized form. Finally, the new constructor is used to create a new object with instance variables whose values are read from the serialized form.
XMLExtensible markup language:
It was defined by (W3C) for general use on the web.
It’s term refers to a textual encoding.It was derived from SGML It was designed for written structured
documents for the web.XML data items are tagged with ‘markup’
stringsThe tags are used to describe the logical
structure of the data and to associate attribute-value pairs with logical structures.
The tags relate to the structure of the text that they enclose.
XMLXML is used to enable clients:
to communicate with web services For defining the interfaces and other properties and
retrieval systemsXML is readable on any computer.The use of XML includes :
The specification of user interfacesThe encoding of configuration files in operating
systems.XML is extensible because the users can
defined their tags If an XML document is intended to be used by more
than one application, then the names of tags must be agreed between them (e.g SOAP message)
XML is used by multiple applications for different purposes. So, it uses namespaces to define the meaning of the tags.
XML & HTML
XML HTML
Was designed for writing structured documents for the
web
Was designed for defining the appearance of web pages
The tags relate to the structure of the text that they enclose
The tags specify how a browser could display the text
The users can define their tags HTML uses a fixed set of tags
XML advantages and disadvantagesAdvantagesThe use of user- defined tagsThe use of namespacesTextual XML documents:
Readableindependent
DisadvantagesLong messages
Long process and transmission timeMore space to store ( how could the problem
be solved?)
Figure 4.10 XML definition of the Person structure
<person id="123456789"><name>Smith</name><place>London</place><year>1934</year><!-- a comment -->
</person >
XML (con.)XML elements and attributes
Elements:An element in XML consist of a portion of
character data surrounded by matching start and end tags.
One element can enclose another element. (what is the benefit?)
An empty tag has no content and is terminated with />
Attributes:The start tag may include pairs of associated
attribute names and values such as id=“123456789”
Multiple attribute values are separated by spaces.(how to choose element or attribute?)
XML (con.)Names:
They generally start with a letter but can also start with an underline or a colon.
Letters are case-sensitiveNames that start with xml are reserved.
Binary data:Encrypted elements can be represented
in base64 notation using only the alphanumeric characters together with +,/and= which has a special meaning.
XML (con.)Parsing and well-formed documents
Structure rules:1. Each start tag has a matching end tag.2. All tags are correctly nested3. Every XML document must have a single root
element. Parsing:
1. parser is easy to be implemented if we follow structure rules.
2. When parser reads an XML document that is not well formed it will report a fatal error.
3. XML parsers normally parse the contents of elements (why?)
Every XML document must have a prolog as its first line which must at least specify the version of XML
XML (con.)XML namespaces
XML namespace is a set of names for a collection of elements types and attributes, that is referenced by a URL
An XML namespace can be used by any other XML document
Any element that makes a use of an XML namespace can specify that namespace as an attribute called xmlns
Figure 4.11 Illustration of the use of a namespace in the Person structure
<person pers:id="123456789" xmlns:pers = "http://www.cdk4.net/person">
<pers:name> Smith </pers:name>
<pers:place> London </pers:place >
<pers:year> 1934 </pers:year>
</person>
XML (con.)XML schemas
It defines the elements and attributes that can appear in a document
It defines how the elements are nestedIt defines the order and the number of
elements, whether an element is empty or can include text
APIs for accessing XMLXML parser and generators are available for
most commonly used programming languages. ( e.g. marshaling and unmarshaling in Java)
Figure 4.12 An XML schema for the Person structure
<xsd:schema xmlns:xsd = URL of XML schema definitions ><xsd:element name= "person" type ="personType" />
<xsd:complexType name="personType"><xsd:sequence>
<xsd:element name = "name" type="xs:string"/> <xsd:element name = "place" type="xs:string"/> <xsd:element name = "year" type="xs:positiveInteger"/>
</xsd:sequence><xsd:attribute name= "id" type = "xs:positiveInteger"/>
</xsd:complexType></xsd:schema>
Remote object referenceRemote object references
Is an identifier for a remote object that is valid throughout a distributed system.
It is passed in the invocation message to specify which object is to be invoked.
It must be unique over space and time.It must no be reused if the remote object is
deleted. ( error message must be produced)
Figure 4.13Representation of a remote object reference
Internet address port number time object number interface of remote object
32 bits 32 bits 32 bits 32 bits
Client-server communicationThis form of communication is designed to support the
roles and message exchanges in typical client-server interactions.
In normal case it is: Synchronous Reliable
The request-replay protocol
Client Server
doOperation sends request message Invokes receive (blocked until replay)
GetRequestReceives the requestInvokes the methodsendReplay
Figure 4.14Request-reply communication
Request
ServerClient
doOperation
(wait)
(continuation)
Replymessage
getRequest
execute
method
messageselect object
sendReply
Figure 4.15Operations 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.
Figure 4.16Request-reply message structure
messageType
requestId
objectReference
methodId
arguments
int (0=Request, 1= Reply)
int
RemoteObjectRef
int or Method
array of bytes
Message identifiersA message identifier consists of two parts:
A requestId: makes the identifier unique to the sender and it is reset to zero if it reaches the maximum value.
An identifier for sender process: makes the identifier unique in the DS.
Failure model of the request-replay protocolOmission failuresOut of ordercrash
TimeoutsAfter time out, doOperation returns immediately
with indecation to the client that it has failed.doOperation sends the request message repeatedly
until it gets a replay otherwise it indicates to the client by an exception that no result was received
Client-server communication (con.)
Discarding duplicate request messagesBy recognizing successive messages with the same
request identifier and filtering out duplicates
Lost replay messagesAn idempotent operation is an operation that can be
performed repeatedly with the same effect as if it had been performed exactly ones.
HistoryA structure that contains a record of (replay)
messages that have been transmittedAn entry in a history contains : request identifier-
message-client identifierA history will become very large
Client-server communication (con.)
RPC exchange protocolThe request R protocolThe request-replay RR protocolThe request-replay-acknowledge replay RRA protocol
Use of TCP streams to implement the request-replay protocol
To avoid implementing multi-packet protocols is one of the reasons for choosing to implement request-replay protocol over TCP
no need for the request-replay protocol to deal with retransmission of messages and filtering of duplicates or with histories.
Flow-control mechanism allows large arguments and results to be passed without taking special measures to avoid overwhelming the recipient.
TCP simplify the implementation of request-replay protocol.
Client-server communication (con.)
HTTPWeb servers manage resources implemented
in different ways:As data such as text or imageAs a program that can be run on the web server.
HTTP protocol allows for:Content negotiationAuthentication
Client-server interaction consists of the following steps:Client request and server acceptsSending request message to the serverSending replay to the clientConnection is closed
Client-server communication (con.)
HTTP (con.)Later version of the HTTP protocol uses
persistent connections that remain open over a series of request-replay exchanges between client and server.
Requests and replies are marshalled into message as ASCII text string
Resources implemented as data are supplied as MIME-like structures
HTTP methods
GET The web server replies by returning data or runs the program and returns its output
HEAD Returns all the information about data ( type, size and last modification time)
POST Providing a block of data to a data-handling processPosting messageExtending database
PUT Store data as an URL identifier
DELETE The server deletes the resource
OPTIONS The server supplies the client with a list of methods
TRACE The server sends back the request message
HTTP (con.)
Message contents
Figure 4.18HTTP request message
GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1
URL or pathnamemethod HTTP version headers message body
Figure 4.19HTTP reply message
HTTP/1.1 200 OK resource data
HTTP version status code reason headers message body
HTTP (con.)
Group communicationA multicast operation is an operation that
sends a single message from one process to each of the members of a group of processes
Multicast messages provide a useful infrastructure for constructing DS with the following characteristics:Fault tolerance based on replicated servicesFinding the discovery servers in spontaneous
networkingBetter performance through replicated dataPropagation of event notifications
Group communication
IP multicast-an implementation of group communication
IP multicast
Failure model for multicast datagrams
Java API to IP multicast
Reliability ordering of multicast
Some examples of the effects of reliability and
ordering
Group communication
IP multicast- an implementation of group communicationIP multicast
It is built on top of the IPIP packets are addressed to computersIP multicast allows the sender to transmit a
single packet to a multicast groupThe sender unaware of the identities of the
individuals recipients and the size of the group
A multicast group is specified by a class D internet address.
Dynamic membershipIP multicast is available only via UDP
Group communication (con.)
Multicast socketMulticast routers
TTLMulticast address allocation
Permanent or temporary addressesFailure model for multicast datagrams
Omission failuresUnreliable multicast
Java API to IP multicastMulticastSocketjoinGroupleavGroupsetTimeToLive
Group communication (con.)
Reliability and ordering of multicastSome examples of the effects of reliability
and orderingFault tolerance based on replicated services : If one
of the replicas misses the request it will become inconsistent with others
Finding the discovery servers in spontaneous networking :Lost request not an issue when locating discovery server
Better performance through replicated data :The effect of lost message would depend on the method of replication and the importance of all replicas being totally up to date
Propagation of event notifications :The particular application determines the qualities required of multicast
Reliable multicast : any message transmitted is either received by all members or by none
Totally ordered multicast: all of the messages transmitted to a group reach all of the members in the same order
Group communication (con.)