Dispatcher module

The dispatcher module handles a list of structures representing the pool of Web servers in the cluster. Each structure stores per-server information, such as the destination IP address (or addresses, in case of multiple network interfaces) and a representation of the server load status, that is defined by the dispatching policy. This is necessary, as different dispatching algorithms generally use different parameters for the estimation of server load. The dispatcher module is also responsible for parsing the client request and choosing an appropriate Web server according to a content-aware scheduling policy. In our architecture, it is organized as a set of hook functions which can be customized on the basis of the chosen policy. Each hook function handles a specific stage of the dispatching process. We consider the following stages. Initialization. This hook gives an opportunity for executing operations, such as allocation of system resources, which have to be performed at cluster startup only. Request parsing. This hook parses the client request and extracts all information which is necessary for the choice of a Web server. Server selection. This hook takes the extracted client information and, when necessary, the server load status. It has to choose an appropriate server according to some dispatching algorithm. It returns the structure associated to the Web server. The dispatching hook is invoked during the processing of TCP segments containing application-layer requests on a given, configurable, port. Post request. This hook is called whenever a request has been processed by a Web server and the switch is notified. It may be used to update the server load status in a centralized load monitor. Shutdown. This hook permits the execution of operations which have to be performed only at cluster shutdown. Typically, these operations release the resources allocated at the cluster startup. The design through hooks is extremely flexible and modular. The behavior of the switch may be extended and specialized by adding more hooks. Each dispatching policy defines its own hook functions, hence the other modules are unaffected.