chapter 4: interprocess communication

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


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)


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


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”);


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


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.


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.


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


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>

</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


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.


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


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


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


chapter 4: interprocess communication

Documents

message service

message size

service relocatethe

message length of mess

internet protocolssynchronous

fixed internet address

nonblocking variants

ipjava api