BOINC client-server technology
BOINC client-server technology refers to the model under which
BOINCworks. The BOINC framework consists of two layers which operate under the client-serverarchitecture. Once the BOINC software is installed in a machine, the server starts sending tasks to the client. The operations are performed client-sideand 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.
A major part of BOINC is the backend server. The server can be run on one or many machines to allow BOINC to be easily scalable to projects of any size. BOINC servers run on Linux based computers and use Apache,
PHP, and MySQLas a basis for its web and databasesystems.
Scientific computations are run on participants' computers and results are analyzed after they are uploaded from the user PC to a science investigator's database and validated by the backend server. 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 -- e.g.: "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 [ [http://setiathome.berkeley.edu/transition.php SETI@home's transition to BOINC ] ] )
The server consists of two CGI programs and (normally) five 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, there is a feeder daemon that loads tasks from the database, and keeps them in a
shared memoryblock, 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 compares them. The validator can have custom project code to do fuzzy comparison between results, or it can be just a bitwise comparison. If the results match, the workunit is marked valid, users are granted credit for it, and a "canonical result" is chosen.
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).
Server design weaknesses
* The BOINC Server is really only designed to be deployed on
Unix, or Unix-likesystems.
* BOINC Servers are not really as simple to deploy as the BOINC Client as they are based mainly on a large number of scripts.
* The BOINC Server project website does a very bad job of storing a compiled database of server side scripts for those wishing to create a BOINC project.
* The BOINC Server can be deployed on
Windows XPand Windows Vistasystemsfact (as they are POSIXcompliant) but the design structure of Windows makes this difficult and more expensive than just using "off the shelf" Linux.
Server security issues
* The BOINC Server uses
PHPand MySQLas its base technologies -- these application frameworks are subject to compromise on poorly run serversFact|date=January 2008.
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 boinc (or boinc.exe) is the core client.
* The core client is a 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 riskFact|date=January 2008, as well as all of the risks that automatic update procedures have in computing.
Unix, the core client is generally run as a daemon (or occasionally as a 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.
* boincmgr (or boincmgr.exe), a GUI which communicates with the core application using remote procedure calls. 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
WxWidgetstoolkit, 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 frameworkwhereby science applications can display graphics in the user's screensaver window. BOINC screensavers are coded using the [http://boinc.berkeley.edu/graphics.php BOINC graphics API] , Open GL, and the 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.
Wikimedia Foundation. 2010.
Look at other dictionaries:
BOINC — Тип Распределённые вычисления Разработчик … Википедия
BOINC Account Manager — BOINC Тип Распределённые вычисления Разра … Википедия
Tecnología cliente-servidor BOINC — Tecnología cliente servidor BOINC, del Inglés BOINC client–server technology, se refiere al modelo de como funciona BOINC. La infraestructura de BOINC consiste de dos capaz que operan bajo la arquitectura cliente servidor. Una vez que el software … Wikipedia Español
Climateprediction.net — Developer(s) Oxford University Initial release September 12, 2003 (2003 09 12) … Wikipedia
MilkyWay@home — Developer(s) Rensselaer Polytechnic Institute Development status Active … Wikipedia
Orbit@home — is a BOINC based distributed computing project of the Planetary Science Institute. It uses the Orbit Reconstruction, Simulation and Analysis framework to optimize the search strategies that are used to find near earth objects. On March 4, 2008 … Wikipedia
SZTAKI Desktop Grid — (SzDG) is a BOINC project located in Hungary run by the Computer and Automation Research Institute (SZTAKI) of the Hungarian Academy of Sciences. Contents 1 History 2 Local SZTAKI Desktop Grid 3 Scientific Research … Wikipedia
Cosmology@Home — logo Cosmology@Home is a BOINC distributed computing project, run at the Departments of Astronomy and Physics at the University of Illinois at Urbana Champaign. Contents 1 Goals … Wikipedia
Docking@Home — is a distributed computing project hosted by the University of Delaware and running on the Berkeley Open Infrastructure for Network Computing (BOINC) software platform. It models protein ligand docking using the CHARMM program. The ultimate aim… … Wikipedia
Chess960@home — is a distributed computing project that runs on the BOINC software platform. It aims to create a vast collection of Chess960 games and to publish it on the internet for public use. In Chess960@home one half move is one workunit. The deadline for… … Wikipedia