Exercise 2 ========== Construct a reliable multicast tool using UDP/IP. The reliable multicast will assume no network partitions or processor crashes, but it WILL handle all kinds of message omissions over a local area network. 1. The assignment: Using the unreliable UDP/IP protocol, you should write a tool that reliably multicasts packets between n machines that reside on the same network segment, so that one multicast message may get to all of them. The tool consists of two programs: mcast - the tool's process. start_mcast - a process signaling the mcast processes to start. The mcast process should be run as follows: mcast The indicates how many mcast machines will be run. The maximal number of should be a constant and should be set to 10. Note that in a particular execution there may be less than or equal to 10 . is the percentage loss rate for this execution ([0-25] see below). Note also that machine_index will be in the range [1 - ] and that you can assume exactly mcast programs, each with a different index, will be ready to run before start_mcast is executed. The num_of_packets indicates how many packets THIS mcast has to initiate. This number may be on the order of 100,000 packets and even more. Each packet should contain the creating machine_index, a packet_index, and a random number, each stored in a 4 byte integer. The random number is an integer, picked at the time of the creation of the packet, randomly selected from the range 1-100000. Therefore, each packet should contain 12 bytes + additional bytes in case your protocol needs them. After all the mcast processes have been started, the start_mcast process is executed, signaling the mcast processes to start the protocol by sending a single special multicast message. Output: ------- On delivery of a packet the mcast should write to a file, in ASCII format, the packet data as follows: fprintf(fd, "%5d, %6d, %6d\n", pack->machine_index, pack->index, pack->random_data); The output file name will be .out Required Task: -------------- For those who take 600.337: The requirement for the mcast is: You should deliver all packets reliably according to FIFO order. For those who take 600.437: The requirement for the mcast is: You should deliver all packets reliably according to AGREED order that respects FIFO order as well. The designed protocol should not assume knowing the number of packets each participant needs to send, so that it can implement a never-ending daemon. You should work on this exercise in pairs, if at all possible, such that you have two people working together on the desing and two sets of eyes on the same screen during development. Evaluation and Testing: ----------------------- In order to be able to check the software, the mcast program should call a coat routine named recv_dbg instead of the recv system call. The coat routine has the same interface as recv (see man 2 recv). The recv_dbg routine will randomly decide to discard packets in order to create additional network message omissions. EVERY RECV CALL in the mcast program MUST use the recv_dbg call EXCEPT the first one which receives the special start_mcast packet. At the beginning of the mcast program it should wait for the start_mcast packet to arrive. This will be done by calling recv directly (without the coat routine). Only after that packet arrives, the reliable protocol should be invoked. The start_mcast process purpose is to help us avoid membership problems. You must run your program, AT ANY TIME, ONLY on the machines ugrad1 through ugrad20. You may NOT run it on the CS research machines, masters machines, phd machines, etc. If you run it on other CS department machines, you may find your machines cut off from the network administratively. DO NOT use broadcast addresses in your programs (or else some chunk of the CS network may potentially be affected). You can ONLY use MULTICAST addresses in order to multicast messages. Talk to us to get a MULTICAST address that will be assigned to your project !!!!! To benchmark your program you should run a test with 8 machines where 5 of them send 100000 packets each, for a total of 500000 packets, and time how long the test takes. The other machines will get 0 as . You should conduct 6 experiments, each experiment with a different loss rate (0% 1% 2% 5% 10% 25%) and graph the results with the X-axis being the loss rate and the Y-axis being the time the packet transmission took. For each experiment, please conduct 5 tests and note the average time for that experiment. Thus, you should turn in results comparing six experiments: 1. mcast (zero loss rate) 2. mcast with %1 loss rate 3. mcast with %2 loss rate 4. mcast with %5 loss rate 5. mcast with %10 loss rate 6. mcast with %25 loss rate Please have a table with all 6 results and a graph as described above. 2. Submission: There are two separate submissions required. 1) A design document. Due October 12, 2009 at the beginning of class. This is a paper submission. Please PRINT your design document. We will meet with each group separately to provide feedback on the design. Time slots will be assigned in class on October 12. The design document should be a well-written, complete design of your programs and the protocols used to make them reliable, deliver the messages in order, and provide some flow control. We expect it to be 2-3 pages long with diagrams as needed to explain the protocol. Please include a description of your data structures, message formats, and algorithm. 2) A final submission of documentation, writeup and code. Due Monday, October 26 at 11am. This is an electronic submission. See instructions below. For the final submission you should include an updated version of your design document as part of your final report. You should briefly mention changes you made to the design during the project and why you believe those changes were needed. This final report should also include a brief discussion of the performance results you achieved and discuss the comparison of how the protocol worked under different percentages of loss. The programs should be complete, sound, and well documented. A makefile that compiles and builds your complete program with clearly documented options (if needed) is required. You should make a tar file named exactly as your login account with all your documents and code (DO NOT include core files or object files) and email the tar file as an attachment to cs437@cs.jhu.edu. The subject of the email should be "Exercise 2 submission ", and in the body of the email write the names of the students that worked on the exercise. Issues such as correctness, design, documentation, and efficiency will be considered. Please bring a printed version of the your submission to class on Monday October 26.