Non-Java-Based Volunteer Computing

On October19,1997, distributed.net, a world-wide computing network composed of thousands of volunteer machines, successfully cracked the RSA Systems RC5-56 code challenge [4]. This network achieved an average aggregate computing power equivalent to about 26,000 commodity PCs, and involved as many as 500,000 different computers (as distinguished by their IP addresses) over a span of 250 days [8].

A large part of this success can be attributed to the relative ease with which users are able to join distributed.net. To volunteer, a user only needs to:

1.

Go to the distributed.net web site and download a compiled binary for his or her own machine architecture. Versions of the application software have already been coded, compiled, and tested by the distributed.net team for all major architectures.

2.

Unarchive and install the software on the volunteer machines.

3.

Run the software on the volunteer machines.

At this point, the software takes care of automatically communicating with the distributed.net server, requesting work, and sending back results. All the user has to do is leave the software running in the background on these machines. Unlike PVM, distributed.net does not require administrators to personally install daemons on the volunteer machines, or contact the volunteer users to acquire remote shell access. Thus, from the volunteers' point-of-view, distributed.net is significantly easier to use and understand than PVM.

While this approach to volunteer computing has clearly proven its worth, it still has its limitations. First, volunteers still need some technical knowledge - at least enough to download, install, and run the software. Furthermore, a non-trivial amount of programmer effort is still required to write, compile, and test code for all the possible target architectures. In fact, this step may even be harder with distributed.net than with PVM because there might not exist a standardized cross-platform library for doing low-level operations, such as communications, and synchronization, that are already provided by PVM,

Perhaps the biggest problem with systems like distributed.net, however, is security. Although distributed.net, unlike PVM, does not require volunteers to give explicit remote shell access to anyone, it does require them to run programs which implicitly provide the same kind of remote-shell-like access anyway. The code which a volunteer user downloads is executed with user permissions, which means it can access any of its user's files and data, including sensitive data such as credit card numbers and passwords. Clearly, such a serious security risk would (and should) make people wary of volunteering, and thus poses a major obstacle in achieving volunteer computing networks of larger sizes.