Changes between Initial Version and Version 1 of SuperHost


Ignore:
Timestamp:
Sep 24, 2007, 1:50:14 AM (17 years ago)
Author:
Didactylos
Comment:

Initial version

Legend:

Unmodified
Added
Removed
Modified
  • SuperHost

    v1 v1  
     1= Superhost Design and Topology =
     2
     3[[T(VersionSix)]]
     4
     5The superhost idea has been proposed numerous times, but has not yet been implemented. This document discusses concrete design ideas.
     6
     7== Problem ==
     8Large 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.
     9
     10== Solution ==
     11Promote one of the hosts to "superhost". All other hosts will only communicate with the superhost, and only the superhost requires Internet access.
     12
     13== Additional Benefits ==
     14 * 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.
     15 * Hosts can be controlled more tightly, since the superhost will have more information than is normally available to project schedulers.
     16 * The superhost can manage a single work queue, improving turn around times.
     17 * 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" below.)
     18 * Validation can be delegated to the superhost, reducing uploads and server load. (See "security" below.)
     19 * A company can run internal BOINC projects, and fall back on an external project if no work is available from the internal projects.
     20
     21== Topology ==
     22
     23== Security ==
     24For 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.
     25
     26== Implementation ==
     27This design requires major server and client changes, in addition to the superhost application. 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.