ClientServer and Multicast Communication Ren de Vries Based

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

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

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

The Client-Server Paradigm l l l 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. 20 februari 2006 Client-Server and Multicast Communication 4

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

Client-server applications and services l l 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 clientserver paradigm. 20 februari 2006 Client-Server and Multicast Communication 6

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

20 februari 2006 Client-Server and Multicast Communication 8

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

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

Session IPC examples The dialog in each session follows a pattern prescribed in the protocol specified for the service. Daytime service [RFC 867]: Client: Hello, <client address> here. May I have a timestamp please. Server: Here it is: (time stamp follows) World Wide Web session: Client: Hello, <client address> here. Server: Okay. I am a web server and I speak protocol HTTP 1. 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). 20 februari 2006 Client-Server and Multicast Communication 11

The Protocol for a Network Service l 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. iii. l how the service is to be located the sequence of interprocess communication (dynamics) 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. 20 februari 2006 Client-Server and Multicast Communication 12

Locating the service l l l 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. 20 februari 2006 Client-Server and Multicast Communication 13

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

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

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

Example protocol: daytime Defined in RFC 867 20 februari 2006 Client-Server and Multicast Communication 17

Daytime Protocol 20 februari 2006 Client-Server and Multicast Communication 18

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

The get. Address and get. Port Methods 20 februari 2006 Client-Server and Multicast Communication 20

Connectionless Echo Server (advanced) Datagram. Socket ds = new Datagram. Socket(port); while (true) { try { // create a new datagram packet byte[] buffer = new byte[MAXLEN]; Datagram. Packet dp = new Datagram. Packet(buffer, MAXLEN); ds. receive(dp); len = dp. get. Length(); c. Addr = dp. get. Address(); c. Port = dp. get. Port(); String s = new String(dp. get. Data(), 0, len); System. out. println(dp. get. Address() + " at port " + dp. get. Port() + " says " + s); // create a datagram packet to send to client Datagram. Packet the. Echo = new Datagram. Packet(buffer, len, c. Addr, c. Port); ds. send(the. Echo); } // end try … } // end while 20 februari 2006 Client-Server and Multicast Communication 21

Concurrent client sessions with Echo. Server 1 20 februari 2006 Client-Server and Multicast Communication 22

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

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 20 februari 2006 Client-Server and Multicast Communication 24

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. 20 februari 2006 Client-Server and Multicast Communication 25

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

Echo. Server 2 (Connection-oriented) excerpt Server. Socket my. Connection. Socket = new Server. Socket(server. Port); while (true) { // forever loop My. Stream. Socket my. Data. Socket = new My. Stream. Socket (my. Connection. Socket. accept( )); boolean done = false; while (!done) { message = my. Data. Socket. receive. Message( ); if ((message. trim()). equals (end. Message)){ my. Data. Socket. close( ); done = true; } //end if else { my. Data. Socket. send. Message(message); } //end else } //end while !done } //end while forever 20 februari 2006 Client-Server and Multicast Communication 27

Two consecutive client sessions with echo server 2 20 februari 2006 Client-Server and Multicast Communication 28

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

Concurrent, Connection-Oriented Server l l l 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. 20 februari 2006 Client-Server and Multicast Communication 30

Concurrent, connection-oriented server - 2 l l 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. 20 februari 2006 Client-Server and Multicast Communication 31

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

Connection-oriented Daytime Server … the. Server = new Server. Socket(the. Port); p = new Print. Writer(System. out); try { p. println("Echo Server now in business on port " + the. Port ); p. flush(); Connection the. Connection = the. Server. accept(); // read a line from the client the. Input. Stream = new Buffered. Reader (new Input. Stream. Reader (the. Connection. get. Input. Stream())); p = new Print. Writer(the. Connection. get. Output. Stream()); while (!done){ the. Line = the. Input. Stream. read. Line(); if (the. Line == null) done = true; else{ p. println(the. Line); p. flush(); } } the. Connection. close(); 20 februari 2006 acceptance Protocol processing Client-Server and Multicast Communication 33

Connection-oriented Concurrent Day. Time Server Concurrent. Daytime. Server. java Daytime. Server. Thread. java the. Server = new Server. Socket(the. Port); p = new Print. Writer(System. out); try { p. println("day. Time Server now in business on port " + the. Port ); p. flush(); while (true) { the. Connection = the. Server. accept(); daytime. Server. Thread the. Thread = new daytime. Server. Thread(the. Connection) ; the. Thread. start(); } } 20 februari 2006 public class daytime. Server. Thread extends Thread { Socket the. Connection; public daytime. Server. Thread(Socket s) { the. Connection = s; } public void run() { try { Print. Writer p; p = new Print. Writer(the. Connection. get. Output. Stream()); p. println(new Date()); p. flush(); the. Connection. close(); } catch (IOException e) { System. err. println(e); } } // end try } // end thread class Client-Server and Multicast Communication 34

Connection-oriented Echo Server try { public class echo. Server { public static void main(String[] args) { Server. Socket the. Server; int the. Port; Socket the. Connection; Print. Writer p; Buffered. Reader the. Input. Stream; String the. Line; boolean done = false; … the. Server = new Server. Socket(the. Port); p = new Print. Writer(System. out); 20 februari 2006 the. Connection = the. Server. accept(); // read a line from the client the. Input. Stream = new Buffered. Reader (new Input. Stream. Reader (the. Connection. get. Input. Stream())); p = new Print. Writer(the. Connection. get. Output. Stream()); while (!done){ the. Line = the. Input. Stream. read. Line(); if (the. Line == null) done = true; else { p. println(the. Line); p. flush(); } // end if } //end while the. Connection. close(); } // end try … and Multicast Communication Client-Server 35

Sequence diagram – Echo. Server 3 20 februari 2006 Client-Server and Multicast Communication 36

Server Thread class template class Server. Thread implements Runnable { static final String end. Message = ". "; My. Stream. Socket my. Data. Socket; Server. Thread(My. Stream. Socket my. Data. Socket) { this. my. Data. Socket = my. Data. Socket; } 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 20 februari 2006 Client-Server and Multicast Communication 37

Concurrent Echo Server See Concurrent. Echo. Server. java See Echo. Server. Thread. java 20 februari 2006 Client-Server and Multicast Communication 38

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

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. 20 februari 2006 Client-Server and Multicast Communication 40

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

Stateful vs. Stateless server l l l 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. 20 februari 2006 Client-Server and Multicast Communication 42

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. 20 februari 2006 Client-Server and Multicast Communication 43

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

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. 20 februari 2006 Client-Server and Multicast Communication 45

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

Designing a Network Service l l l Because of its inherent complexity, network software is notoriously difficult to test. Use 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. 20 februari 2006 Client-Server and Multicast Communication 47

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. 20 februari 2006 Client-Server and Multicast Communication 48

References & Exercises l l 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 20 februari 2006 Client-Server and Multicast Communication 49

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

Overview Multicast Communication Chapter 6: Liu l Introduction – l l 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 20 februari 2006 Client-Server and Multicast Communication 51

Unicast versus Multicast sender receiver One-to-one communication or unicast 20 februari 2006 Group communication or multicast Client-Server and Multicast Communication 52

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

Multicast group In an application or network service which makes use of multicasting, a set of processes form a group, called a multicast group. l l 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. 20 februari 2006 Client-Server and Multicast Communication 54

An Archetypal Multicast API Primitive operations: l Join – Join a specific multicast group. – – l l l 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). 20 februari 2006 Client-Server and Multicast Communication 55

Some Characteristics of Multicast services (i) l l l 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. 20 februari 2006 Client-Server and Multicast Communication 56

Some Characteristics of Multicast services (ii) l 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. l Some applications, such as video conferencing, can tolerate an occasional miss or misordering of messages, there applications – such as database applications – for which such anomalies are unacceptable. l 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 !) 20 februari 2006 Client-Server and Multicast Communication 57

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

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

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

Classification of reliable multicast – 1: unordered Unordered multicast l l 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. 20 februari 2006 Client-Server and Multicast Communication 61

Classification of reliable multicast – 2: 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. 20 februari 2006 Client-Server and Multicast Communication 62

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 22 -m 12, m 21 -m 12 -m 22 m 21 -m 11 -m 22 -m 12 m 21 -m 22 -m 11 -m 12. 20 februari 2006 Client-Server and Multicast Communication 63

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

Causal Order Multicast – example 1 l l 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. 20 februari 2006 Client-Server and Multicast Communication 65

Causal Order Multicast – example 2 Suppose P 1 multicasts message m 1, to which P 2 replies with a multicast message m 2 l Independently P 3 replies to m 1 with a multicast message m 3. l 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: l 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 20 februari 2006 Client-Server and Multicast Communication 66

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: l P 1 sends m 1, P 2 sends m 2, and P 3 sends m 3. l 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. 20 februari 2006 Client-Server and Multicast Communication 67

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

The Java Basic Multicast API l l l 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. 20 februari 2006 Client-Server and Multicast Communication 69

The Java Basic Multicast API - 2 1. 2. There are four major classes in the API, the first three of which we have already seen in the context of datagram sockets. Inet. Address: 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. Datagram. Packet: As with datagram sockets, an object of this class represents an actual datagram; in multicast, a Datagram. Packet object represents a packet of data sent to all participants or received by each participant in a multicast group. 20 februari 2006 Client-Server and Multicast Communication 70

The Java Basic Multicast API - 3 3. Datagram. Socket: In the datagram socket API, this class represents a socket through which a process may send or receive data. 4. Multicast. Socket : A Multicast. Socket is a Datagram. Socket, 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. 20 februari 2006 Client-Server and Multicast Communication 71

IP Multicast addresses l l 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 IPv 4 a multicast group is specified by (i) a class D IP address combined with (ii) a standard UDP port number. 20 februari 2006 Client-Server and Multicast Communication 72

IP Multicast addresses - 2 l l l Class D IP addresses are those with the prefix bit string of 1110, (224. 0. 0. 0 to 239. 255) Excluding the four prefix bits, there are 32 -4=28 remaining bits, resulting in an address space of 228; 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. IPv 4 multicast addresses are managed and assigned by the Internet Assigned Numbers Authority (IANA) 20 februari 2006 Client-Server and Multicast Communication 73

IP Multicast addresses - 3 1. 2. 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: Obtain a permanently assigned static multicast address from IANA: Permanent addresses are limited to global, wellknown Internet applications, and their allocations are highly restricted. Choose an arbitrary address, assuming that the combination of the random address and port number is not in use Obtain a transient multicast address at runtime; such an address can be received by an application through the Session Announcement Protocol. 20 februari 2006 Client-Server and Multicast Communication 74

IP Multicast addresses - 4 Examples of assigned addresses: 224. 0. 0. 11 224. 0. 1. 84 224. 0. 1. 85 224. 0. 1. 115 224. 0. 6. 000 -224. 0. 6. 127 224. 0. 7. 000 -224. 0. 7. 255 224. 0. 8. 000 -224. 0. 8. 255 224. 0. 9. 000 -224. 0. 9. 255 224. 0. 12. 000 -224. 0. 12. 063 224. 0. 16. 000 -224. 0. 16. 255 224. 0. 18. 000 -224. 0. 18. 255 224. 0. 19. 000 -224. 0. 19. 063 224. 0. 22. 000 -224. 0. 22. 255 224. 2. 0. 0 -224. 2. 127. 253 20 februari 2006 All Systems on this Subnet Mobile-Agents 224. 0. 1. 23 XINGTV jini-announcement jini-request Simple Multicast Cornell ISIS Project Where-Are-You INTV Invisible Worlds Microsoft and MSNBC Xing. Net Dow Jones Walt Disney Company WORLD MCAST Multimedia Conference Calls Client-Server and Multicast Communication 75

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 Multicast. Socket 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 20 februari 2006 Client-Server and Multicast Communication 76

Joining a multicast group To join a multicast group at IP address m and UDP port p, a Multicast. Socket object must be instantiated with p, then the object’s join. Group method can be invoked specifying the address m: // join a Multicast group at IP address 239. 1. 2. 3 and port 3456 Inet. Address group = Inet. Address. get. By. Name("239. 1. 2. 3"); Multicast. Socket s = new Multicast. Socket(3456); s. join. Group(group); 20 februari 2006 Client-Server and Multicast Communication 77

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. "; Inet. Address group = Inet. Address. get. By. Name("239. 1. 2. 3"); Multicast. Socket s = new Multicast. Socket(3456); s. join. Group(group); // optional Datagram. Packet hi = new Datagram. Packet(msg. get. Bytes( ), msg. length( ), group, 3456); s. send(hi); 20 februari 2006 Client-Server and Multicast Communication 78

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]; Inet. Address group = Inet. Address. get. By. Name("239. 1. 2. 3"); Multicast. Socket s = new Multicast. Socket(3456); s. join. Group(group); Datagram. Packet recv = new Datagram. Packet(buf, buf. length); s. receive(recv); 20 februari 2006 Client-Server and Multicast Communication 79

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

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

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. 20 februari 2006 Client-Server and Multicast Communication 82

Setting the “time-to-live” - 2 l l l 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. 20 februari 2006 Client-Server and Multicast Communication 83

Setting the “time-to-live” - 3 String msg = "Hello everyone!"; Inet. Address group = Inet. Address. get. By. Name("224. 0. 0. 1"); Multicast. Socket s = new Multicast. Socket(3456); s. set. Time. To. Live(1); // set time-to-live to 1 hop – a count // appropriate for multicasting to local hosts Datagram. Packet hi = new Datagram. Packet(msg. get. Bytes( ), msg. length( ), group, 3456); s. send(hi); The value specified for the ttl must be in the range 0 <= ttl <= 255; an Illegal. Argument. Exception will be thrown otherwise. 20 februari 2006 Client-Server and Multicast Communication 84

Setting the “time-to-live” - 4 The recommended ttl settings are: l l l 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 20 februari 2006 Client-Server and Multicast Communication 85

Multicast program examples l Example 1: – – l Example 1 Sender Example 1 Receiver Example 2 – – Example 2 Sender. Receiver Read. Thread 20 februari 2006 Client-Server and Multicast Communication 86

Reliable Multicast API l l 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. 20 februari 2006 Client-Server and Multicast Communication 87

Summary - 1 l l l 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. 20 februari 2006 Client-Server and Multicast Communication 88

Summary - 2 l l The Java basic multicast API provides unreliable multicast. A Multicast. Socket is created with the specification of a port number. The join. Group and leave. Group methods of the Multicast. Socket class, a subclass of Datagram. Socket, 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 Datagram. Packet class is also needed to create the datagrams. There are existing packages that provide reliable multicast, including the Java Reliable Multicast Service (JRM Service). 20 februari 2006 Client-Server and Multicast Communication 89