Slides for Chapter 4: Interprocess Communication From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 4, © Addison-Wesley 2005
IS473 Distributed Systems CHAPTER 4 Interprocess Communication (IPC)
OUTLINE Applications, services Remote Method Invocation (RMI) Remote Procedure Calling (RPC) request-reply protocol Middleware This layers chapter marshalling and external data representation UDP and TCP IS473 - Chapter (4) Dr. Almetwally Mostafa
OUTLINE Interprocess Communication Characteristics. API for Internet Protocols (UDP, TCP). External Data Representation and Marshalling. Client-Server Communication. Group Communication Unix Case Study. IS473 - Chapter (4) Dr. Almetwally Mostafa
Characteristics of IPC Massage passing between a pair of processes supported by two communication operations: Send and Receive. A queue is associated with each message destination regarded as a buffer between the sender and receiver: When the buffer is empty the receiver must wait. When the buffer is full the sender must wait, or messages will be lost. Communication is termed as synchronous or asynchronous depending on the degree of coordination imposed between sender and receiver: Synchronous: both send and receive are blocking operations: Sender blocks until a receive is issued Receiver blocks until a message arrives. Asynchronous: send operation is non-blocking Sender is non-blocking (copy goes to its local buffer) Receiver blocking (ALWAYS) or non-blocking (out of control flow). IS473 - Chapter (4) Dr. Almetwally Mostafa
Ports and Sockets Communication between processes is made between ports. Each computer has 216 possible ports represented by integer numbers: some ports have specific use but others are available for general use. Each port corresponds to a single receiving process, but each process may have more than one port at which it receives. Any number of senders can send messages to a port. Sockets are software abstractions of ports used within running processes. Messages are sent between a pair of sockets. Sockets need to be bound to a port number and a host IP address in order to be useable for sending and receiving messages. Socket binding may be automatic (Java) or done explicitly (BSD UNIX). Each socket is associated with a particular transport protocol, i.e. UDP (datagrams) or TCP (streams). IS473 - Chapter (4) Dr. Almetwally Mostafa
Ports and Sockets agreed port any port socket socket message client server other ports IP address = 138.37.94.248 IP address = 138.37.88.249 IS473 - Chapter (4) Dr. Almetwally Mostafa
Characteristics of IPC mechanisms Ports do more than identify a process • Single process can use more than one port •Can maintain multiple connections / listen for communication on separate ports Sockets are a software abstraction which provide a communication endpoint for processes • Combination of – Host ID (e.g. IP address) – Port number • (Typically) implement – Non-blocking send – Blocking receive IS473 - Chapter (4) Dr. Almetwally Mostafa
IPC Communication using UDP To send or receive using UDP, a process must – Create a socket, bound to a port on the localhost • Clients can then issue a send, identifying the IP address and port number to which the destination socket is bound • Datagrams are received at a socket without consideration of the source – any client socket can send to any other socket IS473 - Chapter (4) Dr. Almetwally Mostafa
UDP Datagram Size IP puts a limit of 64kbytes on packets • UDP datagram must fit into this size, taking into consideration the addition of IP headers • Typical applications use limit of 8kbytes IS473 - Chapter (4) Dr. Almetwally Mostafa
UDP Failure Model Omission Failures – Datagrams can be dropped because of -Full Buffers -Checksum Failure -Either send-omission, receive omission • Ordering – Messages can arrive out of order • Underlying IP routes packets independently IS473 - Chapter (4) Dr. Almetwally Mostafa
UDP Applications Where failures are tolerable – DNS – VOIP • Where overheads are costly – E.g. where the requirement to store state information at sender or receiver, or the requirement to retransmit messages introduces costly latency in the application IS473 - Chapter (4) Dr. Almetwally Mostafa
Java API for Internet Addresses The java.net package is intended to provide an application programmer with a powerful infrastructure for networking: Java provides three basic socket classes: DatagramSocket for datagram communication and Both of ServerSocket and Socket for stream communication. Java includes classes for representing URLs (the URL class) and Internet addresses (the InetAddress class). More explicit networking can be considered using the socket classes, which makes use of the InetAddress class. InetAddress class has no public constructor but has getByName() method that take a DNS name and make use of the DNS server. InetAddress aComputer = InetAddress.getByName(“wassif.ccis.ksu.edu.sa"); InetAddress class is designed to handle both IPv4 (4 bytes) and IPv6 (16 bytes) addresses. IS473 - Chapter (4) Dr. Almetwally Mostafa
UDP Datagram Communication A datagram is communicated between processes when one process sends it and the other receives it. Datagrams sent from socket to socket without acknowledgement or reliability. UDP applications provide their own checks to achieve the required quality of reliable communication. A server binds its socket to a specific server port known to clients but a client binds its socket to any free port. Sender socket information is passed with the datagram content so that a reply can be sent. The receiver must specify a buffer of a particular size (8 KBytes in most implementations) to place received message. Message will be truncated if the buffer size is not enough. Longer messages must fragmented into chunks to match buffer sizes. IS473 - Chapter (4) Dr. Almetwally Mostafa
UDP Datagram Communication Datagram communication provides non-blocking sends and blocking receives although timeouts can be set. Timeouts can be set on receiver socket to forbid indefinitely waiting in case of crashed sender or lost message. Choosing an appropriate timeout interval is difficult. The receive method does not specify who the message should be received from: It will retrieve any message which has arrived at its socket from any sender. However, it is possible to bind a socket so that it only sends to or receives messages from a particular remote port. UDP is suitable for applications that need low overheads and accepting occasional omission failures (as DNS service). IS473 - Chapter (4) Dr. Almetwally Mostafa
Java API for UDP Datagrams Java API provides datagram communication by two classes: DatagramPacket: Has a constructor to create datagram packets comprising a message, its length, and destination socket information Has another constructor to put a received message into that packet. The message can be retrieved using getData method and the Internet address and the port are accessed by getAddress and getPort methods. Array of bytes containing message-length of message-internet address-port number DatagramSocket: Supports sockets for sending and receiving UDP datagrams. Has a constructor with a port number as argument to tie that port, if a particular port is needed, or without argument to use any free local port. send and receive methods are used for transmitting datagrames between a pair of sockets. The method setSoTimeout allows a timeouts to be set and connect method is used for connecting a socket to a particular remote port and host address. IS473 - Chapter (4) Dr. Almetwally Mostafa
Figure 4.3 UDP 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 hostname DatagramSocket 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.4 UDP 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 An abstraction provided by TCP API as a stream of bytes to which data may be written and from which data may be read. Stream abstraction offers the following characteristics: No restriction about message sizes: Applications can choose how much data written to or read from a stream. Guarantee message delivery using acknowledgment scheme: The sender retransmits the message if it does not receive an acknowledgment within a timeout. Attempt to match the speeds of reader and writer processes: The writer may be blocked until the reader has consumed sufficient data. Guarantee unduplication and ordering of messages: Message identifiers enable the receiver to detect and reject duplicates or to reorder messages not arrived in sender order. IS473 - Chapter (4) Dr. Almetwally Mostafa
TCP Stream Communication A pair of communicating processes establish a connection before they can communicate over a stream: One of the two processes plays the client role and the other plays the server role. The client role involves: Creating a stream socket bound to any free port. Making a connect request to a server at its server port. The server role involves: Creating a listening socket bound to a server port and waiting for clients to request connections. Making accept request to reply a client request at its port. Creating a new stream socket to communicate with this client. Keeping the listening socket for new connecting requests. Once the connection is established the processes write to and read from the stream without needing to use Internet addresses and ports. IS473 - Chapter (4) Dr. Almetwally Mostafa
TCP Stream Communication The pair of sockets in client and server are connected by input and output streams, one for each direction. The connection is broken when any of its sockets is closed: Sockets may be closed by a close request from either of the connected processes or when any of them is failed or exited. A process using a broken connect will be notified when attempting to read from or write to its stream. Many frequently used services run over TCP connections with reserved port numbers: HTTP is used for communication between web browsers and web servers. FTP allows browsing of remote computer directories and transfer files from one computer to another over a connection. SMTP is used to send mail between computers. IS473 - Chapter (4) Dr. Almetwally Mostafa
TCP Failure Model Timeout and retransmission – Sliding window protocol • Connections can break down – No guarantee that connection will not break, so not fully reliable • Limitations – Processes cannot distinguish between network failure and receiving process failure – Processes cannot be certain whether packets sent were received IS473 - Chapter (4) Dr. Almetwally Mostafa
Java API for TCP Streams Java API provides stream communication by two classes: ServerSocket: Intended for use by a server to create a socket at a server port for listening connect request from clients. Has an accept method that is blocked until arriving of any request to create an instance of stream socket. Socket: Used by a pair of processes with a stream connection. Has a constructor used by the client to create its stream socket and send a connect request to the specified remote server. Provides getInputStream and getOutputStream methods for accessing the two input and output streams associated with a socket. read and write methods are used for bytes reading from and writing to InputStream and OutputStream respectively. IS473 - Chapter (4) Dr. Almetwally Mostafa
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 destination Socket 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.3 String 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*/}}
4-3 External Data Representation Representation problems: Data structures must be flattened, converted to a sequence of bytes, before transmission and rebuilt on arrival. Not all computers store primitive data values in the same order. Solution methods: Values are converted to an agreed external format, external data representation, before transmission and reconverted to the local form on receipt. Values are transmitted in the sender’s format with an indication of the used format and the receipt converts the values to its format (if necessary). Marshalling is the process of assembling a collection of data items in a form suitable for transmission and unmarshalling is the reverse process of disassembling them on arrival. IS473 - Chapter (4) Dr. Almetwally Mostafa
External Data Representation Two alternative approaches to external data representation and marshalling are: CORBA’s common data representation (CDR): Concerned with an external representation for the structured and primitives types. Can be used by a variety of programming languages. Java’s object serialization: Concerned with the flattening and external data representation of any single object or tree of objects. Used only by Java. In both cases, marshalling and unmarshalling activities should be carried out by a middleware layer. The common marshaling approach is to convert the primitive types into a binary form but the conversion into ASCII text (e.g. HTTP protocol) is an alternative. IS473 - Chapter (4) Dr. Almetwally Mostafa
CORBA’s CDR CDR can represent all data types used as arguments or return values during remote invocation of CORBA objects. 15 primitive types and a range of composite types are represented by a sequence of bytes in the invocation or result message. Marshaling and unmarshalling operations are generated automatically from the specification of data items transmitted in a message. The type definitions of data structures and primitive data items are described in CORBA Interface Definition Language (IDL). CORBA interface compiler generates appropriate marshaling and unmarshalling operations from the type definitions of remote methods arguments and results IS473 - Chapter (4) Dr. Almetwally Mostafa
Java Object Serialization Serialization and deserialization in Java: Serialization is the activity of flattening object or a related set of objects in a serial form suitable for transmitting in a message. Deserialization is the activity of restoring the state of an object or a set of objects from their serialized form. All objects referenced on an object are serialized as handles when that object is serialized. Serialization of a specific object is done by creating an instance of the class ObjectOutputStream and invoking its writeObject method with the object name as rgument. ObjectInputStream class is opened on a stream of data to deserialize an object from that stream using the readObject method. Making generic serialization and deserialization is possible using reflection rather than to generate special marshalling functions for each type of object (as in CORBA). IS473 - Chapter (4) Dr. Almetwally Mostafa
Remote Object References Needed when a client invokes a method of an object located on a remote server. Must be generated in a manner that ensure uniqueness over space and time. Unique among all of the processes in the various computers in a distributed system. References of deleted remote objects are not reused to avoid accessing different objects. Constructed by connecting the IP address of its computer and the port number of the process created it with the time of its creation and a local object number. Internet address port number time object number interface of remote object 32 bits IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Request-reply protocols are designed to support client-server communication with the following characteristics: Synchronous in normal cases because the client process blocks until the reply arrives from the server. Reliable and grantee of message delivery. Acknowledgments are not required since requests are followed by replies. Flow control is not needed due to small amounts of data transferred Connection establishment involves only two extra pair of messages. Usually implemented over UDP datagrames but can also applied over TCP streams. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Request Server Client doOperation (wait) (continuation) Reply message getRequest execute method select object sendReply Request-reply communication IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Request-reply protocol is based on a triple of communication primitives: doOperation: Used by clients to send a request message for invoking remote operations. Its arguments specify the remote object reference, the method to be invoked and the arguments of that method. Its result is a remote method reply. getRequest: Used by a server process to acquire service request messages. sendReply: Used by a server process to send the reply messages to clients Its arguments are the reply, and IP address and port of designated client. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication The structure of a request or a reply message as follow: Message type: indicate whether the message is a request or a reply. Message ID: contain a request message identifier generated by the client and the server refer to it into the corresponding reply message to enable the client to check that the reply is the result of the current request. Object reference: the reference of remote object. Method ID: the identifier for the method to be invoked. Arguments of the invoked method Each message identifier must be unique in the distributed system and include two parts: A request ID taken from an increasing sequence by the client process to make the identifier unique to the client. An identifier of the client process (IP address + port number). IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Failure Recovery Request-reply protocol can suffer from the following failures: Omission failures: Use timeout and resend request when timeout expires and reply hasn’t arrived Server receives repeated request Idempotent (unchangable) operations: same result obtained on every invocation. Non-idempotent operations: re-send result stored from previous request, requires maintenance of a history of replies. Loss of replies: request - reply - acknowledge reply (RRA) protocol Message duplication: return request ID with reply. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Over TCP Streams Used if successive requests and replies between the same client-server pair are sent over the same stream. Reasons: Avoid implementing multi-packet protocols. Reduce the connection overhead to every remote invocation. Allow transmit remote methods arguments and results of any size. Ensure reliable delivery of request and reply messages. Avoid the need to deal with messages retransmission, duplicates filtering, and histories. Provide flow-control mechanism that allows large arguments and results to be passed without special measures. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Hypertext Transfer Protocol (HTTP) A lightweight request-reply protocol for the exchange of network resources between web browser clients and web servers in the following steps: Connection establishment between client and server (likely TCP, but any reliable transport protocol is acceptable) Client sends request Server sends reply Connection closure The need to establish and close a connection for every request-reply exchange is inefficient scheme, therefore HTTP 1.1 allows persistent transport connections (remains open for successive request/reply pairs) Resources are supplied as MIME-like structures (e.g. text/plain, text/html, image/gif and image/jpeg). Requests and replies are marshalled into ASCII text strings. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Hypertext Transfer Protocol (HTTP) Each client request specifies the URL of a server resource and a method name applied to it. The methods include the following: GET: request of resource, identified by URL, may refer to data: server returns identified data. program: server runs program and returns output data. HEAD: request similar like GET, but only meta data on resource is returned (like date of last modification). POST: specifies resource (for instance, a server program) that can deal with the client data provided with previous request. PUT: supplied data to be stored in the given URL. DELETE: delete an identified resource on server. OPTIONS: request a list of methods can be applied to the given URL. IS473 - Chapter (4) Dr. Almetwally Mostafa
Client-server Communication Hypertext Transfer Protocol (HTTP) A request message specifies the method name, the URL of resource, the protocol version, some headers and an optional message body (not needed in case of data resource). A reply message specifies the protocol version, a status code and reason, some header and an optional message body. The status code and reason provide an report on the success otherwise in carrying out the request. method URL or pathname HTTP version headers message body GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1 HTTP version status code reason headers message body HTTP/1.1 200 OK resource data IS473 - Chapter (4) Dr. Almetwally Mostafa
Group Communication Multicasting: operation to send a single message from one process to each of the members of a predefined group of processes transparently. Provide a useful infrastructure for constructing distributed systems with the following characteristics: Replicated services: client requests are multicast to a group of servers, each of them performs an identical operation. Clients can still be served when some of the group members fail. Finding services and their interfaces. Better performance: data are replicated to increase the performance of a service. Propagation of event notification: multicast to notify processes when something happens (e.g. newsgroups). IS473 - Chapter (4) Dr. Almetwally Mostafa
Group Communication IP multicast is built on top of IP protocol, and is designed for communication between groups of hosts (not ports at this level of the protocol stack). A specific class of IP addresses (class D) is reserved for multicast groups, on a temporary or a permanent basis. IP multicast is available only via UDP protocol: Datagrams are sent to a multicast IP address and ordinary port numbers. When a multicast message arrives at a host, copies are forwarded to all the local sockets that have joined the specified multicast address and are bound to the specified port number. Java API provides a datagram interface to IP multicast through the subclass MulticastSocket of the class DatagramSocket with the additional capabilities of being able to join multicast groups. IS473 - Chapter (4) Dr. Almetwally Mostafa