| 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. |