Because we were only interested in the multicast features of the server, we chose to only implement those features in our stand-alone server. The server is not capable of traditional unicast HTTP delivery. It is not even HTTP aware since the client will request a page using the UDP HTTP protocol described below. The files which are available on the server were taken from the cnn.com site using urlget with header removal disabled. The files served contain the HTTP headers modified to look like the server generated them.
The server listens on a well known UDP port for one of two types of packets from a proxy. One is the HTTP request and the other is the HTTP done. The HTTP request is a request for a URL. The HTTP done informs the server that the proxy successfully received the URL.
Once the server receives a packet it parses the type of packet and the URL. If the type of packet is a HTTP request, the server adds one member to the flag which maintains the number of members for that multicast group. Then the server sends the HTTP ack to the proxy and checks to see if a multicast group for that URL already exists. If not, the server forks a child process to handle the new multicast group. The parents process immediately returns to the listen state. If the type of the packet is HTTP done, the server subtracts the member from the flag for that URL.
The child process creates the multicast group and passes the data for that URL to the reliable multicast API to serve the request. The multicast handler needs to be initiated when the group is formed. The server continues to multicast to the group until all members successfully receive the URL. The server keeps track of the number of participants in the multicast group. When all members receive the URL, the multicast group is closed and the child process dies.