2. CS 843 - Distributed Computing Systems Chapter 4: Interprocess Communication Chin-Chih Chang, chang@cs.twsu.edu From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

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

4. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.1 Middleware layers

5. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

6. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

7. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The Characteristics of Interprocess Communication 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.

8. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

9. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The Characteristics of Interprocess Communication 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.

10. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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”);

11. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.2 Sockets and ports message agreed port any port socket Internet address = 138.37.88.249Internet address = 138.37.94.248 other ports client server

12. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

13. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UDP Datagram Communication 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.

14. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UDP Datagram Communication 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.

15. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UDP Datagram Communication 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 destination 2.the transmission of extra messages 3.latency for the sender

16. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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).

17. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Common Internet Applications that use UDP 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.

18. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

19. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Common Internet Applications that use UDP 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.

20. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UDP Protocol

21. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

22. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

23. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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();} }

24. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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();} }

25. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

26. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

27. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

28. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

29. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

30. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

31. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

32. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

33. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

34. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 TCP Protocol

35. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

36. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.InetAddress  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.

37. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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());}} }

38. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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

39. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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*/}} }

40. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Protocol Usages by Common Internet Applications

41. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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

42. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 External Data Representation and Marshalling 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.

43. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 External Data Representation and Marshalling 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.

44. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 External Data Representation and Marshalling 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

45. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Common Data Representation (CDR) CORBA CDR is the external data representation defined with CORBA 2.0 (OMG).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

46. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.7 CORBA CDR for constructed types

47. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Common Data Representation (CDR) 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.

48. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.8 CORBA CDR message The flattened form represents aPerson struct with value: {‘Smith’, ‘London’, 1934} 0–3 4–7 8–11 12–15 16–19 20-23 24–27 5 "Smit" "h___" 6 "Lond" "on__" 1934 index in sequence of bytes4 bytes notes on representation length of string ‘Smith’ length of string ‘London’ unsigned long

49. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Common Data Representation (CDR) 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.

50. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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. }

51. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Java Object Serialization 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.

52. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Java Object Serialization 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.

53. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Java Object Serialization 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.

54. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Java Object Serialization 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.

55. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.9 Indication 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.String name: 6 London h0 java.lang.String place: h1 Explanation class name, version number number, type and name of instance variables values of instance variables

56. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

57. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

58. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Representation of a remote object reference Internet addressport numbertimeobject number interface of remote object 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

59. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

60. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

61. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.11 Request-reply communication Request ServerClient doOperation (wait) (continuation) Reply message getRequest execute method message select object sendReply

62. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.12 Operations 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.

63. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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.

64. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.13 Request-reply message structure messageType requestId objectReference methodId arguments int (0=Request, 1= Reply) int RemoteObjectRef int or Method array of bytes

65. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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.

66. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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..

67. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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.

68. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.14 RPC exchange protocols Name Messagessent by Client ServerClient R Request RR Request Reply RRA Request Reply Acknowledge reply

69. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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.

70. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Client-Server Communication 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.

71. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

72. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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.

73. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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.

74. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol The HTTP methods include:  GET – requests the resource whose URL is given as argument. oGET can be used to send the contents of a form to a cgi program as an argument. oThe GET operation can be made conditional on the date a resource was last modified. oGET can also be configured to obtain parts of the data.  HEAD – the request is identical to GET, but it does not return any data.

75. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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: oProviding a block of data to a data-handling process such as servlet or a cgi program; oPosting a message to a bulletin board, mailing list or newsgroup; oExtending a database with an append operation.  PUT – requests that the data supplied in the request is stored with the given URL as identifier.

76. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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.

77. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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.

78. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.15 HTTP request message GET//www.dcs.qmw.ac.uk/index.htmlHTTP/ 1.1 URL or pathnamemethodHTTP versionheadersmessage body

79. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 HTTP: Request-Reply Protocol 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.

80. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.16 HTTP reply message HTTP/1.1200OK resource data HTTP versionstatus codereasonheadersmessage body

81. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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:

82. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

83. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

84. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 IP Multicast The following details are specific to IPv4:  Multicast routers – IP packets can be multicast on a local network and on the Internet. oLocal multicasts use the multicast capability of the local network such as an Ethernet. oMulticast 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.

85. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 IP Multicast  Multicast address allocation (continued): o224.0.0.1 to 244.0.0.255 are assigned to be permanent multicast addresses. oA temporary multicast group requires a free multicast address to avoid accidental participation in an existing group before use and cease after use. oFor local multicast, TTL can be set to a small value. oFor 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.

86. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

87. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.mbone

88. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.17 Multicast 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

89. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.17 continued // 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();} }

90. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

91. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

92. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

93. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

94. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

95. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.18 Sockets used for datagrams ServerAddress and ClientAddress are socket addresses Sending a messageReceiving a message bind(s, ClientAddress) sendto(s, "message", ServerAddress) bind(s, ServerAddress) amount = recvfrom(s, buffer, from) s = socket(AF_INET, SOCK_DGRAM, 0)

96. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UNIX Datagram Communication 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.

97. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UNIX Datagram Communication 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.

98. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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.

99. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 4.19 Sockets used for streams Requesting a connectionListening 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

100. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UNIX Stream Communication 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.

101. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 UNIX Stream Communication 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.

102. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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

103. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 client Termination: close - close connection socket