Client-based approach

In this approach, client side entity is responsible for selecting the server so no server side processing is required for selection of server. The routing to replica is done by client software (browser) or by client-side DNS or proxy servers. So these schemes can be categorized as follows:

• Web clients : In this approach clients are aware of existence of replicas of same resource on multiple servers and they choose the replica themselves. Following are two schemes that utilize client software for server selection.
  1. Netscape's Approach : This approach is taken by Netscape Navigator browsers [15]. On access to Netscape home page, browser generates a random number X between 1 and 32 and accesses http://homeX.netscape.com. Each server can have multiple homeX aliases pointing to it so that client software need not to be modified in case more servers are deployed, just changing aliases will suffice.
     This approach is not generally applicable as not all companies can control client software, it requires re-installation or change of web clients if number of aliases increase. Also, it does not guarantee server availability and load balancing of servers because if any server is down or overloaded (and the aliases has not been changed), random selection will still try to access resource from that server.

  2. Smart Clients : In scheme proposed by Yoshilakawa et al [31], a Java Applet is run on the client side, whenever user accesses the Distributed Web Server System. This Applet knows all the IP addresses of servers in the System. Applet sends messages to probe node load, response time and network delays, etc., and selects the best node.
     This approach does not require client software modification and provides scalability and availability, but downloading the Java Applet requires a TCP connection, and extra probe messages cause delay and increased network traffic. Also all clients might not be capable of running the Java Applet.

• Client's DNS resolver : This scheme is used by Beck and Moore [7] in I2-DSI system. In this scheme, client's local DNS resolver issues probes to servers instead of web client and may choose the server based on response time or previous access performance reports from client.
  This scheme requires customized DNS and clients must also be modified for giving reports. If the server address is cached, then all requests in future will go to the same server. So load balancing may not be achieved. If caching is restricted by a lower TTL value, then we are putting additional load on DNS infrastructure.

• Client Side Proxy : This scheme was proposed by Baentsh et al [6]. Servers form a hierarchical structure and content replicated on each server is some part of URL name space. Each parent server in hierarchy propagates information about replicas present on direct descendents in extra HTTP headers in response to request for resource. Client-side proxy learns about replicas and next time request can go to server containing replica of resource.
  This approach requires both server software and proxy modification to give information about replica and process extra HTTP headers respectively.
  

All these approaches require change in client side components, which are not controlled by the e-Commerce company or the hosting ISP, So these approaches suffer from the problem of limited applicability.