600.211: Unix Systems Programming

Fall Semester 2005: September 8, 2005 - December 12, 2005

Assignment 4: Serving the Web

Out on: October 25, 2005
Due by: November 6, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration: Teams
Grading: Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%

Overview

The fourth assignment for 600.211: Unix Systems Programming is all about writing your own web server. This is a team assignment, and all of you should know which team you're in (I hope). Each member of a team will receive the same score for the product you submit together. Note that some parts of this assignment are not 100% about the actual web server code. You'll see... :-)

Problem 1: Team Website

Consider yourself a startup company with a plan to take over some segment of the web server market. You're pretty sure that attacking Apache is not going to work, but maybe in some niche market you can actually make money? Anyway, your first task is to set up a website for your shiny new company; be sure to include the following:

An overview of who you are and what you're doing (the "front door" of your site).
Some kind of "white paper" that explains the "special thing" your webserver will do.
Some kind of "time line" that lays out your basic plan for the development of your product.
Bios for all you guys/gals, hopefully making a professional and trustworthy impression.
Documentation for your product, addressing how to install, configure, and run it.
A page where potential clients can download the latest tarball to try your product.
Whatever else you can think of. :-)

Please make sure that your website validates as XHTML 1.1 (check the HTML for this page to see how to add a suitable link). Please put your website online somewhere and email us the URL as soon as possible! You still have to submit the HTML for your website when you submit the rest of your assignment!

Problem 2: Versioning and Automation

Aside from making a decent "public" impression with your website, your development environment should also be set up in a somewhat professional way. Here are some of the things you should do:

Maintain all your artifacts for this project in the Subversion repository provided for your team. This includes your website, your documentation, your code, and any supporting scripts and programs you write (e.g. for this very problem).
Use make to automate the build processes you need, for example to create PDFs from your raw documentation, to actually compile your product, to update your website, etc. Note that creating tarballs for distribution or running unit or system tests should also be automated.
Use cron to regularly build and test your code (every 24 hours). The results of your tests should be emailed to your team mailing list. Aside from commit notifications from Subversion, having build and test results "visible" to everyone also increases "awareness" inside your team. And it helps you blame the right person for breaking a build. :-)

Note that documentation in some plain text format is easier to maintain in Subversion than opaque prorietary formats; we recommend plain ASCII text, troff or man page format, LaTeX, or DocBook. Also, cron can be a bit tricky to use. Remember that it works on a "per machine" basis, not on a "per account" basis. So don't change crontabs all over the place, and only have one person be responsible for setting this up. You must submit all your automation scripts and a short description of your automation setup when you turn in your project!

Problem 3: Basic Web Server Prototype

You are producing the first version of your webserver for this assignment, so there are no "fancy" requirements yet. Obviously you need to implement the Hyper Text Transfer Protocol, otherwise we can't really talk about building a web server. Actually HTTP/1.0 is good enough for now, but you may want to think about HTTP/1.1 already. You don't even have to implement all of HTTP/1.0 for now, authorization is a good example for something you could ignore; make sure you document what parts of HTTP/1.0 you do not support yet. Here are some things you really should support though:

Obviously you cannot have a web server that doesn't support the GET request; don't try to sneak anything else past us. :-)
Your web server should keep a log file of all requests received and how they are processed. Consider using the syslog service maybe? You don't have to...

Feel free to check out other web servers for ideas. It might also help to check out really small web servers, for inspiration, but don't read their sources in too much detail; after all, you don't want to get into some "intellectual property" dispute, right? :-)

Hints

There's really only one hint: Remember that you're going to maintain the code you produce for this assignment for a while. Aside from writing clean code, it may be a good idea to start documenting in a way that allows others to just read the documentation for a certain module, not the module itself. I recommend looking at doxygen for that.

Deliverables

Please turn in a gzip compressed tarball of your assignment (the extension should be .tar.gz). The tarball should uncompress into a directory cs221-assignment-4-login with login replaced by your Unix login name (so I would use cs211-assignment-4-phf); uncompressing should not create any other files in the current directory. The tarball should contain no derived files whatsoever, but allow building all derived files with make. We expect that your Makefile handles "the usual" targets like clean and test aside from all (which is the main way we will build your program). Include a README file that briefly explains what the program does and contains any other notes you want us to check out before grading; make sure the README lists all members of your team! Include other "common" files such as INSTALL describing how to install your tool, CREDITS to pay your respects to the people whose code you're reusing, and LICENSE to describe copyright and distribution terms if you feel like it. You can look at any number of "famous" open source projects to see what kind of structure is appropriate; gif2png is a relatively small example, but you don't need everything in there. However, seeing as we're now getting close to an actual product, you should give a "real" distribution some thought.

Grading

For reference, here is a short explanation of the grading criteria. Packaging refers to the proper organization of the stuff you hand in, following the guidelines for Deliverables above. Style refers to C programming style, including things like consistent indentation, appropriate identifiers, useful comments, etc. Simple, clean, readable code is what you should be aiming for. Performance refers to how fast your program can produce the required results compared to other submissions. Design refers to proper modularization and the proper choice of algorithms and data structures; often this can be judged by asking "How hard would it be to add feature X?" and "How hard is it to replace algorithm X with algorithm Y?". Functionality refers to your program being able to do what it should according to the specification given above; if the specification is ambiguous and you had to make a certain choice, defend that choice in your README file.

If your program cannot be built you will get no points whatsoever. If your program cannot be built using make we will take off 10%. If your program cannot be build without warnings using gcc -W -Wall -O -ansi -pedantic we will take off 10% (except if you document a very good reason). If your program fails miserably even once, e.g. segfaults or runs forever, we will take off 10%. Since you are handing in way more stuff this time, it could be that we find another reason to take some points off; it's not too likely though.