Warning: This is not for the current semester.
For this assignment you will need to use a port number which nobody else will be using. Each student is assigned a set a 10 port number for this assignment. The list can be found here.
Part 1: Get the sample code
Obtain the client, server, and UICI code from
/usr/local/courses/cs3733/spring99/assign06,
compile and link them and make sure they work.
Part 2: Web redirection
You are going to write a program which
will allow browsers to point to the machine you are running on
and redirect requests to another web server.
Here is how it will work.
You will be assigned a port number, p. You will write a parallel UICI server which will listen on port p. When a connection request is made to port p, you will make a connection request to port 80 (the web server port) on ringer (our web server machine) and fork a child to handle the communication. The child will then monitor input on two communication channels, the one corresponding to port p on the local machine and the one corresponding to port 80 on ringer. Any input coming in on one port will be sent to the other. If either connection is closed, or an error occurs, both communication channels should be closed and the child should exit, but the parent should continue listening for additional connections.
Every time a connection is made, a message should be sent to standard error indicating the name of the machine the connection came in on. When the connection is closed, another message should print out the number of bytes that was transferred in each direction. This message should also contain the name of the machine which initialized the connection.
Test your program by having a browser point to your machine and try to access your course web page. If your web page is on ringer (www.cs.utsa.edu) in ~yourname/yourdir, and you are running on machine host, using port p, use the following URL: http://host:p/~yourname/yourdir
Your web page should come on on your browser.
Part 3: Web redirection with monitoring.
Use your filter and filter_header from the previous
assignment to display lines of printing characters
that are transmitted during a web session.
Create two pipes, fromclient and fromserver.
Have your parent open these pipes and use these file descriptors
for monitoring. If your assignment 4 or assignment 5
was working correctly
you should be able to use the filter and header_filter
programs from that assignment without change.
The filter function requires 6 file descriptors.
Note that the two communication
file descriptors from your UICI connections are used for both
input and output.
Although these programs should work without modification, you might want to modify them so that they use u_read, u_write, and u_close in the appropriate places. Note the the I/O to the monitors is not network communication.
You might also want to modify header_filter so that it resets itself to its initial state after receiving a buffer containing non-printing characters not terminated by a newline.
Test your program by opening two windows in which the contents of the pipes fromclient and fromserver are displayed.
Part 4: Write a Web server. This part is optional.
Write a web server.
You can use what you see from part 3 to guess what is going on,
or you can read about how web servers work at
http://www.jmarshall.com/easy/http/.
The idea of a web server is very simple. It listens on port 80
for connection requests. (You will have to use your own port number.)
When a request comes in, it starts looking for header lines of a
specific format. It interprets the ones it understands and ignores
the others. One type of header line requests that a file on the
server machine be transmitted to the client. The server then
sends the appropriate header lines and data to the client.
A simple web server (one that does not support CGI) does not have to be able to receive data from the client, only header lines. It only has to understand a very few types of header lines.
See if you can write a web server that will allow a browser to read a web page that only contains text. Then see if it will also handle GIF or JPG files. It turns out that the server does not have to do anything special to handle these. You might even try transmitting sound.
Here is a what a very simple web server will do.
Listen on port 80 for a connection. When a connection is made, read a line of printing characters. This is called the initial line. There are two main types of initial lines that need to be recognized. All others can be ignored.
GET /filename HTTP/1.0
is an request for a particular file. Strip off the leading slash and treat the rest as a file relative to the current directory. You will then send some header lines and this file to the remote machine.
HEAD /filename HTTP/1.0
This is the same as GET except that only the header lines are sent, not the actual file.
After receiving the initial line, the server reads additional lines until a blank line is found. You can ignore these lines.
The server then sends a response line. The initial response line indicates success or failure. Here is a typical success line:
HTTP/1.0 200 OK
and here is a typical failure line:
HTTP/1.0 404 Not Found
You can get by with just these initial response lines.
After a failure, you can just send a blank line and close the connection.
After a success line you will send the requested information after a few more header lines. The last header line is a blank line.
After a success, you need to send additional header lines with information about the file you are going to send. Each line contains a piece of information such as the size of the file, creation date, type of contents, etc.
You should include the following message lines:
Content-Type: text/html
Content-Length: 12345
In the above example and html file is being sent containing 12345 bytes. After these lines, a blank line is sent followed by the 12345 bytes of data from the file.
If the file being sent was a gif file, you would use the following line:
Content-Type: image/gif
After sending the data, close the connection.