DokuWiki

(Though these are just the answers ;^)

• I always run the proxy server on hive.sewanee.edu even though it may not be strictly necessary. If you are having issues connecting from telnet/browser to the proxy server, try it on hive.sewanee.edu. If it still doesn't work, the problem must likely is in your program.

• The Tiny web server's parse_uri function is a good example of techniques to parse Request Headers; borrow from it liberally

• The Tiny web server code is also a good example of how to send information from the proxy back to the client

• Collecting everything the client is sending to the server and writing it all at once works fine however it is still necessary to screen out the Keep-Alive headers, etc. The reverse is not true: read information from the web server one line at a time, and sent it to the client one line at a time.

• As explained in the text, the server will send EOF when the file it is sending is complete. Check with Chapter 10 or the code in csapp.c to see what rio functions return when they receive EOF.

• You can probably get communication from client→proxy and proxy→server working fine when testing with telnet, and the web browser still won't work. If that happens, make sure you've modified the request headers as explained in the Tips section.

• Also, working telnet tests are worth a good bit of partial credit even if web browser tests do not all work.

• Usually buffered I/O to files (for logging) do not finish if the file is not closed. Rather than close it each time you modify log file, use the function fflush to force all changes to be written to the file, especially if you are using buffered I/O.

Use the model in the text/notes of the threaded echo server. After a connection has been accepted, everything you did to service the client/server interaction in the non-multithreaded version goes in a thread function. If you already had that in a separate function, this much will be relatively easy.

Testing…not so much. Initially test the same way, one request at a time. However the way to know this is multithreaded environment is to attack it with multiple requests at the same time. Make sure one request doesn't complete before the next starts.

All writes to the log file must be protected with a semaphore, so different threads don't overwrite each other's output.