以下は下記原文 2003/12/21(JST)時点の非公式翻訳です。転記などはご遠慮ください。
オリジナルの知的財産権は University of California に属します。
原文: Redundancy and errors

最終更新時刻 9:11 PM, Dec. 21 2003 JST

冗長性とエラー

Last modified 3:57 PM, August 20 2003

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

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

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

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

検証機能(validator)： この部分には2つの機能があります。 1つめは、充分な数（定足数(quorum)）の成功したリザルトが戻ってきたときに、それらを比較して「合意(consensus)」がとれているかを調べる、という機能です。リザルトを比較する方法 (それは、プラットフォームごとに異なる浮動小数点演算を考慮に入れる必要があるかもしれません）および、合意がとれた状態かどうか決定するポリシー（例えば、3つのうちの最良の2つを取るなど）を、アプリケーションが供給します。合意状態に達したら、特定の1つのリザルトが、「正規の(canonical)」リザルトとして指名されます。 2つめの機能は、合意状態に達した後にリザルトが届いた場合、その新しいリザルトを正規のリザルトと比較し、[リザルトを送ってきた] 参加者が功績（credit)を得ることができるかどうかを決めます。
受入れ機能（アシミレーター, Assimilator）： これは、プロジェクトにワークユニットの処理釈�蓿繙就�粮㏍芍��轣蛹≒鳫�笏蜿遐�竚癈鷭∂焜聨纃瘟赧漓�籬�㏍聽轣蛹就箋絏矼綏更羇号控聰繖痺⊂桿轣蛹Γ蔚飴頏阡繝�籟鹿畩または失敗）を知らせる機構です。この動作は、ワークユニットごとに、ただ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