Superhost Design and Topology

T(DesignDocument)?

The superhost idea has been proposed numerous times, but has not yet been implemented. This document discusses concrete design ideas.

Problem

Large organisations wishing to run BOINC often don't want to open up their entire network to BOINC project servers, or allow unmanaged BOINC clients running on the network, potentially attached to unauthorised projects.

Solution

Promote one of the hosts to "superhost". All other hosts will only communicate with the superhost, and only the superhost requires Internet access.

Additional Benefits

• Internet traffic is reduced, since the superhost can communicate more efficiently with the project servers, and only needs to download a single copy of any file.
• Hosts can be controlled more tightly, since the superhost will have more information than is normally available to project schedulers.
• The superhost can manage a single work queue, improving turn around times.
• Normal work unit copy rules can be ignored, allowing a single work unit download to be run on multiple computers within the cluster. (See security section.)
• Validation can be delegated to the superhost, reducing uploads and server load. (See security section.)
• A company can run internal BOINC projects, and fall back on an external project if no work is available from the internal projects.

Topology

Security

For an untrusted cluster, the project must treat the superhost exactly the same as a single host. However, if there is a trust relationship between the project and the superhost, then the superhost can be treated as the sum of its hosts, with the capability to manage work unit redundancy on the project's behalf. Validation offers some technical challenges, but simple bitwise validation using homogeneous redundancy can be achieved easily.

Implementation

This design requires major server and client changes, in addition to the superhost application.

• The scheduler RPC schema will need extending to cope with more complex requests.
• The scheduler will have to treat such requests differently.
• The client will have to attach to a superhost (account manager RPCs may be useful here).

A simplified design could start by treating the superhost as a project from the point of view of the clients, and as a client from the point of view of the projects. Discussion on boinc_dev resulted in a consensus that this approach is impractical, since there would be so many special cases. This leaves designing the superhost as an end-to-end system.

SZTAKI have a hierarchical BOINC implementation. Source should be available soon.