Chapter-4

Interprocess Communication

4.1 Introduction

• UDP provides a message passing abstraction– the simplest form of interprocess

communication. This enables a sending process to transmit a single message to a
receiving process. The independent packets containing these messages are called
datagrams.
• TCP provides the abstraction of a two-way stream between pairs of processes. The
information communicated consists of a stream of data items with no message
boundaries.
• The objects and data structures used in application programs can be translated into a
form suitable for sending messages over the network, taking into account the fact that
different computers may use different representations for simple data items.
• Multicast communication: a form of interprocess communication in which one process
in a group of processes transmits the same message to all members of the group.

4.2 The API for the Internet protocols

4.2.1 The Characteristics of interprocess communication

1. Synchronous and asynchronous communication
➢ synchronous: blocking send and receive
➢ asynchronous: non-blocking sends and blocking or non-blocking receive

➢ blocking send: waits until the corresponding receive is issued

➢ non-blocking send: sends and moves on
➢ blocking receive: waits until the message is received
➢ non-blocking receives: if the message is not here, moves on

1
 2. Message Destination
➢ Message are sent to (Internet address, local port) pairs.
➢ A local port is a message destination within a computer, specified as an integer.
➢ A port has exactly one receiver but can have many senders.
➢ Any process that knows the number of a port can send a message to it.
➢ Servers generally publicize their port numbers for use by clients.

3. Reliability
➢ Reliable communication in terms of validity and integrity.
➢ As far as the validity property is concerned, a point-to-point message service can
be described as reliable if messages are guaranteed to be delivered despite a
‘reasonable’ number of packets being dropped or lost.

4. Ordering
➢ Some applications require that messages be delivered in sender order – that is, the
order in which they were transmitted by the sender.
➢ The delivery of messages out of sender order is regarded as a failure by such
applications.

4.2.2 Sockets
Socket
Socket provides an endpoint for communication between processes. For a process to receive
messages, its socket must be bound to a local port and one of the Internet addresses of the
computer on which it runs.

➢ Processes may use the same socket for sending and receiving messages.
➢ Each computer has a large number (216) of possible port numbers for use by local
processes for receiving messages.
➢ Any process may make use of multiple ports to receive messages.

4.2.3 UDP datagram communication

A datagram sent by UDP is transmitted from a sending process to a receiving process
without acknowledgement or retries.
• Some issues:

2
 ➢ message size: up to 216, usually restrict to 8K
➢ blocking: non-blocking send, blocking receive
➢ timeouts: timeout on blocking receive
➢ receive from any: doesn't specify sender origin (possible to specify a
particular host for send and receive)

• use of UDP
➢ DNS, VoIP
➢ less overhead: no state information, extra messages, latency due to start up

4.2.4 TCP stream communication

TCP protocol provides the abstraction of a stream of bytes to which data may be written
and from which data may be read.
• Characteristics:
➢ message size: unlimited
➢ lost messages: uses an acknowledgement, retransmit after timeout of no
acknowledgement
➢ flow control: sender can be slowed down or blocked by the receiver
➢ message duplication and ordering: sequence
➢ message destination: establish a connection, one sender- one receiver,
high overhead for short communication
• use of TCP: http, ftp, telnet, smtp

Some issues:
➢ matching of data items: two processes need to agree on format and order
(protocol)
➢ blocking: non-blocking send, blocking receive (send might be blocked due to
flow control)
➢ concurrency: one receiver, multiple senders, one thread for each connection

4.3 External data representation and marshalling

The information stored in running programs is represented as data structures – for example, by
sets of interconnected objects – whereas the information in messages consists of sequences of
bytes. Irrespective of the form of communication used, the data structures must be flattened
(converted to a sequence of bytes) before transmission and rebuilt on arrival. The individual
primitive data items transmitted in messages can be data values of many different types, and
not all computers store primitive values such as integers in the same order.
One of the following methods can be used to enable any two computers to exchange binary
data values:
➢ The values are converted to an agreed external format before transmission and
converted to the local form on receipt; if the two computers are known to be the same
type, the conversion to external format can be omitted.
➢ The values are transmitted in the sender’s format, together with an indication of the
format used, and the recipient converts the values if necessary.

3
 External data representation
An agreed standard for the representation of data structures and primitive values is
called an external data representation.

Marshalling Vs. Unmarshalling

➢ Marshalling is the process of taking a collection of data items and assembling them
into a form suitable for transmission in a message.
➢ Unmarshalling is the process of disassembling them on arrival to produce an equivalent
collection of data items at the destination.

Three alternative approaches to external data representation and marshalling

• CORBA’s common data representation, which is concerned with an external
representation for the structured and primitive types that can be passed as the
arguments and results of remote method invocations in CORBA. It can be used
by a variety of programming languages.
• Java’s object serialization, which is concerned with the flattening and external
data representation of any single object or tree of objects that may need to be
transmitted in a message or stored on a disk. It is for use only by Java.
• XML (Extensible Markup Language), which defines a textual format for
representing structured data. It was originally intended for documents
containing textual self-describing structured data – for example documents
accessible on the Web – but it is now also used to represent the data sent in
messages exchanged by clients and servers in web services.

4.3.1 CORBA’s Common Data Representation (CDR)

• Primitive types: short, long ...
➢ support both big-endian and little-endian
➢ transmitted in sender's ordering and the ordering is specified
➢ receiver translates if needed

• CORBA IDL compiler generates marshalling and unmarshalling routines

4
4.3.2 Java object serialization
• serialization and de-serialization are automatic in arguments and return values of
Remote Method Interface (RMI)
• flattened to be transmitted or stored on the disk
➢ write class information, types and names of instance variables
➢ new classes, recursively write class information, types, names...
➢ each class has a handle, for subsequent references
➢ values are in Universal Transfer Format (UTF)

As an example, consider the serialization of the following object:

Person p = new Person (“Smith”, “London”, 1984);

5
 • References are serialized as handles.
➢ It must ensure that each object is written once only
➢ second or subsequent occurrence of the object is written as a handle
• The use of reflection
➢ to enquire about about the properties (name, types, methods) of a class

4.3.3 Extensible Markup Language (XML)

• Extensible markup language (XML)
➢ User-defined tags (vs. HTML has a fixed set of tags)
➢ different applications agree on a different set of tags
➢ Tags are in plain text (not binary format)—not space efficient

• Person struct in XML

➢ Tag names: person, name, place, year
➢ Element: <name>Smith</name>
➢ Attribute: id="123456789” of person
➢ Binary data need to be converted to characters (base64)

6
XML namespace
• Name clashes within an application
• Namespaces: a set of names for a collection of element types and attributes
➢ xmlns: xml namespace
➢ pers: name of the name space (used as a prefix)
• http://www.cdk4.net/person : location of schema

XML schema
• Defines elements and attributes
• Similar to type definition
• xsd: namespace for xml schema definition

4.3.4 Remote object references

A remote object reference is an identifier for a remote object that is valid throughout a
distributed system. A remote object reference is passed in the invocation message to specify
which object is to be invoked.

• call methods on a remote object (CORBA, Java)

7
 ➢ unique reference in the distributed system
➢ Reference = IP address + port + process creation time + local object # in a process
+ interface
➢ Port + process creation time -> unique process
➢ Address can be derived from the reference

4.4 Multicast communication

Multicast useful for:

• fault tolerance based on replicated services
➢ requests multicast to servers, some may fail, the client will be served
• discovering services in spontaneous networking
➢ multicast to find out who has the services
• better performance through replicated data
➢ multicast updates
• propagation of event notification
➢ new items arrived, advertising services

4.4.1 IP multicast – An implementation of multicast 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 set of computers that form a multicast group.

• A multicast group is specified by a class D addresses, first four bits are 1110 in IPv4.
• IP multicast is available only via UDP.
• Join a group via socket binding to the multicast address.
• Messages arriving on a host deliver them to all local sockets in the group.
• Multicast routers: route messages to out-going links that have members
• Multicast address allocation
➢ permanent
➢ temporary:
o no central registry by IP (one addr might have different groups)
o use (time to live) TTL to limit the distance propagation of hops

8
 o tools like sd (session directory) can help manage multicast addresses and find
new ones

Time to live (TTL)

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.

4.4.2 Reliability and ordering of multicast

The effects of reliability and ordering of multicast communication are:
1. Fault tolerance based on replicated services
2. Discovering services in spontaneous networking
3. Better performance through replicated data
4. Propagation of event notifications

***********************************