Our system model taken by us is shown in Figure 3.1. Different steps in HTTP request service are shown in this figure. Client software first asks its local resolver for IP address of web server, if local resolver or intermediate resolvers do not have this mapping or TTL has expired, this request reaches to server side authorized DNS in step 1 and DNS replies with IP address of front node of one of several cluster (selected according to algorithm, which we discuss later) in step 1.1. In step 2, client software or some entity on behalf of client (client proxy or gateway) sends request to front node of that cluster using obtained IP address in step 1. Front node decides which server in the cluster should serve the request (algorithm for selection is described later) and request is forwarded to that server by front node in step 3. Finally, in step 4, selected server replies with request object on behalf of front node.
We have chosen cluster based model because it creates additional level for system state information collection and gives full control over dispatching of each HTTP connection. Besides, our assumption is that clients are geographically distributed in distant parts of world and company can place each cluster at strategic location near its customers, where they can serve customers better. This model also allows website administrator to change number of servers in any cluster as well as change the number and location of clusters easily.
This model allows us to collect finer level information about each server at the cluster level and aggregated information about each cluster can be passed to entity(DNS in our case) requiring this state information for making request distribution decisions at coarser level.
