Proxy Servers And Why BOINC Doesn't Have Them
From Unofficial BOINC Wiki
(note: this article refers to workunit-caching proxy servers, not general purpose proxy servers such as SOCKS or HTTP proxy servers, which the BOINC Daemon does support)
Contents |
[edit] General
SETI@Home Classic benefited from 'proxy servers' such as SETIQueue, that store Work Units and Results, and transfer them between the Participant's Computers and the main SETI@Home server. Proxies provide a smooth supply of work even when the main server is down, and they make it possible to run SETI@Home Classic on computers not connected directly to the Internet.
These programs won't work with the BOINC Client Software (see below), but some of their benefits can be achieved in other ways:
- The buffering of multiple work units is provided by the BOINC Client Software itself - you can specify how much work your computer should get each time it contacts the server.
- Hosts that are not directly connected to the Internet, but share a LAN with one that is, can participate in BOINC using an HTTP 1.0 proxy such as Squid for Unix or FreeProxy for Windows.
[edit] Why won't SETIQueue work with BOINC?
Unlike SETI@Home Classic, with its 'one size fits all' work units, the BOINC System allows Work Units that have extreme requirements (memory, disk, CPU) and makes sure they're sent only to hosts that can handle them. In the BOINC System, a client communicates directly with the server, telling the server about its hardware (memory size, CPU speed etc.) and the server chooses work for it accordingly. Furthermore, the BOINC System has separate Scheduling and Data Servers (in SETI@Home Classic, a single Server played both roles).
[edit] How a BOINC proxy system might work
Here's a sketch of a proxy system based on modified BOINC Client Software. We assume that there's a 'proxy' host that does only communication and storage, and a number of 'worker' hosts that do computation. The core client must be modified to accept -proxy and -worker options:
- With the -proxy option, the client does network communication (Scheduler RPC, file upload and download) and no computation, CPU Benchmarking, or measurement of other hardware info like memory and disk size. (It does, however, measure and store network speed.) It exits when network communication is finished.
- With the -worker option, the client does the complement: computation and CPU benchmarking but no network communication, etc. It exits when computation is finished (or perhaps when a CPU becomes idle, or when a project is starved).
The proxy host would maintain a set of separate BOINC directories, one for each worker host. The high-level logic is (for each worker host):
- Run the BOINC Client Software with -worker on the worker host.
- When it exits, synchronize its directory with the corresponding directory on the proxy host.
- Run the core client with -proxy on the proxy host.
- When it exits, synchronize its directory with the corresponding directory on the worker host.
- Repeat.
Note: None of the above is implemented. If you are a programmer and would like to help, please let us know. Also note: as described above, the system is not asynchronous (computation and communication don't overlap) and the proxy doesn't act as a buffer. It could be modified to have these properties.
[edit] UCB Source
[edit] Copyright ©
- 2005 University of California
- 2005 Paul D. Buck
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
