HW1: Network Socket Programming

CS 493/693 Homework, Dr. Lawlor, 2006/01/23. Due at 5pm on Monday, Jan 30.

Here are a set of questions related to network socket programming. All the questions relate to the code in the hw1 support directory (Zip, Tar-gzip) You're welcome to use my "osl/socket.h" library, or use real Berkeley sockets, as long as I can just build and run the code on my Linux box without futzing. Prepare the input files below, and turn them all in on Blackboard by clicking "View/Complete Assignment", attaching the files, and then "Submit". Note that you've got to get the filenames and contents *exactly* right, or my grading script won't find them!

File Name	From
problem1.txt	Observations on tinyserver.cpp and tinyclient.cpp
problem2.cpp	tinyserver.cpp modified to process multiple clients
problem3.cpp	tinyclient.cpp modified to talk to twoserver.cpp
problem4.cpp	webserver.cpp modified to actually serve files
problem5.cpp	vulnserver.cpp modified to crash vulnclient.cpp

Try running these network programs in various weird ways, and see what happens. Turn in the file "problem1.txt". You can add comments to this file, but I probably won't look at them.

(A) What happens if two copies of tinyserver.cpp try to listen on the same port of the same machine at the same time? If it gives an error, put the exact error text into the file problem1.txt. If it works, put the line "A works" in problem1.txt.

(B) What happens if you run tinyclient.cpp without running the server? If it eventually gives an error, put the exact error text into the file problem1.txt. If it works, put the line "B works" into problem1.txt.

Change tinyserver.cpp so rather than exiting after processing a client, it goes back and waits for additional clients. Your modified version should never exit unless something goes horribly wrong. Turn in your modified tinyserver.cpp as "problem2.cpp".

Change tinyclient.cpp to support a two-pass communication protocol. After connecting to the server, first send a count as a 32-bit big-endian integer, then the count bytes of message data. The message should by default be the 7-byte message "foobaby", but (for style points) should be easy to change in the future. You can use "twoserver.cpp" as a server for testing. Turn in your modified tinyclient.cpp as "problem3.cpp".

Change webserver.cpp so rather than just echoing the request, it actually serves a web page from a file. Only allow access to files in a directory called "public_html" in the same directory where the program is run. So for example if the HTTP request is "GET /foo.html HTTP/1.1", serve back the contents of the file "public_html/foo.html". Don't worry about spaces in the filename (or URL encoding), or functionality for filenames longer than 100 characters. You can test out the server by pointing a real web browser at http://localhost:1234/foo.html. Turn in your modified webserver.cpp as "problem4.cpp".

If you're taking 693, you MUST also implement these features.
- Real file lengths, instead of just reading the first 128 bytes of each file like the crappy webclient.cpp expects.
- A working "cgi-bin/shutdown.cgi" URL that exits the server. You don't have to implement this as a real CGI--just hardcode the functionality into the server.
- Subdirectories of public_html. For example, "GET /bar/foo.html HTTP/1.1" should return the file "public_html/bar/foo.html".
Students in 493 need not implement these features, and won't get extra credit for doing so, but may impress their professor.

There's a subtle security vulnerability in vulnclient.cpp. It's not exposed with the current string vulnserver.cpp sends, but it's definitely there. Read vulnclient.cpp to determine the problem, and modify vulnserver.cpp so vulnclient crashes. Turn in your modified vulnserver.cpp as "problem5.cpp".

The code you write for this homework (and heck, anywhere in life) must be:

Secure. It MUST NOT contain buffer overflows or other security holes. In particular, problem 4 MUST NOT allow access to files outside the public_html directory (e.g., "C:/", "/etc/passwd", "../../foo.txt").
Robust. It shouldn't crash or stop working right for very long or weird input.
Fairly easy to understand. Add good comments, don't egregiously duplicate code, etc.