In general, a web server would fork a process for each incoming request, and that process would serve a single client. In order to discover requests for hot pages, it will be necessary to change this model as was done in [3]. A group of pre-determined processes will be available to serve client requests. Some of these will be traditional unicast processes, and some will be multicast enabled. In order to match requests with processes, a queue will be the interconnect between the server receiving the requests and the processes. The server will scan the queue for matching requests before queuing a new request. If a match is found, the new request will be grouped with its matching request(s). These groups of requests in the queue will then be candidates for multicast delivery. There will likely be some threshold, a minimum number in the group, that will determine whether a multicast or unicast delivery process is used. The queue length and number of processes of each type (unicast and multicast) will be chosen such that the desired benefits of multicasting can be achieved without adversely effecting the traditional unicast performance.
Clients will need to be altered to support the possibility of a multicast response to their request. Upon sending a request to a server, the client will join the multicast group associated with the page requested. The client will then send the request and expect a response. The response may trigger a traditional unicast response and delivery if the page is not a Hot Page. Otherwise the request will designate that the desired data will be multicast delivered. If the request is to be served via a multicast delivery, the client will wait for the multicast, timing out and retransmitting the request if necessary.
Figure: Reliable Multicast Web Server Protocol Stack.
Figure: End to End Message Exchanges for Multicast Delivery.