We have also used Smart Clients to build a scalable frontend for FTP sites. As a motivating example, the Netscape Navigator FTP
download page
contains twelve hyperlinks for netscape FTP hosts. Users choose
among netscape sites or mirrors to perform manual load balancing. To
improve on this interface, Smart Client applets present a single
download button to the user. The client interface applet
delivers requests to the director to retrieve a file, while the
director picks a machine at random from a static set of nodes. When
the user presses the button, the applet transparently determines the
best site for file retrieval.
To demonstrate the scalability available from using Smart Clients, we measure delivered bandwidth to Smart Client applets running in Netscape Navigator from a varying number of FTP servers. We emphasize that the choice of FTP site is transparent to the end user (a single button is pressed to begin file retrieval) and that our FTP application can be downloaded to run with unmodified servers and Java-compliant browsers. The tests were run on a cluster of Sun Sparcstation 10's and 20's interconnected by a 10 Mbps Ethernet switch. The Ethernet switch allows each machine in the cluster to simultaneously deliver 10 Mb of aggregate bandwidth to the rest of the cluster without the the contention associated with shared Ethernet networks. Either one, two, or four of the machines are designated FTP servers, while the rest of the machines in the cluster attempt 40 consecutive retrievals of a 512 KB file. This experimental setup approximates multiple FTP mirror sites spread across the wide area.
: This figure demonstrates how a Smart Client interface to
FTP delivers scalable performance. The graph shows delivered
aggregate bandwidth as a function of number of clients making
simultaneous requests.
Figure 6 summarizes the results of the FTP scalability tests. The graph shows aggregate delivered bandwidth
in megabytes per second as a function of the number of client machines
making simultaneous file requests. For one FTP server, 8
clients are able to saturate the single available Ethernet link at 1.2
MB/s. The
results for two and four FTP servers demonstrate that the random
selection of an FTP server used within the applet delivers
reasonable scalability. Sixteen clients are able to retrieve
approximately 2 MB/s from two servers, while 16 clients saturate four
servers at approximately 3 MB/s.
For small number of clients, a single FTP server demonstrates the best performance because all 40 file downloads are made during a single connection. For the multi-server tests, multiple connections and disconnections take place as the clients attempt to randomly balance load across the servers. In the future, this problem can be avoided by implementing site affinity with successive file requests (if delivered bandwidth on the previous was deemed satisfactory), implementing a load daemon on the nodes to allow the clients to continuously choose lightly loaded machines, or by using services such as the Internet Weather Map [Mat 1996] to choose low-latency hosts. This information can be used to incrementally scale connections to available FTP servers (i.e. allow some machines to be recruited only when needed).
