View source for BOINC client–server technology

{{Short description|BOINC volunteer computing client–server structure}}
[[File:Boincarchitecture.png|thumb|600x600px|'''Visual diagram of BOINC client–server structure''']]'''BOINC client–server technology'''<ref>{{Cite web |title=BOINC client–server technology {{!}} Semantic Scholar |url=https://www.semanticscholar.org/topic/BOINC-client%E2%80%93server-technology/1436870 |access-date=2022-08-14 |website=www.semanticscholar.org |language=en}}</ref> refers to the model under which [[BOINC]] works. The BOINC framework consists of two layers which operate under the [[client–server]] [[Network architecture|architecture]]. Once the BOINC software is installed in a machine, the [[Server (computing)|server]] starts sending tasks to the [[Client (computing)|client]]. The operations are performed [[client-side]] and the results are uploaded to the [[server-side]].

==Design and structure of BOINC==
* BOINC is designed to be a free structure for anyone wishing to start a distributed computing project.
* BOINC consists of a server system and client software that communicate with each other to distribute, process, and return workunits.

== Server structure ==
A major part of the BOINC system is the backend server. The server can run on one or many machines to allow BOINC to scale easily to projects of any size. BOINC servers run on Linux-based computers and use [[Apache HTTP Server|Apache]], [[PHP]], and [[MySQL]] for their web and [[database]] systems.

Scientific computations run on participants' computers. After uploading from the user's client to a science investigator's database, the backend server validates and analyzes the results. The validation process involves running all tasks on multiple contributor PCs and comparing the results.

BOINC servers also provide these features: 
* '''homogeneous redundancy''' (sending workunits only to computers of the same [[Platform (computing)|platform]] — for example: ''Win XP SP2'' only)
* '''workunit trickling''' (sending information to the server before the workunit completes)
* '''locality scheduling''' (sending workunits to computers that already have the necessary files and creating work on demand)
* '''work distribution based on host parameters''' (workunits requiring 512 MB of RAM, for example, will only be sent to hosts having at least that much RAM<ref>[http://setiathome.berkeley.edu/transition.php SETI@home's transition to BOINC<!-- Bot generated title -->]</ref>)

The server consists of two [[Common Gateway Interface|CGI]] programs and (normally) five [[Daemon (computer software)|daemons]], written in [[C++]]. Computations to be performed by clients are called '''workunits'''. A '''result''' describes an instance of a workunit, even if it hasn't been completed. A project does not explicitly create results; the server creates them automatically from workunits.

The scheduler CGI program handles requests from clients, receiving completed results and sending new work to compute. The scheduler doesn't get available results directly from the database. Instead, a '''feeder''' daemon loads tasks from the database and keeps them in a [[shared memory (interprocess communication)|shared-memory]] block, which the scheduler reads. The feeder periodically fills empty "slots" in the shared-memory block after the scheduler has sent those results to a client.

When all the results from a workunit are completed and returned, the '''validator''' checks them. One popular method would be to compare the results against each other. The validator can have custom project-code to do fuzzy comparison between results, or it can perform a bitwise comparison. If the validator determines that at least some of the results are valid, it marks the work unit and the valid results as valid, users who returned legitimate results are granted [[BOINC Credit System|credit]] for it, and a "canonical result" is chosen. If the results don't agree, or if one of the results is not reported by its deadline, the server generates an additional instance of the job, and sends it to a third host. This is repeated until a quorum of matching results is found or a limit on the number of instances is
reached.<ref>{{Cite book|chapter-url=https://ieeexplore.ieee.org/document/4228395|doi = 10.1109/IPDPS.2007.370667|s2cid = 15164675|chapter = Local Scheduling for Volunteer Computing|title = 2007 IEEE International Parallel and Distributed Processing Symposium|year = 2007|last1 = Anderson|first1 = David P.|last2 = McLeod|first2 = John|pages = 1–8|isbn = 978-1-4244-0909-9}}</ref>

Next, the '''assimilator''' daemon processes the canonical result using project-specific code. For example, some projects may parse the file and store information in a database, others may just copy the file somewhere else. An assimilator may also generate more workunits based on the returned data.

The '''file_deleter''' daemon deletes output files after the assimilator has processed them, and deletes input files that aren't needed anymore.

The '''transitioner''' daemon handles state transitions of workunits and results. It also generates results from workunits when they are first created, and when more are needed (for example, if a result turns out invalid).

== Client structure ==
[[File:BOINC screenshot.png|thumb|A screenshot of the [[BOINC Account Manager|BOINC manager application]]]]

BOINC on the client is structured into a number of separate applications. These intercommunicate using the BOINC [[remote procedure call]] (RPC) mechanism. 

These component applications are:

* The program {{Mono|boinc}} (or {{Mono|boinc.exe}}) is the core client.
* The core client is a [[process (computing)|process]] which:
** Takes care of communications between the client and the server.
** The core client also downloads science applications, provides a unified logging mechanism, makes sure science application binaries are up-to-date, and schedules CPU resources between science applications (if several are installed).
** Although the core client is capable of downloading new science applications, it does not update itself. BOINC's authors felt doing so posed an unacceptable security risk{{Citation needed|date=January 2008}}, as well as all of the risks that automatic update procedures have in computing.
** On [[Unix]], the core client is generally run as a [[daemon (computer software)|daemon]] (or occasionally as a [[crontab|cron]] job).
** On Windows, BOINC initially was not a Windows service, but an ordinary application.  BOINC Client for Windows, Versions 5.2.13 and higher add, during installation, the option of "Service Installation".
** Depending on how the BOINC client software was installed, it can either run in the background like a daemon, or starts when an individual user logs in (and is stopped when the user logs out).  The software version management and work-unit handling provided by the core client greatly simplifies the coding of science applications.
* One or several science applications. Science applications perform the core scientific computation.  There is a specific science application for each of the distributed computation projects which use the BOINC framework.  Science applications use the BOINC daemon to upload and download workunits, and to exchange statistics with the server.
* {{Mono|boincmgr}} (or {{Mono|boincmgr.exe}}), a [[graphical user interface|GUI]] which communicates with the core application using [[remote procedure call]]s. By default a core client only allows connections from the same computer, but it can be configured to allow connections from other computers (optionally using password authentication); this mechanism allows one person to manage a farm of BOINC installations from a single workstation. A drawback to the use of RPC mechanisms is that they are often felt to be security risks because they can be the route by which hackers can intrude upon targeted computers (even if it's configured for connections from the same computer).
* The GUI is written using the cross-platform [[WxWidgets]] toolkit, providing the same user experience on different platforms. Users can connect to BOINC core clients, can instruct those clients to install new science applications, can monitor the progress of ongoing calculations, and can view the BOINC system message logs.
* The BOINC [[screensaver]]. This provides a [[software framework|framework]] whereby science applications can display graphics in the user's screensaver window.  BOINC screensavers are coded using the BOINC graphics API, [[OpenGL]], and the [[OpenGL Utility Toolkit|GLUT]] toolkit. Typically BOINC screensavers show animated graphics detailing the work underway, perhaps showing graphs or charts or other data visualisation graphics.
* Some science applications do not provide screensaver functionality (or stop providing screensaver images when they are idle). In this circumstance the screensaver shows a small BOINC logo which bounces around the screen.

Since BOINC has features that can render it invisible to the typical user, there is risk that unauthorized and difficult to detect installations may occur. This would aid the accumulation of BOINC-credit points by hobbyists who are competing with others for status within the BOINC-credit subculture.

==Client platforms==

{|class="wikitable"
|-
!Operating system
!Hardware
!Examples
!Status
|-
|[[Linux]]
|[[IA-32]] and [[AMD64]]
|rowspan="3"|PCs and servers
|Most Linux projects require 64-bit Linux. 32-bit Linux projects could require installation of 32-bit libraries if they are run on 64-bit Linux.
|-
|[[Mac OS X|macOS]]
|[[X86-64]], [[ARM architecture|ARMv8]]
|Different BOINC clients used to be available for PowerPC, IA-32, and AMD64. The AMD64 client was capable of running IA-32 applications if the BOINC server supports this. BOINC Manager 7.16.13 is for both X-86-64 and ARMv8.
|-
|[[Windows]]
|[[IA-32]] and [[AMD64]]
|Different BOINC clients are available for IA-32 and AMD64. The 64-bit client will run 32-bit applications if the BOINC server supports this.
|-
|[[Raspbian]] ([[Linux]])
|[[ARM architecture|ARM]]
|[[Raspberry Pi]]
|Very few client applications available
|-
|[[Android (operating system)|Android]] ([[Linux]])
|[[ARM architecture|ARM]], [[MIPS architecture|MIPS]], or [[IA-32]]
|Smartphones and tablets
|Few client applications available. Some projects may require unofficial clients(NativeBOINC)
|}

== See also ==
* [[Berkeley Open Infrastructure for Network Computing|Berkeley Open Infrastructure for Network Computing (BOINC)]]
* [[Volunteer computing|Volunteer Computing]]

== References ==
{{Reflist}}

{{BOINC topics}}

{{DEFAULTSORT:BOINC client-server technology}}
[[Category:Software that uses wxWidgets]]
[[Category:Berkeley Open Infrastructure for Network Computing]]