Your assignment is to develop a simple HTTP server that can process requests for static files (can send back whatever file is named in the request). Your server must support the file types listed below:
| File Name Suffix | Content Type |
|---|---|
| .html | text/html |
| .gif | image/gif |
| .jpg | image/jpeg |
Note that your server must include a content-type header (based on the table above) and a content-length header. Your server does not need to worry about the contents of the files it sends back to the browser - it can rely completely on the file name suffix.
Your server should map URIs to files by turning the URI into a relative path by simply removing the leading slash from the received URI and use what's left as a relative path (relative to the directory in which the server process was started). If a request is received that does not correspond to a file your server must return an HTTP error (404 - Not found).
For example - if the current directory holds the files
foo.html, calvin.gif and
pizza.html and the server is started up from a shell
session while in that directory - the URI /calvin.gif
should result in sending the file calvin.gif back to the client. It is
expected that you can simply attempt to open the file specified by the
URI (after removing the leading slash) - if the open fails send back
an HTTP error (404). Note that a URL may involve a path (not just a
file name), so your code should be able to handle things like
/foo/calvin.gif (but you don't need to do anything
special to support this).
NOTE: Your server does not need to deal with requests that
map to directories - you only need to worry about files. You server
should
not crash if given a URI like "/foo/blah/" or even
"/", but it can simply return an HTTP error.
NOTE: In general it's a bad idea to use URIs as relative
paths without looking for and removing ".." components from a path.
For example, you wouldn't want a real web server to send back the file
/etc/passwd if the request was
/../../../../etc/passwd. You don't need to worry
about this issue for this assignment.
The focus of this project is on the development of a concurrent server. Your server must be capable of providing concurrency in 4 different ways, a command line option is used to select the mechanism used. The table below lists the command line options and the resulting method of concurrency:
| Command line option | Method of concurrency |
|---|---|
| -f | Forking server, one child per client. |
| -pf | Preforked server, the number of child processes is specified on the command line as an additional argument. |
| -t | Threaded server, one thread per client. |
| -pt | Prethreaded server, the number of threads is specified on the command line as an additional argument. |
For example, if your program is named hw5:
This would create a forking server - one child per client:
./hw5 -f
This would create a pre-forked server with 10 child processes:
./hw5 -pf 10
This would create a threaded server - one thread per client:./hw5 -t
This would create a pre-threaded server with 5 threads:
./hw5 -pt 5
Your submission must include all the source code for your system and a README file that describes each file and how to build your program.
The grading will be based on the same formula used for the other projects: 50% for basic functionality, 25% for how well your server deals with unexpected requests, memory allocation (no leaks!), error handling, cleaning up after childen,etc. The last 25% is for code quality. I am instructing the TA to be much more critical of code quality for this project than for previous projects - if you hand in a program with no comments that is not easy to read you will lose 25%!.
Start with your HW2 server code, modify it to send back files instead of calling crawling functions. Get this part working as an iterative server before worrying about concurrency.
Package up the code that handles one request so you can easily call it as a new thread, or from a child process
Read chapters 23 (Threads) and 27 (Server Design). There are lots of things to consider when creating pre-forked and pre-threaded servers, the book covers the alternatives.
Submission of your homework is via email, the general idea is to send an email message with all your files as attachments. There is an automated email submission system that will respond to your submission right away, so you will have a record that we got your files.
All projects must be submitted via email to netprog-submit@cs.rpi.edu. The subject line of the submission message should contain a single number indicating the project number (1 for HW1, 2 for HW2, etc.). You must include your files as attachments, feel free to send a zip-file or a tar file.
Don't send compiled code!
You can expect a return email indicating receipt of your project submission immediately. This receipt will include a list of all the files that were successfully extracted by the submission script - please look over the receipt carefully to make sure your submission worked.
Multiple Submissions: You can resubmit up to 10 times for each project, we will always grade the last submission received unless you tell us otherwise.