Assignment 3: Writing a Pattern-based Web Client and Server

The purpose of this assignment is to deepen your understanding of reactive I/O, OO event demultiplexing, and active objects in the context of the ACE C++ toolkit. As before, we will write two programs: (1) a Web client and (2) a Web server. In brackets are some hints about what kinds of ACE frameworks and classes you should use.

In addition to the ACE C++ socket wrappers, the frameworks that you must use for this assignment are the ACE ACE_Reactor and ACE_Acceptor. The other hints are simply for your convenience. Graduate students are required to use the ACE_Connector on the client -- for ugrads this is optional.

Web Client

The Web client program should do the following activities:

Read the URL and the server port number from the command line. Create a socket that is connected to the server machine at the specified port (e.g., HTTP port 80) [ACE_Connector, ACE_INET_Addr, ACE_SOCK_Connector, ACE_SOCK_Stream].
Send the request URL to the server, read all the content coming back across HTTP connection, and write the content to a temporary file created in your Web cache (e.g., using ACE_FILE_Connector::connect()) on the local host [ACE_File_Connector, ACE_File_IO, ACE_SOCK_Stream]. Make sure that the client won't hang indefinitely if the server fails to follow the HTTP protocol or of the network and remote hosts fail. For instance, make sure that all of your sends and recvs can time out after a fixed period of time has elapsed.
As before, grad students should spawn an external viewer to display the file. You should determine the type of viewer using the MIME content type information returned by the server. Your client should parse this information and use it to determine which viewer to spawn.

The client should print out the appropriate error message [perror] and exit with a return status of 1 if any of the system calls fail to work properly. If everything works correctly, the program should exit with a return status of 0.

Web Server

The concurrent multi-threaded server program should do the following activities:

Create an Internet domain ``passive-mode'' stream socket on a port number specified on the command line [ACE_Acceptor,ACE_Svc_Handler,ACE_SOCK_Acceptor] and wait in the main thread for connections to arrive from clients.
When a client request arrives, the handle_input method of the ACE_Acceptor will automatically accept the connection and call the open method of the subclass of ACE_Svc_Handler that you use defined. The open method is a hook that you fill in to activate your service handler once the connection has been established.
There are a number of ways to implement the open hook function (which we will discuss in class). One way is to turn the newly connected service handler into an active object (using the activate method inherited from ACE_Task), which then processes the client request in the service handler's svc hook, which you must write. Another way is to use reactive I/O via the ACE_Reactor. There are hybrid schemes you can use, as well.
Regardless of which approach you use, make sure that your service handler is intelligent about not getting hung indefinitely on blocking send and recv calls. I recommend using synchronous and/or asynchronous timed I/O calls.
The server should not exit unless you explicitly kill it via a signal (e.g., SIGINT). You should add a signal handler (using either the ACE_Reactor signal interface or the ACE_Sig_Action interface) that performs any termination code necessary to gracefully shutdown the server upon receipt of a signal. It is hard to come up with a completely portable scheme for handling signals and shutting down tasks in multi-threaded programs. For this assignment, make sure that you use a portable and robust mechanism for closing down the server.
Make sure that all resources you allocate in the program, including memory, socket, and files, are deallocated before your program exits to avoid leaks.

Comments
The amount of code you write should actually shrink a bit by using these ACE frameworks. In particular, you should focus on "refactoring" your existing solution(s), rather than writing new code from scratch.

References
- W. Richard Stevens, UNIX Network Programming, Prentice Hall, 1990.
- W. Richard Stevens, TCP/IP Illustrated, Vol 3. Addison-Wesley, 1995.
- Acceptor and Connector
- The Reactor: An Object-Oriented Interface for Event-Driven UNIX I/O Multiplexing
- The Object-Oriented Design and Implementation of the Reactor: A C++ Wrapper for UNIX I/O Multiplexing (Part 2 of 2)
- IPC SAP -- A Family of Object-Oriented Interfaces for Local and Remote Interprocess Communication