3 | | 1) BOINC high-level architecture |
4 | | projects, URLs |
5 | | accounts |
6 | | clients, attachment |
7 | | preferences |
8 | | applications |
9 | | app version |
10 | | platforms |
| 5 | == Project == |
| 6 | |
| 7 | A '''project''' is an entity that does distributed computing using BOINC. |
| 8 | Projects are independent; each one has its own applications, database, web site, and servers, |
| 9 | and is not affected by the status of other projects. |
| 10 | Each project is identified by a [ServerComponents#ThemasterURL master URL], |
| 11 | the URL of its web site. |
| 12 | |
| 13 | It the implementation level, a project consists of |
| 14 | * a directory tree, containing files related to the project, and |
| 15 | * a MySQL database. |
| 16 | |
| 17 | Multiple projects can coexist on a single server computer. |
| 18 | |
| 19 | The components of a project include: |
| 20 | |
| 21 | === Application === |
| 22 | |
| 23 | An '''application''' includes several programs (for different platforms) |
| 24 | and a set of [JobIn workunits] and [JobOut results]. |
| 25 | A project can include multiple applications. |
| 26 | |
| 27 | === Platform === |
| 28 | |
| 29 | A '''platform''' is a compilation target - typically a combination of a CPU architecture and an operating system. |
| 30 | BOINC defines a set of standard platforms, but a project can define its own. |
| 31 | |
| 32 | === Application versions === |
| 33 | |
| 34 | An application program may go through a sequence of versions. |
| 35 | A particular version, compiled for a particular platform, |
| 36 | is called an '''application version'''. |
| 37 | An application version consists of one or more files. |
| 38 | |
| 39 | === Workunit === |
| 40 | |
| 41 | A '''workunit''' is a computation to be performedi, i.e. a "job". |
| 42 | It may include any number of input files. |
| 43 | It has various attributes, such as resource requirements and deadline. |
| 44 | |
| 45 | A work is associated with an application, not with an application version. |
| 46 | In other words, you don't specify what platform the job is to be run on. |
| 47 | |
| 48 | === Result === |
| 49 | |
| 50 | A '''result''' describes an instance of a computation, either unstarted, in progress, or completed. |
| 51 | Each result is associated with a workunit. |
| 52 | In some cases there may be several instances, or "replicas", of a given workunit. |
| 53 | |
| 54 | === Account === |
| 55 | |
| 56 | Each volunteer in a project has an '''account''', identified by an email address and password. |
| 57 | An account has an associated amount of '''credit''', |
| 58 | a numerical measure of the work done by that volunteer's computers. |
| 59 | |
| 60 | == Client and attachment == |
| 61 | |
| 62 | Volunteers run a program called the '''BOINC client'''; |
| 63 | this is the only software they manually download. |
| 64 | |
| 65 | A given computer running the BOINC client can be '''attached''' to |
| 66 | accounts on one or more project. |
| 67 | Each attachment has a '''resource share'''. |
| 68 | If a computer is attached to multiple projects, |
| 69 | its resources are divided among them in proportion |
| 70 | to their resource shares. |
| 71 | |
| 72 | == BOINC in a nutshell == |
| 73 | |
| 74 | The overall flow of BOINC: |
| 75 | |
| 76 | * When a BOINC client runs low on work, it issues a '''scheduler request''' to one of its attached projects. The request message specifies the client's platform. |
| 77 | * The project's '''scheduler''' (a daemon running on its server) scans the project's database for jobs that can be handled by the client, and returns one or more. |
| 78 | * The client downloads the files associated with the application versions and workunits, and executes the programs. |
| 79 | * When the jobs are completed, the client uploads the resulting output files. |
| 80 | |
| 81 | This cycle is repeated indefinitely. |