Using Smart Clients to Build Scalable ServicesBy Chad Yoshikawa, Brent Chun, Paul Eastham, Amin Vahdat, Thomas Anderson, and David Culler, University of California, Berkeley
Summary by Peter Collinson
Still competing with the noise from next door, the session continued with a talk by Chad Yoshikawa on some work that has been going on in Berkeley to attempt to solve the basic problem of scalability on the Web. Currently, busy sites are attempting to mirror themselves at other locations convenient for some subset of their users. For example, Altavista now has an Australian clone. If I wish to use that clone, then I have to explicitly choose the correct URL by making a specific selection that maps onto the cloned service. It would be considerably better if I could click on a single button and have the system take me to the site that it is fastest for me to use.
There are several possible ways of achieving this desire, and the folks at Berkeley have explored a single solution: moving the intelligence into the probably lightly loaded client. The solution creates a Smart Client. The Smart Client is a specially adapted version of the jfox Java browser that understands and can deal with some special applets.
When users connect to a service, their smart client is sent two cooperating applets that are specific to that service. One applet, the client interface applet, provides the user with an interface to the service; the other applet, the director applet, masks the details of the individual servers that comprise that service. The client interface takes user input and packages requests to the director. The director has a knowledge of all the providers of a service and also has enough information to choose the "best" service for the client.
The information the director use to select the best service for the user depends on the application. One choice is to randomly select from the several servers, but this may not result in optimum matching. The solution adopted in this investigation was to measure the network load on the server and make the client pick the least loaded one.
The technique has been applied to several client services on the Berkeley internal network. It is used to supply a Telnet connection to the most lightly loaded workstation from a group of 100 workstations on the Berkeley NOW network. Smart clients have been used transparently to pick a random FTP server from a group of FTP mirror sites. Finally, it's been used to provide a scalable chat system where individuals enter and leave chat rooms to converse with others located in the same virtual room. In this last example, the system provides a fault tolerant system where servers can take over from each other when one dies for some reason or another.
The authors feel that their solution works very well, and the variety of applications to which the technique has been applied attests to the efficacy of the solution.
For more information on this topic see: https://now.CS.Berkeley.EDU/SmartClients/.
Originally published in ;login: Vol. 22, No.2, April 1997.
Last changed: May 28, 1997 pc