EECS 489 Lab 6: Forward Error CorrectionThis assignment is due on Friday, 25 Mar 2016, 6 pm.
IntroductionThis lab have you implement a simple Forward Error Correction (FEC) algorithm on top of the best-effort netimg application from Lab 5. Still assuming the absence of flow control and retransmission, we use a simple XOR-based FEC (or, a linear network code over GF(2)) to correct the loss of a single packet within a given window of data.
Support CodeBefore doing anything else, please make a copy of your Lab5 solution. You will need it to start on PA3. In addition to the support files for Lab 5, you're provided with support code consisting of the file fec.cpp and an updated Makefile. You should place these files in your Lab5 solution folder. You're also provided with Linux binary executable of a reference client, reffecimg and reference server, reffecdb in /afs/umich.edu/class/eecs489/w16/lab6/. As with Lab5, these are really netimg and imgdb renamed, to prevent you from running the wrong binaries when testing. The programs still refer to themselves as netimg and imgdb in the diagnostic messages printed to screen. You should be able to run your client against the provided server and the provided client against your server. There are no changes to the command line options of both programs from Lab 5. As usual, you can search for the string "YOUR CODE HERE" in the code to find places where your code goes. This lab builds upon a working Lab5 solution. If you don't have a working Lab5, you can "purchase" one from the teaching staff at the cost of 15 (ouf of 100) points of your PA3 grades.
Task 1: Server SideYour first task is to update the server code. You can search for the string "Lab6 Task 1" in imgdb.cpp and fec.cpp to find places where "Task 1" related code must be filled in. When client sends a query to the server, it also specifies the size of the FEC window (iq_fwnd) to use. The format of the query packet is the same as in Lab5 and is defined in netimg.h. In imgdb::recvqry(), this size is stored in the imgdb::fwnd member variable. The FEC window size is the number of segments from which each FEC data is computed. Think of the FEC window as advancing over the image data, jumping one full window at a time. Each time, prior to an FEC window advance, you must generate an FEC data computed over all the segments within the current FEC window.
Image transmission and FEC computation overviewThe image buffer returned by LTGA::GetPixels() may or may not divide evenly into packets of maximum-segment size (mss). You MUST use the buffer AS IS, not to make a copy of the image or resize the buffer prior to transmission. When transmitting an image, all data packets except the last one are of size mss. The image data carried in each packet (the datasize henceforth) is thus mss minus the size of all headers, including the ihdr_t and the UDP and IP headers. As in Lab5, each data byte is assigned a sequence number and the sequence number of a packet, carried in its ihdr_t, is the sequence number of the first data byte in the packet. One FEC packet is sent for every imgdb::fwnd number of segments. Each FEC packet comprises an ihdr_t header and the FEC data. The FEC data portion of the packet is of a fixed size, i.e., the same datasize as per above and is computed over the image data carried in the most recent FEC window data segments. The sequence number carried in an FEC packet is the sequence number of the first byte of the FEC window over which the FEC data is computed. Only the image data in a packet is used to compute the FEC data; the packet headers, including the ihdr_t header, are not used to compute the FEC data. When an image data packet carries less than datasize amount of image data, the FEC data is updated as if the image data has been padded with 0s up to datasize. The last FEC window of an image may be smaller than imgdb::fwnd (the FEC packet size remains the same fixed size).
ImplementationAll changes to the imgdb server code are confined to the function imgdb::sendimg(). You need to figure out how to:
Task 2: Client SideYour second task is to update the client code. You can search for the string "Lab6 Task 2" in netimg.cpp to find places where "Task 2" related code must be filled in. The provided function netimg::sendqry() computes the FEC window size fwnd and sends it to the server in the iq_fwnd field of the iqry_t packet. The function netimg::recvimg() is where all your work for this task is to be done. You can re-use the struct msghdr to receive both image and FEC data packet. The 5-line of code to do this is an adaptation of your Lab 5 code. As with the server side, you need to figure out how to:
Testing Your CodeYou should test your code with small-ish mss, say 2048 bytes, and a large enough receiver window size, say 200, to see how FEC can reconstruct lost packets. You know your FEC is working if you see gaps in the displayed image "patched/filled in" out of order. Or you can study the diagnostic messages the reference apps send to stderr. If the output reports one segment dropped in one or more FEC window but the final image is displayed without gaps, your program is working correctly. You should also play with the server's drop probability and observe how higher drop probability causes more gaps/streaks in the displayed image that our simple FEC cannot reconstruct. Multiple lost packets per FEC window will result in gaps in the displayed image. This is the expected/correct behavior. To test your handling of out-of-order packets, run your test over MWireless to increase the probability that some packets will arrive out of order.
Submission InstructionsTo incorporate publicly available code in your solution, or to pass off the implementation of an algorithm as that of another are both considered cheating in this course. If you can not implement a required algorithm, you must inform the teaching staff when turning in your assignment. Your submission must compile and run without errors on CAEN eecs489 hosts using the provided Makefile, unmodified, without any additional libraries or compiler options. Your "Lab6 files" comprises your fec.cpp, netimg.cpp, imgdb.cpp, and any other support files you modify.
To turn in your Lab6, upload a zipped or gzipped tarball of your Lab6 files to the CTools Drop Box. Keep your own backup copy! The timestamp on your uploaded file is your time of submission. If this is past the deadline, your submission will be considered late. You are allowed multiple "submissions" without late-policy implications as long as you respect the deadline. We highly recommend that you use a private third party repository such as github or M+Box or Dropbox or Google Drive to keep the back up copy of your submission. Local timestamps can be easily altered and cannot be used to establish your files' last modification times (-10 points). Be careful to use only third-party repository that allows for private access. To put your code in publicly accessible third-party repository is an Honor Code violation.Turn in ONLY the files you have modified. Do not turn in support code we provided that you haven't modified (-4 points). Do not turn in any binary files (object, executable, dll, library, or image files) with your assignment (-4 points). Your code must not require other additional libraries or header files other than the ones listed in the Makefile (-10 points).
Do remove all printf()'s or cout's and cerr's and any other logging statements you've added for debugging purposes. You should debug using a debugger, not with printf()'s. If we can't understand the output of your code, you will get zero point.