以下は下記原文 2005/02/01(JST)時点の検証無し翻訳です。原文は University of California より GFDL で配付されており、
この翻訳も GFDL に従います。
原文: Redundancy and errors

最終更新時刻 2006/03/01 01時11分 JST

冗長性とエラー

Last modified 5:57 AM UTC, February 01 2005

BOINCの「リザルト」は、まだ実行されていないものも含めて、個々の計算を抽象化したものです。典型的な動きとしては、BOINCのサーバがクライアントに「リザルト」を送り、クライアントが計算を実行して [結果を]サーバに返します。しかし、リザルトには色々なことが起こりえます：

クライアントがリザルトを正しく計算して、返却する。
クライアントが誤りを含む計算をして、返却する。
クライアントがファイルのダウンロードまたはアップロードに失敗する。
アプリケーションがクライアントでクラッシュする。
クライアントが壊れてしまったり、BOINCを停止したために、何も返してこない。
リザルトの処理に必要な資源を、どのクライアントも充分に持っていないため、スケジューラがリザルトを送出できない。

BOINCは、ある型の冗長計算を提供します。そのやり方では、個々の計算は複数のクライアントで実行され、その結果どうしを比較し、それらが「合意」に達した場合だけ受理します。ときには、新しくリザルトを作って送出しなければならないこともあります。

その[冗長計算の手順について、]詳細な部分のほとんどをBOINCが管理しますが、アプリケーション開発者が関与しなければならない箇所も、以下のように2つあります：

検証機能(validation)： この部分には2つの機能があります。 1つめは、充分な数(定足数(quorum))の成功したリザルトが戻ってきたときに、それらを比較して「合意(consensus)」がとれているかを調べる、という機能です。リザルトを比較する方法 (それは、プラットフォームごとに異なる浮動小数点演算を考慮に入れる必要があるかもしれません)および、合意がとれた状態かどうか決定するポリシー(例えば、3つのうちの最良の2つを取るなど) を、アプリケーションが供給します。合意状態に達したら、特定の1つのリザルトが、「標準的(canonical)」リザルトとして指名されます。 2つめの機能は、合意状態に達した後にリザルトが届いた場合、その新しいリザルトを標準的リザルトと比較し、[リザルトを送ってきた] 参加者が功績(credit)を得ることができるかどうかを決めます。
取込み機能(アシミレーター, Assimilation)： これは、プロジェクトにワークユニットの処理結果(成功または失敗)を知らせる機構です。この動作は、ワークユニットごとに、ただ1回だけ起こります。ワークユニット[の計算処理]が成功裏に終われば、(つまり、標準的リザルトが得られたなら)、プロジェクトが提供するこの機能は、[標準的リザルトの] 出力ファイル(複数可)を読んで、その内容を処理します (例えば、内容をデータベースに記録するなど)。もし、ワークユニット[の計算処理]が失敗に終わった場合は、この機能はログに記録を残したり、E-メイルを送ったり、といったことをするかもしれません。

次の例では、プロジェクトは下記の条件でワークユニット(WU)を作成しています。
min_quorum = 2
target_nresults = 3
max_delay = 10

BOINC は自動的に3つのリザルトを作り、ばらばらなタイミングで送出しています。時刻8のリザルト到着で、計算に成功したリザルトの数が2に達したので、検証機能が呼びだされます。合意に達していることを検出し、ワークユニットは取込み機能(アシミレータ)で受け入れられています。時刻10で新たなリザルト(result3)が到着しています。検証が再び行われ、この場合は result3 が功績(credit)を得ることができるか検査しています。

時刻        0   1   2   3   4   5   6   7   8   9   10  11  12  13  14

            生成                            検証と受入れ
WU          x                               x  x
                生成    送出            成功   
result 1        x       x---------------x
                生成    送出                成功   
result 2        x       x-------------------x
                生成        送出                    成功   
result 3        x           x-----------------------x

次の例では、result 2が消えてしまいました。 (つまり、 BOINCスケジューラに答えが届きません)。 result3が到着して、合意に達したことを確かめると、ワークユニットは取込まれます。時刻13で、スケジューラは result2を「断念(give up)」しています。 (断念することで、後で到着するリザルトを検証するために必要な、標準的リザルトの出力ファイルを捨てることができます。 )

時刻        0   1   2   3   4   5   6   7   8   9   10  11  12  13  14

            生成                                    検証と取込み       
WU          x                                        x  x
                生成    送出            成功   
result 1        x       x---------------x
                生成    送出    紛失                            断念  
result 2        x       x--------                               x
                生成        送出                    成功   
result 3        x           x-----------------------x

次の例では、result2 が時刻5で失敗で返っています。すると、生きているリザルトの数が2個に減ってしまいます。 target_nresultsが3 に設定されているので、 BOINCはもう一つ別のリザルト(result4)を生成します。 result4が返って来るまえに、時刻9で合意に達しています。

時刻        0   1   2   3   4   5   6   7   8   9   10  11  12  13  14

            生成                                 検証と取込み     
WU          x                                    x  x
                生成    送出            成功   
result 1        x       x---------------x
                生成    送出    失敗  
result 2        x       x-------x
                生成        送出                成功   
result 3        x           x-------------------x
                              生成   送出                   成功   
result 4                         x   x----------------------x