CS433/533 Homework Assignment Three (Part 1): HTTP Protocol and Web Server

This assignment gives you a chance (Part 1) to better understand HTTP design, including its protocol and the processing at the server (Part 1). In Part 2, we will extend part 1 to give you a chance to become more familiar with concurrent network programming, covering topics including threads, synchronization, wait/notify (monitor), asynchronous I/O, and benchmarking. Hence, when designing Part 1, please consider extension to Part 2 in mind.



The server that we will design is a simplified version of HTTP 1.0. The most basic application message, encoded in ASCII, from the client to the server is:

Host: <ServerName>

where CRLF is carriage return and line feed, representing an empty line. This request asks for the file stored at location <DocRootServerName>/<URL>, where DocRootServerName is the root directory for the requested server name.

For example, if <DocRooServerNamet>=/tmp/mydoc, and <URL> is /file1.html, the server will return the file /tmp/mydoc/file1.html, if it exists. If the request does not specify the Host header, the server returns the first server (virtual host) configured; see below.

The basic reply message from the server to the client, encoded in ASCII, is:

HTTP/1.0 <StatusCode> <message>
Date: <date>
Server: <your server name>
Content-Type: text/html
Content-Length: <LengthOfFile>
<file content>

CRLF again represents an empty line. If the file is found and readable, the returned <status code> is 200 and you can give a message such as OK. Otherwise, please give an error code of 400. If you are curious about HTTP error codes, you can see http://www.ietf.org/rfc/rfc1945.txt. You can use Java File class to obtain file size.

Part 1a: Simple Client

Your test client should be multi-threaded. The client can generate test requests to the server with the following command line:

%java SHTTPTestClient -server <server> -servname <server name> -port <server port> -parallel <# of threads> -files <file name> -T <time of test in seconds>

In a typical deployment, we do not need to specify both server and servname. For example, in a typical setting, a Web hosting server with IP1 may host multiple virtual hosts named www.vh1.com, www.vh2.com. All of these DNS names will resolve to the same IP1. But for our testing, since the zoo machine typically has only a single DNS name, we add the servname switch to specify the virtual host.

The <file name> is the name of a file that contains a list of files to be requested. For example, a file may look like the following:


Then each thread of the client will request file1.html, then file2.html, then file3.html, and then file1.html. The thread then repeats the sequence. The client simply discards the received reply. The client stops after <time of test in seconds>. The client should print out the total transaction throughput (# files finished downloading by all threads, averaged over per second), data rate throughput (number bytes received, averaged over per second), and the average of wait time (i.e., time from issuing request to getting first data). Think about how to collect statistics from multiple threads.

Part 1b: Sequential and Per-thread HTTP Servers

In class we will cover multiple approaches to implementing network servers. In Part 1, you will need to implement only the sequential server an the per-thread server.

You can feel free to reuse the example code provided in class.

When your server executes, it must support the following: