Internal Data Structures

Apache modules have access to selected internal data structures of the server. A good example here is the list of ``listeners.'' A listener is a special data structure containing a network socket and a pointer to an ``accept'' function that is going to be used with this socket. By inserting and removing listeners to and from the list we can make Apache wait for incoming connections on multiple ports.

The list of listeners is used every time a client request is received. Recall that HTTP requests are transmitted using TCP connections. Typically, an incoming TCP connection is first ``accepted'' (which corresponds to the phase of establishing the connection) and then ``processed'' (which corresponds to the actual data exchange). Also, Apache makes sure that the complete HTTP response is sent (``flushed'') to the client before the TCP connection is closed. It is done internally by the request-processing subsystem, however, and for this reason there is no customizable phase for that (and no special hook function, either).

To avoid conflicts between multiple threads trying to simultaneously accept the same connection, a special lock is used. In this way, all the ``accept'' operations are serialized. Moreover, each accept-then-process sequence is associated with its private resource pool. It is created before accepting, and destroyed after closing the connection.

We can thus perceive Apache as a server running the following loop:

1. create an empty connection resource pool;
2. lock the global ``accept_lock;''
3. poll on the set of sockets extracted from the list of listeners;
4. take any socket reporting the arrival of new data;
5. accept a new TCP connection on the socket, using the accepting function associated with the socket (if present), or a general one (otherwise);
6. unlock the global ``accept_lock;''
7. process the accepted connection by passing the connection to the request-processing subsystem; it then passes the connection to appropriate request-processing hooks;
8. destroy the connection resource pool;
9. return to step 1.

The reason for presenting such a detailed description of how Apache deals with TCP connections is that it provides a good basis to understand the way in which we add UDP support to Apache. We will return to this problem later in this chapter, when discussing the details of implementing the redirector inside Apache.