The explosive growth of the World Wide Web is straining the architecture of many Internet sites. Slow response times, network congestion, and ``hot sites of the day'' being overrun by millions of requests are fairly commonplace. These problems will only worsen as the Web continues to experience rapid growth. As a result, it has become increasingly important to design and implement network services, such as HTTP, FTP, and web searching services, to scale gracefully with offered load. Such scalable services must, at minimum, address the following issues:
Unfortunately, providing these properties for network services while remaining compatible with the de facto URL (Uniform Resource Locator) naming scheme has proven difficult. URLs are by definition location dependent and hence are a single point of failure and congestion. A number of efforts address this limitation by hiding the physical location of a particular service behind a logical DNS hostname. Examples of such systems include HTTP redirect, DNS Aliasing, Failsafe TCP, Active Networks, and Magic Routers.
We argue that in many cases the client, rather than the server, is the right place to implement transparent access to network services. We will describe limitations associated with each of the above solutions and demonstrate how these limitations can be avoided by moving portions of server functionality onto the client machine. This approach offers the advantage of increased flexibility. For example, clients aware of the relative load on a number of FTP mirror sites can connect to the least loaded mirror to deliver the highest throughput to the end user. Ideally, the selection and connection process takes place without any intervention from the end user, unlike the Web today where users must choose among FTP mirror sites manually. Note that in this example, clients must take into account available network bandwidth to each mirror site as well as the relative load of the sites to receive optimal performance. Such flexibility would be difficult to provide with existing server-side solutions since individual servers may not have knowledge of mirror site group membership and client location.
The migration of service functionality onto client machines is enabled by two recent developments. Today, most popular Internet services, such as FTP, HTTP, and search engines are universally accessed through extensible Web browsers. This extensibility allows insertion of service-specific code onto client machines. In addition, the advent of Java [Gosling \& McGilton 1995] allows such code to be easily distributed to multiple platforms. Next, network latency and bandwidth are increasingly the bottleneck to the performance delivered to clients. Thus, client processors can be left relatively idle. We will demonstrate that offloading service functionality onto these idle cycles can substantially improve the quality of service along the axis described above.
Motivated by the above observations, we describe the design and implementation of Smart Clients to support our argument for client-side location of code for scalability and transparency. The central idea behind Smart Clients is migrating server functionality to the client machine to improve the overall quality of service in the ways described above. This approach contrasts the traditional ``thin-client'' model where clients are responsible largely for displaying the results of server operations. While our approach is general, this paper concentrates on augmenting the client-side architecture to provide benefits such as fault transparency and load balancing to the end user.
The rest of this paper is organized as follows. Section 2 discusses existing solutions to providing scalable services. The limitations of the existing solutions motivates the Smart Client architecture, described in Section 3. Section 4 demonstrates the utility of the architecture by describing the implementation and performance of interfaces for telnet, FTP, and a scalable chat service. Section 5 evaluates our requirements above in the context of the Smart Client architecture. Section 6 describes related work, and Section 7 concludes.