We begin our discussion of the Smart Client architecture by describing the techniques used to provide load balanced and fault tolerant access to network services. Discussion of bootstrapping the retrieval of the Smart Client is deferred until Section 3.2. We assume that services accessed by Smart Clients are implemented by a number of peer servers. In other words, any of a list of machines are capable of serving individual client requests. Thus, the director applet makes a service-specific choice of a physical host to contact based on an internal list of (dynamically changing) server sites. Ideally, this choice should balance load among servers while maximizing performance to the end user.
While the choice of load balancing algorithm is service specific, we enumerate a number of sample techniques. The simplest approach is to randomly pick among service providers. While this approach is simple to implemement and does not require server modifications, it can result in both poor load balancing and poor performance to the end user. For example, an FTP applet picking randomly among a list of service providers may pick an under-powered mirror site on another continent. A refinement on random load balancing would bias future random choices based on how quickly requests to a particular server are processed. For services where multiple successive requests are likely, we believe this technique should result in good performance while maintaining implementation simplicity.
Another technique involves maintaining service-specific profiles of servers. In the FTP example above, a description of hardware performance and network connectivity (perhaps using techniques similar to the Internet Weather Report [Mat 1996]) may be associated with each server. The Smart Client director applet can then use this information to evaluate available bandwidth to each server based on the client's location. A further improvement requires maintaining load information for each server. In this case, the client is able to maximize performance by weighing a combination of network connectivity, server performance, and current server load.
The mechanisms used for load balancing can be adapted to provide fault transparency to the end user. Techniques such as keep-alive messages or time outs can be utilized to determine server failure. Upon failure, the director applet can reinvoke the load balancing mechanism to choose an alternate server and reapply the request. By storing all uncompleted server requests and necessary client state information, the director applet can connect to an alternative site to retransmit all outstanding requests transparently to the user.