Your assignment is to write an HTTP server that returns a document whose size is determined by the request URI. Your server will support 2 different for methods of providing concurrency, and you will do some performance measurements to determine whether there is a noticable difference between the two methods of concurrency.
The contents of the document returned by your server 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
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.
The focus of this project is on the development and testing of a concurrent server. Your server must be capable of providing concurrency in 2 different ways, either a forking server (new child per request), or a pre-threaded server. A command line option is used to select the threaded server and the number of threads that should be created when the server initially starts.
The first command line argument is the port number that your server should bind to. This is the only command line argument required for the forking server (if only one command line argument is used, your server should be a forking server).
If a second command line argument is found, your server should treat this as the number of threads to be used for a pre-threaded server.
Usage: lab4 portnum [num_threads] ./lab4 1234 starts forking server on port 1234 ./lab4 3333 100 starts pre-threaded server on port 3333 with 100 threads
Once your server is working, you must test your server and make
some measurements of the two methods of concurrency 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.
Below is sample usage
ab program to give you an idea of what it
does. The test run below sends 100 requests to www.cse.unr.edu for the
URI ~mgunes/foo.html, sending 10 requests at a time (10 clients at a
> ab -n 100 -c 10 www.cse.unr.edu/~mgunes/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.cse.unr.edu Server Port: 80 Document Path: /~mgunes/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
You must write a brief (1-2 pages) report that describes your tests, summarizes the results, and provides some insight into what the results mean.
Your report should focus on a comparison of the 2 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
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 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.
Develop a tool that will utilize probability distribution functions to make requests to test your web server.
Note that, for this part you need to implement sessions. That is, you keep a socket connection open for multiple requests. However, you should have a timer that will terminate the connection after 1 min of no activity.
60% of your grade will depend on your server code (we will build and test your server), the other 40% depends on your report.
Up to 75 points bonus as described above.
You must submit all the source code necessary for us to build your system. Your submission must also include a README that includes your name and a desciption of each file submitted (and anything else you want to tell us).
You must also submit your report as part of your submission.
Finally, feel free to include a description of any problems you had or anything else you think might be helpful to us.
Submission of your homework is via WebCT. You must submit all the required files in a single tar or zip file containing all the files for your submission.
Acknowledgement: The assignment is modified from Dave Hollinger.