Data Networks: Project 1 Grading

This document describes how we graded your submissions for project 1.

Important note about project requirements

For each project assignment, we specify the requirements you have to meet. The requirements for the first project included, for example, a working Makefile and a running implementation of the solution that can be started with a given command line and argument list. While we have been generous this time if someone failed to meet even the basic requirements, we will not do so for future assignments. IN THE FUTURE, PROJECT REQUIREMENTS WILL BE ENFORCED STRICTLY. WE WILL NOT BE ABLE TO GRADE SOLUTIONS THAT DO NOT INCLUDE A WORKING MAKEFILE, OR DO NOT WORK WHEN STARTED WITH THE SPECIFIED COMMAND LINE AND ARGUMENTS, ON THE SPECIFIED SET OF COMPUTERS (i.e., CIP machines).

This time, we made a reasonable effort to get your submission to run, even though this is not our responsibility. We will not be able to do so in the future. Still, we were unable to compile or run some of the submissions. We still gave some points for providing documentation, when appropriate, in these cases (see below for details).

Also, please make sure that we receive your submission on time. Keep in mind that emails take some time to arrive in the receiver's mailbox. Thus, you should send your submission early enough to meet the deadline. We were generous when your submission arrived a few minutes late, but we might change this policy for the upcoming submissions.

Goal of this project

When designing distributed applications, you have to be aware of all the things that can go wrong in the Internet. Besides valid inputs and common conditions, there are a large number of corner cases you have to take care of, such as lost, corrupted, reordered and delayed messages. Moreover, you have to anticipate that a client program might be faulty. In such cases, the faulty client's request cannot be fulfilled; however, the server must not crash or hang indefinitely as a result of a bad request. Designing for the failure-free case is relatively simple, but hardening protocols and systems against unexpected behavior and conditions (and you can find a lot of these in the Internet) is difficult, but extremely important. Part of this assignment's goal was to learn this. Therefore, our test cases cover, besides the "good cases", many corner cases. Our test may have exposed situations you have not thought of while implementing your solution.

Documentation - 10%

The project assignment asked you to provide your project source code zipped in an archive, equipped with a working Makefile, and a description of your project in a Readme file.

Meeting these requirements contributed 10% to the final grade:

• Readme file: 3%
• Working Makefile: 5%
• Source code zipped: 2%

PING-PONG server - 55%

We came up with some test cases to evaluate your solution. We were using our own client implementation. If you implemented the protocol correctly, the interaction of our client with your server should be no problem. In case this failed, you still get points if your own client-server implementation works.

• Server-client interaction - 30%
  • Does the provided client-server implementation work?

• Valid PINGs - 15%
  • Server can handle PINGs with length 0
  • Server can handle small PINGs
  • Server can handle very large PINGs

• Broken and multiple PINGs - 10%
  • Server can handle PINGs with an incorrect length field (either too small or too big).
  • Server can handle multiple connections.

HTTP server - 35%

We ran exhaustive tests to challenge your http server implementation with cases that it could face when deployed in the Internet.

In all cases, your HTTP server should either send back the correct file or send back an appropriate error code. In general, we were generous when you sent back reasonable error codes. The acceptable responses in each case are stated below. The points in each subcategory are equally split between the individual tests.

• Valid requests - 15%
  • Request for existing text files: response contains the entire requested file
  • Request for non-existing files: 404
  • Request with additional HTTP headers: response contains the entire requested file

• Unexpected requests - 10%
  • Request using an http version other than 1.1: 400, 501, or 505
  • Request using a command other than GET: 400 or 501
  • Request for a very long URL: response contains the file
  • Request for a very large file: response contains the file
  • Request for a directory: 400, 403, 404, 501, directory listing, or index.html file in the directory
  • Request for a binary file: 400, 501, or the file with the correct MIME-type in the header. You cannot send back the file with Content-type set to text/html!
  • Request a file with ".." in the path name: 400, 403
  • Request with non-ASCII characters added to the URL: 400, 404. Your server should not be confused by the non-ASCII characters.

• Broken and concurrent requests - 10%
  • Split the request into two packets (spaced by 1 second): send back requested file after receiving the whole request
  • Send an incomplete request (stop in the middle of the GET request): time out after a while, do not lock up.
  • Send concurrent requests. This is split in two parts. We tested concurrent valid requests (e.g., requesting an existing file) and concurrent invalid request (e.g., using the wrong http version): handle all incoming requests, either sequentially or concurrently and, of course, appropriately. Do not lock up on invalid requests.