1. 20 februari 2006 Client-Server and Multicast Communication 1 René de Vries Based on slides by M.L. Liu and M. van Eekelen

2. 20 februari 2006Client-Server and Multicast Communication2 Overview Client Server Communication Chapter 5: Liu Introduction – Reviewing, usage and definitions Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References

3. 20 februari 2006Client-Server and Multicast Communication3 Introduction The Client-Server paradigm is the most prevalent model for distributed computing protocols. It is the basis of all distributed computing paradigms at a higher level of abstraction. It is service-oriented, and employs a request-response protocol.

4. 20 februari 2006Client-Server and Multicast Communication4 The Client-Server Paradigm A server process, running on a server host, provides access to a service. A client process, running on a client host, accesses the service via the server process. The interaction of the process proceeds according to a protocol.

5. 20 februari 2006Client-Server and Multicast Communication5 Client-server, an overloaded term

6. 20 februari 2006Client-Server and Multicast Communication6 Client-server applications and services An application based on the client-server paradigm is a client-server application. On the Internet, many services are Client-server applications. These services are often known by the protocol that the application implements. Well known client-server Internet services include HTTP, FTP, DNS, finger, etc. User applications may also be built using the client- server paradigm.

7. 20 februari 2006Client-Server and Multicast Communication7 Place in the Internet Protocol Stack

8. 20 februari 2006Client-Server and Multicast Communication8

9. 20 februari 2006Client-Server and Multicast Communication9 A service session A Session is an interaction between the server and one client.

10. 20 februari 2006Client-Server and Multicast Communication10 The interprocess communications and event synchronization Typically, the interaction of the client and server processes follows a request- response pattern.

11. 20 februari 2006Client-Server and Multicast Communication11 Session IPC examples The dialog in each session follows a pattern prescribed in the protocol specified for the service. Daytime service [RFC867]: Client: Hello, here. May I have a timestamp please. Server: Here it is: (time stamp follows) World Wide Web session: Client: Hello, here. Server: Okay. I am a web server and I speak protocol HTTP1.0. Client: Great, please get me the web page index.html at the root of your document tree. Server: Okay, here’s what’s in the page: (contents follows).

12. 20 februari 2006Client-Server and Multicast Communication12 The Protocol for a Network Service A protocol is needed to specify the rules that must be observed by the client and the server during the conducting of a service. i. how the service is to be located ii. the sequence of interprocess communication (dynamics) iii. the representation and interpretation of data exchanged with each IPC (signature) On the Internet, such protocols are specified in the RFC-series. The Request For Comments (RFC) document series is a set of technical and organizational notes about the Internet (originally the ARPANET), beginning in 1969. Memos in the RFC series discuss many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes and opinions.

13. 20 februari 2006Client-Server and Multicast Communication13 Locating the service A mechanism must be available to allow a client process to locate a server for a given service. A service can be located through the address of the server process, in terms of the host name and protocol port number assigned to the server process. This is the scheme for Internet services. Each Internet service is assigned to a specific port number. In particular, a well-known service such as ftp, HTTP, or telnet is assigned a default port number reserved on each Internet host for that service. At a higher level of abstraction, a service may be identified using a logical name registered with a registry, the logical name will need to be mapped to the physical location of the server process. If the mapping is performed at runtime (that is, when a client process is run), then it is possible for the service’s location to be dynamic, or moveable.

14. 20 februari 2006Client-Server and Multicast Communication14 Overview Client Server Communication Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summery References

15. 20 februari 2006Client-Server and Multicast Communication15 Connectionless Server A connectionless server accepts one request at a time from any client, processes the request, and sends the response to the requestor.

16. 20 februari 2006Client-Server and Multicast Communication16 Software Engineering for a Network Service

17. 20 februari 2006Client-Server and Multicast Communication17 Example protocol: daytime Defined in RFC867RFC867

18. 20 februari 2006Client-Server and Multicast Communication18 Daytime Protocol

19. 20 februari 2006Client-Server and Multicast Communication19 Daytime Protocol Implementation Sample 1 – using connectionless sockets: DaytimeServer1.java DaytimeClient1.java

20. 20 februari 2006Client-Server and Multicast Communication20 The getAddress and getPort Methods

21. 20 februari 2006Client-Server and Multicast Communication21 Connectionless Echo Server (advanced) DatagramSocket ds = new DatagramSocket(port); while (true) { try { // create a new datagram packet byte[] buffer = new byte[MAXLEN]; DatagramPacket dp = new DatagramPacket(buffer, MAXLEN); ds.receive(dp); len = dp.getLength(); cAddr = dp.getAddress(); cPort = dp.getPort(); String s = new String(dp.getData(), 0, len); System.out.println(dp.getAddress() + " at port " + dp.getPort() + " says " + s); // create a datagram packet to send to client DatagramPacket theEcho = new DatagramPacket(buffer,len, cAddr, cPort); ds.send(theEcho); } // end try … } // end while

22. 20 februari 2006Client-Server and Multicast Communication22 Concurrent client sessions with EchoServer1

23. 20 februari 2006Client-Server and Multicast Communication23 Overview Client Server Communication Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References

24. 20 februari 2006Client-Server and Multicast Communication24 Connectionless vs. connection-oriented server A connectionless server – Uses a connectionless IPC API (e.g., connectionless datagram socket) – Sessions with concurrent clients can be interleaved. A connection-oriented server – Uses a connection-oriented IPC API (e.g. stream-mode socket ) – Sessions with concurrent clients can only be sequential unless the server is threaded

25. 20 februari 2006Client-Server and Multicast Communication25 Connection-Oriented Client-Server applications In a connection-oriented client-server application: – The server is passive: it listens and waits for connection requests from clients, and accepts one connection at a time. – A client issues a connection request, and waits for its connection to be accepted. – Once a server accepts a connection, it waits for a request from the client. – When a client is connected to the server, it issues a request and waits for the response. – When a server receives a request, it processes the request and sends a response, then wait for the next request, if any. – The client receives the response and processes it. If there are further requests, the process repeats itself.

26. 20 februari 2006Client-Server and Multicast Communication26 The Basic Connection-Oriented Client-Server Model

27. 20 februari 2006Client-Server and Multicast Communication27 EchoServer2 (Connection-oriented) excerpt ServerSocket myConnectionSocket = new ServerSocket(serverPort); while (true) { // forever loop MyStreamSocket myDataSocket = new MyStreamSocket (myConnectionSocket.accept( )); boolean done = false; while (!done) { message = myDataSocket.receiveMessage( ); if ((message.trim()).equals (endMessage)){ myDataSocket.close( ); done = true; } //end if else { myDataSocket.sendMessage(message); } //end else } //end while !done } //end while forever

28. 20 februari 2006Client-Server and Multicast Communication28 Two consecutive client sessions with echo server2

29. 20 februari 2006Client-Server and Multicast Communication29 Overview Client Server Communication Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References

30. 20 februari 2006Client-Server and Multicast Communication30 Concurrent, Connection-Oriented Server A connection-oriented server services one client at a time. If the duration of each client session is significant, then the latency or turnaround time of a client request becomes unacceptable if the number of concurrent client processes is large. To improve the latency, a server process spawns a child process or child thread to process the protocol for each client. Such a server is termed a concurrent server, compared to an iterative server.

31. 20 februari 2006Client-Server and Multicast Communication31 Concurrent, connection-oriented server - 2 A concurrent server uses its main thread to accept connections, and spawns a child thread to process the protocol for each client. Clients queue for connection, then are served concurrently. The concurrency reduces latency significantly.

32. 20 februari 2006Client-Server and Multicast Communication32 Connection-oriented server: latency analysis For a given server S, let Tc be the expected time that S takes to accept a connection, Tp be the expected time S takes to process the protocol for a client, N be the expected number of concurrent clients requiring the service of S.

33. 20 februari 2006Client-Server and Multicast Communication33 Connection-oriented Daytime Server … theServer = new ServerSocket(thePort); p = new PrintWriter(System.out); try { p.println("Echo Server now in business on port " + thePort ); p.flush(); theConnection = theServer.accept(); // read a line from the client theInputStream = new BufferedReader (new InputStreamReader (theConnection.getInputStream())); p = new PrintWriter(theConnection.getOutputStream()); while (!done){ theLine = theInputStream.readLine(); if (theLine == null) done = true; else{ p.println(theLine); p.flush(); } theConnection.close(); Protocol processing Connection acceptance

34. 20 februari 2006Client-Server and Multicast Communication34 Connection-oriented Concurrent DayTime Server ConcurrentDaytimeServer.java DaytimeServerThread.java ConcurrentDaytimeServer.javaDaytimeServerThread.java theServer = new ServerSocket(thePort); p = new PrintWriter(System.out); try { p.println("dayTime Server now in business on port " + thePort ); p.flush(); while (true) { theConnection = theServer.accept(); daytimeServerThread theThread = new daytimeServerThread(theConnection) ; theThread.start(); } public class daytimeServerThread extends Thread { Socket theConnection; public daytimeServerThread(Socket s) { theConnection = s; } public void run() { try { PrintWriter p; p = new PrintWriter(theConnection.getOutputStream()); p.println(new Date()); p.flush(); theConnection.close(); } catch (IOException e) { System.err.println(e); } } // end try } // end thread class

35. 20 februari 2006Client-Server and Multicast Communication35 Connection-oriented Echo Server public class echoServer { public static void main(String[] args) { ServerSocket theServer; int thePort; Socket theConnection; PrintWriter p; BufferedReader theInputStream; String theLine; boolean done = false; … theServer = new ServerSocket(thePort); p = new PrintWriter(System.out); try { theConnection = theServer.accept(); // read a line from the client theInputStream = new BufferedReader (new InputStreamReader (theConnection.getInputStream())); p = new PrintWriter(theConnection.getOutputStream()); while (!done){ theLine = theInputStream.readLine(); if (theLine == null) done = true; else { p.println(theLine); p.flush(); } // end if } //end while theConnection.close(); } // end try …

36. 20 februari 2006Client-Server and Multicast Communication36 Sequence diagram – EchoServer3

37. 20 februari 2006Client-Server and Multicast Communication37 Server Thread class template class ServerThread implements Runnable { static final String endMessage = "."; MyStreamSocket myDataSocket; ServerThread(MyStreamSocket myDataSocket) { this.myDataSocket = myDataSocket; } public void run( ) { boolean done = false; String message; try { //add code here }// end try catch (Exception ex) { System.out.println("Exception caught in thread: " + ex); } } //end run } //end class

38. 20 februari 2006Client-Server and Multicast Communication38 Concurrent Echo Server See ConcurrentEchoServer.javaConcurrentEchoServer.java See EchoServerThread.javaEchoServerThread.java

39. 20 februari 2006Client-Server and Multicast Communication39 Overview Client Server Communication Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References

40. 20 februari 2006Client-Server and Multicast Communication40 Stateful vs. stateless server In actual implementation, a server may be – Stateless – Stateful – A hybrid, wherein the state data is distributed on both the server-side and the client-side. Which type of server is chosen is a design issue.

41. 20 februari 2006Client-Server and Multicast Communication41 Stateful server A stateful server maintains stateful information on each active client. Stateful information can reduce the data exchanged, and thereby the response time.

42. 20 februari 2006Client-Server and Multicast Communication42 Stateful vs. Stateless server Stateless server is straightforward to code. Stateful server is harder to code, but the state information maintained by the server can reduce the data exchanged, and allows enhancements to a basic service. Maintaining stateful information is difficult in the presence of failures.

43. 20 februari 2006Client-Server and Multicast Communication43 State Data Storage State data can be stored in a local variable in the run method of each thread. When each client is serviced by a separate thread, a local variable suffices as a storage for the state data. Using local variables in a thread to store session state data is adequate for a network service server. In complex network applications such as shopping carts, more complex mechanisms are needed for state data storage.

44. 20 februari 2006Client-Server and Multicast Communication44 Overview Client Server Communication Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References

45. 20 februari 2006Client-Server and Multicast Communication45 A client can contact multiple servers A process may require the service of multiple servers. For example, it may obtain a timestamp from a daytime server, data from a database server, and a file from a file server.

46. 20 februari 2006Client-Server and Multicast Communication46 Middleware A process can serve as a intermediary, or middleware, between a client and a server.

47. 20 februari 2006Client-Server and Multicast Communication47 Designing a Network Service Because of its inherent complexity, network software is notoriously difficult to test. Use the three-layered software architecture and modularize each layer on both the client and the server sides. Use an incremental or stepwise approach in developing each module. Starting with stubs for each method, compile and test a module each time after you put in additional details. Develop the client first. It is sometimes useful to employ an Echo server (to be introduced in the next section) which is known to be correct and which uses a compatible IPC mechanism to test the client independent of the server; doing so allows you to develop the client independent of the server. Use diagnostic messages throughout each program to report the progress of the program during runtime. Test the client-server suite on one machine before running the programs on separate machine.

48. 20 februari 2006Client-Server and Multicast Communication48 Summary You have been introduced to the client-server paradigm in distributed computing. Topics covered include: The difference between the client-server system architecture and the client-server distributed computing paradigm. Definition of the paradigm and why it is widely adopted in network services and network applications. The issues of service sessions, protocols, service location, interprocess communications, data representation, and event synchronization in the context of the client-server paradigm. The three-tier software architecture of network applications: Presentation logic, application logic, and service logic. Connectionless server versus connection-oriented server. Iterative server versus concurrent server and the effect on a client session. Stateful server versus stateless server. In the case of a stateful server: global state information versus session state information.

49. 20 februari 2006Client-Server and Multicast Communication49 References & Exercises Deitel & Deitel “Java How to Program” SUN Java reference pages java.sun.com Liu “Distributed Computing - principles and applications” Fred Halsall “Data communications, computer networks and open systems” Selfstudy Exercises Chapter 5: Exercises 1, 2, 9, 12.a

50. 20 februari 2006 Client-Server and Multicast Communication 50 Multicast Communication

51. 20 februari 2006Client-Server and Multicast Communication51 Overview Multicast Communication Chapter 6: Liu Introduction – Definitions, Applications, Primitives and Characteristics. Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References Selfstudy Exercises Chapter 6: Exercises 1, 2

52. 20 februari 2006Client-Server and Multicast Communication52 Unicast versus Multicast senderreceiver One-to-one communication orunicast Group communication ormulticast

53. 20 februari 2006Client-Server and Multicast Communication53 Multicast Broadcast is special kind of multicast Multicast applications: – groupware – online conferences – interactive distance learning – online auction – services for fault tolerance – etc.

54. 20 februari 2006Client-Server and Multicast Communication54 Multicast group A process can join and leave a multicast group. Each process in a group (member) can send and receive messages. A message sent by any process in the group can be received by each participating process in the group. For multicast operations, a naming scheme is needed to uniquely identify a multicast group. Example: online conferencing A group of processes interoperate using multicasting to exchange audio, video, and/or text data. In an application or network service which makes use of multicasting, a set of processes form a group, called a multicast group.

55. 20 februari 2006Client-Server and Multicast Communication55 An Archetypal Multicast API Primitive operations: Join – Join a specific multicast group. – A member is entitled to receive all multicast addressed to the group. – A process is able to be a member of multiple multicast groups. Send – Send a message to all members currently participating in a multicast group. Receive –Receive messages sent to a multicast group. Leave – Leave a multicast group. – This operation allows a member to stop participating in a multicast group. – Disables the reception of any multicast addressed to the left group (The process may remain a member of other multicast groups).

56. 20 februari 2006Client-Server and Multicast Communication56 Some Characteristics of Multicast services (i) Runtime support of the multicast mechanism is responsible for delivering the message to each member in the multicast group. As each participating process may reside on a separate host, the delivery of these messages requires the support of mechanisms running independently on those systems. Due to factors such as failures of network links and/or network hosts, routing delays, and differences in software and hardware, the time between when a unicast message is sent and when it is received may vary among the recipient processes.

57. 20 februari 2006Client-Server and Multicast Communication57 Some Characteristics of Multicast services (ii) A message may not be received by one or more of the processes at all, due to errors and/or failures in the network, the machines, or the runtime support. Some applications, such as video conferencing, can tolerate an occasional miss or misordering of messages, there are applications – such as database applications – for which such anomalies are unacceptable. Employing a multicasting mechanism for an application, it is important that you choose one with the characteristics appropriate for your application. (Otherwise, you have to do it yourself !) Some Characteristics of Multicast services (ii)

58. 20 februari 2006Client-Server and Multicast Communication58 Classification of multicasting mechanisms (in terms of message delivery) (i) Unreliable multicast: will make a good-faith attempt to deliver messages to each participating process Arrival of the correct message at each process is not guaranteed. Message sent by a process may be received by zero or more processes. Messages can be received unordered.

59. 20 februari 2006Client-Server and Multicast Communication59 Overview Multicast Communication Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summery References

60. 20 februari 2006Client-Server and Multicast Communication60 Classification of multicasting mechanisms (in terms of message delivery) (ii) Reliable multicast: Guarantees that each message is eventually delivered to each member. All messages will be delivered in a non-corrupted form to all members. Only once delivered. No guarantees on ordering. Unordered, FIFO, Causal, Atomic, …

61. 20 februari 2006Client-Server and Multicast Communication61 Classification of reliable multicast – 1: unordered Unordered multicast Safe delivery of each message No guarantee on the delivery order of the messages. Example: - Processes P 1, P 2, and P 3 have formed a multicast group and three messages, m 1, m 2, m 3 have been sent to the group. - Delivery: 3! = 6 permutations (m 1 -m 2 -m 3, m 1 -m 3 -m 2, m 2 -m 1 -m 3, m 2 -m 3 -m 1, m 3 -m 1 -m 2, m 3 -m 2 -m 1 ) - Note that it is possible for each participant to receive the messages in an order different from the orders of messages delivered to other participants.

62. 20 februari 2006Client-Server and Multicast Communication62 Classification of reliable multicast – 2: FIFO FIFO multicast Guarantees that the delivery of the messages is in FIFO (first-in-first-out) order or send-order multicast. Example: Suppose P 1 sends messages m 1, m 2, and m 3 in order, then each process in the group is guaranteed to have those messages delivered in that same order: m 1, m 2, then m 3.

63. 20 februari 2006Client-Server and Multicast Communication63 A Note on FIFO multicast Note that FIFO multicast places no restriction on the delivery order among messages sent by different processes. To illustrate the point, let us use a simplified example of a multicast group of two processes: P 1 and P 2. Suppose P 1 sends messages m 11 then m 12, while P 2 sends messages m 21 then m 22. Then delivery examples are: m 11 -m 12 -m 21 -m 22, m 11 -m 21 -m 12 -m 22, m 11 -m 21 -m 22 -m 12, m 21 -m 11 -m 12 -m 22 m 21 -m 11 -m 22 -m 12 m 21 -m 22 -m 11 -m 12.

64. 20 februari 2006Client-Server and Multicast Communication64 Classification of reliable multicast – 3: Causal Order Causal Order Multicast A multicast system is said to provide causal multicast if its message delivery satisfies the following criterion: Let m i causes the occurrence of message m j. ( m i -> m j ) Messages m i and m j are said to have a causal or happen-before relationship. Then m i will be delivered to each process prior to m j. The happen-before relationship is transitory: if m i -> m j and m j -> m k, then m i -> m j -> m k. A causal-order multicast system guarantees that these three messages will be delivered to each member in the order of m i, m j, then m k.

65. 20 februari 2006Client-Server and Multicast Communication65 Causal Order Multicast – example 1 Suppose three processes P 1, P 2, and P 3 are in a multicast group. P 1 sends a message m 1, to which P 2 replies with a multicast message m 2. Since m 2 is triggered by m 1, the two messages share a causal relationship of m 1 -> m 2. Suppose the receiving of m 2 in turn triggers a multicast message m 3 sent by P 3, that is, m 2 -> m 3. Then three messages share the causal relationship of m 1 -> m 2 -> m 3.  A causal-order multicast message system ensures that these three messages will be delivered to each of the three processes in the order of m 1 - m 2 - m 3.

66. 20 februari 2006Client-Server and Multicast Communication66 Causal Order Multicast – example 2 Suppose P 1 multicasts message m 1, to which P 2 replies with a multicast message m 2 Independently P 3 replies to m 1 with a multicast message m 3. The three messages now share these causal relationships: m 1 -> m 2 and m 1 -> m 3.  A causal-order multicast system can delivery these message in either of the following orders: m 1 - m 2 - m 3 m 1 - m 3 - m 2 Note: It is not possible for the messages to be delivered in any other permutation of the three messages, such as m 2 - m 1 - m 3 or m 3 - m 1 - m 2

67. 20 februari 2006Client-Server and Multicast Communication67 Classification of reliable multicast – 4: Atomic Order Atomic order multicast In an atomic-order multicast system, all messages are guaranteed to be delivered to each participant in the exact same order. Note that the delivery order does not have to be FIFO or causal, but must be identical for each process. Example: P 1 sends m 1, P 2 sends m 2, and P 3 sends m 3. An atomic system will guarantee that the messages will be delivered to each process in only one of the six orders: m 1 -m 2 - m 3, m 1 - m 3 - m 2, m 2 - m 1 -m 3, m 2 -m 3 -m 1, m 3 -m 1 - m 2, m 3 -m 2 -m 1.

68. 20 februari 2006Client-Server and Multicast Communication68 Overview Multicast Communication Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References

69. 20 februari 2006Client-Server and Multicast Communication69 The Java Basic Multicast API At the transport layer, the basic multicast supported by Java is an extension of UDP (the User Datagram Protocol) UDP is connectionless and unreliable. Java provides a set of classes which are closely related to the datagram socket API classes that we looked at in Chapter 3.

70. 20 februari 2006Client-Server and Multicast Communication70 The Java Basic Multicast API - 2 There are four major classes in the API, the first three of which we have already seen in the context of datagram sockets. 1. InetAddress: In the datagram socket API, this class represents the IP address of the sender or receiver. In multicasting, this class can be used to identify a multicast group. 2. DatagramPacket: As with datagram sockets, an object of this class represents an actual datagram; in multicast, a DatagramPacket object represents a packet of data sent to all participants or received by each participant in a multicast group.

71. 20 februari 2006Client-Server and Multicast Communication71 The Java Basic Multicast API - 3 3. DatagramSocket: In the datagram socket API, this class represents a socket through which a process may send or receive data. 4. MulticastSocket : A MulticastSocket is a DatagramSocket, with additional capabilities for joining and leaving a multicast group. An object of the multicast datagram socket class can be used for sending and receiving IP multicast packets.

72. 20 februari 2006Client-Server and Multicast Communication72 IP Multicast addresses A multicast datagram is meant to be received by all members of a specific multicast group. Each multicast datagram needs to be addressed to a multicast group instead of an individual member. The Java multicast API uses the Internet Protocol (IP) multicast addresses for identifying multicast groups. In IPv4a multicast group is specified by (i) a class D IP address combined with (ii) a standard UDP port number.

73. 20 februari 2006Client-Server and Multicast Communication73 IP Multicast addresses - 2 Class D IP addresses are those with the prefix bit string of 1110, (224.0.0.0 to 239.255.255.255) Excluding the four prefix bits, there are 32-4=28 remaining bits, resulting in an address space of 2 28 ; that is, approximate 268 million class D addresses are available, although the address 224.0.0.0 is reserved and should not be used by any application. IPv4 multicast addresses are managed and assigned by the Internet Assigned Numbers Authority (IANA)

74. 20 februari 2006Client-Server and Multicast Communication74 IP Multicast addresses - 3 An application which uses the Java multicast API must specifiy at least one multicast address for the application. To select a multicast address for an application, there are the following options: 1.Obtain a permanently assigned static multicast address from IANA: Permanent addresses are limited to global, well-known Internet applications, and their allocations are highly restricted. 2.Choose an arbitrary address, assuming that the combination of the random address and port number is not in use 3.Obtain a transient multicast address at runtime; such an address can be received by an application through the Session Announcement Protocol.

75. 20 februari 2006Client-Server and Multicast Communication75 IP Multicast addresses - 4 Examples of assigned addresses: 224.0.0.1All Systems on this Subnet 224.0.0.11Mobile-Agents 224.0.1.23 XINGTV 224.0.1.84jini-announcement 224.0.1.85jini-request 224.0.1.115Simple Multicast 224.0.6.000-224.0.6.127Cornell ISIS Project 224.0.7.000-224.0.7.255Where-Are-You 224.0.8.000-224.0.8.255INTV 224.0.9.000-224.0.9.255Invisible Worlds 224.0.12.000-224.0.12.063Microsoft and MSNBC 224.0.16.000-224.0.16.255XingNet 224.0.18.000-224.0.18.255Dow Jones 224.0.19.000-224.0.19.063Walt Disney Company 224.0.22.000-224.0.22.255WORLD MCAST 224.2.0.0-224.2.127.253Multimedia Conference Calls

76. 20 februari 2006Client-Server and Multicast Communication76 IP Multicast addresses - 5 For our examples and exercises, we will make use of the static address 224.0.0.1, with an equivalent domain name ALL-SYSTEMS.MCAST.NET, for processes running on all machines on the local area network, such as those in your laboratory; alternatively, we may use an arbitrary address that has not been assigned, such as a number in the range of 239.*.*.* (for example, 239.1.2.3). In the Java API, a MulticastSocket object is bound to a port address such as 3456, and methods of the object allows for the joining and leaving of a multicast address such as 239.1.2.3

77. 20 februari 2006Client-Server and Multicast Communication77 Joining a multicast group To join a multicast group at IP address m and UDP port p, a MulticastSocket object must be instantiated with p, then the object’s joinGroup method can be invoked specifying the address m: // join a Multicast group at IP address 239.1.2.3 and port 3456 InetAddress group = InetAddress.getByName("239.1.2.3"); MulticastSocket s = new MulticastSocket(3456); s.joinGroup(group);

78. 20 februari 2006Client-Server and Multicast Communication78 Sending to a multicast group A multicast message can be sent using syntax similar with the datagram socket API. String msg = "This is a multicast message."; InetAddress group = InetAddress.getByName("239.1.2.3"); MulticastSocket s = new MulticastSocket(3456); s.joinGroup(group); // optional DatagramPacket hi = new DatagramPacket(msg.getBytes( ), msg.length( ),group, 3456); s.send(hi);

79. 20 februari 2006Client-Server and Multicast Communication79 Receiving messages sent to a multicast group A process that has joined a multicast group may receive messages sent to the group using syntax similar to receiving data using a datagram socket API. byte[] buf = new byte[1000]; InetAddress group = InetAddress.getByName("239.1.2.3"); MulticastSocket s = new MulticastSocket(3456); s.joinGroup(group); DatagramPacket recv = new DatagramPacket(buf, buf.length); s.receive(recv);

80. 20 februari 2006Client-Server and Multicast Communication80 Leaving a multicast group A process may leave a multicast group by invoking the leaveGroup method of a MulticastSocket object, specifying the multicast address of the group. s.leaveGroup(group);

81. 20 februari 2006Client-Server and Multicast Communication81 Overview Multicast communication Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References

82. 20 februari 2006Client-Server and Multicast Communication82 Setting the “time-to-live” The runtime support for a multicast API often employs a technique known as message propagation, whereby a packet is propagated from a host to a neighboring host in an algorithm which, when executed properly, will eventually deliver the message to all the participants. Under some anomalous circumstances, however, it is possible that the algorithm which controls the propagation does not terminate properly, resulting in a packet circulating in the network indefinitely.

83. 20 februari 2006Client-Server and Multicast Communication83 Setting the “time-to-live” - 2 Indefinite message propagation causes unnecessary overhead on the systems and the network. To avoid this occurrence, it is recommended that a “time to live” parameter be set with each multicast datagram. The time-to-live (ttl) parameter, when set, limits the count of network links or hops that the packet will be forwarded on the network.

84. 20 februari 2006Client-Server and Multicast Communication84 Setting the “time-to-live” - 3 String msg = "Hello everyone!"; InetAddress group = InetAddress.getByName("224.0.0.1"); MulticastSocket s = new MulticastSocket(3456); s.setTimeToLive(1); // set time-to-live to 1 hop – a count // appropriate for multicasting to local hosts DatagramPacket hi = new DatagramPacket(msg.getBytes( ), msg.length( ),group, 3456); s.send(hi); The value specified for the ttl must be in the range 0 <= ttl <= 255 ; an IllegalArgumentException will be thrown otherwise.

85. 20 februari 2006Client-Server and Multicast Communication85 Setting the “time-to-live” - 4 The recommended ttl settings are: 0 if the multicast is restricted to processes on the same host 1 if the multicast is restricted to processes on the same subnet 32 if the multicast is restricted to processes on the same site 64 if the multicast is restricted to processes on the same region 128 if the multicast is restricted to processes on the same continent 255 if the multicast is unrestricted

86. 20 februari 2006Client-Server and Multicast Communication86 Multicast program examples Example1: – Example1Sender – Example1Receiver Example2 – Example2SenderReceiver – ReadThread

87. 20 februari 2006Client-Server and Multicast Communication87 Reliable Multicast API the Java basic Multicast API provides unreliable multicast The Java Reliable Multicast Service (JRM Service) provides the capabilities for a receiver to repair multicast data that are lost or damaged, as well as security measures to protect data privacy. The Totem system, developed by the University of California, Santa Barbara, “provides reliable totally ordered delivery of messages to processes within process groups on a single local-area network, or over multiple local-area networks interconnected by gateways.” TASC’s Reliable Multicast Framework (RMF) provides reliable and send ordered (FIFO) multicast.

88. 20 februari 2006Client-Server and Multicast Communication88 Summary - 1 Unicast vs. multicast. An archetypal multicast API must provide operations for joining, leaving, sending, and receiving. Basic multicast is connectionless and unreliable; A reliable multicast system ensures delivery. Reliable multicasts can be further categorized by the order of message delivery they support: Unordered multicast may deliver the messages to each participant in any order. FIFO multicast preserves the order of messages sent by each host. Causal multicast preserves causal relationships among the messages. Atomic multicast delivers the messages to each participant in the same order. IP multicast addressing uses a combination of a Class D address and a UDP port number. A multicast application may use a static Class D address, a transient address obtained at run time, or an arbitrary unassigned address.

89. 20 februari 2006Client-Server and Multicast Communication89 Summary - 2 The Java basic multicast API provides unreliable multicast. A MulticastSocket is created with the specification of a port number. The joinGroup and leaveGroup methods of the MulticastSocket class, a subclass of DatagramSocket, can be invoked to join or leave a specific multicast group; and the send and receive methods can be invoked to send and receive a multicast datagram. The DatagramPacket class is also needed to create the datagrams. There are existing packages that provide reliable multicast, including the Java Reliable Multicast Service (JRM Service).