CS 536 (Park) Assignment VI Due: Nov. 23 (Tue.), 2004Submission instructions: Please type your answers and submit electronic copies using turnin by 5pm on the due date.You may use any number of word processing software (e.g., Framemaker, Word, LATEX), but the final output must bein pdf or ps format that uses standard fonts (a practical test is to check if the pdf/ps file prints on a CS Departmentprinter without problem). For experiments and programming assignments that involve output to terminal, please usescript to record the output and submit the output file. Use gnuplot to plot graphs. Use ps2gif to convert a eps/psplot to gif format (e.g., for inclusion in Word).PROBLEM 1Read Sections 5.1, 5.2, 5.4, and 6.3 from P & D.PROBLEM 2 (10 pts)Read “Congestion avoidance and control” by Van Jacobson. In Proc. ACM SIGCOMM ’88 , pp. 314–329, 1988. Thepaper (a version thereof) can be found athttp://www-nrg.ee.lbl.gov/papers/congavoid.pdfGive a one-page summary and critique.PROBLEM 3 (15 pts: for the plan, not the project)Write a 3-page project plan as follows: (i) any relevant background, (ii) what you aim to do, (iii) why you find itinteresting and worthwhile, (iv) specific output—in DARPA jargon, “deliverable”—that you will produce, (v) thespecific steps you plan to take to achieve the target outputs, and (vi) what you expect to find (your clear/fuzzy gutinstinct although you may be proved wrong). Your project has the following components: idea, implementation,benchmarking, measurement, and interpretation of the results. These need to be written up, in a professional manner,in a 15–20 page report (11 pt font, A4 letter) including plots and (any) references. The project plan is due on Nov. 15(Mon.), 2004, in hardcopy, submitted at the beginning of class. I will check it and return my comments Nov. 17, inclass. It will either be a pass or revision required. What I will look for is the soundness of the plan, its scope andfeasibility. Scope is of paramount importance: you do not want to propose something overly grandious that cannotbe feasibly tackled in the given time frame (project is due Dec. 18, 2004). View it as an assignment, albeit solvinga single “heavy-weight” problem in place of 3–4 smaller problems that a typical assignment contains. Project ideaswill be posted on the course web page. Your project need not be confined to this list. You may form a group ofup to 3 people. The pros are: divide-and-conquer, share in the fruits of the joint effort. The cons are: coordinationoverhead, share in the fruits of the joint effort. (In a group effort, each group member gets the same project grade.)PROBLEM 4 (40 pts)As a continuation of Problem 4, Assignment IV, extend cbrsend v2, call it cbr send v3, such that it uses the first4 bytes of the payload as a sequence number field to keep track of sent packets. Modify the receiver cbrrecv so thatit records the sequence number—along with the other information logged—in main memory that is then dumped todisk at the end of the run. The receiver should also count, in real-time, the number of dropped packets during thespecified time-window argument and output to stdout both the number of dropped packets and loss rate (droppedpackets divided by the number of packets sent during the time window). Lastly, add a termination check to thereceiver so that upon receiving a packet with the sequence number (unsigned integer) all 1s it goes into terminationmode as with SIGINT. The sender, after transmitting packet-count number of packets, sends 10 of these specialtermination packets using a 100 msec spacing, to signal the receiver that it should terminate. The SIGINT basedtermination mode remains so that manual intervention with graceful shutdown can be affected.Benchmark the CBR sender/receiver application on two Xinu machines with payload-size 1 KB, packet-count 100000(you need to increase the initial array size allocated), packet-spacing 10 msec, and burst-size 2. Using gnuplotdraw the time series plots in Problem 4, Assignment IV, under aggregation time window 500 msec that includes thepacket loss plot. Benchmark the application by porting the Linux code to your Linux PC at home/dorm/undisclosedlocation—only if you have cable/DSL broadband connection (or faster)—and repeat the experiment by sending fromthe Linux PC to one of the Xinu machines. Perform the benchmark experiment in reverse direction by sending froma Xinu machine to your Linux PC. If you have a Linux PC but do not have broadband connection (but have freelocal calling telephone service), then use your 56 Kbps modem for the experiment with packet-spacing 100 msec andpayload-size 200 B. In this case, for comparative purposes, you need to additionally run a corresponding benchmarktest between two Xinu machines at this spec. If you don’t have a Linux PC at your residence or you don’t have freelocal calling, then use one of Purdue’s public Linux/UNIX accounts to carry out the “remote” benchmark experiment.Using your measurement data and plots, discuss your findings.PROBLEM 5 (60 pts)Design, implement and benchmark a UDP-based peer-to-peer (P2P) pseudo real-time audio streaming application.Your application can be built on top of the CBR sender/receiver application, with suitable modifications. The sender,myaudio send, takes as command-line arguments% myaudio send IP-address port-number audio-file packet-size packet-spacing modewhere audio-file is a stored audio file that will be streamed to the receiver (i.e., client)—unless otherwise indicated,assume the file format is binary—packet-size (in bytes) is the size of the UDP payload (excluding 4-byte sequencenumber) at which unit the audio file will be segmented and transported, packet-spacing (msec) is the initial packetspacing used in the CBR transmission of the audio file, and mode specifies the congestion control mode: 0 (methodA), 1 (method B), 2 (method C), and 3 (method D). The receiver, myaudio play, has command-line arguments% myaudio play port-number time-window log-file packet-size pb-del pb-sp buf-sz target-bufwhere pb-del is the initial playback delay (sec)—time delay from the arrival of the first audio packet—pb-sp (msec)is the time interval at which buffered audio is written to /dev/audio for actual playback (triggered by SIGALRM),buf-sz is the total allocated buffer space (bytes), and target-buf (bytes) is the target buffer level (i.e., Q∗). In thereceiver’s code structure, attention