Paper Preview

One way to improve Web performance and reliability is to replicate popular Web resources among different servers. If one of the servers fails, clients satisfy their requests from other servers that contain replicas of the same resource. Client requests can be directed to the ``closest'' server that contains the requested resource and thereby improve the request response time. Replication also allows the balancing of clients' requests among different servers and enables ``cost-conscious scalability'' [9,42] of the Web service whereby a surge in a server load can be handled by dynamically replicating hot data on additional servers. In this paper we present an overview of design of our Web++ system for replication of the HTTP service. Unlike other similar systems reported in literature, Web++ is completely transparent to the browser user and requires no changes to the existing Web infrastructure. Web++ clients are downloaded as cryptographically signed applets to commercially available browsers. There is no need for end-users to install a plug-in or client-side proxy. There is no need for any modification of the browser; the Web++ applet can execute in both Netscape Navigator 4.x and Microsoft Explorer 4.x browsers. Web servers that support servlets can be directly extended with Web++ servlets. Other servers are extended with a server-side proxy that supports servlets. All client-to-server and server-to-server communication is carried on top of HTTP 1.1. Other salient features of Web++ are:

Reliability

Resources are replicated among multiple Web++servers. If one of the servers fails, clients transparently fail-over to another server that replicates the requested resource. After a failure repair, the server transparently returns to service without affecting clients. Furthermore, Web++guarantees data delivery if at least one of the servers holding the requested resource is available.

Fast response time

User's requests are directed by Web++to the server that is expected to provide the fastest response time among all other available servers where the resource is replicated. This is done transparently to the user and the user is not required to know which server has delivered the resource.

Dynamic replication

If there is a high demand for a resource, the resource can be dynamically replicated on another server that is lightly loaded or close to the clients that frequently request the resource. Furthermore, when demand for a resource drops, some servers may drop the resource copy. Additional servers may be recruited from a pool of under-utilized servers to help sustain a load peak.

Light-Weight Clients

The client applets maintain very little state information. In fact, the only information that they maintain is the HTTP latency of the various servers. This allows our system to be run on many hardware configurations with limited resources.