Topics for this lecture

• Inter-process communication
– Characteristics of IPC
– Synchronous and asynchronous communication
– External data representation and marshalling
Inter-process • CORBA’s Common Data Representation
• Java Object serialisation
communication – Client-Server Communication
• Client-Server Communication
• Communication within services provided by a group of servers:
– Group Communication
Dr Simon Blake – IP multicast

Significance of this lecture Significance of this lecture

• DIS depend on networks • We have looked at networking

– Networks depend on messaging • So now we turn our focus to higher level
– Messaging needs to be: software layers
• Efficient • These layers are designed to facilitate
• Reliable easy operation
• Robust • And to embody the ‘good’ design
• And ideally transparent characteristics of our DIS
– How is this achieved?

Recall: The software layered

The focus of this lecture
approach
• The OSI model
Application Application
A message,
descends
Presentation through the Presentation Application: Applications, services
layers

Session Session RMI and RPC

Transport Transport Middleware
Request Reply Protocol (RRP) layers
Then ascends This lecture
Network through the Network Marshalling and external data representation
layers at the
receiver
Data Data
The network Transport: UDP and TCP
Physical Physical
Other lower lever layers…
A HOST – A COMPUTER A HOST – A COMPUTER

1
 Messaging basics Synchronisation
• API (application programming interface) • Synchronisation
– In the context of this lecture this refers to an interface for – Synchronous (blocking)
application programmers to use either UDP or TCP
• Sender is ‘blocked’, i.e. is frozen during send until the receive
message is returned
• Message passing has two fundamental operations • Sender and receiver synchronise
– Send and Receive (Request and Reply) – Asynchronous (non-blocking)
– i.e. one process sends the other receives • Sender can carry on processing once the message is sent
– Simply requires both destinations and messages (i.e. copied to some local buffer)
– May involve synchronisation
– Current systems tend to be synchronous
• BUT… – Non-blocking adds complexity into software code
– How does this occur?

Synchronisation (cont.) API & IP: process communication

• Examples • Message destinations

– Blocking: – Addressing
• Request money from an ATM • The address uniquely identifies the hardware, perhaps a computer
• The ATM blocks until it receive authorisation from the bank. (host on a node)
• A local port a destination on a computer
– Non-blocking – One or more messages can be send to port(s)
• In a DIS a non-blocking message allows sending processes to carry – Processes can use one or more ports for receiving messages
on working while waiting for a response
• Email is a good real world example of non-blocking message
• You send a mail and carry on working while waiting for a reply 156.254.12.35:875
• Update traffic details on an in car sat/nav device
• The sat/nav device carries on working while waiting for new data
Address + port

API & IP: process communication Process communication

ports
• Other issues to consider during inter- ports

process communication
Port: 1
Port: 1

– Reliability
• Reliable systems should not corrupt messages even if
packets are lost or dropped client server

– Ordering Port: 671

Port: 771
• Messages be delivered in the order sent
A computer, IP address = 138.37.543.345 A computer, IP address = 138.37.53.349

2
Process communication & Sockets Process communication
ports

• Sockets Socket maps to a port

ports Socket maps to a port

– An abstraction whereby process bind to a socket Port: 1

which relates to a port Port: 1

– Assigns a specific local port to a process

– Process talk to the socket – which relates to a port
client server
– Processes can only access message from ports
Port: 671
linked to their socket Port: 771
– Requests must be made to specific ports but could
originate for any or in some instances specific ports A computer, IP address = 138.37.543.345 A computer, IP address = 138.37.53.349

UDP communication UDP communication

– UDP and the Datagram method • More details
• In a nutshell – The send method is non-blocking (asynchronous)
– Datagram sent from one process to a receiving process • thus they are free once send has taken place
– First the sender (the client) and receiver (the server) must bind – The receive method uses blocking (synchronous), although
to a socket
other threads can be used to perform other work.
» Client could bind to any port
– Receive blocking can use time-outs to limit the length of the
» Server binds to its specified broadcast port for receiving
block.
messages
• although defining ‘good’ values for timeouts is hard
– The client then sends its message to the server address
including in the message the senders address (required for the – Received messages are stored in the bound socket’s queue.
response) – Receive inspects the bound socket for messages
– The server receives and processes – Received messages could come from anywhere
– The server then sends a response to the client address and
port

UDP communication UDP communication

– Uses of UDP and the Datagram method • UDP and the Datagram method
• Useful where omission failures are tolerable – Method example:
– i.e. naming services
– aSocket.send(request)
• Useful in reducing communication overheads that exist in – aSocket.recieve(reply)
guaranteed delivery methods
• where both request and reply are DatagramPackets

– Other methods:
– setSoTimeout
– connect

3
API & IP: UDP communication API & IP: UDP communication

• In Java • In Java
• A DatagramPacket class contains:
The message Length of message Internet address Port
In Java a DatagramPacket is sent and received thus:
• i.e.
3432 543 4531 13 145.25.123.871 589
aSocket.send(myPacket);
aSocket.recieve(myPacket);
In Java a DatagramPacket is constructed:
Note: aSocket is an instantiated instance of the Java DatagramSocket class.
myPacket = new DatagramPacket(m,args[0].length(), aHost, serverPort);
Interested readers are referred to the course text (pages 138 and 139) for
Note: the DatagramPacket contains the host address (aHost) and the host port more detailed implementations of UDP client and servers
(serverPort)

API & IP: TCP communication API & IP: TCP streaming

– API to TCP uses a stream abstraction • How does it work? In a nutshell

• A stream of bytes – Client requests a stream
– Client creates stream socket to any port
– Client sends a connect request to a server at the server specific
– The stream abstraction hides the following: port
• Message sizes – The server is bound to a designated server port and listens for
• Lost messages connect messages from clients
– Once a connect message is accepted the server uses a new
• Flow control socket for the stream
• Message duplication and ordering – The client is informed of the socket
• Destinations – The client then connects to the dedicated socket

API & IP: TCP streaming API & IP: TCP streaming

• How does it work? More detailed • Dealing with failures

– The server is bound to a designated server port and listens for connect
messages from clients – TCP does not provide reliable communication
– A client requests a stream and creates a socket to any port to send its as it can fail
request from
• The sender stops sending if too many dropped or
– The client then sends a connect request to a server at the server
specific port fail checksums or the network fails
– Once a connect message is accepted the server creates a another • NOTE: The cause of the failure cannot be known
socket for the stream by each process (i.e. network failure or process
– The client is informed of the new socket
failure)
– The server send information via the new socket
– The client and server communicate using input and output streams
through their sockets.

4
 API & IP: TCP streaming API & IP: UDP communication

• Example uses of TCP • In Java

• HTTP • Both the server and client have two classes:
– DataInputStream and a DataOutputStream
• FTP
• A Socket class is used to retrieve each stream
• Telnet – aClientSocket.getInputStream()
• SMTP – sClientSocket.getOutputStream()
• The streams can be read or write to using
– outputStream.writeUTF(data)
• Frequently using reserved port numbers – inputStream.readUTF(data)

Each stream is a string of bits representing in binary primitive data types.

Other classes include:

ServerSocket (used for the server to listen for client stream request)

External data & Marshalling External data & Marshalling

– Process and applications use primitive data • Process data is frequently stored as objects and
types, data-structures
Transaction
• Integers, doubles, etc. -transactionNumber: long
Account *
• Not all primitive data types are stored the same in -accountNumber: long 1
-accountNumber: double
-detail[]: char
each system -balance: double
-otherAccounts[]: int
• Heterogeneity -transactions[]: Transaction
– big-endian / little-endian with integers, +requestTransactions():Transaction
+updateBalance(double):double
– floating points are represented differently too,
..etc.. • Message data is a simple stream of bytes
– 1 byte, 2 bytes used for strings.
– Many more too!!
010101010101010101010100101111010101001010010101

API & IP: External data &

External data & Marshalling
Marshalling
• A sender must then convert its data into a stream of
bytes – All objects and data need to be serialised for
• And bytes have to fit an agreed standard sending
– Data can then be reconstructed once received
• Converting data is called marshalling
• The agreed standard is called external data Is serialised De-serialised
representation transmitted
010101010101010101010100101111010101001010010101

• Both a sender and receiver need to marshal or un-

Sender data Received data
marshal data from the agreed external format
But of course… The receiver could format the data anyway they want!

5
 API & IP: External data & API & IP: External data &
Marshalling Marshalling
• We shall take a brief look at:
– Essentially there are two methods
– CORBA and the common data representation
• 1. Agree an external format
– Java Object serialisation
– Sender converts to external format
– Receiver converts to their local format – XML
• 2. The data is sent using the format with an
indication of the format that is used. – CORBA and JAVA use a binary external data
representation
– XML uses a textual representation
– Either is fine – so long as both the send and receiver
know which is being used,

CORBA CORBA - CDR

• Marshalling in CORBA can be automatically • Data representation: uses Common Data Representation
accomplished (CDR)
– CDR supports 15 primitive types + some composite types
• Primitives such as long, short, boolean, etc. (see page 146)
• We simply need to define an IDL (Interface
• Complex types are sequence, array, union, string, enumerated,
Definition Language) for the data we want to struct
transmit in messages
• Marshalling is automatic providing an IDL (Interface
Definition Language) is available for the data:
• A CORBA IDL contains both: struct Person{ This tells CORBA that we are
– The methods that are to be used remotely string name; going to use a Person data
string place; structure that contains a name and
– The data types and attributes that they will used long DOB; place both stored as strings and a
}; DOB stored as a long

CORBA - CDR JAVA serialisation

• Lets consider the following data structure • Java object serialisation
person{“Simon”, “London”, 1976} – Java RMI can serialise objects + primitive types
• This given the IDL CORBA could convert the data into a a – Classes that are to be serialised MUST implement the
stream of bytes according to CORBA’s rules Serialisable Java interface
• i.e. public class Person implements Serialisable
– Serialised classes can be sent as messages and stored on
0-3 5
CDR sends strings by first sending the disk
4-7 Simo
string length then the data
8-11 n_ _ _
– In Java:
12-15 6
• Serialisation refers to the flattening of the classes and data
16-19 Lond Another string, again in the CDR
20-23 on_ _ format • De-serialisation refers to the un-flatting (reconstruction) of the
data and classes
24-27 1976 Integer sent as is

6
 JAVA serialisation JAVA serialisation
What is written? • So what gets serialised…
1. Class information
public class Person implements Serilizable {
name of the class, version and methods private String name;
private String place; private long DOB;
2. The data public Person(String inName, String inPlace,
long inDOB){ The class Class + its data
3. Any referenced classes name=inName;
information
place = inPlace;
3.1 This involves writing their class information DOB = inDOB;
}
3.2. And.. their data too }

3.3 And.. any referenced classes from the referenced class

3.31. This involves writing their class information Attribute Data
3.3.2. And.. Their data too name Simon And the data
3.3.3. Any referenced classes in the referenced class place London

DOB 1976
And so on as a recursive procedure

JAVA serialisation Java serialisation

• Example of a serialisation • Java Reflection
– Person p = new Person(“Simon”, “London”, 1976);
– The ability to enquire about the properties of a class, names,
– Written to an ObjectOutputStream using writeObject
types, methods and instance variables
– Read from an ObjectOutputStream using readObject – Using reflection objects can easily be serialised and de-
serialised as they can inspect themselves to determine what
Person 8-bype version number h0
they are made of.
3 Int year java.lang.String name: java.lang.String place:
1976 5 Simon 6 London h1
– Reflection simplifies the marshalling process significantly as we
have seen.

• Serialisation and de-serialisation is handled by the

middleware, the programmers does not need to worry
about this process except to understand how to define it
(serialisable) and then how to read and write objects.

Client / Server communication Client Server Communication

• Client-server message exchanges commonly use the
Request
Request Reply (RR) protocol. doOperation
message
getRequest

– They also tend to be synchronous .. Select object

• clients block until a response is returned (wait) Execute method

Reply
– It is reliable as a response constitutes an acknowledgement .. sendReply
message
• RR is reliable for the client (Continuation)
• Request Reply Acknowledge (RRA) makes the communication
reliable for both the server and client

Client calls the server method using doOperation

• Communication itself could use either UDP or TCP Server receives and reads the request using getRequest
The server then matches the object of the request and executes its method
The server then sends the reply (sendReply)

7
 Client Server Communication Object References
doOperation(RemoteObjectReference o, int methodId, byte[] arguments)
• Client invoking a remote object
arguments is the marhsaled data
– Sends message to server
methiodId the method being remotely invoked
– Specifies the object that contains the method
o a reference to the remote object
• This requires a reference

getRequest();
• Solution = use an object reference
collects a request from a server port
– Object references are passed with the message request
– Object references need to be unique
sendReply(byte[] reply, InetAddress clientHost, int clientPort); • Unique can be guaranteed using the following as a Object
sends the request back to the cleint Reference
32 bits 32 bits 32 bits 32 bits
reply is the marshalled data
Internet Address Port Time Object Number Interface of
remote object

Client Server Communication Client Server Communication

A typical message would contain: • Message labelling / identification
• messageType – Reliability requires a robust scheme for identification
• requestID of messages
• objectReference – This comprises of two parts
• An ID should be unique local
• methodId
– A simple number would suffice
• arguments • An ID should be unique for the DIS
– Suffix the sender address and port
All in serial form

Client Server Communication Client Server Communication

• Failures
– The RR protocol needs to deal with failures
• If the datagram technique is used
– Omission failures (timeouts helps solve)
– Message order failure (labelling helps to solve)
– And possible process failures too
– Many techniques can be used to reduce problems
• Timeouts
– Clients may have timeouts for blocking for a response before re-
submitting the request
• Ignore duplicate requests
– If the server is still process
• Dealing with lost replies
– If the server completes processing and then recieves the same request
– Re-run process… but.. does repeating the process produce the same
result?
– Could store history of process results
– Different types of operations
• (idempotent operation = an operation that always has the same affect)
• histories
– Client block implies we need only store the most recent process for a
client, this can be stored in a history file
– Could have time limit on historical data

8
 Client Server Communication Group communication
• TCP streams for C/S messaging – Multicast
– Can be useful for client server message exchanges • Pair wise communication is not always the most efficient or
desired
– This method allows large amounts of data streams to • Multiple servers might provide similar services
be exchanged without the need for sending and • It might then be more efficient to request the service from
managing numerous datagram packets either server
• i.e. serialised objects are typically large
– Eliminates the need for histories, duplicate checking – Benefits of multicast
etc. as the transmission control protocol provides • Fault tolerance
these facilities • Discovery services
• Better performance through replication
• Useful for event notifications

Group communication Summary

• IP multicast • Inter-process communication
– Multicast address are specified in the D class – Characteristics of IPC
– Synchronous and asynchronous communication
• 224.0.0.0 to 239.255.255.255
– Clients send their message to a group IP addresses • External data representation and marshalling
(see above) – CORBA’s Common Data Representation
– Java Object serialisation
– Clients join IP groups and when they do receive all
messages sent to that group • Client-Server Communication
– Client-Server Communication
– Multicast routers can be used to forward multicasts to
– Communication within services provided by a group of servers:
other routers and or hosts
– Group Communication
– Note: is available via UDP for obvious reasons • IP multicast