Server Scalability

Due to security restrictions, Java applets can only communicate with the web server from which they were downloaded. This forces browser-based volunteer computing networks into star topologies which have high congestion and limited scalability. To address this problem, we have developed a simple volunteer server system that volunteers with HTTP servers on their own machines can download and run as a Java application. This application creates a generic VSProblem object which, like other problem objects, contains data pools and managers for serving worker and watcher clients. Unlike other problem objects, however, VSProblem's createWork() method does not create new work on its own, but instead gets groups of work data from the main server. Correspondingly, its signalDone() method sends the results back to the main server, and its createNextWork() method requests more work.

Figure 7 shows how volunteer servers can help improve a system's performance and scalability. Consider the scenario shown in Fig. 7(a), where some volunteers are slowed down by delays due to congestion or some other constraint of the server link (e.g., the server may be in a different country). In such a situation, we can improve overall running time by having the workers connect indirectly through volunteer servers with faster links (e.g., uncongested servers, or servers in their own countries), as shown in Fig. 7(b).

  

Figure 7: Using volunteer servers. (a) Slow links result in unnecessary delays and idling. (b) Volunteer servers help by exploiting communication parallelism and locality.

Table 3 shows results from an experiment simulating these scenarios using a 28.8Kbps modem link for the slow link, and 10Mbit Ethernet for the fast link. Note that although the computation took only 5s with the main server on a fast link, it took almost 200s when the main server was placed on a slow link, as workers were forced to wait idly while the server received their results and sent them new work through the slow link. To address this problem, we used one volunteer server to act as a ``cache'' between the main server and the workers, using the fast link as shown in Fig. 7(b) to allow them to work at full speed without idling. As shown, this reduced the total running time to 125s, of which the first 5s were spent by the workers to do the computation, and the remaining 120s by the volunteer server to send all the results back to the server through the slow link. The volunteer server also allowed watchers to be added without further congesting the slow link and slowing down the computation.

  

Table 3: Running the Mandelbrot application on a volunteer server.

In general, volunteer servers enable us to overcome congestion and long latencies by exploiting locality and parallelism in communications. Other potential applications of volunteer servers include forming server pools for handling large numbers of clients, and building networks with non-star topologies.