CS 843 - Distributed Computing Systems Chapter 4: Interprocess Communication Chin-Chih Chang,...

CS 843 - Distributed Computing SystemsChapter 4: Interprocess Communication Chin-Chih Chang, [email protected]

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 3, © Addison-Wesley 2001

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

© Addison-Wesley Publishers 2000

Introduction

• The characteristics of protocols for communication between processes in a distributed system are discussed in this chapter as shown in Figure 4.1.

• The application program interface to UDP provides a message passing abstraction.

• The application program interface to TCP provides the abstraction of a two-way stream between pairs of processes.

• The Java UDP and TCP APIs are discussed in the second section.



Figure 4.1Middleware layers

Applications, services

Middlewarelayers

request-reply protocol

marshalling and external data representation

UDP and TCP

Thischapter

RMI and RPC



Introduction

• The third section is concerned with how the objects and data structures used in application programs can be translated into a form suitable for sending in messages over the network.

• Request-reply protocols are designed to support client-server communication in the form of either RMI or RPC. These are topics of the fourth section.

• Group multicast protocols are designed to support group communication. They are presented in fifth section.

• Interprocess communication in UNIX is a case study.



The Characteristics of Interprocess Communication

• Message passing between a pair of processes can be supported by two message communication operations: send and receive.

• In the synchronous form of communication, both send and receive are blocking operations.

• In the asynchronous form of communication, the send operation is non-blocking and the receive operation can be blocking and non-blocking.




• Non-blocking receive is more efficient but more complex. So current systems do not generally provide the non-blocking form of receive.

• In the Internet protocols, messages are sent to (Internet address, local port) pairs. Any process that knows the number of a port can send a message to it.



The Characteristics of Interprocess Communication• Using a fixed Internet address can be avoided by

one of the following approaches to provide location transparency: Client program refer to services by name. This allows

services to be relocated but not to migrate (be moved while running).

The operating system, for example, Mach, provides location-independent identifiers for message destinations.

• Messages can be addressed to processes in the V system. However, ports provide several alternative points of entry to a receiving process. Chorus provides the ability to send messages to groups of destination.




• A reliable communication ensures validity and integrity: For validity, a point-to-point message service can be

described as reliable if messages are guaranteed to be delivered.

For integrity, messages must arrive uncorrupted and without duplication.

• Some applications require that messages be delivered in send order.



Sockets

• A socket provides endpoints for communication between processes as shown in Figure 4.2.

• A socket must be bound to a local port.• A socket pair (local IP address, local port, foreign IP

address, foreign port) uniquely identifies a communication.

• Processes using IP multicast share ports.• Java provides a class, InetAddress, that represents

Internet Addresses. For example, InetAddress wsu =

InetAddress.getByName(“kirk.cs.twsu.edu”);



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



UDP Datagram Communication

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

• A server will bind its socket to a known server port. A client binds its socket to any free local port.

• The receive method returns the Internet address and port of the sender, in addition to the message.

• The receiving process needs to specify an array of bytes of a particular size in which to receive a message. The most size restriction is 8 kilobytes.




• Sockets normally provide non-blocking sends and blocking receives for datagram communication.

• The send operation returns once the message has been sent to the underlying UDP and IP protocols.

• The method receive blocks until a datagram is received, unless a timeout has been set on the socket.

• If the process that invokes the receive method has other work to do while waiting for the message, it should arrange to use a separate thread.




• In some programs, timeouts can be set on sockets. It should be large in comparison with the time required to transmit a message.

• It is possible to specify a specific Internet address and port for a socket to send and receive only from that address.

• UDP datagrams suffer from the following failures: Omission failures: Message may be dropped occasionally. Ordering: Messages can sometimes be delivered out of

sender order.




• A reliable delivery service may be constructed by the use of acknowledge.

• UDP can be used in applications which accept occasional omission failures. For example, DNS.

• UDP is preferred because they do not suffer from the overheads associated with guaranteed message delivery:1. the need to store state information at source and

destination2. the transmission of extra messages3. latency for the sender



Common Internet Applications that use UDP

• traceroute - print the route packets take to network host. Try /usr/sbin/traceroute www.microsoft.com.

• RIP (Routing Information Protocol) is a widely-used protocol for managing router information

• BOOTP (Bootstrap Protocol) is a protocol that lets a network user be automatically configured (receive an IP address) and have an operating system boot or initiated without user involvement. BOOTP is the basis for a more advanced network manager protocol, the Dynamic Host Configuration Protocol (DHCP).




• Dynamic Host Configuration Protocol (DHCP) is a communications protocol that lets network administrators manage centrally and automate the assignment of Internet Protocol (IP) addresses in an organization's network.)

• Network Time Protocol (NTP) is a protocol that is used to synchronize computer clock times in a network of computers.

• Trivial File Transfer Protocol (TFTP) is an Internet software utility for transferring files where user authentication and directory visibility are not required.



Common Internet Applications that use UDP• Simple Network Management Protocol (SNMP) is

the protocol governing network management and the monitoring of network devices and their functions.

• The domain name system (DNS) is the way that Internet domain names are located and translated into Internet Protocol addresses.

• The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update file on a remote computer as though they were on the user's own computer. UDP is used with the early version of NFS.




• Remote Procedure Call (RPC) is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details.

• There are several RPC models and implementations. A popular model and implementation is the Open Software Foundation's Distributed Computing Environment (DCE).

• Open Network Computing (ONC) RPC, sometimes referred to as Sun RPC, was one of the first commercial implementations of RPC.



UDP Protocol



Java API for UDP Datagrams

• The Java API provides datagram communication by means of two classes: DatagramPacket - Datagram packets are used to

implement a connectionless packet delivery service. DatagramSocket - A datagram socket is the sending or

receiving point for a packet delivery service.

• DatagramPacket: getData - Returns the data buffer. getPort - Returns the port number on the remote host. getAddress - Returns the IP address.



Java API for UDP Datagrams

• DatagramSocket: send - Sends a datagram packet from this socket. receive - Receives a datagram packet from this socket. setSoTimeout - Enable/disable the specified timeout, in

milliseconds. connect - Connects the socket to a remote address for

this socket.

• Figure 4.3 shows a client program. Figure 4.4 shows the program for the corresponding server.



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

}}



TCP Stream Communication

• The API to the TCP protocol, which originates from BSD 4.x UNIX, provides the abstraction of a stream of bytes.

• The following characteristics of the network are hidden by the stream abstraction: Message sizes – The application can choose how much

data it writes to a stream or reads from it. Lost messages – The TCP protocol uses an

acknowledge scheme. If the acknowledgement is not received within a timeout, it will be resent.



TCP Stream Communication

Flow control – The TCP protocol attempts to match the speeds of the sending and receiving process.

Message duplication and ordering – Messages identifiers are associated with each IP packet. It enables the recipient to detect and reject duplicates, or to reorder messages.

Message destinations – Once the connection between a pair of processes is established, the processes simply read from and write to the stream.



TCP Abstractions

• The data is the abstraction of a stream of bytes.• A connection is established before messages are

sent.• It assumes one process is the client and one is the

server in establishing a connection.• The client create a socket bound to any local port

and then makes a connect request for connecting the server at its server port.

• The server creates a listening socket bound to a server port and wait for (accept) the incoming requests.



TCP Abstractions

• Messages are sent using handles (sockets) rather than source-destination addresses.

• An application closes a socket once it is done with the transmission.

• The issues related to stream communication are: Matching of data items: Two communicating processes

need to agree on the contents of the transmitted data. Blocking: When a process tries to read data from an input

channel (stream), it will get the data or block until the data is available.

Thread: When a sever accepts a connection, it generally creates a new thread for the new client.



TCP Failure Model

• TCP uses three mechanism to create a reliable communication: Checksums and sequence numbers for integrity: TCP

streams use checksums to detect and reject corrupt packets and sequence numbers to detect and reject duplicate packets.

Timeouts and retransmission for validity: TCP streams use timeouts and retransmissions to deal with lost packets.

• The problem is if the network becomes congested, no acknowledge is received and then the connection is broken. Thus TCP does not provide reliable communication.



TCP Failure Model

• When a connection is broken, it will has the following effects: The processes using the connection cannot distinguish

between network failure and failure of the process. The communication process cannot tell whether their

recent messages have been received or not.

• The programmers need to deal with this situation in the program.



Common Internet applications that use TCP

• HTTP (HyperText Transfer Protocol) is used for communication between web browsers and web servers.

• FTP (file transfer) – File Transfer Protocl• Telnet provides access by means of a terminal

session to a remote computer.• SMTP (Simple Mail Transfer Protocol) is used send

mail between computers.• POP (Post Office Protocol) is a standard protocol for

receiving e-mail.



Common Internet applications that use TCP

• BGP (Border Gateway Protocol) is a protocol for exchanging routing information between gateway hosts (each with its own router) in a network of autonomous systems.

• The domain name system (DNS) is the way that Internet domain names are located and translated into Internet Protocol addresses.

• NNTP (Network News Transfer Protocol) is the predominant protocol used by computer clients and servers for managing the notes posted on Usenet newsgroups.



Common Internet Applications that use TCP

• The Network File System (NFS) is a client/server application that lets a computer user view and optionally store and update file on a remote computer as though they were on the user's own computer.

• Open Network Computing (ONC) RPC, sometimes referred to as Sun RPC, was one of the first commercial implementations of RPC.

• The Open Software Foundation's Distributed Computing Environment (DCE) is a popular model and implementation of RPC.



TCP Protocol



Java API for TCP Streams

• The Java API provides TCP streams by means of two classes: ServerSocket - This class implements server sockets. A

server socket waits for requests to come in over the network.

Socket - This class implements client sockets.

• ServerSocket: accept - Listens for a connection to be made to this

socket and accepts it. The result of executing accept is an instance of Socket.



Java API for TCP Streams

• Socket: Socket (InetAddress address, int port) - Creates a

stream socket and connects it to the specified port number at the specified IP address. It will throws UnknownHostException or an IOException.

getInputStream - Returns an input stream for this socket.

getOutputStream - Returns an output stream for this socket.

• Figure 4.5 shows a client program. Figure 4.6 shows the corresponding server program.

http://java.sun.com/j2se/1.4/docs/api/java/net/InetAddress.html



Figure 4.5 TCP client makes connection to server, sends request and receives reply

import 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 continued

class 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*/}}}

}



Protocol Usages by Common Internet Applications



External Data Representation and Marshalling

• Not all computers store primitive values such as integers in the same order. There are two variants: Big-endian – the most significant byte comes first Little-endian – the most significant byte comes last

• The set of codes used to represent characters: ASCII – one byte per character Unicode – two bytes per character to present texts in

different languages




• One of the following methods can be used to enable any two computers to exchange data values: The values are converted to a agreed external format. 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.

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




• Marshalling: It is the process of taking a collection of data items and

assembling them into a form suitable for transmission in a message.

It involves data translation to an external data representation.

• Unmarshalling: It is the process of disassembling them on arrival to

produce an equivalent data items at the destination. It involves generation of primitive values from their

external data representation.




• Two alternative approaches to external data representation and marshalling are discussed: CORBA’s (Common Object Request Broker Architecture

– a distributed computing environment) common data representation is used to pass arguments and results of remote method invocation.

Java’s object serialization is used to flatten objects that are transmitted in a message or stored on a disk. It is for use only by Java.

• Two approaches can be used to marshal the primitive data types: Binary form ASCII text – used by HTTP



Common Data Representation (CDR)

• CORBA CDR is the external data representation defined with CORBA 2.0 (OMG).

• CDR can represent all the data types that can be used as arguments and return values in remote invocations in CORBA.

• CORBA CDR data types: Primitive types: char, boolean, octet (1 byte), short,

unsigned short, wchar (2 byte), long, unsigned long, float (4 byte), long long, unsigned long long,double,long double (8 byte), any

Constructed types: sequence, string, array, struct, enumerated , union as shown in Figure 4.7

http://www.omg.org/



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 comp onentsenumerated unsigned long (the value s are spe cifie d by the order dec lar ed)uni on type ta g followed by the sel ecte d member




• Figure 4.8 shows a message in CORBA CDR: The representation of each string consists of an

unsigned long representing its length followed by the characters in the string.

Variable length data is padded with zeros. Each unsigned long occupying four bytes starts at an

index that is a multiple of four.

• Sun XDR (eXternal Data Representation) is another example of data exchange standard. It is developed by Sun for use in messages exchanged between clients and servers in Sun NFS.



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




• Marshalling in CORBA is generated automatically from the specification of the data to be transmitted. This standard data item can be specified in CORBA IDL (Interface Definition Language) as follows:

struct Person { string name; string place; long year; };

• The CORBA interface compiler generates appropriate marshalling and umarshalling operations for the arguments and results of remote method.



Java Object Serialization

• In Java RMI, both objects and primitive data values may be passed as arguments and results of method invocations. An object is an instance of a Java class.

• The Java class equivalent to the Person struct defined in CORBA IDL might be:

public class Person implements Serializable {

private String name; private String place; private int year; public Person (String n, String pl, int yr) { name = n; place = pl; year = yr; } // followed by methods for accessing the instance variables. }




• In Java, the term serialization refers to the activity of flattening an object or a connected set of objects into a serial form for storing or transmission.

• Deserialization consists of restoring the state of an object or a set of objects from their serialized form.

• The information about a class consists of the name of the class and a version number, which is changed when major changes are made to the class.

• Java objects can contain references to other objects. These referred objects are serialized with the referring object.




• References are serialized as handles. The serialization must ensure 1-1 correspondence between object references and handles.

• To serialize an object is done as follows: Its class name and version are written out, followed by its

instance variables. If the instance variables belong to new classes, their class

information are also written out. This recursive procedure continues until all necessary

classes have been written out.




• The contents of primitive types are written in a portable binary format using methods of the ObjectOutputStream class.

• Strings and characters are written by its writeUTF method using Universal Transfer Format (UTF): It enables ASCII characters to be represented unchanged

(in one byte). Unicode characters are represented by multiple bytes. Strings are preceded by the number of bytes they occupy

in the stream.




• The serialized form of Person p = new Person(“Smith”, “London”, 1934) is illustrated in Figure 4.9.

• To make use of Java serialization, for example to serialize the Person object, create an instance of the class ObjectOutputStream and invoke its writeObject method, passing the Person object as argument.

• To deserialize an object from a stream of data, open an ObjectInputStream on the stream and use its readObject method to rebuild the original object.



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 Reflection

• The Java language supports reflection – the ability to enquire about the properties of a class, such as the names and types of its instance variables and methods.

• Reflection makes it no need to generate special marshalling functions for each type of object.



Remote Object References

• A remote object reference is an identifier for a remote object that is valid throughout a distributed system.

• Remote object references must be unique and are not reused.

• A remote object can be constructed by concatenating the Internet address of its computer and port number of the process with the creation time and a local object number as shown in Figure 4.10.



Representation of a remote object reference

Internet address port number time object number interface of remote object

32 bits 32 bits 32 bits 32 bits

• a remote object reference must be unique in the distributed system and over time. It should not be reused after the object is deleted. Why not?

• the first two fields locate the object unless migration or re-activation in a new process can happen

• the fourth field identifies the object within the process• its interface tells the receiver what methods it has (e.g. class Method)• a remote object reference is created by a remote reference module

when a reference is passed as argument or result to another process it will be stored in the corresponding proxy it will be passed in request messages to identify the remote object

whose method is to be invoked

Figure 4.10

•



Client-Server Communication

• The request-reply communication is designed to support the roles and message exchange in client-server interactions.

• A request-reply protocol built over datagrams avoids unnecessary overheads associates with the TCP stream protocol: Acknowledgements are redundant, because requests are

followed by replies; Establishing a connection involves extra pairs of

message exchange; Flow control is redundant for the majority of invocations,

which pass only small arguments and results.



Client-Server Communication• Figure 4.11 shows a request-reply communication

based on three communication primitives : doOperation, getRequest, and sendReply.

• This protocol is used in most RMI and RPC system: The doOperation method is used by clients to invoke

remote operations. After sending the request message, doOperation invokes

receive to wait for a reply message. GetRequest is used by a server process to acquire

service requests . When the server has invoked the method in the specified

object, it then uses sendReply to send the reply to the client.



Figure 4.11Request-reply communication

Request

ServerClient

doOperation

(wait)

(continuation)

Replymessage

getRequest

execute

method

messageselect object

sendReply



Figure 4.12Operations 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.




• This protocol is used in most RMI and RPC system: (continued) When the reply is received by the client, the original

doOperation is unblocked.

• The information to be transmitted in a request message or a reply message is shown in Figure 4.13: messageType – 0 = Request, 1 = Reply requestID – message identifier objectReference – remote object reference methodID – the method to be invoked arguments – arguments to be transmitted.



Figure 4.13Request-reply message structure

messageType

requestId

objectReference

methodId

arguments

int (0=Request, 1= Reply)

int

RemoteObjectRef

int or Method

array of bytes




• A message identifier consists of two parts: A requestID, which is taken from an increasing sequence

of integers by the sending process (unique to the sender);

An identifier for the sender process, for example its port and IP address (unique in the distributed system).

• If the three primitives are implemented over UDP datagrams, they suffer from following failures: They suffer from omission failures; Messages are not guaranteed to be delivered in sender

order; They suffer from the failure of processes.




• Methods to prevent failures: Timeouts - doOperation sends the request repeatedly

until it gets a reply or it is sure that the delay is due to lack of the server response rather than lost messages.

Discarding duplicate request messages - The protocol is designed to recognize successive messages and filter out duplicates.

Lost reply messages – The server will re-execute the same operation if it receives a duplicate request. Then an idempotent operation that can be performed repeatedly with the same effect will be required..




• Methods to prevent failures (continued): History – For servers that require retransmission of

replies without re-execution of operations, a history may be used. A problem associated with the use of a history is its memory cost.

• Three RPC protocols are implemented in the presence of communication failures: The request (R) protocol; The request-reply (RR) protocol; The request-reply-acknowledge reply (RRA) protocol.

• The messages passed in these protocols are summarized in Figure 4.14.



Figure 4.14RPC exchange protocols

Name Messages sent byClient Server Client

R RequestRR Request Reply

RRA Request Reply Acknowledge reply




• The R protocol may be used when: There is no returned value. The client needs no confirmation from the server.

• The RR protocol is useful for most client-server exchange because it is based on the request-reply protocol.

• The PRA protocol is used to enable the server to discard entries from its history.




• The datagram is limited to 8 kilobytes and may not be adequate for use in RMI. The TCP can be used.

• The TCP protocol has the following advantages: It makes it possible to transmit objects of any size. There is no need to deal with retransmission. The flow control mechanism allows large arguments and

results.

• Thus, the TCP protocol is chose for implementing request-reply protocols.



HTTP: Request-Reply Protocol

• Web servers manage resources implemented in different ways: as data – text, image, applet as a program – cgi program, servlets

• The HTTP protocol allows: Method invocation Content negotiation – Client can specify the data

representation. Authentication – Credentials and challenges are used to

support password-style authentication.




• HTTP is implemented over TCP and has the following interactions: The client requests and server accepts a connection at

the default server port or at a port specified in the URL. A persistent connection is built.

The client sends a request to the server; The server sends a reply to the client; The connection can be closed by client or server.

• The HTTP protocol use ASCII text for the message exchange.




• Resources implemented as data are supplied as MIME-like structures.

• Multipurpose Internet Mail Extension (MIME) is a standard for send multipart data containing, text, images, and sound in e-mail messages. Data is prefixed with its Mime type so that the recipient

will know how to handle it. A Mime type specifies a type and a subtype, for example,

text/plain, text/html, image/gif, image/jpeg.




• The HTTP methods include: GET – requests the resource whose URL is given as

argument. o GET can be used to send the contents of a form to a

cgi program as an argument.o The GET operation can be made conditional on the

date a resource was last modified.o GET can also be configured to obtain parts of the data.

HEAD – the request is identical to GET, but it does not return any data.




• The HTTP methods include: (continued) POST – specifies the URL of resource that can deal with

the data supplied with the request. This method is designed to deal with:o Providing a block of data to a data-handling process

such as servlet or a cgi program;o Posting a message to a bulletin board, mailing list or

newsgroup;o Extending a database with an append operation.

PUT – requests that the data supplied in the request is stored with the given URL as identifier.




• The HTTP methods include: (continued) DELETE – the server deletes the resource identified by

the given URL. OPTIONS – the server supplies the client with a list of

methods it allows to be applied to the given URL and its special requirements.

TRACE – the server sends back the request message. Used for diagnostic purposes.

• The requests described above may be intercepted by a proxy server.




• Figure 4.15 shows the contents of an HTTP request message: The method is GET. URL specifies a data resource. The protocol version is HTTP 1.1. The header fields contain request modifiers and client

information. An authorization field can be used to provide the client’s

credentials.



Figure 4.15HTTP request message

GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1

URL or pathnamemethod HTTP version headers message body




• Figure 4.16 shows the contents of an HTTP reply message: The protocol version is HTTP 1.1. The status code reporting the transmission status is a

three-digital integer for interpretation by a program. The reason shows the transmission status understood by

a person. The header fields are used to pass additional information

about the server or concerning access to the resource. The message body contain the requested data in Mime

format.



Figure 4.16HTTP reply message

HTTP/1.1 200 OK resource data

HTTP version status code reason headers message body



Group Communication

• A multicast operation is an operation to send a single message from one process to a group of processes.

• This operation suits the service that is implemented as a number of different processes in different computers.

• Multicast messages provide a useful infrastructure for constructing distributed systems with the following characteristics:



Group Communication

• Multicast characteristics: (continued) Fault tolerance based on replicated services – Client

requests are multicast to a group of servers. Even when some members fail, clients can still be served.

Finding the discovery servers in spontaneous networking – Multicast messages can be used by servers and clients to locate discovery services.

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. For example, a news system and the Jini system.



IP Multicast

• IP multicast built on top of the Internet Protocol allows the sender to transmit a single IP packet to a set of computers.

• A multicast group is specified by a class D Internet address – an address whose first 4 bits are 1110 in IPv4 (Figure 3.15).

• The membership of multicast groups is dynamic.• At the application programming level, IP multicast

is available via UDP.• At the IP level, a computer belongs to a multicast

group when sockets belong to that group.



IP Multicast

• The following details are specific to IPv4: Multicast routers – IP packets can be multicast on a

local network and on the Internet.o Local multicasts use the multicast capability of the

local network such as an Ethernet.o Multicast in the Internet make use of multicast

routers. The distance of propagation is specified in the Time To Live or TTL.

Multicast address allocation – Multicast address can be permanent or temporary.



IP Multicast

Multicast address allocation (continued):o 224.0.0.1 to 244.0.0.255 are assigned to be

permanent multicast addresses.o A temporary multicast group requires a free multicast

address to avoid accidental participation in an existing group before use and cease after use.

o For local multicast, TTL can be set to a small value.o For multicast on the Internet, the session directory

(sd) program can be used. It allows people to browse advertised sessions and advertise their own sessions.

• Datagrams multicast over IP multicast suffer from omission failures. This is a unreliable multicast.



Java API to IP Multicast

• The Java API provides a datagram interface to IP multicast through the class MulticastSocket, which is a (UDP) DatagramSocket, with additional capabilities for joining groups of other multicast hosts on the internet. MulticastSocket - Create a multicast socket. joinGroup - Joins a multicast group. leaveGroup - Leave a multicast group. setTimeToLive - Set the default time-to-live for

multicast packets sent out on this MulticastSocket in order to control the scope of the multicasts.



Java API to IP Multicast

• A multicast peer program shown in Figure 4.17 specify the message and the multicast address in the arguments to the main method.

• An application implemented over IP multicast may use more that one port.

• For example, the MultiTalk [mbone] application, which allows groups of users to hold text-based conversations, has one port for sending and receiving data and another for exchanging control data.

http://www.merit.edu/~mbone/index/titles.html



Figure 4.17Multicast peer joins a group and sends and receives datagrams

import java.net.*;import java.io.*;public class MulticastPeer{

public static void main(String args[]){ // args give message contents & 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);

// this figure continued on the next slide



Figure 4.17continued

// get messages from others in group byte[] buffer = new byte[1000];

for(int i=0; i< 3; i++) { 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();}

} }



IP Multicast

• The following situations could occur: Omission failure – A recipient could drop a message

because its buffer is full. A datagram sent from on multicast router to another might be lost.

Process failure – If a multicast router fails, the group members beyond that router won’t receive the message.

Ordering issue – The packets could arrive in a different order.



IP Multicast

• Examples of the effects of reliability and ordering: Fault tolerance based on replicated services – In

replicated servers, multicast requires that either all or none should receive the request to perform an operation to remain consistent.

Finding the discovery servers in spontaneous networking – An occasional lost request is not an issue when locating a discovery server.

Better performance through replicated data – The effect of lost messages and inconsistent ordering depends on the method of replication.

Propagation of event notifications – The particular application determines the qualities required of multicast.



IP Multicast

• These examples suggest that some applications require a more reliable multicast. Reliable multicast – Any message transmitted is either

received by all members of a group or by none of them. Totally ordered multicast – All of the messages

transmitted to a group reach all of the members in the same order.



Interprocess Communication in UNIX• The IPC primitives in BSD 4.x UNIX are

implemented as a layer over the Internet TCP and UDP protocols.

• Message destinations are specified as socket addresses (Internet address + local port number), on which the interprocess communication operations are based.

• Before a pair of processes can communicate, the recipient must bind its socket descriptor to a socket address.

• The socket lasts until it is closed or until every process with the descriptor exits.



UNIX Datagram Communication

• The datagram communication is illustrated as in Figure 4.18.

• socket - create a socket and get a descriptor (file handle) for it. int socket(int domain, int type, int protocol) The domain parameter specifies a communication

domain. The socket has the indicated type, which specifies the

communication semantics. The protocol specifies a particular protocol to be used

with the socket. Zero causes the system to select the suitable protocol.



Figure 4.18Sockets used for datagrams

ServerAddress and ClientAddress are socket addresses

Sending a message Receiving a message

bind(s, ClientAddress)

sendto(s, "message", ServerAddress)

bind(s, ServerAddress)

amount = recvfrom(s, buffer, from)

s = socket(AF_INET, SOCK_DGRAM, 0)s = socket(AF_INET, SOCK_DGRAM, 0)




• bind – specify the local endpoint address for a socket. int bind(int sockfd, struct sockaddr *my_addr,

socklen_t addrlen); sockfd – a socket descriptor created by the socket call. my_addr – The address structure specifies an IP

address and protocol port number. addrlen – The size of the address structure in bytes.

• send, sendto, sendmsg - send a message from a socket.




• recv, recvfrom, recvmsg - receive a message from a socket

• close - close a file descriptor• UDP is not able to transfer a message more than

8KB.



UNIX Stream Communication

• In order to use the stream protocol, two processes must first establish a connection between their pair of sockets.

• For communication between clients and servers, clients request connections and a listening server accepts them.

• A connected pair of stream sockets can be used until the connection is closed.

• The stream communication is illustrated in Figure 4.19.



Figure 4.19Sockets used for streams

Requesting a connection Listening and accepting a connection

bind(s, ServerAddress);listen(s,5);

sNew = accept(s, ClientAddress);

n = read(sNew, buffer, amount)

s = socket(AF_INET, SOCK_STREAM,0)

connect(s, ServerAddress)

write(s, "message", length)

s = socket(AF_INET, SOCK_STREAM,0)

ServerAddress and ClientAddress are socket addresses




• Normally, a server would first listen and accept a connection and then fork a new process to communicate with the client.

• The server or listening process first uses the socket operation to create a stream socket and the bind operation to bind its socket to the server’s socket address.

• It uses the listen operation to listen for connections on a socket. int listen (int sockfd, int backlog) : The backlog

parameter defines the maximum length the queue of pending connections may grow to.




• The server uses the accept system call to accept connection requested by a client.

• After a connection has been established, both processes may then use the write (send) and read (recv) operations to send and receive messages.



Example - Programming Client

Initialization:• gethostbyname - look up server • socket - create socket • connect - connect to server port

Transmission: • send – send message to server• recv - receive message from server

Termination: • close - close socket



Example - Programming Server

Initialization:• socket - create socket • bind – bind socket to the local address• listen - associate socket with incoming requests Loop: • accept - accept incoming connection • recv - receive message from client• send - send message to clientTermination: • close - close connection socket

CS 843 - Distributed Computing Systems Chapter 4: Interprocess Communication Chin-Chih Chang,...

Documents

Transcript of CS 843 - Distributed Computing Systems Chapter 4: Interprocess Communication Chin-Chih Chang,...