• The information stored in running programs is represented as data structures, whereas the information in messages consists of sequences of bytes.

​

• Irrespective of the form of communication used, the data structure must be converted to a sequence of bytes before transmission and rebuilt on arrival.

• External Data Representation is an agreed standard for the representation of data structures and primitive values.

​

• Data representation problems are:
• Using agreed external representation, two conversions necessary
• Using sender’s or receiver’s format and convert at the other end

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

• Three approaches to external data representation and marshalling are:
• CORBA
• Java’s object serialization
• XML

• Marshalling and unmarshalling activities is usually performed automatically by middleware layer.
• Marshalling is likely error-prone if carried out by hand.

• 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.

​

​

• 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.

• 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.

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

​

• 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

}

The serialized form is illustrated in Figure 10.

• 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.

• 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.

• 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)

• 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.

• 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

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

• The request-reply protocol is shown in Figure 12.

• 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.

​

• The information to be transmitted in a request message or a reply message is shown in Figure 14.

• 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.

• 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.

• 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.

• 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)

​

​

​

​

​

​

​

• 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.

• 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.

• 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

• 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.

• A Mime type specifies a type and a subtype, for example:
• text/plain
• text/html
• image/gif
• image/jpeg

• 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.

• HEAD
• This method is similar to GET, but only meta data on resource is returned (like date of last modification, type, and size)

• 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

• 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

• TRACE
• The server sends back the request message

• A reply message specifies
• The protocol version
• A status code
• Reason
• Some headers
• An optional message body

• 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.

• 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.

• 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.

• 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.

​

• 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.

• 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.

• 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.

• 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.

• 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)

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();}

}

}

• 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.