Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues 1 Packages Projects Releases Wiki Activity

doc format 

svn path=/trunk/boinc/; revision=355
This commit is contained in:
David Anderson 2002-08-20 23:54:17 +00:00
parent 28ff9e7e06
commit c9fea02a4e
45 changed files with 269 additions and 251 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/account.html
View File

@ -1,3 +1,5 @@
<title>Participant accounts</title>
<body bgcolor=ffffff>
<h2>Participant accounts</h2>
<p>

5
doc/affinity.html
View File

@ -1,6 +1,7 @@
<title>Compute Model: handling very long computations</title>
<title>Handling long computations</title>
<body bgcolor=ffffff>
<h2>Compute model: handling very long computations</h2>
<h2>Handling long computations</h2>
<p>
Some applications have very long (multi-month) computations

1
doc/api.html
View File

@ -1,4 +1,5 @@
<title>The BOINC Application Program Interface (API)</title>
<body bgcolor=ffffff>
<h2>The BOINC Application Programming Interface (API)</h2>
The BOINC API is a set of C++ functions.

1
doc/app.html
View File

@ -1,4 +1,5 @@
<title>Platforms, Applications, and Versions</title>
<body bgcolor=ffffff>
<h2>Platforms, Applications, and Versions</h2>
<p>
A <b>platform</b> is a compilation target (Windows/Intel,

1
doc/back_end.html
View File

@ -1,4 +1,5 @@
<title>Back End Examples</title>
<body bgcolor=ffffff>
<h2>Back End Examples</h2>
<p>
Here are some examples of the "back ends" that could be used by

1
doc/batch.html
View File

@ -1,4 +1,5 @@
<title>Batches</title>
<body bgcolor=ffffff>
<h2>Batches</h2>
<p>
Workunits and results can be grouped together into <b>batches</b>.

1
doc/client_data.html
View File

@ -1,4 +1,5 @@
<title>Core Client: Data Structures</title>
<body bgcolor=ffffff>
<h2>Core Client: Data Structures</h2>
<p>
The key data structures in the core client are as follows.

4
doc/client_debug.html
View File

@ -1,5 +1,7 @@
<title>Core Client: Debugging</title>
<h2>Core Client: Debugging</h2> <h3>Core client logging and error output</h3>
<body bgcolor=ffffff>
<h2>Core Client: Debugging</h2>
<h3>Core client logging and error output</h3>
<p>
The core client writes error messages to stderr.
This mechanism is reserved for serious problems,

1
doc/client_files.html
View File

@ -1,4 +1,5 @@
<title>Core Client: File Structure</title>
<body bgcolor=ffffff>
<h2>Core Client: File Structure</h2>
<p>
The core client runs in a BOINC home directory.

29
doc/client_fsm.html
View File

@ -1,4 +1,5 @@
<title>Core Client: Finite-State Machine (FSM) Structure</title>
<body bgcolor=ffffff>
<h2>Core Client: Finite-State Machine (FSM) Structure</h2>
<p>
The core client can perform many activities (file transfers,
@ -25,21 +26,27 @@ are nonblocking.
The core client uses the following FSM types:
<ul>
<li>
<b>NET_XFER</b> (container: <b>NET_XFER_SET</b>). Each instance
represents a network connection, for which data is being transferred
to/from memory or a disk file. The <b>poll()</b> function uses
<b>NET_XFER</b> (container: <b>NET_XFER_SET</b>).
Each instance represents a network connection,
for which data is being transferred to/from memory or a disk file.
The <b>poll()</b> function uses
<b>select()</b> to manage the FSM without blocking.
<li>
<b>HTTP_OP</b> (container: <b>HTTP_OP_SET</b>). Each instance
represents an HTTP operation (GET, PUT or POST).
<b>HTTP_OP</b> (container: <b>HTTP_OP_SET</b>).
Each instance represents an HTTP operation (GET, PUT or POST).
<li>
<b>FILE_XFER</b> (container: <b>FILE_XFER_SET</b>). Each
instance represents a file transfer (upload or download) in progress.
<b>FILE_XFER</b> (container: <b>FILE_XFER_SET</b>).
Each instance represents a file transfer (upload or download) in progress.
<li>
<b>ACTIVE_TASK</b> (container: <b>ACTIVE_TASK_SET</b>). Each
instance represents a running application.
<b>PERS_FILE_XFER</b> (container: <b>PERS_FILE_XFER_SET</b>).
Each instance represents a "persistent file transfer",
which recovers from server failures and disconnections,
and implements retry and give-up policies.
<li>
<b>ACTIVE_TASK</b> (container: <b>ACTIVE_TASK_SET</b>).
Each instance represents a running application.
</ul>
<p>
An FSM may be implemented using other FSMs; for example, FILE_XFER
is implemented using HTTP_OP, which in turn is implemented using
NET_XFER.
is implemented using HTTP_OP, which in turn is implemented using NET_XFER.

1
doc/client_logic.html
View File

@ -1,3 +1,4 @@
<title>Core Client: Logic</title>
<body bgcolor=ffffff>
<h2>Core Client: Logic</h2>
<p>

1
doc/client_network.html
View File

@ -1,3 +1,4 @@
<title>Core Client: Network Scheduling and Retry Policy</title>
<body bgcolor=ffffff>
<h2>Core Client: Network Scheduling and Retry Policy</h2>
<p>

1
doc/comp_examples.html
View File

@ -1,3 +1,4 @@
<title>Compute Model: Examples</title>
<body bgcolor=ffffff>
<h2>Compute Model: Examples</h2>
<p>

21
doc/database.html
View File

@ -1,4 +1,5 @@
<title>The BOINC Database</title>
<body bgcolor=ffffff>
<h2>The BOINC Database</h2>
<p>
BOINC uses a relational database to keep track of participants, work
@ -15,26 +16,30 @@ The database tables are as follows:
<dt> platform
<dd> Compilation targets of the core client and/or applications.
<dt> app
<dd> Applications. The core client is treated as an application; its
name is "core_client".
<dd> Applications.
The core client is treated as an application; its name is "core_client".
<dt> app_version
<dd> Versions of applications. Each record includes a URL for
<dd> Versions of applications.
Each record includes a URL for
downloading the executable, and the MD5 checksum of the executable.
<dt> user
<dd> Describes users, including their email address, name, web
password, and authenticator.
<dt> preferences
<dd> Describes preferences. The actual preference information is
<dd> Describes preferences.
The actual preference information is
stored in an XML document in a "blob" field of this table.
<dt> host
<dd> Describes hosts.
<dt> workunit
<dd> Describes workunits. The input file descriptions are stored in
an XML document in a blob field. Includes counts of the number of
<dd> Describes workunits.
The input file descriptions are stored in an XML document in a blob field.
Includes counts of the number of
results linked to this workunit, and the numbers that have been sent,
that have succeeded, and that have failed.
<dt> result
<dd> Describes results. Includes a "state" (whether the result has
been dispatched). Stores a number of items relevant only after the
<dd> Describes results.
Includes a "state" (whether the result has been dispatched).
Stores a number of items relevant only after the
result has been returned: CPU time, exit status, and validation status.
</dl>

1
doc/dev.html
View File

@ -1,3 +1,4 @@
<title>Application Development</title>
<body bgcolor=ffffff>
<h2>Application Development</h2>
<p>

8
doc/file_access.html
View File

@ -1,8 +1,8 @@
<title>Compute Model: Remote File Access</title>
<h2>Compute Model: Remote File Access</h2>
<title>Remote File Access</title>
<body bgcolor=ffffff>
<h2>Remote File Access</h2>
<p>
Output files can be designated as sticky but not
upload-when-present.
Output files can be designated as sticky but not upload-when-present.
Sometimes this is done because the file will be
used as an input for a later workunit; it may also be done to spread
large output data across participant disks, in cases where the data may

1
doc/file_xfer_policy.html
View File

@ -1,3 +1,4 @@
<title>Core Client: Network Scheduling and Retry Policy</title>
<body bgcolor=ffffff>
<h2>Core Client: Network Scheduling and Retry Policy</h2>
<p>

7
doc/files.html
View File

@ -1,4 +1,5 @@
<title>Compute Model: Storage</title>
<body bgcolor=ffffff>
<h2>Compute Model: Storage</h2>
<h3>Files</h3>
<p>
@ -24,7 +25,7 @@ A file is described by an XML element of the form
The components are as follows:
<ul>
<li> The <b>&lt;name&gt;</b> element gives the file's name, which
must be unique within the project.
must be unique within the project.
<li> Each <b>&lt;url&gt;</b> element gives a URL where the file is
(or will be) located on a data server.
<li> The <b>&lt;md5_cksum&gt;</b> element is the MD5 checksum of the
@ -43,10 +44,10 @@ that the file protections should be set to allow execution.
</ul>
These attributes allow the specification of various types of files: for
example, input or output files that are retained for use as input to
later computations.
later computations.
<p>
Once a file is created (on a data server or a participant host) it
is immutable.
is immutable.
<h3>File references</h3>
<p>
Files may be associated with <a href="work.html">workunits</a>,

25
doc/flow.html
View File

@ -1,5 +1,6 @@
<title>Compute Model: Work Distribution</title>
<h2>Compute Model: Work Distribution</h2>
<title>Work Distribution</title>
<body bgcolor=ffffff>
<h2>Work Distribution</h2>
<p>
Results are not necessarily dispatched one at a time.
Instead, each participant host
@ -7,23 +8,21 @@ maintains an estimate of the amount of work remaining
(i.e. the time until one of its processors will be idle).
Each host also
has two scheduling parameters, the <b>high-water mark</b> and the
<b>low-water mark</b> (these are part of the host's "preferences",
discussed later).
<b>low-water mark</b>
(these are part of the host's "preferences", discussed elsewhere).
<p>
Normally the work remaining is between the high- and low-water marks.
When the work remaining reaches the low-water mark, the core
client contacts one or more scheduling servers, and attempts to get
enough work to exceed the high-water mark.
client contacts one or more scheduling servers,
and attempts to get enough work to exceed the high-water mark.
The scheduling server sends a maximum of four weeks of work.
If a work unit is not feasible for a host
because it consumes too many system resources, the scheduling server
will not send that work unit.
because it consumes too many system resources,
the scheduling server will not send that work unit.
<p>
The amount of work (measured in FP/int ops) sent in a single
scheduling RPC can be limited by the project, on a per-application basis.
<p>
This scheme allows hosts that are sporadically connected (because
they're portable or have modem-based connections) to avoid becoming idle
due to lack of work.
<p>
<b>To do</b>: per-workunit flag saying to return the result ASAP?
This scheme allows hosts that are sporadically connected
(because they're portable or have modem-based connections)
to avoid becoming idle due to lack of work.

8
doc/graphics.html
View File

@ -1,6 +1,7 @@
<title>The graphics API</title>
<title>The BOINC graphics API</title>
<body bgcolor=ffffff>
<h2>The graphics API</h2>
<h2>The BOINC graphics API</h2>
<p>
Applications can optionally generate graphics,
which are displayed either in an application window,
@ -52,7 +53,6 @@ This file has the format
<p>
The graphics API implementation uses a 60 Hz timer.
Every 0.5 sec, it sees if graphics.xml has been modified,
and if so parses it.
Every 0.5 sec, it sees if graphics.xml has been modified, and if so parses it.
Every 1/60 sec, it sees if it's time for a new frame,
and if so calls <tt>app_render()</tt>.

27
doc/host_measure.html
View File

@ -1,4 +1,5 @@
<title>Measuring and Distinguishing Hosts</title>
<body bgcolor=ffffff>
<h2>Measuring and Distinguishing Hosts</h2>
<p>
The core client measures the following aspects of each host:
@ -6,27 +7,28 @@ The core client measures the following aspects of each host:
<li> <b>CPU performance</b>: integer ops/sec, double-precision
floating-point ops/sec, and memory bandwidth are measured separately.
They are measured by a process executing at the same priority as BOINC
applications, so the results will be affected by other processes. These
measurements are taken when the client starts for the first time, and
once every month aftewards.
applications, so the results will be affected by other processes.
These measurements are taken when the client starts for the first time,
and once every month afterwards.
<li> <b>Number of CPUs</b>: By default, the number of simultaneous
slot directories will be set to this number unless otherwise indicated
by user preferences.
<li> <b>Vendor and model of CPU</b>
<li> <b>Disk space</b>: free space and total space on the drive which
BOINC is installed on. These numbers will be used to ensure BOINC does
BOINC is installed on.
These numbers will be used to ensure BOINC does
not use more space than set in the user preferences.
<li> <b>Memory</b>: total RAM, CPU cache, and swap space. These
numbers can be used by the scheduling server to decide whether or not to
assign work to a client. This also provides a means for assignment of
<li> <b>Memory</b>: total RAM, CPU cache, and swap space.
These numbers can be used by the scheduling server to decide whether or not to
assign work to a client.
This also provides a means for assignment of
differing work based on host abilities.
<li> <b>Timezone</b>:
<li> <b>Last IP address</b> and count of consecutive same addresses.
<li> <b>Number of RPCs and time of last RPC</b>.
<li> <b>Fractions of time</b> that core client runs on host, host is
connected, and user is active.
These are computed as
exponentially-weighted averages; see the class TIME_STATS.
These are computed as exponentially-weighted averages; see the class TIME_STATS.
<li> <b>Operating system name and version</b>.
<li> <b>Average up- and downstream network bandwidth</b>.
These are computed as exponentially-weighted averages; see the class NET_STATS.
@ -50,9 +52,8 @@ and the host maintains the sequence number in its
<p>
To install the BOINC client on a large number of computers, users
are instructed to copy only the executable and the <tt>prefs.xml</tt>
file.
are instructed to copy only the executable and the <tt>prefs.xml</tt> file.
If the user copies the <tt>client_state.xml</tt> file as well, the
first RPCs from the other hosts will have a repeat sequence number; in
this case the scheduling server creates a new host record and returns
first RPCs from the other hosts will have a repeat sequence number;
in this case the scheduling server creates a new host record and returns
its ID.

68
doc/index.html
View File

@ -7,51 +7,56 @@ is a software platform for distributed computing projects like
distributed.net and SETI@home.
<ul>
<li> <a href="intro.html">Introduction</a>
<li> <a href="intro.html">Overview of BOINC</a>
</ul>
<h3>Participating in BOINC projects</h3>
<font size=+2><b>Participating in BOINC projects</b></font>
<font size=-1>
<dd> How to donate your unused computing power
to projects that use BOINC.
<dd> How to donate your unused computing power to BOINC-based projects.
</font>
<ul>
<li> <a href="account.html">Participant accounts</a>
<li> <a href="account.html">Joining a project</a>
<li> <a href="prefs.html">Preferences</a>
<li> <a href="startup.html">Participant startup</a>
<li> <a href="startup.html">Participating in multiple projects</a>
</ul>
<h3>Designing a distributed computation with BOINC</h3>
<font size=+2><b>
Designing distributed computations with BOINC
</b></font>
<font size=-1>
<dd> Read this if you are considering using distributed computing
for your a compute- or storage-intensive application.
<dd> How to use BOINC for resource-intensive applications.
</font>
<ul>
<li><a href=parallelize.html>Is your application suitable?</a>
<li><a href=files.html>Compute model: files and file references</a>
<li><a href=app.html>Compute model: applications, platforms and versions</a>
<li><a href=work.html>Compute model: workunits</a>
<li><a href=result.html>Compute model: results</a>
<li><a href=batch.html>Compute model: batches</a>
<li><a href=flow.html>Compute model: work distribution</a>
<li><a href=affinity.html>Compute model: handling very long computations</a>
<li><a href=file_access.html>Compute model: remote file access</a>
<li><a href=parallelize.html>Is your application suitable for BOINC?</a>
<li><a href=files.html>Files and file references</a>
<li><a href=app.html>Applications, platforms and versions</a>
<li><a href=work.html>Workunits</a>
<li><a href=result.html>Results</a>
<li><a href=batch.html>Batches</a>
<li><a href=flow.html>Work distribution</a>
<li><a href=affinity.html>Handling long computations</a>
<li><a href=file_access.html>Remote file access</a>
<li><a href=validation.html>Accounting and result validation</a>
<li><a href=back_end.html>Back end examples</a>
</ul>
<h3>Developing a BOINC application</h3>
<font size=+2><b>
Developing a BOINC application
</b></font>
<font size=-1>
<dd> Read this to learn how to port an application to BOINC.
<dd> How to develop or port an application program for use with BOINC.
</font>
<ul>
<li><a href=api.html>The API</a>
<li><a href=graphics.html>The graphics API</a>
<li><a href=dev.html>Application development</a></ul>
<li><a href=api.html>The BOINC API</a>
<li><a href=graphics.html>The BOINC graphics API</a>
<li><a href=dev.html>The application development process</a></ul>
<h3>Setting up a BOINC server</h3>
<font size=+2><b>
Setting up a BOINC server
</b></font>
<font size=-1>
<dd> Read this to learn how to create a BOINC project.
<dd> How to create a BOINC project.
</font>
<ul>
<li><a href=project.html>Projects</a>
@ -63,10 +68,11 @@ for your a compute- or storage-intensive application.
<li> <a href="test.html">Test applications and scripts</a>
</ul>
<h3>Developing and operating the back end of a BOINC project</h3>
<font size=+2><b>
Developing and operating the back end of a BOINC project
</b></font>
<font size=-1>
<dd> Read this to learn how to feed work into a BOINC system,
and collect the results.
<dd> How to feed work into a BOINC system and collect the results.
</font>
<ul>
<li> <a href="tools_security.html">Operational tools: security</a>
@ -75,9 +81,11 @@ and collect the results.
<li> <a href="security.html">Security</a>
</ul>
<h3>Implementation and debugging of BOINC</h3>
<font size=+2><b>
Implementation and debugging of BOINC
</b></font>
<font size=-1>
<dd> Read this to learn how to debug and enhance the BOINC software.
<dd> How to debug and enhance the BOINC software.
</font>
<ul>
<li> <a href="database.html">The BOINC database</a>

11
doc/install.html
View File

@ -1,7 +1,7 @@
<title>Installing a BOINC server</title>
<body bgcolor=ffffff>
<h2>Installing a BOINC server</h2>
<table width=780><tr><td>
<p>
To create a BOINC server you must have the following software installed:
<ul>
@ -154,8 +154,7 @@ It is not critical for the running of BOINC.
BOINC_MASTER_URL
</h4>
This is currently used by one of the test scripts.
It is not critical for the running of BOINC. Normally, each
project will be identified by a BOINC_MASTER_URL. The client will
go to this URL and will be told where to go to get work from the
scheduler.
</td></tr></table>
It is not critical for the running of BOINC.
Normally, each project will be identified by a BOINC_MASTER_URL.
The client will go to this URL and will be told where to go
to get work from the scheduler.

159
doc/intro.html
View File

@ -1,115 +1,98 @@
<title>Introduction to BOINC</title>
<h2>Introduction to BOINC</h2>
<title>Overview of BOINC</title>
<body bgcolor=ffffff>
<h2>Overview of BOINC</h2>
<p>
BOINC supports applications
that can be divided into large parallel parts with few data dependencies;
it is not presently intended for fine-grained parallel applications.
BOINC is a software platform for distributed computing
using volunteer computer resources.
The features of BOINC fall into several areas:
<h3>Resource sharing among independent projects</h3>
<p>
The features of BOINC include:
Many different projects can use BOINC.
Projects are independent; they operate their own servers and databases.
However, projects can share resources in the following sense:
Participants install a <b>core client</b> program
which in turn downloads and executes project-specific application programs.
Participants control which projects they participate in,
and how their resources are divided among these projects.
When a project is down or has no work,
the processing power of its participants is divided among
the other projects in which the participants are registered.
<p>
<h3>Project features</h3>
<p>
BOINC provides features that simplify
the creation and operation of distributed computing projects.
<ul>
<li>
<b>Multiple independent projects</b>
<b>Flexible application framework</b>
<br>
BOINC allows multiple independent projects to share participants.
Participants download a single <b>core client</b> program,
which in turn downloads and executes project-specific executables.
Participants can control which projects they participate in,
and how their resources are divided among these projects.
Since the projects are independent,
any downtime for one project will merely result in temporary extra
processing power for another.
Existing applications in common languages (C, C++, Fortran)
can run as BOINC applications with little or no modification.
An application can consist of several files
(e.g. multiple programs and a coordinating script).
New versions of applications can be deployed without
participant involvement.
<li>
<b>Comprehensive security</b>
<b>Security</b>
<br>
All file transfers to the host computer are validated with an
MD5 checksum, and all executable files are signed with RSA
public/private key encryption (1024 bit default).
See the <a href="security.html">security</a> page for more details.
BOINC protects against several types of attacks.
For example, it uses digital signatures based on public-key encryption
to protect against the distribution of viruses.
<li>
<b>Host work caching</b>
<b>Multiple servers and fault-tolerance</b>
<br>
The BOINC core client will download enough work to keep the host
busy for a user specifiable amount of time.
This will allow the client
to continue to function during project downtimes, as well as decrease
the frequency of connections to servers.
<li>
<b>Multiple platform support</b>
<br>
The BOINC core client can run on almost any platform (Mac OS X,
Windows 95 and later, Linux and other Unix systems) and provides OpenGL
based graphics support on Mac OS X, Windows 95 and up, and X Windows.
<li>
<b>Multiple server support</b>
<br>
The BOINC architecture supports multiple scheduling and data servers.
If one server is temporarily unavailable,
clients automatically try alternate servers.
If all servers are unavailable,
clients perform random exponential backoff to avoid flooding the server.
Projects can have separate scheduling and data servers,
with multiple servers of each type.
Clients automatically try alternate servers;
if all servers are unavailable, they do exponential backoff.
<li>
<b>Open source</b>
<br>
BOINC is open source; it's distributed under the Mozilla
Public License version 1.0.
Projects that use
BOINC are not required to release the source code of their project
specific applications.
Application programs need not be open source.
BOINC can be used for private, commercial, or public distributed
computing projects.
Each project must provide and maintain its own server systems;
these systems can be set up easily using
open-source components (MySQL, PHP, Apache).
<li>
<b>Support for large data</b>
<br>
BOINC supports applications that produce or consume large
amounts of data (on the order of gigabytes).
It allows data distribution
and collection to be spread across many servers, and it allows
participant hosts to transfer large data unobtrusively.
Users are able to specify maximum disk usage.
BOINC also handles network disconnections and allows
user-specifiable network bandwidth restrictions.
BOINC supports applications that produce or consume large amounts of data,
or that use large amounts of memory.
Data distribution and collection can be spread across many servers,
and participant hosts transfer large data unobtrusively.
Users can specify limits on disk usage and network bandwidth.
Work is dispatched only to hosts able to handle it.
</ul>
<h3>Participant features</h3>
<p>
BOINC provides the following features to participants:
<ul>
<li>
<b>Extreme resource requirement support</b>
<b>Multiple participant platforms</b>
<br>
BOINC supports applications with extreme requirements for
memory, disk, cache or other resources.
Work is dispatched only to hosts
able to handle it.
<li>
<b>Application program Interface</b>
<br>
An Application Program Interface (API) is provided to
application developers to ease integration with BOINC.
See the <a href="api.html">API page</a> for details.
<li>
<b>Support for applications in any language</b>
<br>
BOINC applications can be developed in any language (C++,
Fortran, Perl).
An application can consist of several files
(e.g. multiple programs and a coordinating script).
New versions of
applications can be deployed without requiring participants to download.
<li>
<b>Multiprocessor support</b>.
The BOINC client can use multiple CPUs.
The BOINC core client is available for most common platforms (Mac OS X,
Windows, Linux and other Unix systems).
The client can use multiple CPUs.
<li>
<b>Web Based User and Administrative Interfaces</b>
<b>Web-based administrative interfaces</b>
<br>
A set of PHP scripts is included to provide interfaces for user
and administrative tasks.
These include preference editing, account creation and user information display.
BOINC provides web-based interfaces for
account creation, preference editing, and participant status display.
A participant's preferences are automatically propagated to all their hosts,
making it easy to manage large numbers of hosts.
<li>
<b>Database and server architecture</b>
<b>Configurable host work caching</b>
<br>
BOINC provides a SQL schema, database functions, a simple server
architecture, web based user interfaces and server administration tools.
Each project must provide and maintain its own server systems and
backend result processing but these systems can be set up easily and
require only open-source components (MySQL, PHP, Apache, and Linux).
The BOINC scheduling server also supports FastCGI for enhanced server
performance.
The core client downloads enough work to keep its host
busy for a user-specifiable amount of time.
This allows the host to continue to function during project downtimes,
and decreases the frequency of connections.
</ul>
</body>
</html>

1
doc/master_url.html
View File

@ -1,4 +1,5 @@
<title>The Master URL</title>
<body bgcolor=ffffff>
<h2>The Master URL</h2>
<p>
Each project is identified by a <b>master URL</b>.

12
doc/prefs.html
View File

@ -1,9 +1,10 @@
<title>Preferences</title>
<body bgcolor=ffffff>
<h2>Preferences</h2>
<p>
Participants can specify <b>preferences</b> determining and limiting
how BOINC uses their computers. Preferences are divided into three
groups:
how BOINC uses their computers.
Preferences are divided into three groups:
<ul>
<li> <b>Work preferences</b>
<ul>
@ -46,8 +47,7 @@ allocated to a project is proportional to this number.
<p>
Each participant has a single set of preferences.
If you want to have different preferences for different hosts,
you must create a
separate accounts.
you must create a separate accounts.
<h3>Propagation of preferences</h3>
<p>
@ -58,7 +58,7 @@ If the server has a more recently modified version of the preferences, it
returns these to the client.
Thus a change to preferences is quickly
propagated to all hosts, and to the databases of all enrolled projects.
A participant may edit preferences on the web site of any enrolled
project; however, care should be taken to ensure that a change isn't
A participant may edit preferences on the web site of any enrolled project;
however, care should be taken to ensure that a change isn't
overwritten by an earlier change.
The easiest way to do this is to edit preferences only at one web site.

1
doc/prefs_mod.html
View File

@ -1,3 +1,4 @@
<title>Modifying Preferences</title>
<body bgcolor=ffffff>
<h2>Modifying Preferences</h2>
<p>

6
doc/project.html
View File

@ -1,4 +1,5 @@
<title>Projects and Applications</title>
<body bgcolor=ffffff>
<h2>Projects and Applications</h2>
A <b>project</b> is a group of one or
more distributed applications, run by a single organization, that use BOINC.
@ -23,9 +24,8 @@ The server side of a project consists of two parts:
<ul>
<li> A <b>project back end</b> that supplies applications and work
units, and that handles the computational results.
Input and output
files are distributed by <b>data servers</b>, which are HTTP servers
able to handle CGI programs with POST commands.
Input and output files are distributed by <b>data servers</b>,
which are HTTP servers able to handle CGI programs with POST commands.
These servers need not be owned or operated by the project.
A project might, for example,
recruit other organizations to donate network bandwidth by hosting data

1
doc/project_startup.html
View File

@ -1,4 +1,5 @@
<title>Project Startup Checklist</title>
<body bgcolor=ffffff>
<h3>Project Startup Checklist</h3>
<ul>
<li> Install auxiliary software (Apache, MySQL, PHP)

1
doc/protocol.html
View File

@ -1,4 +1,5 @@
<title>The BOINC Client/Server Protocol</title>
<body bgcolor=ffffff>
<h2>The BOINC Client/Server Protocol</h2>
<h3>Protocol nucleus</h3>

31
doc/result.html
View File

@ -1,5 +1,6 @@
<title>Compute Model: Results</title>
<h2>Compute Model: Results</h2>
<title>Results</title>
<body bgcolor=ffffff>
<h2>Results</h2>
<p>
A <b>result</b> describes an instance of a computation, either to be
performed, in progress, or completed.
@ -7,13 +8,12 @@ Results are stored in the <b>result</b> table of the BOINC DB.
The attributes of a result include:
<ul>
<li> The name of the result (unique across all results in the
project).
<li> The name of the result (unique across all results in the project).
<li> The name of the associated workunit.
<li> The time when the completed result should be reported to a
scheduling server.
This is assigned by the project, and is used by
clients to prioritize operations, and to initiate scheduler RPCs.
clients to prioritize operations and to initiate scheduler RPCs.
There is no guarantee that the result will actually be reported by this time.
<li> An XML document listing the names of its output files; see below.
<li> An XML document giving the sizes and checksums of its output
@ -63,19 +63,16 @@ Results
may be generated in either of two ways (selected as part of the application):
<ul>
<li> <b>Advance generation</b> of results.
One or more result records
are stored in the database when the workunit is produced.
The scheduling
server dispatches each result to a single participant host.
When all
result records have been dispatched, participants hosts are "turned away".
One or more result records are stored in the database
when the workunit is produced.
The scheduling server dispatches each result to a single participant host.
When all result records have been dispatched,
participants hosts are "turned away".
<li> <b>On-demand generation</b> of results.
The application
specifies a "result template", which has place-holder tokens for the
output filenames.
The application specifies a "result template",
which has place-holder tokens for the output filenames.
The scheduling server, in response to a host request,
generates a new result record and sends the result template.
The host
generates unique output filenames, and returns them along when it the
computation is done.
The host generates unique output filenames,
and returns them along when it the computation is done.
</ul>

4
doc/road_map.html
View File

@ -1,4 +1,6 @@
<h2>Road map</h2>
<title>Source code road map</title>
<body bgcolor=ffffff>
<h2>Source code road map</h2>
<pre>
boinc/

4
doc/rpc_policy.html
View File

@ -1,4 +1,5 @@
<title>Scheduler RPC Timing and Retry Policies</title>
<body bgcolor=ffffff>
<h2>Scheduler RPC Timing and Retry Policies</h2>
<p>
Each scheduler RPC reports results, gets work, or both.
@ -10,8 +11,7 @@ that project, how much work to ask for, and what to do if the RPC fails.
The scheduler RPC policy has the following goals:
<ul>
<li> Make as few scheduler RPCs as possible.
<li> Use random exponential backoff if a project's scheduling servers
are down.
<li> Use random exponential backoff if a project's scheduling servers are down.
This avoids an RPC storm when the servers come back up.
<li> Eventually re-read a project's master URL file in case its set
of schedulers changes.

3
doc/sched_debug.html
View File

@ -1,5 +1,4 @@
<title>Scheduling Server: Debugging</title>
<body bgcolor=ffffff>
<h2>Scheduling Server: Debugging</h2>
<p>
</body>
</html>

1
doc/sched_impl.html
View File

@ -1,3 +1,4 @@
<title>Scheduling Server: Implementation</title>
<body bgcolor=ffffff>
<h2>Scheduling Server: Implementation</h2>
<p>

1
doc/sched_policy.html
View File

@ -1,4 +1,5 @@
<title>Scheduling Server: Policy</title>
<body bgcolor=ffffff>
<h2>Scheduling Server: Policy</h2>
<p>
The scheduling server will attempt to send enough work to excede a

1
doc/security.html
View File

@ -1,4 +1,5 @@
<title>Security</title>
<body bgcolor=ffffff>
<h2>Security</h2>
<p>
Many types of attacks are possible in public-participation

34
doc/startup.html
View File

@ -1,34 +1,20 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html lang="en">
<head>
<title>Participant Startup</title>
<meta name="generator" content="BBEdit 6.1.2">
</head>
<body>
<title>Participant Startup</title>
<body bgcolor=ffffff>
<h2>Participant Startup</h2>
<p>
The BOINC core client is run in a <b>BOINC home directory</b>. On
hosts that share a network file system, each host must have its own
BOINC home directory.
</p>
The BOINC core client is run in a <b>BOINC home directory</b>.
On hosts that share a network file system,
each host must have its own BOINC home directory.
<p>
The use of "proxy" servers (such as SETI@home's SETIQueue) serves
two purposes:
The use of "proxy" servers (such as SETI@home's SETIQueue) serves two purposes:
</p>
<ul>
<li>
To buffer input and output data, allowing hosts to work for long
<li> To buffer input and output data, allowing hosts to work for long
periods without connecting to the Internet, or when the project's
servers are down.
</li>
<li>
To support hosts that are not connected to the Internet.
</li>
<li> To support hosts that are not connected to the Internet.
</ul>
BOINC's high/low water mark scheme performs the first function. The
second function would be hard to do; the proxy server would have to
BOINC's high/low water mark scheme performs the first function.
The second function would be hard to do; the proxy server would have to
parse the XML descriptions of workunits and results, and would interact
with data servers.
</body>
</html>

1
doc/test.html
View File

@ -1,4 +1,5 @@
<title>Test Applications and Scripts</title>
<body bgcolor=ffffff>
<h2>Test Applications and Scripts</h2>
<p>
The <b>apps</b> directory contains the following test applications:

5
doc/tools_other.html
View File

@ -1,4 +1,5 @@
<title>Operational Tools: Applications and Versions</title>
<body bgcolor=ffffff>
<h2>Operational Tools: Applications and Versions</h2>
<p>
BOINC provides a few tools for creating and operating projects:
@ -13,7 +14,9 @@ Web interfaces (currently these provide only read access).
</ul>
Projects can create their own tools, either at a low level (e.g.
directly accessing the BOINC DB from PHP or Perl scripts) or by using
the BOINC DB C++ API (db/db.h). <h3>The Add utility program</h3>
the BOINC DB C++ API (db/db.h).
<h3>The Add utility program</h3>
<p>
The program <b>add</b> performs various types of initialization:
<dl>

1
doc/tools_security.html
View File

@ -1,4 +1,5 @@
<title>Security Tools</title>
<body bgcolor=ffffff>
<h3>Security Tools</h3>
<p>
The program <b>lib/crypt_prog</b> can be used for several purposes:

1
doc/tools_work.html
View File

@ -1,4 +1,5 @@
<title>Operational Tools: Work and Results</title>
<body bgcolor=ffffff>
<h2>Operational Tools: Work and Results</h2>
<p>
Workunits and results can be created using either a utility program

1
doc/validation.html
View File

@ -1,4 +1,5 @@
<title>Accounting and Result Validation</title>
<body bgcolor=ffffff>
<h2>Accounting and Result Validation</h2>
<p>
Participants are given <b>credit</b> for the computations performed

12
doc/version.html
View File

@ -1,9 +1,9 @@
<title>Versioning</title>
<h2>Versioning</h2>
<title>Application versions</title>
<body bgcolor=ffffff>
<h2>Application versions</h2>
<p>
Each version of an application is assigned an integer <b>version
number</b>.
Each version of an application is assigned an integer <b>version number</b>.
Projects can assign version numbers however they like; for
example, version 304 might represent major version 3 and minor version 4.
Version numbers should be used consistently across platforms; Windows
version 304 should be functionally identical to Mac version 304.
Version numbers should be used consistently across platforms;
Windows version 304 should be functionally identical to Mac version 304.

13
doc/work.html
View File

@ -1,8 +1,9 @@
<title>Compute Model: Workunits</title>
<h2>Compute Model: Workunits</h2>
<title>Workunits</title>
<body bgcolor=ffffff>
<h2>Workunits</h2>
<p>
A <b>workunit</b> describes a computation to be performed. Workunits
are maintained in the <b>workunit</b> table in the BOINC DB.
A <b>workunit</b> describes a computation to be performed.
Workunits are maintained in the <b>workunit</b> table in the BOINC DB.
The attributes of a workunit include:
</p>
<ul>
@ -49,8 +50,8 @@ described by a <b>&lt;file_info&gt;</b> element.
A workunit is associated with an application, not with a particular
version or set of versions???.
If the format of your input data changes in
a way that is incompatible with older versions, you must create a new
application.
a way that is incompatible with older versions,
you must create a new application.
This can often be avoided by using XML data format.
<p>
The <a href="tools.html">create_work</a> utility program provides a