INTERPROCESS COMMUNICATION

INTERPROCESS
COMMUNICATION
From Chapter 4 of Distributed Systems
Concepts and Design,4th Edition,

By G. Coulouris, J. Dollimore and T. Kindberg

Published by Addison Wesley/Pearson

Education June 2005

1
 INTERPROCESS COMMUNICATION

Topics
 INTRODUCTION
 The API for the INTERNET PROTOCOLS
 EXTERNAL DATA REPRESENTATION
 CLIENT-SERVER COMMUNICATION
 GROUP COMMUNICATION

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
2
 INTERPROCESS COMMUNICATION

Introduction
 This chapter is concerned with
middleware.

Figure 1. Middleware layers

3
Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
INTERPROCESS COMMUNICATION

4
INTERPROCESS COMMUNICATION

5
INTERPROCESS COMMUNICATION

6
INTERPROCESS COMMUNICATION

7
INTERPROCESS COMMUNICATION

8
INTERPROCESS COMMUNICATION

9
INTERPROCESS COMMUNICATION

10
INTERPROCESS COMMUNICATION

11
INTERPROCESS COMMUNICATION

12
INTERPROCESS COMMUNICATION

13
INTERPROCESS COMMUNICATION

14
INTERPROCESS COMMUNICATION

15
INTERPROCESS COMMUNICATION

16
INTERPROCESS COMMUNICATION

17
INTERPROCESS COMMUNICATION

18
INTERPROCESS COMMUNICATION

19
INTERPROCESS COMMUNICATION

20
INTERPROCESS COMMUNICATION

21
INTERPROCESS COMMUNICATION

22
INTERPROCESS COMMUNICATION

23
INTERPROCESS COMMUNICATION

24
INTERPROCESS COMMUNICATION

25
INTERPROCESS COMMUNICATION

26
INTERPROCESS COMMUNICATION

27
INTERPROCESS COMMUNICATION

28
INTERPROCESS COMMUNICATION

29
INTERPROCESS COMMUNICATION

30
INTERPROCESS COMMUNICATION

31
INTERPROCESS COMMUNICATION

32
INTERPROCESS COMMUNICATION

33
INTERPROCESS COMMUNICATION

34
INTERPROCESS COMMUNICATION

35
INTERPROCESS COMMUNICATION

36
INTERPROCESS COMMUNICATION

37
INTERPROCESS COMMUNICATION

38
INTERPROCESS COMMUNICATION

39
INTERPROCESS COMMUNICATION

40
INTERPROCESS COMMUNICATION

41
INTERPROCESS COMMUNICATION

42
INTERPROCESS COMMUNICATION

43
INTERPROCESS COMMUNICATION

44
INTERPROCESS COMMUNICATION

45
INTERPROCESS COMMUNICATION

46
INTERPROCESS COMMUNICATION

47
INTERPROCESS COMMUNICATION

48
INTERPROCESS COMMUNICATION

49
INTERPROCESS COMMUNICATION

50
INTERPROCESS COMMUNICATION

51
INTERPROCESS COMMUNICATION

52
INTERPROCESS COMMUNICATION

53
INTERPROCESS COMMUNICATION

54
INTERPROCESS COMMUNICATION

55
INTERPROCESS COMMUNICATION

56
INTERPROCESS COMMUNICATION

57
INTERPROCESS COMMUNICATION

58
INTERPROCESS COMMUNICATION

59
 INTERPROCESS COMMUNICATION

CORBA Common Data Representation (CDR)

 CORBA Common Data Representation (CDR)
 CORBA CDR is the external data representation
defined with CORBA 2.0.
 It consists 15 primitive types:
 Short (16 bit)
 Long (32 bit)
 Unsigned short
 Unsigned long
 Float(32 bit)
 Double(64 bit)
 Char
 Boolean(TRUE,FALSE)
 Octet(8 bit)
 Any(can represent any basic or constructed type)

 Composite type are shown in Figure 8.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
60
 INTERPROCESS COMMUNICATION

CORBA Common Data Representation (CDR)

Figure 8. CORBA CDR for constructed types

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
61
 INTERPROCESS COMMUNICATION

CORBA Common Data Representation (CDR)

 Constructed types: The primitive values that
comprise each constructed type are added
to a sequence of bytes in a particular order,
as shown in Figure 8.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
62
 INTERPROCESS COMMUNICATION

CORBA Common Data Representation (CDR)

 Figure 9 shows a message in CORBA CDR
that contains the three fields of a struct
whose respective types are string, string,
and unsigned long.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
63
 INTERPROCESS COMMUNICATION

CORBA Common Data Representation (CDR)

example: struct with value {‘Smith’, ‘London’, 1934}

Figure 9. CORBA CDR message

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
64
 INTERPROCESS COMMUNICATION

Java object serialization

 In Java RMI, both object and primitive data values may
be passed as arguments and results of method
invocation.
 An object is an instance of a Java class.
 Example, the Java class equivalent to the Person struct
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;
}
//followed by methods for accessing the instance variables
}

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
65
 INTERPROCESS COMMUNICATION

Java object serialization

The serialized form is illustrated in Figure 10.

Figure 10. Indication of Java serialization form

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
66
 INTERPROCESS COMMUNICATION

Extensible markup language(XML)

• XML is used to enable clients to communicate with web services
and for defining interfaces and other properties of web services.

• Both XML and HTML are derived from SGML. (Standardized

generalized markup language)

• It is used in archiving and retrieval systems.

XML Definition of the Person structure

<person id=“123456789”>
<name>Smith</name>
<place>London</place>
<year>1934</year>
<!– a comment 67
</person>
 INTERPROCESS COMMUNICATION

Remote Object References

 Remote object references are needed when a
client invokes an object that is located on a
remote server.
 A remote object reference is passed in the
invocation message to specify which object is to
be invoked.
 Remote object references must be unique over
space and time.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
68
 INTERPROCESS COMMUNICATION

Remote Object References

 In general, may be many processes hosting
remote objects, so remote object referencing
must be unique among all of the processes in
the various computers in a distributed system.
 generic format for remote object references is
shown in Figure 11.

Figure 11. Representation of a remote object references

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
69
 INTERPROCESS COMMUNICATION

Remote Object References

 internet address/port number: process which
created object
 time: creation time
 object number: local counter, incremented each
time an object is created in the creating process
 interface: how to access the remote object (if
object reference is passed from one client to
another)

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
70
 INTERPROCESS COMMUNICATION

Client-Server Communication
 The client-server communication is designed to
support the roles and message exchanges in
typical client-server interactions.
 In the normal case, request-reply communication
is synchronous because the client process
blocks until the reply arrives from the server.
 Asynchronous request-reply communication is
an alternative that is useful where clients can
afford to retrieve replies later.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
71
 INTERPROCESS COMMUNICATION

Client-Server Communication
 Often 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 are transferred

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
72
 INTERPROCESS COMMUNICATION

Client-Server Communication
 The request-reply protocol was based on a trio
of communication primitives: doOperation,
getRequest, and sendReply shown in Figure 12.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
73
 INTERPROCESS COMMUNICATION

Client-Server Communication
 The request-reply protocol is shown in Figure 12.

Figure 12. Request-reply communication

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
74
 INTERPROCESS COMMUNICATION

Client-Server Communication
 The designed request-reply protocol matches requests to
replies.
 If UDP datagrams are used, the delivery guarantees
must be provided by the request-reply protocol, which
may use the server reply message as an
acknowledgement of the client request message.
 Figure 13 outlines the three communication primitives.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
75
 INTERPROCESS COMMUNICATION

Client-Server Communication

Figure 13. Operations of the request-reply protocol

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
76
 INTERPROCESS COMMUNICATION

Client-Server Communication
 The information to be transmitted in a request
message or a reply message is shown in Figure 14.

Figure 14. Request-reply message structure

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
77
 INTERPROCESS COMMUNICATION

Client-Server Communication
 In a protocol message
 The first field indicates whether the message is a
request or a reply message.
 The second field request id contains a message
identifier.
 The third field is a remote object reference .
 The forth field is an identifier for the method to be
invoked.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
78
 INTERPROCESS COMMUNICATION

Client-Server Communication
 Message identifier
 A message identifier consists of two parts:
 A requestId, which is taken from an
increasing sequence of integers by the
sending process
 An identifier for the sender process, for
example its port and Internet address.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
79
 INTERPROCESS COMMUNICATION

Client-Server Communication
 Failure model of the request-reply protocol
 If the three primitive doOperation,
getRequest, and sendReply are
implemented over UDP datagram, they
have the same communication failures.
 Omission failure
 Messages are not guaranteed to be
delivered in sender order.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
80
 INTERPROCESS COMMUNICATION

Client-Server Communication
 RPC exchange protocols
 Three protocols are used for implementing
various types of RPC.
 The request (R) protocol.
 The request-reply (RR) protocol.
 The request-reply-acknowledge (RRA)
protocol.
(Figure 15)

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
81
 INTERPROCESS COMMUNICATION

Client-Server Communication

Figure 15. RPC exchange protocols

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
82
 INTERPROCESS COMMUNICATION

Client-Server Communication
 In the R protocol, a single request message is
sent by the client to the server.
 The R protocol may be used when there is no
value to be returned from the remote method.
 The RR protocol is useful for most client-server
exchanges because it is based on request-reply
protocol.
 RRA protocol is based on the exchange of three
messages: request-reply-acknowledge reply.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
83
 INTERPROCESS COMMUNICATION

Client-Server Communication
 HTTP: an example of a request-reply
protocol
 HTTP is a request-reply protocol for the
exchange of network resources between
web clients and web servers.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
84
 INTERPROCESS COMMUNICATION

Client-Server Communication
 HTTP protocol steps are:
 Connection establishment between client
and server at the default server port or at a
port specified in the URL
 client sends a request
 server sends a reply
 connection closure

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
85
 INTERPROCESS COMMUNICATION

Client-Server Communication
 HTTP 1.1 uses persistent connections.
 Persistent connections are connections that
remains open over a series of request-reply
exchanges between client and server.
 Resources can have MIME-like structures
in arguments and results.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
86
 INTERPROCESS COMMUNICATION

Client-Server Communication
 A Mime type specifies a type and a
subtype, for example:
 text/plain
 text/html
 image/gif
 image/jpeg

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
87
 INTERPROCESS COMMUNICATION

Client-Server Communication
 HTTP methods
 GET
 Requests the resource, identified by URL as
argument.
 If the URL refers to data, then the web server replies
by returning the data
 If the URL refers to a program, then the web server
runs the program and returns the output to the client.

Figure 16. HTTP request message

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
88
 INTERPROCESS COMMUNICATION

Client-Server Communication
 HEAD
 This method is similar to GET, but only meta
data on resource is returned (like date of
last modification, type, and size)

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
89
 INTERPROCESS COMMUNICATION

Client-Server Communication
 POST
 Specifies the URL of a resource (for
instance, a server program) that can deal
with the data supplied with the request.
 This method is designed to deal with:
• Providing a block of data to a data-handling
process
• Posting a message to a bulletin board, mailing
list or news group.
• Extending a dataset with an append operation

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
90
 INTERPROCESS COMMUNICATION

Client-Server Communication
 PUT
 Supplied data to be stored in the given URL
as its identifier.
 DELETE
 The server deletes an identified resource by
the given URL on the server.
 OPTIONS
 A server supplies the client with a list of
methods.
 It allows to be applied to the given URL

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
91
 INTERPROCESS COMMUNICATION

Client-Server Communication
 TRACE
 The server sends back the request
message

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
92
 INTERPROCESS COMMUNICATION

Client-Server Communication
 A reply message specifies
 The protocol version
 A status code
 Reason
 Some headers
 An optional message body

Figure 17. HTTP reply message

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
93
 INTERPROCESS COMMUNICATION

Group Communication
 The pairwise exchange of messages is not
the best model for communication from
one process to a group of other
processes.
 A multicast operation is more appropriate.
 Multicast operation is an operation that
sends a single message from one process
to each of the members of a group of
processes.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
94
 INTERPROCESS COMMUNICATION

Group Communication
 The simplest way of multicasting, provides
no guarantees about message delivery or
ordering.
 Multicasting has the following
characteristics:
 Fault tolerance based on replicated
services
 A replicated service consists of a group of
servers.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
95
 INTERPROCESS COMMUNICATION

Group Communication
 Client requests are multicast to all the
members of the group, each of which
performs an identical operation.
 Finding the discovery servers in
spontaneous networking
 Multicast messages can be used by servers
and clients to locate available discovery
services in order to register their interfaces
or to look up the interfaces of other services
in the distributed system.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
96
 INTERPROCESS COMMUNICATION

Group Communication
 Better performance through replicated
data
 Data are replicated to increase the
performance of a service.
 Propagation of event notifications
 Multicast to a group may be used to notify
processes when something happens.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
97
 INTERPROCESS COMMUNICATION

Group Communication
 IP multicast
 IP multicast is built on top of the Internet
protocol, IP.
 IP multicast allows the sender to transmit a
single IP packet to a multicast group.
 A multicast group is specified by class D IP
address for which first 4 bits are 1110 in
IPv4.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
98
 INTERPROCESS COMMUNICATION

Group Communication
 The membership of a multicast group is
dynamic.
 A computer belongs to a multicast group if
one or more processes have sockets that
belong to the multicast group.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
99
 INTERPROCESS COMMUNICATION

Group Communication
 The following details are specific to IPv4:
 Multicast IP routers
• IP packets can be multicast both on local
network and on the wider Internet.
• Local multicast uses local network such as
Ethernet.
• To limit the distance of propagation of a
multicast datagram, the sender can specify the
number of routers it is allowed to pass- called
the time to live, or TTL for short.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
100
 INTERPROCESS COMMUNICATION

Group Communication
 Multicast address allocation
• Multicast addressing may be permanent or
temporary.
• Permanent groups exist even when there are no
members.
• Multicast addressing by temporary groups must
be created before use and cease to exit when
all members have left.
• The session directory (sd) program can be used
to start or join a multicast session.
• session directory provides a tool with an
interactive interface that allows users to browse
advertised multicast sessions and to advertise
their own session, specifying the time and
duration.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
101
 INTERPROCESS COMMUNICATION

Group Communication
 Java API to IP multicast
 The Java API provides a datagram interface
to IP multicast through the class
MulticastSocket, which is a subset of
DatagramSocket with the additional
capability of being able to join multicast
groups.
 The class MulticastSocket provides two
alternative constructors , allowing socket to
be creative to use either a specified local
port, or any free local port.
(Figure 18)

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
102
 INTERPROCESS COMMUNICATION

Group Communication
import java.net.*;
import java.io.*;
public class MulticastPeer{
public static void main(String args[]){
// args give message contents and destination multicast group (e.g. "228.5.6.7")
MulticastSocket s =null;
try {
InetAddress group = InetAddress.getByName(args[1]);
s = new MulticastSocket(6789);
s.joinGroup(group);
byte [] m = args[0].getBytes();
DatagramPacket messageOut = new DatagramPacket(m, m.length, group, 6789);
s.send(messageOut);
byte[] buffer = new byte[1000];
for(int i=0; i< 3;i++) { // get messages from others in group
DatagramPacket messageIn = new DatagramPacket(buffer, buffer.length);
s.receive(messageIn);
System.out.println("Received:" + new String(messageIn.getData()));
}
s.leaveGroup(group);
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());
}finally {if(s != null) s.close();}
}

Figure 18. Multicast peer joins a group and sends and receives datagrams
Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
103
 INTERPROCESS COMMUNICATION

Group Communication
 A process can join a multicast group with a given
multicast address by invoking the joinGroup
method of its multicast socket.
 A process can leave a specified group by invoking
the leaveGroup method of its multicast socket.
 The Java API allows the TTL to be set for a
multicast socket by means of the setTimeToLive
method. The default is 1, allowing the multicast to
propagate only on the local network.

Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005
104