Research Issues

  In developing a volunteer computing system, there are several issues that need to be addressed. These issues include:

1.

Programming Interface. The programming interface must be flexible and easy-to-use. That is, it must allow programmers to implement a wide variety of parallel applications, and be able to do so easily and quickly. This goal can be addressed by taking advantage of Java's object-oriented features to achieve maximum code and design pattern reuse.

2.

Adaptive Parallelism. Since volunteer nodes can have different kinds of CPUs, and can join and leave a computation at any time, parallel programming models for volunteer computing systems must be adaptively parallel [16]. Unlike traditional models, they must not assume the existence of a fixed number of nodes, or depend on any static timing information about the system. Various strategies for implementing adaptive parallelism include eager scheduling [4], Linda tuple-spaces [9], and Cilk [5]. Each of these strategies have different strengths and weaknesses, and there is no clear ``best'' strategy for all parallel applications.

3.

Fault-Tolerance. Volunteer computing systems must be able to tolerate both unintentional random faults, such as data loss or corruption due to faulty network links or faulty processors, and intentional faults caused by malicious nodes submitting erroneous data. In general, fault-tolerance can only be addressed using some form of redundancy. Replication techniques, such as majority voting or the more sophisticated and reliable algorithms in [22], can be used but are inefficient. Spot-checking [25], where double-checking results is done only occasionally, is less reliable, but potentially much more efficient.

4.

Computational Security. While volunteers are secure from malicious applets, the computation itself and users of its results are not secure from malicious volunteers. Possible attacks include sabotage, where volunteers (and possibly also non-volunteers) intentionally submit erroneous results, and spying, which is a concern in paid volunteer systems where the user of a computation, may not want volunteers to know what they are working on. Inserting digital signature and checksum computations into the result-generating code can prevent sabotage by making it possible to distinguish between result packets coming from volunteers who actually ran the code, and those that have been fabricated by saboteurs. However, these techniques are only effective if the volunteers cannot disassemble the code. Encrypted computation may be used to address this issue, and can also prevent spying [2]. In cases where true encrypted computation is not possible, dynamic obfuscation, where the code is obfuscated by the server occasionally and unpredictably, may prevent hackers from disassembling code fast enough to sabotage the results [25].

5.

Scalability and Congestion. One of the major problems in Java-based volunteer computing is that currently, security restrictions dictate that applets running in users' browsers can only communicate with the Web server from which they were downloaded. This forces Java-based volunteer networks into star topologies which have high congestion, no parallelism in communications, and limited scalability. This problem may be solved by employing multiple servers. If we are willing to trust volunteers, and if some volunteers are willing to exert extra effort, then we can write volunteer server code as Java applications. These must be run outside a browser, but are not restricted in the hosts to which they can connect, and can access the local file system. Newer implementations of browsers such as Netscape and Microsoft Internet Explorer support signed applets, which can be used as volunteer servers as well.

6.

User Interface Design. In most traditional parallel applications, user-interfaces for the processing nodes typically do not exist, and are not usually a concern. In volunteer computing systems, however, they become an issue. Volunteers need to be able to do such things as start, stop, or set the priority of the applet. Also, some sort of progress indicator would be desirable in order to assure the user that the machine is actually doing useful work. Designing user interfaces for viewing results and statistics, or for submitting jobs or specifying parameters, is also an issue. Whereas these are typically available only to the server's administrators, we may want to make them available to clients as well. In paid volunteer systems, for example, users would like to be able to submit jobs to a volunteer computing system and receive results.