Exercise 2 ========== Construct a reliable multicast tool using UDP/IP. The reliable multicast will assume no network partitions or processor crashes, but it should handle all kinds of message losses 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..20] 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 instance has to initiate. This number may be on the order of 200,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-1,000,000. In addition, each packet will include 1400 additional payload bytes. If your protocol requires additional information, that can be added to the packet. Therefore, each packet should include at least 1412 bytes, and possibly more, depending on the information used by the protocol. 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, "%2d, %8d, %8d\n", pack->machine_index, pack->index, pack->random_data); The output file name will be .txt Required Task: -------------- The requirement for the mcast is: You should deliver all packets reliably according to AGREED order that respects FIFO and CAUSAL 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 design and two sets of eyes on the same code 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 recvfrom or recv system calls. The coat routine has the same interface as recv (see man 2 recv). The recv_dbg routine randomly decides to discard packets in order to cause emulated message losses. 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 issues. You must run your program, AT ANY TIME, ONLY on the machines ugrad1-ugrad24 You may NOT run your programs on the CS research machines, masters machines, phd machines, etc. If you run your programs 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. Check Slack for the MULTICAST address and a port that will be assigned to you !!!!! To benchmark your program you should run a test with 8 machines where 6 of them send 160000 packets each, for a total of 960000 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% 20%) 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 %20 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) An initial design document, due Thursday September 30, 2021 at the beginning of class. This is a paper submission. Please PRINT your design document. A separate meeting with each group to provide feedback on the design will be conducted. Time slots will be assigned in class on September 30. The design document should be a well-written design of your program and the protocol used to make it reliable, deliver the messages in order, and provide some flow control. It is expected to be about 2-3 pages long with diagrams as needed to explain the protocol. Please include a description of your general approach, message formats, data structures, and protocol. 2) A final submission of documentation, writeup and code, due Friday, October 15 at 11pm. 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 in pdf or ascii. 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 document and code files (DO NOT include core or object files) and email the tar file as an attachment to cs417@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.