NetProg Homework 5

Homework 5: Concurrent HTTP Server and performance report
Due Date for Local and live remote students: Fri, April 5th (by 11:59PM)
Due Date for Tape and Videostream Delay students: Fri, April 12th

Late Penalty: 10 points per day (out of 100)

Submit to netprog-submit@cs.rpi.edu with the subject line "5"
Complete Submission instructions are here

Your assignment is to write an HTTP server that returns a document whose size is determined by the request URI. Your server will support a variety of techniques for providing concurrency, and you will do some performance measurements to determine which method works best for various size requests.

The contents of the document can be any HTML document you want, the size of the document is determined by the requested URI. Your server should strip the leading slash '/' from the URI and interpret the resulting string as a integer (in decimal) that indicates the size of the document to be sent to the client.

If the request line looks like this:

GET /1234
HTTP/1.0

Your server should send back a document that contains exactly 1,234 bytes of text. You should send back a valid HTML document, but the content of the document can be anything. The minimum size requested will be 100 bytes, this minimum means that you can always create a valid document (with HTML, HEAD and BODY tags). For example, the following document is 100 bytes long:

<HTML>
<HEAD>
<TITLE>100 bytes of fun</TITLE>
</HEAD>
<BODY> a a a a a a a a a a a a </BODY>
</HTML>

This document is 250 bytes long:

<HTML>
<HEAD>
<TITLE>250 bytes of fun</TITLE>
</HEAD>
<BODY> a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a </BODY>
</HTML>

Note that your server must send back an HTTP response line, a content-type header and a content-length header. None of these count towards the size of the document.

Your server should send back an HTTP response line that indicates an error if the requested URI is not a number or is less than 100.

Server Variants

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.

The first command line argument to your server will be the port number on which your server should look for clients.

For example, if your program is named hw5:

This would create a forking server - one child per client: ./hw5 1234 -f

This would create a pre-forked server with 10 child processes: ./hw5 1234 -pf 10

This would create a threaded server - one thread per client:./hw5 1234 -t

This would create a pre-threaded server with 5 threads: ./hw5 1234 -pt 5

NOTE: On solaris.remote.cs.rpi.edu you are restricted to a total of 64 processes, this includes your login shell and any other processes you may be running. You need to include code that can handle the possibility that fork will return an error (don't simply keep trying to fork, make your server quit if it wants to fork and is not able to!).

Performance Report

Once your server is working, you must test your server and make some measurements of the performance for various request sizes and degrees of concurrency. You do not need to provide timing or statistics gathering code in your server, instead you will use a client that can make lots of requests and report on the results. The ApacheBench program is available for making measurements - this program can generate multiple HTTP requests to your server with any desired level of concurrency. The program executable is installed on the CS Suns as ~hollingd/public.html/netprog/ApacheBench/ab, there is a copy of the formatted man page in the same directory. Below is sample usage of the ab program to give you an idea of what it does. The test run below sends 100 requests to www.cs.rpi.edu for the URI ~hollingd/foo.html, sending 10 requests at a time (10 clients at a time).

> ab -n 100 -c 10 www.cs.rpi.edu/~hollingd/foo.html
This is ApacheBench, Version 1.1
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998 The Apache Group, http://www.apache.org/

Server Software:        Apache/1.3.4                                       
Server Hostname:        www.cs.rpi.edu
Server Port:            80

Document Path:          /~hollingd/foo.html
Document Length:        19 bytes

Concurency Level:       10
Time taken for tests:   1.823 seconds
Complete requests:      100
Failed requests:        0
Total transfered:       26400 bytes
HTML transfered:        1900 bytes
Requests per seconds:   54.85
Transfer rate:          14.48 kb/s

Connnection Times (ms)
           min   avg   max
Connect:     0     0     5
Total:     133   178   265

Your report should focus on a comparison of the 4 concurrency modes supported by your server. The general idea is to determine which mode works best and by how much. The requests per second numbers reported by ab are probably the most useful for this comparison, the transfer rate and total time may also be useful. You should try various request sizes and levels of concurrency in your tests (what works best for small requests? is it different than what works best for large requests? , etc.) DO NOT SIMPLY SEND US THE OUTPUT GENERATED BY ab! You are to write a report that summarizes your findings and includes enough information so that we could reproduce your tests. Convince us that you have thought about which model of concurrency is best for various patterns (size/concurrency) of requests.

There is no specific correct result/conclusion we are looking for. Instead we are looking for an indication that you have thought about what to measure and how to measure it. Your report should be no more than 2 pages and should include some conclusions about what kind of concurrency you think works best for various patterns of requests. Some reasonable parameters to test include (these are not required, just an example to give you and idea of what kinds of things you can test):

small requests vs. large requests.
level of client concurrency is greater than server concurrency vs. fewer clients than server processes/threads.

Deliverables

You should submit all the files necessary to build and run your server. Your submission must also include a file named README that includes the following:

Your Name
Instructions on how to build your server.
A list of files and a 1-line description of the contents of each file.
References to any borrowed code (the source code must also include this information).
A description of any known problems. If you think you know how to solve the problem(s) and simply didn't have time to do so - let us know how!
Anything else you think might be useful to us, such as what you learned, what you had trouble with, if the project was too hard or too easy, etc.

Your submission must also include your report - this can be a plain text file, MS Word, PDF or HTML. Other formats may be fine as well, but please ask first to make sure. If you would prefer to submit your report as hardcopy that is also fine, but it must be given to Dave or a TA before the project deadline. Please don't submit a report any longer than 2 pages, your report is meant to be a description of your tests, a summary of the results of the tests and a conclusion.

Grading

Your server must support all four concurrency models, and we must not be able to crash it or get it to hang by sending invalid requests. You must take care of zombies and avoid memory leaks. Your server must send back documents of the requested size. Your server must always send back a valid HTTP response line.

Points will be awarded as follows (partial credit is available for each item):

Server works properly with valid requests (supports all 4 concurrency models).	40%
Server can handle any kind of nonsense.	10%
Writeup (your report).	25%
Code Style/readability	25%

Note that the report is worth 25% of the grade, so you need to worry about this! Pretend that you have been assigned to determine the architecture for a web server your company is writing. Your report must convince others that you understand the issues, have made a complete set of measurements, and have data to back up your conclusion(s).

Submitting your files

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 (5 for HW5). 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.

Homework 5: Concurrent HTTP Server and performance report Due Date for Local and live remote students: Fri, April 5th (by 11:59PM) Due Date for Tape and Videostream Delay students: Fri, April 12th