JP2006155614A - 一般化されたＰａｘｏｓ - Google Patents

一般化されたＰａｘｏｓ Download PDF

Info

Publication number
JP2006155614A
JP2006155614A JP2005338653A JP2005338653A JP2006155614A JP 2006155614 A JP2006155614 A JP 2006155614A JP 2005338653 A JP2005338653 A JP 2005338653A JP 2005338653 A JP2005338653 A JP 2005338653A JP 2006155614 A JP2006155614 A JP 2006155614A
Authority
JP
Japan
Prior art keywords
command structure
proposed
proposal number
proposal
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005338653A
Other languages
English (en)
Other versions
JP4986442B2 (ja
Inventor
Leslie B Lamport
ビー．ランポート レスリー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2006155614A publication Critical patent/JP2006155614A/ja
Application granted granted Critical
Publication of JP4986442B2 publication Critical patent/JP4986442B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/82—Solving problems relating to consistency

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)

Abstract

【課題】分散コンピューティングシステムにおいて、クライアントの要求の受信から応答の送信間のメッセージ遅延をより少なくする。
【解決手段】一般化されたコンセンサスを達成し、交換可能なコマンドを任意の順序で選択する。リーダーは、コマンドの前に選択されたシーケンスについて知ることができ、コマンドの互換シーケンスを提案する。デバイスは、前に選択されたシーケンスと互換のコマンドのシーケンスを選択する。追加コマンドは、前に選択されたシーケンスおよび追加コマンドを含むコマンドのシーケンスを選択する。デバイスがクライアントから直接に提案を受信する場合に、さらなる効率を実現することができる。さまざまなクライアントからさまざまな順序で到着する複数の提案が、さまざまな順序で選択される場合がある。これらの提案が交換可能である場合に、一般化されたコンセンサスが存在し、システムが効率的な動作を継続することを可能にする。
【選択図】図１１ｃ

Description

本発明は、全般的には分散コンピューティングに関し、具体的には、交換可能であるコマンドを順序付けずにコンセンサスを達成できるフォールトトレラント分散コンピューティングに関する。
パーソナルコンピューティングデバイスが強力になり、大きいストレージ空間と高い処理能力を含むようになるにつれて、平均的なユーザが、日常の作業を実行する際にこれらのリソースのますます小さい比率を消費するようになる。したがって、現在のパーソナルコンピューティングデバイスの多くは、そのコンピューティング能力が、ほとんどのユーザが課す要求を大きく超えるので、しばしば、その潜在能力のすべてを使用されてはいない。強力な現代のパーソナルコンピューティングデバイスの未使用のリソースから用途および価値を導出するますます人気の高まる方法が、分散コンピューティングシステムであり、この分散コンピューティングシステムでは、コンピューティングデバイスが、互いに強調して働いて、データおよび計算リソースへのより信頼できるアクセスを提供する。
過剰なコンピューティング容量を使用する有用な機構を提供することに加えて、分散システムは、より大きくより高価なコンピューティングデバイスの性能およびストレージ容量を達成するために、専用の安価なコンピューティングデバイスからなるものとすることもできる。分散システムのもう１つの利益は、単一のより大きいコンピューティングデバイスの力を失わせる物理的問題にもかかわらず動作を継続する能力である。そのような問題に、持続する停電、悪天候、洪水、テロリスト活動などが含まれる。
個々のメンバコンピューティングデバイスがネットワークから切断され、電源を切られ、システム機能不全をこうむり、または他の形で使用不能になる高い危険性を補償するために、冗長性を使用して、分散コンピューティングシステムが動作状態のままになることを可能にすることができる。したがって、任意の１つのパーソナルコンピューティングデバイスに保管された情報を、少なくとも１つの追加のパーソナルコンピューティングデバイスに冗長に保管することができ、パーソナルコンピューティングデバイスの１つが故障した場合であってもその情報にアクセス可能なままにすることができる。
分散コンピューティングシステムは、システム内のすべてのデバイスが同一のタスクを実行し、同一の情報を保管する、完全な冗長性を実践することができる。そのようなシステムは、デバイスのうちの１つを除くすべてが故障した場合であっても、ユーザが有用な動作を実行し続けることを可能にすることができる。あるいはまた、そのようなシステムを使用して、同一の情報の複数のコピーを、ある地理的領域全体に分散させることを可能にすることができる。たとえば、複数の国にまたがる会社が、全世界の分散コンピューティングシステムを確立することができる。
しかし、分散コンピューティングシステムは、そのシステムを構成する個々のデバイスを正しく同期させることの複雑さに起因して、維持が困難である可能性がある。個々のプロセスにまたがるタイムキーピングが、最良でも困難になる可能性があるので、状態機械手法が、しばしば、個々のデバイスにまたがってアクティビティを調整するのに使用される。状態機械は、状態の組、コマンドの組、応答の組、および各応答／状態対を各コマンド／状態対にリンクするクライアントコマンドによって記述することができる。状態機械は、その状態を変更し、応答を作ることによって、コマンドを実行することができる。したがって、状態機械は、その現在の状態および実行しようとしているアクションによって完全に記述することができ、正確なタイムキーピングを使用する必要がなくなる。
したがって、状態機械の現在の状態は、前の状態、それ以降に実行されたコマンド、およびこれらのコマンドが実行された順序に依存する。２つまたはそれ以上の状態機械の間の同期を維持するために、共通の初期状態を確立することができ、各状態機械は、この初期状態から開始して、同一のコマンドを同一の順序で実行することができる。したがって、ある状態機械を別の状態機械に同期化するために、別の状態機械によって実行されたコマンドの判定を行う必要がある。したがって、同期化という問題は、実行されたコマンドの順序の判定、または、より具体的には、所与のステップについて実行された特定のコマンドの判定という問題になる。
所与のステップについてどのコマンドが実行されたかを判定する機構の１つを、Ｐａｘｏｓアルゴリズムと称する。Ｐａｘｏｓアルゴリズムでは、個々のデバイスのどれであっても、リーダーとして働き、そのシステムのすべてのデバイスによる実行のために所与のクライアントコマンドを提案（ｐｒｏｐｏｓｅ）しようとすることができる。すべてのそのような提案を、提案をより簡単に追跡するために提案番号と共に送信することができる。そのような提案番号は、デバイスが実行すべきコマンドに関する合意を試みている特定のステップとの関連を担う必要がない。当初、リーダーは、そのリーダーがサブミットするつもりの提案の提案番号を提議（ｓｕｇｇｅｓｔ）することができる。次に、残りのデバイスのそれぞれが、リーダーによる提案番号の提議に、それらのデバイスが投票した最後の提案の指示または提案に投票しないことの指示を用いて応答することができる。さまざまな応答を介して、リーダーが、デバイスによって投票された他の提案について知らない場合に、リーダーは、前のメッセージで提議した提案番号を使用して、所与のクライアントコマンドがデバイスによって実行されることを提案することができる。各デバイスは、そのステージで、そのアクションに投票するかそれを拒否するかを判定することができる。あるデバイスは、別のリーダーによるより高い提案番号の提議に応答した場合に限って、アクションを拒否しなければならない。定足数と称する十分な数のデバイスが、提案に投票する場合に、提案されたアクションが、合意されたといわれ、各デバイスは、そのアクションを実行し、結果を送信することができる。そのような形で、デバイスのそれぞれが、同一の順序でアクションを実行することができ、すべてのデバイスの間で同一の状態が維持される。
一般に、Ｐａｘｏｓアルゴリズムは、２フェーズすなわち、上で説明したように、デバイスによって投票された、以前の提案をリーダーが知ることを可能にする最初のフェーズと、リーダーが実行のためにクライアントコマンドを提案できる第２フェーズからなると考えることができる。リーダーは、前の提案を知ったならば、第１フェーズを繰り返す必要がない。その代わりに、リーダーは、第２フェーズを継続的に繰り返し、複数のステップで分散コンピューティングシステムによって実行できるクライアントコマンドのシリーズを提案することができる。そのような形で、各ステップに分散コンピューティングシステムによって実行される各クライアントコマンドを、Ｐａｘｏｓアルゴリズムの１つのインスタンスと考えることができるが、リーダーは、次のステップに関する別のクライアントコマンドを提案する前に、所与のステップの提案されたクライアントコマンドにデバイスが投票するのを待つ必要がない。
分散コンピューティングシステムは、全体として、状態機械としてモデル化することができる。したがって、完全な冗長性を実装した分散コンピューティングシステムは、デバイスのそれぞれに、システム全体の状態を複製させることができる。そのようなシステムは、各デバイスが同一の状態を維持することを必要とする。いくつかのデバイスが、あるクライアントコマンドが実行されたと考え、デバイスの第２のグループが、異なるクライアントコマンドが実行されたと考える場合に、このシステム全体は、もはや、単一の状態機械として動作しなくなる。そのような状況を避けるために、過半数のデバイスが、一般に、システムによる実行について提案されたクライアントコマンドを選択することを要求することができる。それぞれが過半数を有するデバイスの２つのグループは、必ず少なくとも１つのデバイスを共有しなければならないので、それぞれが過半数のデバイスを含む２つのグループが異なる提案されたクライアントコマンドを選択することを避けるために少なくとも１つの共通デバイスに頼るＰａｘｏｓアルゴリズムなどの機構を実装することができる。
すべてのデバイスが同一のコマンドを同一の順序で実行することを要求することによって、Ｐａｘｏｓアルゴリズムは、クライアントによる要求と分散コンピューティングシステムによるその要求に対する応答との間のメッセージ遅延の個数の増加を犠牲にして、必要以上に柔軟性のないものである可能性がある、構成デバイスの間の同期化を達成する。多くの状況で、さまざまなコマンドが実行される順序に無関係に、同一の状態に達することができる。そのようなコマンドは、互いに交換可能であり、これらの状況に関して、そのような交換可能コマンドの順序付けを必要としないアルゴリズムは、分散コンピューティングシステムが、上で全般的に説明したＰａｘｏｓアルゴリズムより少ないメッセージ遅延でクライアントコマンドに応答するとを可能にすることができる。たとえば、分散コンピューティングシステムが、銀行の顧客の差引勘定を維持するのに使用される場合に、異なる顧客のアクションは、互いに交換可能なコマンドである可能性が高い。したがって、顧客Ａが、自分の口座に１００ドルを預金することを要求し、それとほぼ同時に、顧客Ｂが、自分の口座から５０ドルを引き出す要求を発行した場合に、最終的な状態に影響せずに、どちらのコマンドでも先に実行することができる。その結果、分散コンピューティングシステムは、いくつかのデバイスが顧客Ａのコマンドを先に実行し、残りのデバイスが顧客Ｂのコマンドを先に実行した場合であっても、正しく機能し続けることができる。
米国特許出願１０／１８４，７６７号明細書 本願と同日に提出された「Fast Paxos Recovery」という名称の特許出願（代理人明細書番号２２８６２５） "Time, Clocks, and the Ordering of Events in a Distributed System," by Leslie Lamport published in The Communications of the ACM, Volume 21, Number 7, July 1978 "The Part-Time Parliament" by Leslie Lamport, published in ACM Transactions on Computer Systems, volume 16, number 2 on pages 133-169, dated May 1998
したがって、交換可能なコマンドを考慮に入れることができ、これによって、クライアントの要求の受信とそのクライアントへの応答の送信の間のより少ないメッセージ遅延を導入する分散コンピューティングシステムが必要である。
したがって、本発明の一実施形態で、システムは、構成デバイスがコマンドのシリーズに合意することを可能にする一般化されたＰａｘｏｓアルゴリズムを実装することができ、交換可能なコマンドの順序だけが異なるシリーズを、同等物と考えることができる。
別の実施形態で、減らされた個数のメッセージ遅延がクライアントの要求の受信とクライアントへの応答の送信の間に導入される一般化されたＰａｘｏｓアルゴリズムを提示する。低メッセージ遅延の一般化されたＰａｘｏｓアルゴリズムは、構成デバイスによって選択される交換可能コマンドの順序が同一でない場合であっても正しい動作を継続することができる。
さらなる実施形態で、個々の構成デバイスがリーダーデバイスからの介入を必要とせずに競合する状態を訂正できる、代替の低メッセージ遅延の一般化されたＰａｘｏｓアルゴリズムを提示する。個々の構成デバイスは、リーダーが行うはずのことを判定でき、これによって、リーダーの介入なしで競合を解決することができる。
さらなる実施形態で、他のコマンドと交換可能でないチェックポイントコマンドを使用して、現在合意されている状態を達成でき、一般化されたＰａｘｏｓアルゴリズムまたは低メッセージ遅延の一般化されたＰａｘｏｓアルゴリズムのいずれかを実装するデバイスの間のメモリストレージリソースの効率的な割り当てが可能になる。
さらなる実施形態で、コマンド識別子を使用して、一度要求されたコマンドが１回だけ実行されることを保証することができる。コマンド識別子は、選択されたコマンドを実行する前に、コマンドを実行する任意のデバイスが調べることができ、あるいは、提案されたコマンドの投票の前に、提案されたコマンドに投票する任意のデバイスが調べることができる。
本明細書の説明は、主に、分散コンピューティングシステム内のコンピューティングデバイスの動作に焦点を合わせたものであるが、この説明が、別々のプロセッサ上または別々のメモリ空間内など、単一のコンピューティングデバイスで動作するプロセスに同等に適用可能であることを諒解されたい。したがって、追加の実施形態に、複数のプロセッサが物理的に１つまたは複数のコンピューティングデバイスのどちらに配置されるかに関わりなく、複数プロセッサ環境での、および複数の仮想マシンが１つまたは複数のコンピューティングデバイスのどちらによって実行されているかに関わりなく、複数仮想マシン環境での、変更されたＰａｘｏｓアルゴリズムの動作が含まれる。本発明の追加の特徴および利益は、添付図面を参照して進行する、例示的実施形態の次の詳細な説明から明白になる。
特許請求の範囲に、本発明の特徴を詳細に示すが、本発明は、その目的および利益と共に、添付図面と共に解釈される次の詳細な説明から最もよく理解することができる。
分散コンピューティングシステムに、複数の個々のパーソナルコンピューティングデバイス、サーバコンピューティングデバイス、またはこのシステムに参加するのに十分なプロセッサ能力およびストレージ能力を有する他のデバイスを含めることができる。分散コンピューティングシステムは、その構成コンピューティングデバイスの能力を集約して、大きく高められた処理能力およびストレージ空間を提供するか、複数のデバイスが同一の情報へのアクセスを提供できるようにする冗長性を実装することができる。したがって、分散コンピューティングシステムの１つの共通の用途が、共通のネットワークに接続された多数の異なるパーソナルコンピューティングデバイスの未使用の処理能力およびストレージ空間の集約である。そのような分散コンピューティングシステムは、どのデバイスが現在そのシステムの一部であるか、およびどのデバイスに情報の所与のセットが保管されているかなど、システムに関する情報を維持することができる。この情報は、デバイスがその能力およびストレージ空間を集約するために必要である可能性があり、その結果、各デバイスにコピーを含めることができる。このシステムのデバイスの間の情報の同期化は、下で説明するように状態機械手法を介して容易にすることができる。
あるいはまた、分散コンピューティングシステムのますます一般的になる用途が、さまざまな形の情報の中央ストレージリポジトリとして働くことができるネットワークサーバという用途である。そのような分散システムは、その構成デバイスのすべてに中央ストアを複製することを求め、その結果、中央ストレージと通信しようとするすべてのクライアントが、通信すべき便利で効率的なデバイスを見つけられるようになる。さらに、システムの分散された性質のゆえに、停電、洪水、政治的不安などのローカルイベントが、少数のコンピューティングデバイスだけに影響する可能性があり、システム全体が正しく動作し続け、情報および他のサービスへのアクセスをクライアントに提供できるようになる。
そのような分散コンピューティングシステムは、状態機械と考えることができ、この機械の将来の状態は、現在の状態および行われるアクションによって定義される。分散コンピューティングシステムの各構成デバイスは、システム全体の状態機械を独立に実行することができる。状態機械手法は、非同期に実施することができ、その結果、構成デバイスにまたがる正確な同期を維持する必要がなくなり、デバイスの間の同期を、すべてのデバイスの初期状態をセットし、その後、同一の順序で同一の機能を実行することによって達成することができる。同期を維持する共通の方法は、分散コンピューティングシステムの構成デバイスが、次の機能を実行する前にその機能にすべての構成デバイスが合意することができ、実行された機能のリストを維持できるようにすることである。そのような形で、すべてのデバイスが同一の状態を有することを保証することができる。
サーバとして働く分散コンピューティングシステムは、多国籍企業の中央データベースまたは人気のあるワールドワイドウェブサイトなど、クライアントの別個の組に大量の情報をサービスすることに特に有用である可能性がある。そのような状況では、大量のクライアントが、サーバとして働く分散コンピューティングシステムに情報を要求する可能性がある。複数のデバイスにまたがってサーバ機能性を実装することによって、より多くのクライアントに並列にサービスすることができ、これによって、システム全体のスループットが高まり、全体としてのサーバが、高められた冗長性に起因して、はるかに故障しにくくなる。
構成コンピューティングデバイスが次に実行する機能について合意できる機構の１つを、Ｐａｘｏｓアルゴリズムと称する。Ｐａｘｏｓアルゴリズムでは、下でさらに説明するように、すべてのデバイスが、リーダーとして働き、分散コンピューティングシステム内の他のデバイスに提案番号に関する提議を送信することができる。他のデバイスは、そのデバイスが既に投票した最大の提案番号を有する提案の指示またはそのデバイスが前の提案のどれにも投票していないことの指示のいずれかを用いて応答することができる。リーダーデバイスは、他のデバイスからの応答を受信したならば、提案すべき機能を判定し、提案される機能への投票を要求することができる。各デバイスは、提案の最初の送信の後、要求された投票の前のある時に、より大きい提案番号の提議に応答したのでない限り、提案に投票する。定足数のデバイスが提案に投票する場合に、その提案が受け入れられ、リーダーは、すべてのデバイスに、合意された機能を実行することを要求するメッセージを送信することができる。
分散コンピューティングシステムの構成コンピューティングデバイスが次に実行する機能に合意できるもう１つの機構を、高速Ｐａｘｏｓアルゴリズムと称する。高速Ｐａｘｏｓアルゴリズムは、下でさらに説明するように、デバイスが、クライアントから直接に受信した提案に投票できるようにし、通常動作でのリーダーデバイスの必要をなくす。十分な数のデバイスが提案に投票したならば、その提案が受け入れられ、その結果を要求元クライアントに送信することができる。要求をクライアントから直接に受信することによって、高速Ｐａｘｏｓアルゴリズムは、通常動作で、クライアントの要求の受信と応答の送信の間の１つ少ないメッセージ遅延を導入する。しかし、リーダーデバイスが要求を順序付けないので、構成デバイスが、同一の要求を同一の順序で受信しない場合がある。これは、２つの要求がほぼ同時に送信される場合に特に真である可能性がある。その場合に、一部のデバイスが、次のシステムステップについて一方の機能を選択し、他のデバイスが、次のシステムステップについて他方の機能を選択する場合がある。そのような競合が発生した場合には、Ｐａｘｏｓアルゴリズムを使用して、コンセンサスを復元することができるが、さらなるメッセージ遅延がもたらされる可能性がある。
しかし、２つまたはそれ以上の要求をお互いに関して順序付ける必要がない場合には、高速Ｐａｘｏｓアルゴリズムは、構成デバイスの間のより一般化された合意を可能にすることによって、効率的な動作を継続することができる。しばしば、ほぼ同時に送信される２つの要求が、互いに交換可能である。具体的に言うと、別の要求とほぼ同時に送信された１つの要求に対する応答が、他方の要求によって影響されない。たとえば、バンキングシステムで、顧客Ｂが、自分の口座から５０ドルを引き出す要求を発行するのとほぼ同時に、顧客Ａが、自分の口座に１００ドルを預金することを要求することができる。この２つの例示的なコマンドは、交換可能である。というのは、顧客Ｂの、自分の口座から５０ドルを引き出す要求が、顧客Ｂの要求が顧客Ａの要求の前後のどちらに実行されるかにかかわりなく、顧客Ａの差引勘定を変更しないからである。その結果、顧客Ｂの要求を最初に実行するデバイスは、顧客Ａの要求を最初に実行するデバイスと同一の、顧客Ａおよび顧客Ｂの両方に対する結果をもたらす。
一般化されたＰａｘｏｓアルゴリズムは、任意の順序で交換可能コマンドを選択するデバイスが、同期化されたままになることを認識することができる。たとえば、一般化されたＰａｘｏｓアルゴリズムは、顧客Ｂの要求の前に顧客Ａの要求を選択するデバイスが、顧客Ａの要求の前に顧客Ｂの要求を選択するデバイスと一致することを認識することができる。その結果、一般化されたＰａｘｏｓアルゴリズムは、ステップのシリーズとして実行される機能のシリーズに関する合意を達成することを求めることができるが、上で述べたＰａｘｏｓアルゴリズムは、ステップごとの基礎での合意を必要とする。
動作上、下で詳細に説明するように、一般化されたＰａｘｏｓアルゴリズムは、上で述べたＰａｘｏｓアルゴリズムに類似するものとすることができる。具体的に言うと、すべてのデバイスが、リーダーとして働き、分散コンピューティングシステム内の他のデバイスに提案番号の提議を送信することができる。他のデバイスは、そのデバイスが既に投票した最大の提案番号に対応する提案の指示、またはそのデバイスが前の提案に投票していないことの指示のいずれかを用いて応答することができる。一般化されたＰａｘｏｓアルゴリズムは、機能のシリーズに対する合意を達成しようとするので、リーダーによる提案番号の提議に対する応答に、単一の提案番号に対応する前に投票された提案のシリーズを含めることができる。リーダーは、他のデバイスからの応答を受信したならば、提案すべき機能のシリーズを判定することができ、そのシリーズへの投票を要求することができる。各デバイスは、提案の最初の送信の後、要求された投票の前のある時に、より大きい提案番号の提議に応答したのでない限り、そのシリーズに投票する。定足数のデバイスが機能の提案されたシリーズに投票する場合に、そのシリーズが受け入れられ、リーダーは、すべてのデバイスに、合意された機能を実行することを要求するメッセージを送信することができる。分散コンピューティングシステムは、リーダーが前の提案番号を使用して機能の新しいシリーズを提案するときに、追加機能を選択することができる。各提案されたシリーズに、前に選択されたシリーズを含めることができ、１つまたは複数の新しい機能を追加することができる。
代替の一般化されたＰａｘｏｓアルゴリズムは、上で述べた高速Ｐａｘｏｓアルゴリズムに基づくものとすることができ、分散コンピューティングシステムの構成コンピューティングデバイスが機能のシリーズに合意できるより効率的な機構を提供することができる。したがって、一般化された高速Ｐａｘｏｓアルゴリズムは、下でさらに説明するように、デバイスが、クライアントから直接受信した提案に投票できるようにし、通常動作でのリーダーデバイスの必要をなくすことができる。デバイスは、前に投票された提案および新しい提案を含む提案のシリーズに投票することによって、クライアントの提案に投票することができる。十分な数のデバイスが、互いに競合しない提案のシリーズに投票したならば、そのシリーズおよびそのシリーズの競合しない順列のすべてが、受け入れられたと考えられ、その結果を、要求元のクライアントに送信することができる。デバイスが、クライアントから直接に要求を受信することができるので、一般化された高速Ｐａｘｏｓアルゴリズムは、通常動作で、クライアントの要求の受信と応答の送信の間の１つ少ないメッセージ遅延を導入することができる。さらに、一般化された高速Ｐａｘｏｓアルゴリズムは、機能のシリーズを選択し、交換可能な機能の異なる順序付けに対処するので、競合は、一部のデバイスがあるコマンドを最初に受信し、選択し、他のデバイスが第１のコマンドと交換可能な異なるコマンドを受信し、選択したことだけが原因では生じない。これは、下で詳細に説明するように、ほぼ同時に送信され、さまざまなデバイスに異なる順序で到着する可能性が高いクライアント要求が交換可能でもある可能性が最も高いので、特に有用である可能性がある。しかし、競合が発生する場合には、一般化されたＰａｘｏｓアルゴリズムを使用して、コンセンサスを復元することができるが、これは、さらなるメッセージ遅延ももたらす可能性がある。
分散コンピューティング環境
図面に移ると、図面では同一の符号が同一の要素を指すが、本発明が、図１に示された例示的な分散コンピューティングシステム１０などの分散コンピューティングシステムによって実装されるものとして示されている。提示を簡単にするためにのみ、本発明を、図１に示されているように相互接続されたコンピューティングデバイス１１から１５を含むシステム１０などの分散コンピューティングシステムに関して説明する。当業者が理解するように、本発明は、すべての分散コンピューティング環境に適用可能であり、いかなる形であれ、提示のために単純化されている図１の例示的な分散コンピューティングシステムに制限されることを意図されていない。
図１に、単一のクライアントコンピューティングデバイス２０も示されているが、本発明は、任意の個数のクライアントコンピューティングデバイスを有する環境で動作することが意図されている。クライアントコンピューティングデバイス２０は、分散コンピューティングシステム１０への包括的な通信接続を有するものとして図示されている。当業者に既知のように、そのような通信接続は、任意の通信媒体およびプロトコルを使用することができ、クライアントコンピューティングデバイス２０が分散コンピューティングシステム１０内の１つまたは複数のコンピューティングデバイスと通信することを可能にすることができる。
さらに、図１に、分散コンピューティングシステム１０の一部として図示されていないが、やはりシステム１０への包括的な通信接続を維持するコンピューティングデバイス３０および３１が示されている。上と同様に、この通信接続は、任意の通信媒体およびプロトコルを使用することができ、コンピューティングデバイス３０および３１が分散コンピューティングシステム１０内の１つまたは複数のコンピューティングデバイスと通信することを可能にすることができる。下でさらに詳細に説明するように、コンピューティングデバイス３０および３１は、システム１０の一部にならずに、システム１０によって実行された実行の結果について知ることができる。あるいはまた、コンピューティングデバイス３０および３１は、システム１０によって選択された機能について知ることができ、その機能をそれ自体で実行することができ、これによって、システム１０内のデバイスと同一の状態を独立に維持することができる。
必要ではないが、本発明を、プログラムモジュールなど、コンピューティングデバイスによって実行されるコンピュータ実行可能命令の全般的な文脈で説明する。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、当業者は、本発明を、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む多数のさまざまなコンピューティングデバイスを用いて実践できることを諒解するであろう。上で説明したように、本発明を、分散コンピューティングシステム１０など、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリストレージデバイスに置くことができる。
図２に移ると、本発明を実装できる例示的なコンピューティングデバイス１００が示されている。コンピューティングデバイス１００は、適当なコンピューティングデバイスの一例にすぎず、本発明の使用または機能性の範囲に関する制限を提議することを意図されたものではない。たとえば、例示的なコンピューティングデバイス１００は、図１に示されたコンピューティングデバイス１１〜１５、２０、または３０〜３１のいずれかを正確に表すことを意図されたものではない。例示的なコンピューティングデバイス１００は、メモリパーティション、仮想マシン、複数のプロセッサ、または１つの物理的コンピューティング構造が下で複数のコンピューティングデバイスに帰するものとして説明されるアクションを実行できるようにする類似するプログラミング技法を介するなど、これらのコンピューティングデバイスのうちの１つまたは複数を実装することができる。さらに、コンピューティングデバイス１００を、図２に示された周辺機器の任意の１つまたは組合せに関する依存性または要件を有するものと解釈してはならない。
本発明を、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。分散コンピューティング環境では、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクを実行することができる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルとリモートの両方のコンピュータ記憶媒体に置くことができる。
コンピュータデバイス１００のコンポーネントに、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバス、メモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。さらに、処理ユニット１２０に、１つまたは複数の物理プロセッサを含めることができる。
コンピューティングデバイス１００に、通常は、さまざまなコンピュータ可読媒体が含まれる。コンピュータ可読媒体は、コンピューティングデバイス１００によってアクセスでき、揮発性媒体および不揮発性媒体、リムーバブル媒体およびノンリムーバブル媒体の両方を含む使用可能な媒体のいずれかとすることができる。制限ではなく例として、コンピュータ可読媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を保管する任意の方法またはテクノロジで実施された、揮発性および不揮発性、リムーバブルおよびノンリムーバブルの両方の媒体が含まれる。コンピュータ記憶媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報の保管に使用でき、コンピューティングデバイス１００によってアクセスできる他のすべての媒体が含まれるが、これに制限はされない。通信媒体によって、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施され、通信媒体には、すべての情報配布媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲に含まれなければならない。
システムメモリ１３０に、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形のコンピュータ記憶媒体が含まれる。起動中などにコンピュータ１００内の要素の間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ １３１に保管される。ＲＡＭ １３２には、通常は、処理ユニット１２０から即座にアクセス可能、かつ／または処理ユニット１２０によって現在操作中のデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図２に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
コンピューティングデバイス１００に、他のリムーバブル／ノンリムーバブル、揮発性／不揮発性のコンピュータ記憶媒体も含めることができる。単なる例として、図２に、ノンリムーバブル不揮発性磁気媒体から読み取るかこれに書き込むハードディスクドライブ１４１、リムーバブル不揮発性磁気ディスク１５２から読み取るかこれに書き込む磁気ディスクドライブ１５１、ＣＤ−ＲＯＭまたは他の光媒体などのリムーバブル不揮発性光ディスク１５６から読み取るかこれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境で使用できる他のリムーバブル／ノンリムーバブル、揮発性／不揮発性のコンピュータ記憶媒体に、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、これに制限はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などのノンリムーバブルメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などのリムーバブルメモリインターフェースによってシステムバス１２１に接続される。
上で説明し、図２に示したドライブおよびそれに関連するコンピュータ記憶媒体は、コンピューティングデバイス１００のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。図２では、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管するものとして図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一のまたは異なるもののいずれかとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低限でも異なるコピーであることを示すために、異なる符号を与えられている。ユーザは、キーボード１６２および、一般にマウス、トラックボール、またはタッチパッドと称するポインティングデバイス１６１などの入力デバイスを介してコンピューティングデバイス１００にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含めることができる。上記および他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタのほかに、コンピュータに、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介して接続できる他の周辺出力デバイスも含めることができる。
コンピューティングデバイス１００は、１つまたは複数のリモートコンピュータへの論理接続を使用して、図１に示されたものなどのネットワーク化された環境で動作することができる。図２に、リモートコンピューティングデバイス１８０への一般的なネットワーク接続１７１を示す。一般的なネットワーク接続１７１および図１に示されたネットワーク接続は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、無線ネットワーク、イーサネット（登録商標）プロトコルに従うネットワーク、トークンリングプロトコル、あるいは、インターネットもしくはワールドワイドウェブを含む他の論理ネットワーク、物理ネットワーク、または無線ネットワークを含む、さまざまな異なるタイプのネットワークおよびネットワーク接続のいずれかとすることができる。
ネットワーキング環境で使用されるとき、コンピューティングデバイス１００は、ネットワークインターフェースまたはネットワークアダプタ１７０を介して一般的なネットワーク接続１７１に接続され、このネットワークインターフェースまたはネットワークアダプタ１７０は、有線または無線のネットワークインターフェースカード、モデム、または類似するネットワーキングデバイスとすることができる。ネットワーク化された環境では、コンピューティングデバイス１００に関して図示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを諒解されたい。
次の説明では、そうでないと示されない限り、本発明を、１つまたは複数のコンピューティングデバイスによって実行される行為および動作の記号表現に関して説明する。したがって、そのような行為および動作が、時々コンピュータ実行されると称するが、構造化された形でデータを表す電気信号のコンピューティングデバイスの処理ユニットによる操作を含むことを理解されたい。この操作は、コンピューティングデバイスのメモリシステム内の位置でデータを変換するか維持し、これによって、当業者によく理解される形でコンピューティングデバイスの動作が再構成または他の形で変更される。データが維持されるデータ構造は、データのフォーマットによって定義される特定のプロパティを有するメモリの物理的位置である。しかし、本発明を、前述の文脈で説明するが、下で説明するさまざまな行為および動作をハードウェアで実装することもできることを当業者が諒解するので、これが制限的であることは意図されていない。
概要
本発明によれば、分散コンピューティングシステムは、単一の機能ではなく機能の互換シリーズに合意することによって、一般化されたフォールトトレラントアルゴリズムを実装することができる。下で詳細に説明するＰａｘｏｓアルゴリズムは、２倍の個数のコンピューティングデバイスが使用されるならば、その個数の障害を許容できる分散コンピューティングシステムを実装する機構を提供することができる。やはり下で詳細に説明する一般化されたＰａｘｏｓアルゴリズムは、Ｐａｘｏｓアルゴリズムの機構を利用して、フォールトトレランスを提供することができるが、単一の機能ではなく機能のシリーズを提案し、選択することができる。具体的に言うと、互いに交換可能なコマンドの相対順序だけが異なる機能のシリーズを、互換と考えることができ、定足数のデバイスによる投票を、機能のそのようなシリーズのすべての選択と考えることができる。
下で詳細に説明する高速Ｐａｘｏｓアルゴリズムは、ある個数の３倍のコンピューティングデバイスが使用される場合に、その個数の障害を許容することができる分散コンピューティングシステムを実装するより効率的な機構を提供する。Ｐａｘｏｓアルゴリズムと異なり、高速Ｐａｘｏｓアルゴリズムは、クライアントデバイスから直接に要求を受信でき、クライアントの要求の受信とその要求に対する応答の送信の間の少なくとも１つのメッセージ遅延を節約する。下でさらに詳細に説明する一般化された高速Ｐａｘｏｓアルゴリズムは、同様に、クライアントデバイスから直接に要求を受信することができる。しかし、高速Ｐａｘｏｓアルゴリズムと異なって、一般化された高速Ｐａｘｏｓアルゴリズムは、２つまたはそれ以上の要求がこのアルゴリズムを実装するデバイスにさまざまな順序で到着する場合に、その要求が交換可能であればコンセンサスを達成できる形で、機能のシリーズを選択することができる。要求が交換可能でない場合には、一般化されたＰａｘｏｓアルゴリズムを使用して、特定の順序に関するコンセンサスを達成することができる。
一般化されたＰａｘｏｓアルゴリズムおよび一般化された高速Ｐａｘｏｓアルゴリズムの両方が、機能の制限されないシリーズに対するコンセンサスを達成するので、チェックポイント機能を使用して、より効率的なメモリ使用を可能にすることができる。具体的に言うと、チェックポイント機能は、他の機能と交換可能でない機能とすることができる。その結果、チェックポイント機能は、構成デバイスが機能の新しいシリーズの選択を開始できる点をマークすることができる。チェックポイント機能は、一般化されたＰａｘｏｓアルゴリズムではリーダーデバイスによって、一般化された高速Ｐａｘｏｓアルゴリズムではすべてのクライアントによって、提案することができる。
本発明の実施形態によって企図されているアルゴリズムのさらに詳細な説明は、まず状態機械の説明から進行し、Ｐａｘｏｓアルゴリズムおよび高速Ｐａｘｏｓアルゴリズムの実施形態の説明がこれに続く。その後、一般化されたＰａｘｏｓアルゴリズムおよび一般化された高速Ｐａｘｏｓアルゴリズムの実施形態の詳細な説明を示す。
状態機械
図１に示された分散システム１０などの分散環境では、デバイスの間の調整が、困難な作業になる可能性がある。調整要因として時間に頼ることに固有の問題を回避する機構の１つが、機能の実行が状態機械をある状態から別の状態に移動する状態機械に関して分散コンピューティングシステムをモデル化することである。したがって、状態機械を、状態の組、コマンドの組、応答の組、および各応答／状態対を各コマンド／状態対にリンクする機能を参照して記述することができる。状態機械のクライアントは、状態機械が機能を実行することを要求するコマンドを発行することができる。この機能は、状態機械の状態を変更し、応答を作ることができる。
分散コンピューティングシステムを構成する個々のデバイスは、それぞれ、このシステムの状態機械を実行することができる。したがって、これらのデバイスは、初期状態を決定し、次に、それから、同一の機能を同一の順序で実行することによって調整することができる。デバイスは、単純に、そのデバイスが最後に実行した機能を判定し、他のデバイスによって実行された機能の順序付きリストでその機能を突き止め、次に、そのデバイスに、その順序付きリストからそのデバイスがまだ実行していない機能を実行するように指示することによって同期化することができる。そのような状態機械手法は、最初に、その開示と一貫する本明細書で提示される教示または提議をさらに説明または記述するためにその内容全体を参照によって本明細書に組み込まれている文献で提案された（たとえば、非特許文献１参照）。
Ｐａｘｏｓアルゴリズム
状態機械手法を使用することによって、図１に示された分散コンピューティングシステム１０の構成デバイス１１から１５の同期化を、実行される機能およびそれらを実行する順序に合意することによって達成することができる。実行される機能に合意する方法の１つを、Ｐａｘｏｓアルゴリズムと称する。Ｐａｘｏｓアルゴリズムは、システム１０が、デバイスが高度な警告なしで動作を停止する可能性がある障害にもかかわらず正しく動作することを可能にする。Ｐａｘｏｓアルゴリズムは、システム全体がある機能を実行する前に、少なくとも定足数のデバイスがその機能に合意することを必要とする。Ｐａｘｏｓアルゴリズムを用いると、定足数は、システムの特定の要件に応じて、単に過半数とすることができ、あるいは、それより多数のデバイスを含めることができる。どのように定義されても、定足数は、２つの定足数が少なくとも１つの共通のデバイスを有するように十分に多数とすることができる。
一貫性を維持するために、Ｐａｘｏｓアルゴリズムは、システム１０が機能の実行をステップごとに単一の機能に制限することを要求することができる。したがって、所与のステップについて単一の機能だけを選択することができる。２つの定足数が、共通の少なくとも１つの正しく機能するデバイスを有するので、１を超えないステップの選択を、すべてのデバイスが１つの提案だけについて投票することを要求することによって保証することができる。しかし、複数のデバイスが同時にリーダーとして働いた場合に、そのような要件が、膠着状態を引き起こす可能性がある。というのは、提案のどれもが定足数によって合意されず、デバイスのどれもが異なる機能の提案に投票することができず、その結果、最終的に定足数に達することができなくなるからである。
Ｐａｘｏｓアルゴリズムは、デバイスが投票を変更することを許可されるが、リーダーがそれが提案した機能に制約されるマルチフェーズプロセスを介してこの問題を解決する。Ｐａｘｏｓアルゴリズムを使用すると、リーダーは、前に提案された機能について知らない限り、そのリーダーが選択する任意の機能を提案することができる。リーダーが、定足数に含まれる少なくとも１つのデバイスが既に投票している少なくとも１つの前に提案された機能について知っている場合に、そのリーダーは、そのリーダーが知っている前に提案された機能のうちの最も最近の機能を提案することができる。各デバイスは、そのデバイスが投票した最も最近の提案だけを追跡する必要がある。デバイスが、投票することを約束した提案を受信し、その間に別の提案に投票することを約束していない場合に、そのデバイスは、その提案に１票を投じることができる。デバイスは、提案が、そのデバイスが前に投票を約束した他の提案より大きい提案番号を有する場合に限って、提案に投票することを約束することができる。提案番号の使用は、このシステムが、構成デバイスの間のクロックの複雑で高価な同期化に頼る必要なしに正しい動作を達成できるようにする。最も最近の提案は、一般に、より大きい提案番号を有する。そうでない場合には、下で説明するように、その提案を無視することができる。提案に投票することを約束するときに、デバイスは、リーダーに、現在の提案番号より小さい、そのデバイスが前に投票を約束した最大の提案番号も送信する。そのような形で、リーダーは、必ず前の提案について知ることができる。
図３ａに移り、Ｐａｘｏｓアルゴリズムを、図示の５つのデバイス１１から１５を含む例示的な分散コンピューティングシステム１０を使用して詳細に説明する。そのような環境では、定足数を、３つ以上のデバイスの任意のグループと定義することができる。というのは、そのような定義が、すべての定足数が共通の少なくとも１つのデバイスを有することを保証するからである。図３ａに示されているように、デバイス１３は、リーダーシップの立場を引き受け、デバイス１１〜１２および１４〜１５にメッセージ２００を送信し、デバイス１１〜１５に機能を提案するのに使用される提案番号を提議することができる。デバイス１３は、デバイスおよびリーダーの両方として働くことができるので、それ自体にメッセージ２００を送信するが、そのような送信は、デバイスの内部で処理でき、物理的に送信される必要はない。デバイス１３は、より大きい提案番号を有する前の提案がないことを保証する努力において、任意の大きい提案番号を選択することができる。さらに、デバイス１３自体は、前の提案に投票した可能性があるので、デバイス１３が知っているすべての提案より大きい提案番号を選択することができる。
提案を、提案番号に基づいて順序付けることができるので、複数のデバイスが異なる提案に同一の提案番号を使用しないようにすることが有利である可能性がある。したがって、提案番号は、提案を送信するデバイスのメディアアクセス制御（ＭＡＣ）アドレスなど、一意のデバイスプロパティに基づく機構を使用してデバイスによって選択することができる。あるいはまた、提案番号を、デバイスの間で区分し、各デバイスがその区分の中からのみ提案番号を選択することを要求することができる。提案番号を区分する方法の１つが、「ｉ」番目のデバイスに、システム内のデバイス数を法とする「ｉ」の剰余と合同の提案番号を与えることである。
下で示すように、Ｐａｘｏｓアルゴリズムは、複数のデバイスがリーダーとして働くことを試みる場合であっても動作できるので、デバイスがリーダーシップの立場を引き受ける機構は、重要でない。それでも、異なるデバイスがそれがリーダーであると同時に考えることができる機会を最小にする機構が、システムの効率を高めることができる。たとえば、ＭＡＣアドレスなどの一意のデバイスプロパティに基づく機構が、同時に複数のリーダーを有する機会を減らすことができる。そのような機構の１つで、単純に、最小のＭＡＣアドレスを有する正しく機能するデバイスを次のリーダーとして選択することができる。さらに、リーダー選択機構は、リーダーシップデバイスのコンスタントな変化を避けるために、あるデバイスが既に所定の時間のうちにリーダーとして働く別のデバイスからメッセージを受信している場合に、そのデバイスがリーダーになることを試みることを防ぐことができる。コンスタントなリーダーシップ変化は、システムの動作に非効率性を導入する可能性があるので、上で説明した機構は、より効率的な動作をもたらすことができる。
図３ｂに移ると、新しい提案番号を提議するメッセージ２００などのメッセージの受信時に、デバイス１１〜１５のそれぞれは、メッセージ２００によって提議された提案番号より小さい最大の提案番号と、そのデバイスが票を投じた最大の提案番号によって提案された機能とを示すメッセージ２１１〜２１５を用いて応答することができる。デバイスが、リーダーによって使用された提案番号より大きい提案番号に票を投じた場合に、そのデバイスは、このリーダーからのメッセージを無視することができ、あるいは、下で説明するように、より大きい提案番号にかかわらず、最後の投票情報を用いて応答することができる。図３ｂに示された例示的な状態では、デバイス１２が、提案番号７０に前に投票しており、この提案番号７０は、変数「ｙ」によって識別される機能をシステム１０が実行することを提案するものであった。したがって、メッセージ２００に応答して、デバイス１２は、それが最後に提案番号７０（機能「ｙ」の実行を提案）に投票したことを示すメッセージ２１２を送信することができる。同様に、デバイス１１は、前に提案番号３０に投票し、この提案番号３０は、変数「ｚ」によって識別される機能をシステム１０が実行することを提案した。したがって、メッセージ２１１は、デバイス１１のこの最後の投票の情報をデバイス１３に伝えることができる。デバイス１３〜１５は、まだ提案を受信しておらず、したがって、前にどの提案にも票を投じていない。したがって、これらは、メッセージ２１３〜２１５によって示されるように、ヌル応答を返すことができる。やはり、上と同様に、デバイス１３からそれ自体に送信されるメッセージは、デバイス１３によって内部で処理することができるが、説明のために図示されている。
図３ｃに移ると、リーダー１３は、メッセージ２１１〜２１５を受信した後に、提案される機能が定足数のメンバによって投票された最大の提案番号の機能と同等になるように、提案に対する適当な機能を決定することができる。定足数メンバのどれもが、前の提案に投票していない場合に、リーダーは、提案したいどの機能でも自由に選択することができる。したがって、図３ｂに示されたメッセージ２１１〜２１５に対して、デバイス１３は、機能「ｙ」が提案番号７０の一部としてデバイス１２によって投票され、提案番号７０がリーダー１３が知った最大の提案番号を有する提案なので、機能「ｙ」の実行への投票を請求（ｓｏｌｉｃｉｔ）することを選択することができる。しかし、図３ａから３ｅに示されたシステム１０に、５つのデバイスが含まれるので、定足数を３つのデバイスにすることができる。したがって、リーダー１３が、定足数として働くために３つ以上のデバイスを選択することで十分である。その結果、リーダー１３によって選択される定足数に、デバイス１２を含めないようにすることができる。その場合に、リーダー１３は、機能「ｙ」を提案する必要がない。というのは、デバイス１２が、選択された定足数のメンバでないからである。その代わりに、リーダー１３は、このリーダーが選択した定足数に含まれるデバイスが前に投票した最大の提案番号を用いて提案された機能を提案することができる。デバイスのどれもが、前に提案に投票していない場合には、リーダーは、それが選択するどの機能でも提案することができる。
提案番号を提議するメッセージ２００は、リーダー１３が選択すべき適当な提案番号を決定でき、リーダーが前に提案されたより小さい番号を有する提案のすべてを知ることを可能にする機構として働くので、前のメッセージが小さすぎる提案番号を有する場合に、リーダー１３が、徐々により大きい提案番号を提議して、メッセージ２００などの複数のメッセージを送信することが必要になる可能性がある。リーダーが複数のメッセージを送信することを要求するのではなく、各デバイスが、リーダーによって提議された提案番号が前に投票された提案より大きいか小さいかにかかわりなく、各デバイスが投票した最大の番号の提案を応答することができる。このような方法で、リーダー１３は、前の投票をより効率的に知ることができ、機能を提案するのに用いられる提案番号をより正確に選択することができる。
図３ｃに戻って、リーダー１３は、システム１０のすべてのデバイスからなる定足数を選択し、システム１０による機能「ｙ」の実行への投票を求めるメッセージ２２０を送信するものとして図示されている。メッセージ２２０の受信時に、各デバイスは、機能「ｙ」に投票するかどうかを決定することができる。デバイスは、投票が現在要求されている提案より大きい提案番号を有する新しい提案の提議に応答していない限り、機能に投票することができる。したがって、図３ｃに示された例では、デバイス１１〜１５のうちのどれかが、リーダー１３からメッセージ２２０を受信する前に、１００を超える提案番号を有する新しい提案に関する別の提議を受信し、応答した場合に、そのデバイスは、メッセージ２２０によって投票が請求された機能に投票しないようにすることができる。
図３ｄに移ると、デバイス１１〜１５のそれぞれは、１００を超える提案番号を有する新しい提案に関する他の提議に応答していないかどうかを独立に判定することができる。したがって、これらが応答した新しい提案に関する最後の提議が、現在の提案より大きい番号を有する提案に関するものでないので、デバイス１１および１３〜１５は、提案に投票し、その投票をそれぞれメッセージ２３１および２３３〜２３５で示す。前と同様に、メッセージ２３３は、例示のために図示され、デバイス１３の内部で処理することができる。しかし、デバイス１２は、メッセージ２２０の送信の前のある時に、１００を超える提案番号を有する新しい提案の提議を受信し、応答した可能性がある。したがって、メッセージ２２０の受信時に、デバイス１２は、１００を超える番号を有する新しい提案の提議に既に応答し、したがって、提案１００に投票できないと判定することができる。その結果、図３ｄに示されているように、デバイス１２は、メッセージ２３２を用いて応答し、リーダー１３に、１５０の提案番号を有する提案の提議に応答したことを知らせる。リーダー１３は、デバイス１２の投票を必要とすると判定した場合に、提案番号が１５０を超えることを除いてメッセージ２２０に類似するもう１つのメッセージを送信することができる。あるいはまた、デバイス１２は、メッセージ２２０に応答する必要がなく、デバイス１３は、デバイス１２の投票を必要とする場合に、任意の大きい提案番号を有する提案に関する別の投票を試みることができる。したがって、デバイス１２がより大きい提案番号をリーダー１３に示さない場合に、リーダーは、推測しなければならない場合があり、複数のメッセージを介して適当に大きい提案番号を推測することによってリソースを浪費する可能性がある。
しかし、デバイス１１および１３〜１５は、定足数を構成するのに十分な数を超えるので、リーダー１３は、デバイス１２の投票がなくても提案が受け入れられたと判定することができ、図３ｅに示されたメッセージ２４０を用いて、デバイス１１〜１２および１４〜１５のそれぞれが機能「ｙ」を実行することを要求することができる。デバイス１３は、機能「ｙ」が受け入れられたと判定した際に、メッセージ２４０の送信を待たずに機能「ｙ」を実行することができる。その結果、デバイス１３は、内部的にもメッセージ２４０を送信する必要がない。
デバイス１１および１３〜１５は、定足数を構成するが、リーダー１３が投票すべき提案をサブミットした、デバイス１２を含むものと同一の定足数ではない。しかし、上で説明したように、リーダーは、提案が受け入れられたと判定するために、定足数から投票を受信することだけを必要とし、要求が送信されたものと同一の定足数である必要はない。上で説明したＰａｘｏｓアルゴリズムは、その動作のどの所与のステップについても、単一の機能だけがシステム１０によって選択され実行されることを保証する。たとえば、前に動作していなかった別のデバイスが、動作するようになり、システム１０に再び参加した場合に、このデバイスは、システムが「ｙ」を選択し、実行するのと同一のステップに、「ｙ」と異なる機能を提案することを試みる場合がある。そのようなデバイスが、１００未満の提案番号を有する提案を送信した場合に、この提案は、デバイス１１および１３〜１５によって無視することができる。というのは、これらのデバイスが、図３ｄに示されているように、提案番号１００に既に投票しているからである。その一方で、このデバイスが、提案番号１３０など、１００を超える提案番号を有する提案を送信した場合に、デバイス１１および１３〜１５は、提案番号１００の機能「ｙ」に投票したことを示すメッセージを返す。デバイス１２は、投票していない可能性があるので、図３ｄに示されているように、提案番号３０の機能「ｚ」に投票したことを示すメッセージ２１２を用いて応答する可能性がある。
新しいデバイスは、定足数の間で最大の提案を選択することができ、これは、定義により、デバイス１１〜１５のうちの少なくとも一部を含み、新しいデバイスは、投票に関してその提案で提案される機能をサブミットすることができる。したがって、それが選択する１００を超える提案番号のどれであっても、新しいデバイスは、投票について機能「ｙ」をサブミットする。各デバイスは、上で示したアルゴリズムに従って、その提案に投票することができる。提案１３０は、選択される（特定のステップについて機能「ｙ］を実行するという前の判断を変更しない）か、その間に多すぎるデバイスが別の提案に投票することを約束したので失敗するのいずれかになる。しかし、提案がパスしたならば、他のすべての提案が、同一の機能を提案し、定義により、すべてのデバイスが、その同一の機能だけに投票することができる。そのような形で、Ｐａｘｏｓアルゴリズムは、すべてのシステム１０のデバイスが、所与のステップに同一の機能を実行することを保証する。
上で説明したＰａｘｏｓアルゴリズムの適用は、分散コンピューティングシステムが所与のステップに実行される機能を選択できるようにすることができる。上で説明した動作を繰り返すことによって、分散コンピューティングシステムが、ステップのシリーズとして実行される機能のシリーズに合意することができ、これによって、継続的に動作するシステムを形成することができる。このような方法で、分散コンピューティングシステムが、１つまたは複数のクライアントから要求を受信でき、これらの要求を実行でき、結果をクライアントに返すことができる。
図４ａに移ると、システム１０は、既に、複数のステップについて動作していたものとすることができる。たとえば、図４ａに示された例示的なシステム１０で、最も最近に選択されたステップを、ステップ２４とすることができ、ステップ２５を、現在のステップとすることができる。しかし、前にリーダーとして働いていたデバイスが故障したか、単にクライアント要求を受信しなかった場合がある。クライアント２０は、図４ａで変数「ｘ」によって表される機能を実行する要求を、図示のようにメッセージ３００を使用してデバイス１３に送信することができる。デバイス１３は、上で説明したものなど、複数の機構のいずれかに従って、リーダーなることを試みなければならないと決定することができる。したがって、デバイス１３は、次の提案に関する提案番号１００の使用を提議し、その提案が行われるステップを含むメッセージ３０１を送信することができる。図４ａの例示的な分散コンピューティングシステム１０では、デバイス１３は、ステップ２３および２４が他のデバイス１１〜１２および１４〜１５によって既に判断されたことを知らない。したがって、メッセージ３０１は、それがステップ２３の提案番号１００を提議していることを示す。
複数のステップを実行するシステムでこのアルゴリズムの動作を促進するために、メッセージ３０１などのメッセージが、ステップ２３以上のすべてのステップについて番号１００を有する提案を提議すると理解することができる。このような方法で、リーダー１３は、既に判断されたすべてのステップについて知るまで、メッセージ３０１などのメッセージを継続的に送信する必要がない。その代わりに、リーダー１３は、これから示すように、単一のメッセージラウンドトリップだけを介して、既に選択されたステップについて知ることができる。
図４ｂに移ると、分散コンピューティングシステム１０のデバイス１１〜１５からの応答メッセージ３１１〜３１５が示されている。たとえば、デバイス１１、１４、および１５は、機能「ｙ」がステップ２３について選択され、さらに、機能「ｚ」がステップ２４について選択されたことを記録している。したがって、メッセージ３０１の受信時に、デバイス１１、１４、および１５は、２３以上のすべてのステップ、この場合にはステップ２３および２４について選択されたものとして保管されている機能を示すメッセージ３１１、３１４、および３１５を用いて応答することができる。さらに、デバイス１１、１４、および１５は、２５以上のステップについて投票した最大の提案番号を有する提案の指示を提供することができる。したがって、図４ｂに示された例では、メッセージ３１１は、デバイス１１が２５を超えるステップに関する提案に投票しなかったことと、ステップ２５に関する機能「ｂ」を提案する提案番号１６０に投票したことも示すことができる。その一方で、メッセージ３１４および３１５は、デバイス１４および１５がステップ２４を超えるステップについてどの提案にも投票していないことを示すことができる。システム１０内で送信されるメッセージの数を減らすために、デバイスは、所与のステップについて選択された機能について知らない場合に、最大の提案番号の投票を用いて応答するだけでよい。したがって、デバイス１１は、ステップ２３および２４について機能が選択されたが、ステップ２５について選択されなかったことを知っているので、ステップ２３および２４について選択された機能と、ステップ２５について投票した最大の番号の提案を用いて応答する。
前と同様に、デバイス１３は、リーダーおよび投票するデバイスの両方として働くことができる。したがって、デバイス１３は、メッセージ３０１など、メッセージをそれ自体に送信することができ、メッセージ３１３などのメッセージを用いてそれ自体に応答することができる。そのようなメッセージは、図では例示のみのために示されている。というのは、これらが、デバイス１３の内部で送信される可能性が高いからである。さらに、デバイス１３は、機能が選択されたことを知っている最大のステップ番号を有するステップがどれであるかを検査することができ、デバイス１３が投票したステップを超えるすべてのステップに関する提案の最大の提案番号がどれであるかを検査することができるので、メッセージ３１３には、ヌルインジケータ以外の情報が含まれることはめったにない。
状態機械の現在の状態は、選択された機能だけではなく、これらの機能が実行される順序にも依存する場合がある。したがって、あるデバイスが、所与のステップについてどの機能が選択されたかを知らない場合に、そのデバイスが、そのステップを超えて機能を実行してはならない状況、または順序はずれで機能を実行し、その状態が分散コンピューティングシステムの状態と異なるようになる状況がありえる。たとえば、新しい状態を無条件で指定する機能などのいくつかの機能は、デバイスの現在の状態と独立である。そのような機能は、現在のステップより小さいステップ番号を有するステップの機能がまだ実行されていない場合であっても実行することができる。同様に、データベースへの書込など、前のステップのすべてを知らずに出力を計算できる機能も、クライアントに送信される出力を生成するために、順序はずれで部分的に実行することができる。しかし、一般に、前のすべての機能が実行されるまで、機能を実行してはならない。したがって、デバイスは、必ず、そのデバイスが逃したステップについてどの機能が選択されたかを知ることを試みることができる。デバイス１３は、図４ａに示されているようにメッセージ３０１を送信するときに、ステップ２３が次のステップであるとデバイス１３が考えていることと、ステップ２２までの合意された機能の知識を有することが、暗黙のステートメントである。したがって、ステップ２３未満のステップの機能を逃したデバイスは、デバイス１３がステップ２２までのすべての機能の知識を有することを知り、デバイス１３にその機能を要求することができる。
図４ｂに戻ると、デバイス１２は、ステップ１２についてどの機能が選択されたかを知らない。その結果、デバイス１２は、ステップ１３〜２３について選択された機能を知っている場合であっても、ステップ１１以降の機能を実行することができなかった可能性がある。したがって、メッセージ３１２で、デバイス１２は、リーダー１３にステップ１２の機能を要求することができる。さらに、デバイス１２は、ステップ２３より大きい番号のステップに関する提案に投票していないことを示すことができる。
デバイスが逃したステップが多すぎる場合に、それが逃したすべてのステップに関するすべての機能を送信するのではなく、そのデバイスに現在の状態について単純に知らせることがより効率的である可能性がある。デバイスが多すぎるステップを逃さないことを保証する機構の１つが、各デバイスまたはデバイスの集合が、状態のさまざまな部分または状態全体のスナップショットを周期的にとることを可能にすることである。したがって、別のデバイスの状態を、最新のスナップショット以降に選択された機能と一緒に適当なスナップショットをそのデバイスに送信することによって更新することができる。さらに、状態の個々の部分のチェックサムを使用することによって、別のデバイスの状態を、状態のうちでその現在のコピーと異なる部分をそのデバイスに送信することによって更新することができる。当業者に明白であるように、状態を階層的に分解し、各レベルで分解のチェックサムを使用することによって、状態のうちで変化した部分を、任意の精度で効率的に判定することができる。
メッセージ３１１から３１３の受信の結果として、リーダー１３は、前には知らなかったステップ２３および２４について選択された機能について知ることができ、ステップ２５に関する提案に適当な機能を判定することを試み、ステップ２５までのすべてのステップについて選択された機能をまだ知らない他のデバイスを更新することを試みることができる。最初に、リーダー１３は、メッセージ３０１で１００の提案番号を提議したが、デバイス１１が、それがステップ２５について１００より大きい提案番号を有する提案に既に投票したことを示すメッセージ３１１を用いて応答した。その結果、リーダー１３は、それが知っている最大の提案番号より大きい提案番号を選択し、図４ｃに示されたメッセージ３２０などのもう１つの提議メッセージを送信することができる。あるいはまた、デバイス１１が、メッセージ３０１の提案番号１００の提議を単純に無視することができる。というのは、この提案番号が、デバイス１１が既に投票した提案の提案番号より小さいからである。その場合に、リーダーは、最初の提議を無視したデバイスを考慮に入れる試みで提案番号を増やすことによって再試行している。以上のように、デバイスが、そのデバイスが既に投票した提案の提案番号より小さい提案番号を有する提案の提議を無視する場合に、提議される提案番号を毎回増やしながら、複数の再試行を実行することをリーダーに強制することができる。そのような複数のメッセージは、非効率的である可能性がある。したがって、提案番号が、デバイスが既に投票した提案の提案番号より小さい場合であっても、新しい提案番号に関するすべての提議にデバイスが応答することが好ましい場合がある。というのは、リーダーが、より高い精度で、提議すべき適当な提案番号を判定でき、複数のメッセージを回避できるからである。
図４ｃに移ると、リーダー１３は、デバイスが前に投票したことをリーダー１３が知ったすべての提案の番号より大きい提案番号の提議を試みて、メッセージ３２０に示された提案番号２００など、より大きい提案番号を提議することができる。さらに、リーダー１３は、ステップ２５までに選択された機能をまだ知らないすべてのデバイスに、前に選択された機能に関する情報を提供することもできる。したがって、図に示されているように、リーダー１３は、変数「ｅ」によって表される機能がステップ１２について選択されたことと、変数「ｚ」によって表される機能がステップ２４について選択されたことをデバイス１２に示すメッセージ３２１も送信することができる。
図４ｄで、デバイス１１〜１５は、デバイス１１〜１５がステップ２３および２４に関して選択された機能をデバイス１３に知らせる必要がない（デバイス１３が、これらのステップについて既に知っており、ステップ２５を参照する提案メッセージ３２０および３２１を送信したので）ことを除いて上で図４ｂに示したものに似た形で応答することができる。さらに、メッセージ３３１〜３３５に、デバイスが投票した可能性がある追加の提案など、追加情報を含めることができる。たとえば、デバイス１２は、メッセージ３１２とメッセージ３３２の送信の間のある時に、提案番号１９０を有する提案に投票した可能性がある。その結果、メッセージ３１２は、デバイス１２がステップ２５に関する提案に前に票を投じていない可能性があることを示すことができるが、メッセージ３３２は、デバイス１２が、２５を超えるステップに関する提案にはまだ投票していないが、ステップ２５に関する提案１９０に投票したことを示すことができる。しかし、提案番号のそれぞれが、リーダー１３がメッセージ３２０で送信した提議された提案番号より小さいので、リーダーは、メッセージ３２０で指定された提案番号２００を用いる機能の提案に進むことができる。
図４ｅに移ると、リーダー１３は、ステップ２５についてシステムが機能「ｂ」を実行することを提案する、提案２００に関してデバイス１１〜１５が投票することを要求する、メッセージ３４０によって示される、提案番号２００としてサブミットされる提案を選択するのに十分な情報を有する。前と同様に、デバイス１１および１２は、両方が定足数のメンバであり、前に機能「ｂ」の実行を提案する提案に投票しており、定足数の他のメンバが、より大きい番号の提案に投票していないので、リーダー１３は、クライアント２０がメッセージ３００で機能「ｘ」の実行を要求したという事実にかかわりなく、提案番号２００の機能「ｂ」を提案することができる。このような方法で、Ｐａｘｏｓアルゴリズムは、１つまたは複数のデバイスまたはその通信の障害のゆえになど、提案されたが完了していない前の機能を、正しい順序で実行できることを保証する。
図４ｆに、それぞれメッセージ３５１〜３５５を用いて機能「ｂ」を提案する提案２００について、ステップ２５について投票するデバイス１１〜１５を示す。前と同様に、デバイスは、メッセージ３２０とメッセージ３４０の受信の間により大きい提案番号を有する異なる提案への投票を約束していない限り、提案に投票することができる。リーダー１３は、メッセージ３５１〜３５５を受信したならば、図４ｇに示されているようにメッセージ３６０を送信することができ、デバイス１１〜１２および１４〜１５に、機能「ｂ」がステップ２５について選択されたことを知らせる。リーダー１３は、この機能が定足数によって選択されたことを知っているので、この情報自体を保管することもできる。
しかし、メッセージ３００でクライアント２０によって要求された機能は、図４ｇに示された時点では、まだシステム１０によって選択されていない。システム１０にクライアントのこの要求を選択させるために、リーダー１３は、上の図３ａ〜ｅおよび４ａ〜ｇによって示された完全なＰａｘｏｓアルゴリズムの省略版を実行することができる。
概念上、上で説明したＰａｘｏｓアルゴリズムは、２つの全般的なフェーズに分割することができる。第１フェーズには、定足数に含まれるデバイスによって投票された前の提案についてリーダーが知ることが含まれる。第１フェーズに、図３ａおよび３ｂに示されているように、リーダーによる提案番号提議および定足数の他のメンバによる応答の１つの反復、または図４ａ〜ｄに示されているように、提案番号提議および応答の複数の反復を含めることができる。第２フェーズに、リーダーが投票に関する提案される機能をサブミットし、投票を受け取り、提案が十分な数のデバイスによって投票された場合にデバイスにその合意された機能を実行するように指示することが含まれる。第２フェーズの例は、図３ｃ〜ｅおよび４ｅ〜ｇに示されている。
リーダーは、他の提案について知り、現在および将来のステップのすべてについて安全な提案番号を見つけたならば、失敗するか他のデバイスがリーダーになることを試みない限り、それ以上の情報を懇願する必要はない。したがって、Ｐａｘｏｓアルゴリズムの第１フェーズは、より低い頻度で実行することができるが、第２フェーズは、さらに増加するステップ番号を用いて繰り返して実行して、分散コンピューティングシステムが機能のシリーズに合意し、アクティブな動作状態を維持することを可能にすることができる。
図５ａに移ると、図４ａ〜ｇの例示的な分散コンピューティングシステム１０が、上で詳細に説明したステップ２５の次のシステムステップ２６について選択されるべき機能をリーダー１３が提案している状態で示されている。図４ａ〜ｄに示し、上で詳細に説明したＰａｘｏｓアルゴリズムの第１フェーズの結果として、リーダー１３は、既に、デバイス１１〜１５のどれもが上のステップ２５で提案について投票しておらず、したがって、提案番号２００がステップ２５より後のステップに関するすべての提案に安全であることを知っている。したがって、図５ａに示されているように、ステップ２６について、リーダーは、第１フェーズをもう一度実行する必要なしに、Ｐａｘｏｓアルゴリズムの第２フェーズを開始することができ、メッセージ３００でクライアントによって要求された、機能「ｘ」への投票を請求するメッセージ４００を送信することができる。デバイス１１〜１５のそれぞれが、投票によって応答することができる。Ｐａｘｏｓアルゴリズムのフォールトトレラントな性質を示すために、図５ｂに、メッセージ４１１〜４１３を用いて応答するデバイス１１〜１３だけを示す。デバイス１４および１５は、障害を経験している可能性があり、メッセージ４００を受信しなかったか、これに応答することができない。
それでも、リーダー１３は、定足数に含まれるデバイスのそれぞれが機能の実行に投票したので、機能「ｘ」が選択されたと判定することができる。上で説明したように、定足数は、システム１０などのＰａｘｏｓアルゴリズムを実装するシステム内のデバイスの少なくとも過半数の任意の集合とすることができる。その結果、デバイス１１〜１５のすべてがシステム１０の１つの定足数を構成するが、デバイス１１〜１３自体は、システム１０のもう１つの定足数を構成する。デバイス１１〜１３を含む定足数のすべてのデバイスが、機能「ｘ」について投票したので、リーダー１３は、図５ｃに示されているように、メッセージ４２０を用いて、機能「ｘ」がステップ２６について選択されたことをシグナリングすることができる。さらに、リーダー１３は、投票が成功したことを知っているので、ステップ２５までに選択された機能を知っている限り、ステップ２６について機能「ｘ」を実行することができ、メッセージ４２１としてクライアントに、またはメッセージ４２２としてデバイス３０および３１などの他の関心を持つコンピューティングデバイスに、その機能の実行の結果を送信することができる。メッセージ４２１および４２２は、メッセージ４２０と同時に、またはメッセージ４２０の前もしくは後に送信することができる。
以上のように、リーダーが、確立され、これからのステップ番号のすべてに関する定足数に含まれるデバイスによって投票されたさまざまな最大の番号を有する提案を知ったならば、リーダーは、Ｐａｘｏｓアルゴリズムの第１フェーズをサイクルせずに、投票について提案を請求することができる。図５ａに示されたメッセージを、図４ｇのメッセージ３６０の送信の後に行われるものとして説明するが、リーダー１３が、後続ステップに関する別の提案を送信する前に、デバイスがある提案について投票するのを待つ必要はない。したがって、図４ｅに示されたメッセージ３４０を送信した際に、リーダー１３は、図５ａに示されたメッセージ４００を送信することができ、このような方法で継続し、ステップ２６以降のステップについて、提案番号２００を使用して、機能のシリーズを提案することができる。そのような非同期の形で動作することによって、分散コンピューティングシステム全体が、前のステップに関する投票について知るのを待つことによって低速化する必要はない。
前に機能していなかったデバイスなどの別のデバイスが、リーダーになることを試みた場合に、これが、システムが不正に実行することを引き起こしてはならず、このアルゴリズムの第１フェーズを繰り返させることに成功するだけである。たとえば、別のデバイスがリーダーになることを試みる場合に、そのデバイスは、あるデバイスが応答する提案番号を提議することができる。第２のリーダーによって提供された提案番号に応答した後に、そのデバイスは、第１のリーダーが投票を請求するときにより大きい番号の提案について第１のリーダーに知らせるか、第１のリーダーによるその提案に対する投票の要求を無視することができる。不十分な数のデバイスが投票したので提案が失敗したときに、第１のリーダーは、まず第１フェーズをもう一回実行し、デバイスに提議できる十分に大きい提案番号と思われるものを選択することによって、提案を通すことを試みる。このような方法で、第２のリーダーは、システムを遅延させるだけであって、分散コンピューティングシステムの側の不正な動作を引き起こさない。
上で説明したＰａｘｏｓアルゴリズムを実装するデバイスは、このアルゴリズムで使用される情報を保管する変数を維持することができる。たとえば、それについてどの機能が選択されたかをデバイスが知らないステップのそれぞれについて、デバイスは、そのデバイスが応答した最大の提案番号、投票した最大の提案番号、および対応する提案の値を保管することができ、そのデバイスがリーダーである場合に、さらに、発行した最後の提案の提案番号を保管することができる。さらに、デバイスは、それに関して情報を有するすべてのステップについてどの機能が選択されたかを記録することができる。あるいはまた、デバイスは、所与の時のそのデバイスの状態のスナップショットと、その時以降に選択された機能だけを保管することができる。たとえば、ステップ１〜１００について選択された機能のそれぞれを保管するのではなく、デバイスは、ステップ７５の実行の後のそのデバイスの状態のスナップショットを保管し、その後、ステップ７６〜１００について選択された機能だけを保管することができ、保管される量を４またはそれ以上の因子により減らすことができる。上で説明した情報の一部またはすべてを、図２に示された、揮発性ストレージ１３０または、ハードディスク１４１、フロッピディスク１５２、または光ディスク１５６などの不揮発性ストレージに保管することができる。
Ｐａｘｏｓアルゴリズムに関する追加情報は、その開示と一貫する本明細書に含まれる教示または提議をさらに説明または記述するためにその内容全体を参照によって本明細書に組み込まれている文献に記載されている（たとえば、非特許文献２参照）。
高速Ｐａｘｏｓアルゴリズム
標準Ｐａｘｏｓアルゴリズムの上の詳細な説明からわかるように、リーダーが、確立され、定足数に含まれるデバイスによって投票されたこれから来るすべてのステップ番号に関するさまざまな最大の番号の提案を知ったならば、リーダーは、Ｐａｘｏｓアルゴリズムの第１フェーズをサイクルせずに投票について提案を請求することができる。クライアントの要求の送信とクライアントへの応答の送信の間のメッセージ遅延の数をさらに減らすために、Ｐａｘｏｓアルゴリズムの第２フェーズでのリーダーの役割をなくすことができ、分散コンピューティングシステムのデバイスが、クライアント２０などのクライアントから直接に要求を受信することができる。そのようなアルゴリズムを、「高速Ｐａｘｏｓアルゴリズム」と呼ぶことができるが、このアルゴリズムは、リーダーが適当な提案番号を確立した後に、しばしばクライアント要求の単なる導管として働き、分散コンピューティングシステムのデバイスの追加のポーリングなしで要求された機能を提案する、Ｐａｘｏｓアルゴリズムの上で説明したプロパティに頼る。
それでも、リーダーがどの機能を提案するかを決定したので、Ｐａｘｏｓアルゴリズムは、リーダーに頼って、前に１つの過半数によって選択された機能が同一ステップについてすべての他の過半数によっても選択されることを保証でき、これによって、一貫性が保証される。具体的に言うと、上で説明したように、すべての過半数が少なくとも１つのデバイスを共有するので、そのデバイスは、そのデバイスの前の投票についてリーダーに知らせ、リーダーは、現在の定足数が同一のシステムステップについて同一の機能に投票することを確認することができる。高速Ｐａｘｏｓアルゴリズムは、リーダーなしで動作することができるので、代替の機構を使用して、２つの定足数が同一のシステムステップについて異なる機能を選択しないことを保証することができる。そのような機構の１つが、すべての２つの定足数がそのデバイスの過半数を共有するように、十分に多数のデバイスを定足数として定義することである。このような方法で、前の定足数によって選択された機能を、デバイスの他の定足数をポーリングし、新しい定足数のデバイスの過半数がその機能に投票したかどうかを判定することによって判定することができる。
図６ａに移ると、高速Ｐａｘｏｓアルゴリズムの最初のステップが示されている。具体的に言うと、リーダーデバイス１３は、適当な提案番号を決定したならば、デバイスのそれぞれに、クライアントからのそれ以降のすべてのメッセージを、適当な提案番号を有する、後続システムステップに関する提案として扱わなければならないことを通知することができる。たとえば、図６ａに示されているように、デバイス１３は、提案番号２０１が２６を超えるすべてのシステムステップに安全であることを示すメッセージ５００を送信して、デバイス１１〜１５に、クライアント要求を後続システムステップに関して提案番号２０１の提案として扱わなければならないことを示すことができる。
上で詳細に説明したように、提案番号は、さまざまな機構を介してデバイスに割り当てることができる。各デバイスに提案番号の一意のセットを与えることのほかに、提案番号を割り当てるのに使用される機構を拡張して、一部の提案番号をＰａｘｏｓアルゴリズムに対応するものとして分類し、他の提案番号を高速Ｐａｘｏｓアルゴリズムに対応するものとして分類することができる。このような方法で、デバイスは、分散コンピューティングシステム１０によって現在使用されているアルゴリズムがＰａｘｏｓアルゴリズムまたは高速Ｐａｘｏｓアルゴリズムのどちらであるかを知ることができ、したがって、適当な調整を行うことができる。たとえば、下でさらに詳細に説明するように、高速Ｐａｘｏｓアルゴリズムの一実装のデバイスは、デバイスの間の競合について知った場合に、リーダーデバイスのアクションを予想することができる。デバイスは、Ｐａｘｏｓアルゴリズムまたは高速Ｐａｘｏｓアルゴリズムのどちらが使用されているかを判定するために、使用されている提案番号を記録することによって、そのような機構を実装することができる。
提案番号が特定のアルゴリズムに相関しない場合に、図６ａのリーダー１３は、このリーダーが、図４ｄに示されているように、デバイス１１〜１５が２００未満の提案番号を有する提案に投票しないことのデバイス１１〜１５による合意を既に入手しているので、２６を超えるすべてのステップについて提案番号２００が安全であることを示すことができる。定足数のデバイスが、２００未満の提案番号を有する提案に投票しないことを約束しているので、２００を、「安全な」提案番号と考えることができる。その結果、メッセージ５００は、デバイス１１〜１５に、クライアントからのさらなる要求を２００という提案番号を有する要求として扱うように指示することができる。
しかし、提案番号が、上で説明したように特定のアルゴリズムに相関する場合に、図６ａに示されているように、リーダー１３は、リーダーが知っている前に使用されたすべての提案番号より大きい、高速Ｐａｘｏｓアルゴリズムに対応する提案番号を選択することができる。リーダー１３は、図４ｃ〜ｇおよび５ａ〜ｃに示されているように、２００という提案番号を使用していたので、このリーダーは、たとえば２０１という提案番号など、やはり高速Ｐａｘｏｓアルゴリズムに対応する２００より大きい提案番号を選択することができる。しかし、このリーダーがメッセージ５００を送信する前に、このリーダーは、上で説明したように、より小さい提案番号を使用するすべての提案に投票しないことの約束を定足数のデバイスから入手することによって、この提案番号が安全であることを判定することができる。図４ｃおよび４ｄに示した形などで、２０１という提案番号が、提案され、定足数によって受け入れられたならば、リーダー１３は、その提案番号をクライアント１１〜１５に送信することができる。提案番号２０１は、高速Ｐａｘｏｓアルゴリズムに対応するので、デバイス１１〜１５は、クライアント２０などのクライアントからのさらなる要求を、送信された安全な提案番号を有する提案として扱うことを知ることができる。
図６ｂに移ると、高速Ｐａｘｏｓアルゴリズムの動作が、システム１０のクライアント２０からの要求５１１に関して図示されている。図からわかるように、クライアント２０は、要求３００に関して行われたようにリーダーデバイスに送信するのではなく、デバイス１１〜１５に直接に要求５１０を送信する。デバイス１１〜１５のそれぞれは、このクライアントの要求を、後続システムステップ（図６に示された例ではステップ２７）に関して２０１という提案番号を有する提案として扱うことができる。したがって、デバイスのそれぞれは、ステップ２７に関する前の投票に基づいて、この提案に投票するかどうかを判定することができる。この例では、デバイスのどれもが他の提案に投票していないので、デバイスは、図６ｂで変数「ｗ」によって表される機能の実行のクライアントによる要求が受入可能であるかどうかを個別に判定することができる。
図６ｃに示された高速Ｐａｘｏｓアルゴリズムの一実施形態では、デバイス１１〜１５が、単純に、要求された機能に投票する。したがって、図示されているように、これらのデバイスは、システムステップ２７に関して、変数「ｗ」によって表される機能に投票する。デバイス３０などのさらなるデバイスが、ラーナー（ｌｅａｒｎｅｒ）デバイスとして働くことができ、分散コンピューティングシステム１０によって行われる判断について知ることができる。上で示したように、システム１０の定足数のデバイスが特定の機能に投票する場合に、その機能がシステムによって選択される。図６ｃに示された例では、デバイスのそれぞれが、機能「ｗ」に投票する。しかし、デバイス１１〜１５のうちのいずれか１つが、故障するか、他の形で機能「ｗ」について投票できず、機能「ｗ」が、４つのデバイスが定足数を構成するので、それでもシステム１０によって選択されている。上で述べたように、高速Ｐａｘｏｓアルゴリズムの定足数のデバイスは、他の定足数とそのデバイスの過半数を共有するデバイスの任意の集合とすることができる。許容できる故障の数に関して表すと、定足数は、システムが許容できる故障の数の２倍より大きいデバイスの任意の集合とすることができる。その結果、上で述べたように、高速Ｐａｘｏｓアルゴリズムを実装しようとする分散コンピューティングシステムのサイズは、したがって、そのシステムが許容できる故障の数の３倍より大きいものとすることができる。
図６ｃに示されているように、デバイス１１〜１５のそれぞれが、システムステップ２７について機能「ｗ」に投票したので、ラーナーデバイス３０は、機能「ｗ」が分散コンピューティングシステム１０によって選択されたと判定することができ、その機能の実行に進み、メッセージ５２０を介してその実行の結果をクライアント２０に返すことができる。したがって、デバイス１１〜１５は、特定の機能に投票するときに、その投票を、ラーナーデバイス３０などの１つまたは複数のラーナーデバイスに送信することができる。あるいはまた、デバイス１１〜１５が、単に、その投票を保管し、デバイス３０などのラーナーデバイスが、デバイス１１〜１５をポーリングして、新しい機能がさらなるシステムステップについて選択されたかどうかを判定することができる。
図６ｄに示された高速Ｐａｘｏｓアルゴリズムの代替実施形態では、デバイス１１〜１５が、メッセージ５２１〜５２３を介するなど、その投票を互いに送信できることが企図されている。デバイスは、それ自体を含む定足数のデバイスから、特定の機能への投票を受信したならば、その機能が選択されたと判定することができ、その機能を実行し、結果をクライアント２０に供給することができる。各デバイスは、他のデバイスの投票を受信しているので、各デバイスは、機能が選択されたかどうかを独立に判定することができ、結果をクライアント２０に独立に送信することができる。その結果、クライアント２０は、メッセージ５３１〜５３５など、要求された機能の結果を供給する複数のメッセージを受信することができる。このような方法で、デバイス１１〜１５の一部またはすべてが、システム１０の状態のコピーを維持することができ、実質的に、それぞれがラーナーデバイスとして働く。
以上のように、高速Ｐａｘｏｓアルゴリズムは、デバイスが、より少数の介在するメッセージ遅延で、分散コンピューティングシステムによって実行される機能を提案し、応答を受信することを可能にする。たとえば、図６ｂから６ｄに示されているように、１組のメッセージだけが、クライアントの要求の送信とクライアントの要求の結果の送信の間に送信された。しかし、高速Ｐａｘｏｓアルゴリズムは、定足数のデバイスが動作している場合に限って正しく動作することができる。したがって、例示的なシステム１０の２つ以上のデバイスが故障した場合に、定足数の動作するデバイスが存在しないので、提案を選択することができない。その場合には、システム１０は、上で詳細に説明したように、デバイスのより小さい組として定足数を定義できる標準Ｐａｘｏｓアルゴリズムの使用に頼ることができ、これによって、クライアント提案に作用し続けることができる。
高速Ｐａｘｏｓアルゴリズムは、システム１０の複数のクライアントがほぼ同時に機能を要求した場合に正しく動作しない可能性もある。図７ａに移ると、クライアント２０が、要求メッセージ６００を送信することによって、変数「ｖ」によって表される機能をシステム１０が実行することを要求しているものとして図示されている。しかし、ほぼ同時に、デバイス３１も、この図で変数「ｕ」によって表される機能をシステムが実行することを要求するメッセージ６０１を送信することによって、システム１０のクライアントとして働くことを試みる。メッセージ６００および６０１のそれぞれが、デバイス１１〜１５にほぼ同時に到着する可能性があり、一部のデバイスが、メッセージ６００を最初に受信し、他のデバイスが、メッセージ６０１を最初に受信する。メッセージ６００を最初に受信したデバイスは、上で説明した形で、機能「ｖ」に投票するかこれを仮に実行する可能性があり、メッセージ６０１を最初に受信したデバイスは、機能「ｕ」に投票するかこれを仮に実行することを試みる可能性がある。
図７ｂに移ると、競合するメッセージ６００および６０１の１つの可能な結果が示されており、デバイス１１〜１３が機能「ｖ」に投票し、デバイス１４〜１５が機能「ｕ」に投票している。デバイス３０などのラーナーデバイスが、分散コンピューティングシステム１０のデバイス１１〜１５から投票情報を収集することができる。図７ｂに示された例では、ラーナーデバイス３０が、デバイス１１〜１３から、それぞれ機能「ｖ」への投票を示すメッセージ６１１〜６１３を受信することができる。同様に、ラーナーデバイス３０は、デバイス１４〜１５から、それぞれ機能「ｕ」への投票を示すメッセージ６１４〜６１５を受信することができる。上と同様に、この図に示された例示的なシステム１０について、高速Ｐａｘｏｓアルゴリズムのデバイスの定足数は、４デバイスとすることができる。その結果、機能「ｖ」および機能「ｕ」の両方が、定足数のデバイスによって投票されておらず、ラーナーデバイス３０は、どちらの機能も実行することができない。
高速Ｐａｘｏｓアルゴリズムは、標準Ｐａｘｏｓアルゴリズムに頼り、この２つの機能のどちらを選択できるかを知り、その後、その機能に対するコンセンサスを達成することを試みることによって、図７ａおよび７ｂに示されたものなどの競合を処理することができる。したがって、図７ｂに示された状況に続いて、リーダーデバイスが、上で図４ａ〜４ｄに関して説明したものに似た方法で、標準Ｐａｘｏｓアルゴリズムの第１フェーズに進行することができる。第１フェーズの完了の後に、リーダーは、上で図４ｅ〜４ｇに関して説明したものに似た形で、標準Ｐａｘｏｓアルゴリズムの第２フェーズを開始して、第１フェーズ中に知られた提案に関するコンセンサスを達成することができる。機能「ｕ」および機能「ｖ」の両方が選択されなかったので、リーダーは、ある事前定義の選択判断基準に基づいて、一方を選択し、システムにこれを選択させることができる。リーダーは、その後、他方の機能を提案し、後続システムステップについてこれを選択させることができ、あるいは、リーダーは、最初の要求に対する応答を受信しなかった、機能が選択されなかったクライアントがその機能をもう一度要求することに頼ることができる。リーダーが、現在のシステムステップを超えるシステムステップに関する提案に投票したシステム１０のデバイスがないことを知る点に達したならば、リーダーは、図５ｄに関して上で説明したものに似た形で、高速Ｐａｘｏｓアルゴリズムの別のラウンドを開始するメッセージを送信することができる。あるいはまた、デバイス１１〜１５が、ステップ２８を超えるシステムステップに関する機能を選択するために高速Ｐａｘｏｓアルゴリズムの使用を継続すると同時に、上で説明した標準Ｐａｘｏｓアルゴリズムに参加して、競合を解決し、システムステップ２８に関して機能「ｕ」または機能「ｖ」のどちらを選択するかを決定することができる。その場合に、リーダーは、標準Ｐａｘｏｓアルゴリズムを使用して競合を解決した後に、高速Ｐａｘｏｓアルゴリズムを再開始するために明示的なメッセージを送信する必要がない。というのは、デバイスが、ステップ２８を超えるシステムステップに関して機能を選択するために、高速Ｐａｘｏｓアルゴリズムを既に使用しているからである。
高速Ｐａｘｏｓアルゴリズムの代替実装を、図７ｃおよび７ｄに示す。図７ｃに示されているように、デバイス１１〜１３が、他のデバイスにメッセージ６２１〜６２３を送信して、機能「ｖ」への投票について知らせることができる。同様に、デバイス１４〜１５が、他のデバイスにメッセージ６２４〜６２５を送信して、機能「ｕ」への投票について知らせることができる。しかし、高速Ｐａｘｏｓアルゴリズムの定足数は、上で説明したように４つ以上のデバイスとすることができるので、提案された機能のどちらもが、システム１０によって選択されていない。
Ｐａｘｏｓアルゴリズムの第１フェーズを再開始するのではなく、高速Ｐａｘｏｓアルゴリズムの代替実施形態は、デバイスのそれぞれが競合を検出し、リーダーデバイスを用いることなくその競合の検出を試みることを可能にすることができる。具体的に言うと、デバイス１１〜１５のそれぞれは、メッセージ６２１〜６２５に基づいて、定足数のデバイスが機能「ｕ」または機能「ｖ」に投票していないことを知る。デバイスのそれぞれは、次に、高速Ｐａｘｏｓアルゴリズムに対応しなければならない次に大きい提案番号を選択することができ、メッセージ６２１〜６２５で受信した情報に基づいて、標準Ｐａｘｏｓアルゴリズムが再開始された場合にリーダーが行うのと同一の形で、他のデバイスの以前の投票について知ることができる。上で示したように、リーダーデバイスが、機能「ｕ」と機能「ｖ」の間の競合について知ったならば、リーダーは、ある事前定義の判断基準に基づいていずれかを選択することができ、その機能をデバイスに提案することができる。デバイス１１〜１５のそれぞれは、リーダーと同一の判断基準を独立に適用することができ、これによって、リーダーが提案する機能を判定することができる。判定したならば、デバイスのそれぞれは、リーダーがその機能を提案した場合と同一の形で、新しい提案番号を使用してその機能に投票することができる。したがって、図７ｄに示されているように、デバイスのそれぞれは、新しい提案番号を使用して、機能「ｖ」に投票しなければならないと独立に判定することができる。その結果、デバイス１１〜１５は、それぞれ機能「ｖ」への投票を示すメッセージ６３１〜６３５を、他のデバイスに送信することができる。デバイス１１〜１５のそれぞれは、定足数のデバイスが機能「ｖ」に投票したことを独立に判定することができ、したがって、この機能を実行し、それぞれメッセージ６４１〜６４５を介して結果をクライアントに供給することができる。このような方法で、標準Ｐａｘｏｓアルゴリズムに頼らずに競合を解決することができる。しかし、デバイス１１〜１５のそれぞれが、同一の機能を独立に選択しない場合に、もう１つの競合が発生する可能性がある。したがって、１つの最適化は、同一の競合が複数回発生した場合に標準Ｐａｘｏｓアルゴリズムに頼ることができる。さらに、リーダーがある場合にデバイスがリーダーと異なる機能を選択できる可能性を制限するために、上で説明した実装の使用を、デバイスのどれもが故障を経験していない状況に制限することができる。
以上のように、競合の場合に、高速Ｐａｘｏｓアルゴリズムは、標準Ｐａｘｏｓアルゴリズムの第１フェーズを実行することまたはより大きい番号の提案番号を使用して後続投票を試みることのいずれかによって、追加のメッセージ遅延を導入する可能性がある。競合は、複数のデバイスがクライアントとして働こうとする可能性がある環境で頻繁に発生する可能性があるので、高速Ｐａｘｏｓなどの低メッセージ遅延コンセンサスアルゴリズムは、２つまたはそれ以上の提案がクライアントによってほぼ同時に送信される場合でも競合なしに動作し続けることができない限り、期待される効率を提供しない可能性がある。
高速Ｐａｘｏｓアルゴリズムに関する追加情報は、その開示と一貫する本明細書に含まれる教示または提議をさらに説明または記述するためにその内容全体を参照によって本明細書に組み込まれている特許出願に記載されている（たとえば、特許文献１および２参照）。
一般化されたフォールトトレラントコンセンサスアルゴリズム
上で示したように、高速Ｐａｘｏｓアルゴリズムは、定足数が各システムステップについて一意の機能を選択しない場合に、追加のメッセージ遅延を導入する可能性がある。そのような状況は、デバイス故障に起因して発生する可能性があり、その場合に、上で説明したように、Ｐａｘｏｓアルゴリズムがより少数の動作するデバイスを用いてコンセンサスを達成できるので、Ｐａｘｏｓアルゴリズムを使用することができるが、よりしばしば、２つまたはそれ以上の提案がほぼ同時に分散コンピューティングシステム１０にサブミットされ、デバイス１１〜１５のそれぞれが同一の順序でこの提案を受信しないので、定足数によって一意の機能が選択されない状況が発生する。したがって、句「ほぼ同時に」は、期待されるネットワーク伝搬遅延を介して、２つまたはそれ以上の要求が分散コンピューティングシステムを実装するデバイスのそれぞれに同一の順序で到着すると期待できなくなるように、２つまたはそれ以上の要求が時間的に十分に近くで一緒に送信されることを記述することが意図されている。たとえば、現代のネットワークハードウェアは、デバイスが地理的に互いに近くに配置されている場合に、数ミリ秒以内でメッセージをデバイスの間で送信することを可能にする。そのようなデバイスの構成について、２つまたはそれ以上の要求が「ほぼ同時に」送信されると考えられるのは、これらが、互いに約５０ミリ秒以内に送信される場合である。あるいはまた、デバイスが、全世界に配置されている場合に、期待されるネットワーク伝搬遅延は、デバイスの間でのメッセージの送信に１０分の数秒程度を要する可能性がある。その場合に、２つまたはそれ以上の要求が「ほぼ同時に」送信されたと考えられるのは、これらが互いに約０．５秒以内に送信される場合である。
上の例は、例示としてのみ提供され、説明の範囲を時間のこの範囲だけに制限することを意図されたものではないが、２つまたはそれ以上の潜在的に干渉する要求が、しばしば短い時間ウィンドウ内で送信されることを示す。経験的な証拠が、非常にしばしば、そのような短い時間ウィンドウ内で行われる２つの独立のソースからの要求が、互いに交換可能であることを示唆している。本明細書で使用する用語「交換可能」は、一方の要求が既に応答されたか否かにかかわりなく、他方の要求に対する応答が変化しない、要求の対を指す。同様に、要求の組は、その組の要求のすべての対が交換可能である場合に、「交換可能」とすることができる。交換可能でない要求の対の例として、データベースシステムで、レコードを読み取る要求は、そのレコードを編集する要求と交換可能でない。というのは、読み取られる値が、レコードを読み取る要求がそのレコードを編集する要求の前または後のどちらに許可されたかに応じて異なる可能性があるからである。しかし、交換可能な要求の対の例として、あるレコードを編集する要求は、関連しないレコードを編集する要求と交換可能である。というのは、あるレコードの編集の結果が、別の関連しないレコードが編集される前であれ後であれ、変化しないからである。
交換可能でない要求の対について、その対の要求が各デバイスによって同一の順序で応答される場合に、分散コンピューティングシステムの各デバイスの状態を、同期化されたままにすることができ、各デバイスは、正しい応答を提供することができる。交換可能である要求のすべての対について、定義により、その順序付けが要求の結果を変更しないので、これらの要求は、各デバイスによって同一の順序で応答される必要がない。上の例に戻ると、一貫性を保つために、分散コンピューティングシステムのデバイスのそれぞれは、レコードを編集する要求に応答する前にそのレコードを読み取る要求に応答すること、またはレコードを読み取る要求に応答する前にそのレコードを編集する要求に応答することのいずれかを選択することができる。しかし、一部のデバイスが、第１レコードに向けられた編集要求に応答する前に関連しないレコードを編集する要求に応答することを選択すると同時に、他のデバイスが、反対の順序でこれらの要求に応答する場合に、一貫性はそれでも維持される。
さまざまな要求に応答して実行される機能のシーケンスは、交換可能でない機能の対の順序が維持される限り同等と考えることができるが、これらのシーケンスは、数学的には等しくない。したがって、関連しない２つのレコードをある順序で編集する機能のシーケンスは、その関連しない２つのレコードを逆の順序で編集する機能のシーケンスと同等と考えることができるが、この２つのシーケンスは、実際に互いに反対である。その結果、「コマンド構造」または「ｃ−ｓｔｒｕｃｔ」という概念を使用することができる。コマンド構造は、２つまたはそれ以上のコマンド構造が、機能の異なるシーケンスを含む場合であっても数学的に同等とすることができることを除いて、機能のシーケンスに類似するものとすることができる。具体的に言うと、２つまたはそれ以上のコマンド構造を数学的に同一と考えることができるのは、コマンド構造のそれぞれが、同一の個数のコマンドを有し、交換可能であるすべての機能ついて、各コマンド構造がその機能をどこかに有し、交換可能でない機能のすべての対について、各コマンド構造が同一の順序で機能のその対を有する場合である。
基礎コマンド構造を、ヌル要素とすることができ、すべてのコマンド構造を、ヌル要素にコマンドまたはコマンドのシーケンスを追加することによって作成することができる。したがって、ヌル要素は、すべてのコマンド構造のプレフィックスである。本明細書で使用されるとき、コマンド構造の「プレフィックス」は、コマンドの追加のシーケンスを追加することによってそれからより大きいコマンド構造を導出できる、より小さいコマンド構造である。コマンド構造へのコマンドの同等のシーケンスの追加は、同等のコマンド構造をもたらす。したがって、たとえば、コマンド構造に、まずレコードＡを編集し、次に関連しないレコードＢを編集することを含むコマンドのシーケンスを追加することは、同一の最初のコマンド構造に、まずレコードＢを編集し、次にレコードＡを編集することを含むコマンドのシーケンスを追加することから生じるコマンド構造と等しいコマンド構造をもたらす。さらに、２つまたはそれ以上のコマンド構造は、コマンド構造ごとに、結果のコマンド構造が同等になるようにそのコマンド構造に追加できる１つまたは複数のコマンドシーケンスが存在する場合に、「互換」とすることができる。したがって、２つまたはそれ以上の互換コマンド構造は、共通の上界を有する。
したがって、一般化されたコンセンサスアルゴリズムは、すべてのステップについて特定の機能に合意するのではなく、単に、増加する同等のコマンド構造に合意することができる。コマンド構造への合意によって、一般化されたコンセンサスアルゴリズムは、交換可能なコマンドの対のさまざまな順序付けに対処することができ、各デバイスがシステムステップごとに同一のコマンドを選択することを強制することによって非効率性を生み出す必要がない。下で示すように、一般化されたコンセンサスアルゴリズムは、それでも、上で詳細に説明したＰａｘｏｓアルゴリズムおよび高速Ｐａｘｏｓアルゴリズムに類似するプロパティを有する。たとえば、上で示したように、Ｐａｘｏｓアルゴリズムおよび高速Ｐａｘｏｓアルゴリズムの両方が、機能を選択したならば他の機能を選択できないことをもたらす。同様に、Ｐａｘｏｓアルゴリズムおよび高速Ｐａｘｏｓアルゴリズムの両方が、すべてのクライアントが最終的に特定のステップについて同一の機能を選択する機構を提供する。一般化されたコンセンサスアルゴリズムは、同様に、コマンド構造が選択されたならば、それが将来に選択されるコマンド構造のプリフィックスになることをもたらすことができ、任意の２つのデバイスによって選択されたコマンド構造が可換であることももたらすことができる。
図８ａに移ると、本発明の実施形態によって企図されている一般化されたコンセンサスアルゴリズムの動作が、デバイス１１〜１５を含む分散コンピューティングシステム１０に関して示されている。上で詳細に説明したＰａｘｏｓアルゴリズムと同様に、すべてのデバイスが、リーダーデバイスになることを試みることができ、提案番号を提案するメッセージを他のデバイスに送信することができる。したがって、図８ａに示されているように、デバイス１３が、１００の提案番号を提案するメッセージ７００をデバイス１１〜１５に送信することによって、リーダーになることを試みることができる。
図８ｂに移ると、上で説明したＰａｘｏｓアルゴリズムに似た形で、デバイス１１〜１５のそれぞれが、そのデバイスがコマンド構造について投票した最大の番号の提案および対応するコマンド構造を用いて応答することができる。さらに、デバイスのそれぞれは、そのデバイスがその提案番号を使用して提案されたコマンド構造に票を投じなかった場合であっても、そのデバイスが参加した最大の番号の提案を用いて応答することもできる。図８ｂの例示的な例では、上で説明したように、コマンド構造が機能のシーケンスと異なる数学的プロパティを維持するが、コマンド構造が、機能の単純なシーケンスとして表される。したがって、デバイス１１および１５は、これらが最後に提案７０に参加したことと、変数「ａ」、「ｂ」、「ｃ」、および「ｄ」によって表される機能をこの順番で含む提案７０に対応するコマンド構造に投票したことを示すメッセージ７１１および７１５を用いて応答することができる。同様に、デバイス１２および１４は、これらが最後に提案７０に参加したことと、変数「ａ」、「ｂ」、「ｃ」、および「ｅ」によって表される機能をこの順番で含む提案７０に対応するコマンド構造に投票したことを示すメッセージ７１２および７１４を用いて応答することができる。デバイス１３も、それ自体に応答することができるが、上と同様に、メッセージ７１３は、内部的に通信され、必ずしも明示的なネットワーク通信でない。
リーダーデバイス１３は、メッセージ７１１〜７１５を受信したならば、デバイス１１〜１５に提案される適当なコマンド構造を判定することができる。したがって、上で詳細に説明したＰａｘｏｓアルゴリズムと同様に、リーダーデバイスは、他のデバイスによって送信された前の投票情報に基づいて適当な提案を選択することによって、一貫性を保証することができる。コマンド構造が、特定の提案番号で定足数のデバイスによって投票されたすべてのコマンド構造のプレフィックスである場合に、そのコマンド構造を、その提案番号で選択されたと考えることができる。同様に、コマンド構造が、特定の提案番号より大きい提案番号を使用している定足数のデバイスによって投票されたすべてのコマンド構造のプレフィックスである場合に、そのコマンド構造を、その提案番号で「選択可能」と考えることができる。言い換えると、その投票をもはや変更できないデバイスが、プレフィックスとして選択可能コマンド構造を有するコマンド構造に投票し、かつ残りのデバイスが、選択可能なコマンド構造が選択されることをもたらすコマンド構造に投票できるので、あるコマンド構造がある提案番号で選択されることが可能なままである場合に、そのコマンド構造は、その提案番号で選択可能である。その結果、より小さい提案番号でのすべての選択可能コマンド構造が、提案されるコマンド構造のプレフィックスである場合に、リーダーデバイスが、ある提案番号であるコマンド構造を提案することが安全でありえる。
リーダーが提案するのに安全であるコマンド構造を判定するために、リーダーは、まず、定足数のデバイスが、ある提案番号のリーダーの提案に応答したかどうかを判定する。定足数は、上でＰａｘｏｓアルゴリズムに関して提供した定義に似た形で定義することができる。リーダーは、定足数がそれに応答したと判定したならば、デバイスの応答した組のすべてのデバイスが前に参加した、前の最大の提案番号を識別することができる。応答するデバイスの間から選択できるすべての定足数が、識別された前の最大の提案番号に参加したがその提案番号でどのコマンド構造にも投票しなかった少なくとも１つのデバイスを有する場合に、リーダーは、その識別された前の最大の提案番号でコマンド構造が選択されなかったことを知ることができる。その結果、リーダーは、あるデバイスによって投票された、その識別された前の最大の提案番号に対応するコマンド構造のどれであっても安全に提案することができる。
しかし、応答するデバイスの中から選択できるすべての定足数について、その定足数に含まれる、識別された前の最大の提案番号に参加したすべてのデバイスが、その提案番号に対応するコマンド構造に投票した場合に、リーダーは、マルチステップ動作を介して、提案に安全なコマンド構造を判定することができる。まず、リーダーは、識別された前の最大の提案番号に関連する、デバイスによって投票されたコマンド構造のそれぞれが共有する最大のプレフィックスである基礎コマンド構造を判定することができる。次に、リーダーは、リーダーに応答したデバイスの中からの、定足数を形成するのに十分に大きいデバイスの集合ごとに、そのような基礎コマンド構造を判定することができる。次に、リーダーが提案するのに安全なコマンド構造を、判定された基礎コマンド構造のすべてが収束する最小のコマンド構造として判定することができる。２つまたはそれ以上のコマンド構造が「収束」することができるのは、機能のシーケンスを２つまたはそれ以上のコマンド構造のそれぞれに追加して、最終的に同等のコマンド構造を作ることができる場合である。
図８ｂに示された例では、デバイス１１および１５が、７０の提案番号を使用して提案されたコマンドのシーケンス｛ａ，ｂ，ｃ，ｄ｝によって表されるコマンド構造に最後に投票し、デバイス１２および１４が、やはり７０の提案番号を使用して提案されたコマンドのシーケンス｛ａ，ｂ，ｃ，ｅ｝によって表されるコマンド構造に最後に投票した。デバイス１１〜１２および１４〜１５のどれもが、７０を超える提案番号を使用する提案に参加していない。デバイス１３は、５０の提案番号を使用して提案されたコマンドのシーケンス｛ａ，ｂ｝によって表されるコマンド構造に最後に投票し、５０を超える提案番号を使用する提案に参加していない。その結果、リーダーは、デバイス１１〜１５のいずれかが応答した前の最大の提案番号が提案番号７０であると判定することができる。
Ｐａｘｏｓアルゴリズムに関して上で説明したように、例示的なシステム１０の定足数のデバイスは、３つまたはそれ以上のデバイスの任意の集合とすることができるので、リーダーは、定足数として働くために、下の表１にリストされたデバイスの集合のいずれか１つを選択することができる。しかし、リーダーが提案されるコマンド構造を決定するプロセスの一部として、リーダーは、表１にリストされた可能な定足数のそれぞれが、提案７０に参加したが提案７０を使用して票を投じなかった少なくとも１つのデバイスを有するかどうかを判定することができる。図８ｂからわかるように、そのような定足数は存在しない。
Figure 2006155614
その結果、リーダーは、次に、表１にリストされた定足数のそれぞれについて、提案番号７０に関連する、その定足数のデバイスによって投票されたコマンド構造のそれぞれによって共有される最大のプレフィックスである基礎コマンド構造の判定に進むことができる。たとえば、デバイス１１、１２、および１５を含む定足数について、その定足数のデバイスのそれぞれが、提案番号７０に関連するコマンド構造に投票した。具体的に言うと、デバイス１１および１５は、コマンドのシーケンス｛ａ，ｂ，ｃ，ｄ｝によって表されるコマンド構造に投票し、デバイス１２は、コマンドのシーケンス｛ａ，ｂ，ｃ，ｅ｝によって表されるコマンド構造に投票した。この２つのコマンドシーケンスを比較することからわかるように、これらの両方が、次のプレフィックスを共有する：｛ａ｝、｛ａ，ｂ｝、および｛ａ，ｂ，ｃ｝。このうちで、後者が、両方のコマンド構造によって共有される最大のプレフィックスであり、その結果、これを、デバイス１１、１２、および１５を含む定足数の基礎コマンド構造とすることができる。リーダーは、表１にリストされた他の定足数のそれぞれについて同一の分析を実行することができ、表１の定足数に対応する基礎コマンド構造のシリーズを識別することができる。
当業者が諒解するように、図８ｂに示された例について、表１にリストされた定足数のそれぞれの基礎コマンド構造は、機能のシーケンス｛ａ，ｂ，ｃ｝によって表されるコマンド構造である。その結果、これらの基礎コマンド構造のそれぞれは、機能のシーケンス｛ａ，ｂ，ｃ｝によって表されるコマンド構造に自明に収束し、そのコマンド構造を、リーダーデバイス１３が提案するのに安全なコマンド構造とすることができる。さらに、この安全なコマンド構造をプレフィックスとして有するすべてのコマンド構造も、リーダーが提案するのに安全なコマンド構造とすることができる。しかし、定足数のそれぞれが、同一の基礎コマンド構造を有しない場合に、リーダーデバイスは、基礎コマンド構造がより大きいコマンド構造に収束するかどうかを判定することができ、その後、そのより大きいコマンド構造を提案することができる。
図８ｃに移ると、リーダーデバイス１３が、メッセージ７２０で機能のシーケンス｛ａ，ｂ，ｃ，ｅ，ｄ｝によって表される安全なコマンド構造をデバイス１１〜１５に提案するものとして図示されている。デバイス１１〜１５は、メッセージ７２０を受信したならば、提案されたコマンド構造に投票するかどうかをそれぞれが独立に判定することができる。上で詳細に説明したＰａｘｏｓアルゴリズムと同様に、デバイスは、より大きい提案番号を提案する要求に応答していない場合に、提案された機能またはコマンド構造に投票することができる。さらに、デバイスは、同一の提案番号を使用する他のコマンド構造にまだ投票していない場合、または、同一の提案番号を使用して提案された、前に投票されたコマンド構造が、新たに提案されたコマンド構造のプレフィックスである場合に、提案されたコマンド構造に投票することができる。
図８ｄに移ると、デバイス１１〜１４のそれぞれは、提案されたコマンド構造に投票できることを独立に判定することができ、メッセージ７３１〜７３４を介してリーダー１３に投票をシグナリングする。この一般化されたコンセンサスアルゴリズムのフォールトトレラントな性質を示すために、デバイス１５は、故障を経験し、したがってリーダー１３に応答を供給しないものとして図示されている。上で詳細に説明したＰａｘｏｓアルゴリズムと同様に、リーダー１３は、定足数のデバイスが提案されたコマンド構造を選択したことを判定することができ、その成功を、図８ｅに示されたメッセージ７４０などのメッセージを介してデバイス１１〜１５にシグナリングすることができる。
上で説明した一般化されたフォールトトレラントコンセンサスアルゴリズムは、個々の機能を選択するのではなく、コマンド構造を選択することができるので、リーダー１３は、異なる機能を提案する前にシステム１０を後続システムステップに進める必要がない。代わりに、リーダーは、単に、前に選択されたコマンド構造を含み、新しい機能を追加された新しいコマンド構造を提案することができる。したがって、図８ｆに移ると、リーダー１３は、シーケンス｛ａ，ｂ，ｃ，ｅ，ｄ｝によって表される前に選択されたコマンド構造に機能「ｆ」を追加することによって形成できるシーケンス｛ａ，ｂ，ｃ，ｅ，ｄ，ｆ｝によって表されるコマンド構造を提案することによって、システム１０に、変数「ｆ」によって表される新しい機能を選択させ、実行させることができる。
前に説明したように、デバイス１１〜１５のそれぞれが、提案されたコマンド構造に投票するかどうかを独立に判定することができる。デバイス１１〜１４のそれぞれは、提案番号７０を使用して提案されたコマンド構造に前に投票しているので、新たに提案されたコマンド構造がプレフィックスとして前に投票されたコマンド構造を有するかどうかを独立に判定することができる。シーケンス｛ａ，ｂ，ｃ，ｅ，ｄ，ｆ｝によって表される新たに提案されたコマンド構造は、プレフィックスとして、シーケンス｛ａ，ｂ，ｃ，ｅ，ｄ｝によって表されるコマンド構造を有するので、デバイス１１〜１４のそれぞれは、メッセージ７５０で送信された提案に投票することができる。したがって、図８ｇに示されているように、デバイス１１〜１３は、それが新たに提案されたコマンド構造に投票することを示すメッセージ７６１〜７６３を送信することができる。デバイス１４は、より大きい提案番号に応答している可能性があり、したがって、投票することができない。それでも、表１に示されているように、デバイス１１〜１３が、例示的なシステム１０の定足数を構成するので、リーダー１３は、シーケンス｛ａ，ｂ，ｃ，ｅ，ｄ，ｆ｝によって表される提案されたコマンド構造が選択されたと判定することができ、図８ｈに示されているように、メッセージ７７０などのメッセージを介してデバイス１１〜１５に知らせることができる。
以上のように、上で説明した一般化されたフォールトトレラントコンセンサスアルゴリズムは、分散コンピューティングシステムが、単一の機能ではなく機能のシーケンスに合意することを可能にする。その結果、システムステップの周囲でアルゴリズムを調整する必要は、もはや存在しない。図９ａに移ると、上で説明したアルゴリズムの動作が、分散コンピューティングシステム１０だけではなく、クライアント２０と、追加のコンピューティングデバイス３０および３１も含む環境に関して示されている。その結果、図９ａ〜ｇに示された動作は、図８ａ〜ｇに示された動作と独立であることを意味し、その結果、図８ａ〜ｇに示されたコマンド構造が前に選択されたと仮定されていない。したがって、図９ａに示されているように、クライアント２０は、デバイス１３に要求８００を送信し、変数「ｇ」によって表される機能を実行することを要求することができる。次に、デバイス１３は、上で詳細に示した形で、提案番号１００を提議するメッセージ８０１を送信することによって、リーダーデバイスになることを試みることができる。
図９ｂに移ると、デバイス１１および１３は、それぞれメッセージ８１１および８１３を介して、前の投票情報およびそれぞれが応答した最大の提案番号を示すことができる。具体的に言うと、デバイス１１および１３は、提案番号５０を使用して提案された、機能のシーケンス｛ａ，ｂ｝によって表されるコマンド構造に前に投票したことと、提案番号５０が、それが応答した最大の番号の提案であることを示すことができる。その一方で、デバイス１２および１４〜１５は、リーダー１３によって使用された提案番号より大きい提案番号を有する提議に前に応答したものとして図示されている。したがって、デバイス１２および１４〜１５は、そのデバイスが提案番号１５０を使用する提議に応答したことを示すメッセージ８１２および８１４〜８１５を送信することができる。あるいはまた、上でＰａｘｏｓアルゴリズムに関して詳細に説明したように、デバイス１２および１４〜１５は、リーダー１３によって送信された提案番号が、これらのデバイスが既に応答した最大の提案番号より小さいので、単に、リーダー１３に応答しないようにすることができる。どちらの場合でも、リーダー１３は、定足数のデバイスがリーダーの提案に投票することに合意しなかったと判定することができ、より大きい提案番号の送信を試みることができる。
図９ｃに移ると、リーダー１３が、２００という新しい提案番号を提議するメッセージ８２０を送信するものとして図示されている。デバイス１１〜１５のそれぞれは、上で説明したものに類似の方法でこの新しい提案番号に応答することができる。たとえば、図９ｄに示されているように、デバイス１１および１３は、メッセージ８３１および８３３を介して、前にメッセージ８１１および８１３を介して送信したものと同一の情報を送信することができる。というのは、この両方のデバイスが、リーダーの最初のメッセージ８０１と後続の提案８２０の受信の間に他のメッセージに応答しなかったからである。その一方で、デバイス１２および１４〜１５は、リーダーが提議した提案番号が十分に大きいので、リーダーに最後の投票情報を供給することができる。したがって、図９ｄに示されているように、デバイス１２および１４は、それぞれメッセージ８３２および８３４を介して、提案番号１５０を使用して提案された機能のシリーズ｛ａ，ｂ，ｃ｝によって表されるコマンド構造に前に投票したことと、提案番号１５０が、これらが応答した最大の提案番号であることを示すことができる。同様に、デバイス１５は、メッセージ８３５を介して、５０という提案番号を使用して提案された機能のシーケンス｛ａ，ｂ｝によって表されるコマンド構造に前に投票したことと、提案番号１５０を使用する提案に応答したが、提案１５０に対応する票を投じなかったことを示すことができる。
メッセージ８３１〜８３５を介して供給された情報を与えられて、リーダーは、デバイス１１〜１５に提案するのに安全なコマンド構造を判定することができる。上で詳細に説明したように、リーダーは、リーダーが選択できる可能な定足数のそれぞれが、提案１５０に参加したが提案１５０を使用して票を投じなかった少なくとも１つのデバイスを有するかどうかを判定することができる。図からわかるように、すべてのデバイスが提案１５０に参加した、デバイス１２および１４のいずれかまたは両方を含む定足数が存在する、すなわち、デバイス１２および１４のいずれかまたは両方が、提案１５０を使用して票を投じた。その結果、リーダーは、上で詳細に説明したように、リーダーが応答するデバイス１１〜１５の中から選択できるすべての定足数に関する基礎コマンド構造を判定することができる。リーダーが提案するのに安全なコマンド構造は、判定された基礎コマンド構造のそれぞれをプレフィックスとして有するすべてのコマンド構造とすることができる。例として、デバイス１１、１２、および１３を含む定足数は、機能シーケンス｛ａ，ｂ｝によって表される基礎コマンド構造を有することができる。同様に、デバイス１２、１４、および１５を含む定足数も、機能シーケンス｛ａ，ｂ｝によって表される基礎コマンド構造を有することができる。当業者が諒解するように、図９ｄに示された例示的な状況について、すべての可能な定足数が、機能シーケンス｛ａ，ｂ｝によって表される基礎コマンド構造を有する。したがって、プレフィックスとして、機能シーケンス｛ａ，ｂ｝によって表される基礎コマンド構造を有するすべてのコマンド構造が、リーダー１３が提案するのに安全なコマンド構造になる。
図９ｅに移ると、リーダー１３が、メッセージ８４０を介してデバイス１１〜１５に提案される、機能シーケンス｛ａ，ｂ，ｃ，ｇ｝によって表されるコマンド構造を選択したものとして図示されている。上で示したように、そのようなコマンド構造は、機能シーケンス｛ａ，ｂ，ｃ，ｇ｝によって表されるコマンド構造がプレフィックスとして機能シーケンス｛ａ，ｂ｝によって表されるコマンド構造を有するので、安全である。具体的に言うと、機能シーケンス｛ａ，ｂ，ｃ，ｇ｝によって表されるコマンド構造は、機能シーケンス｛ａ，ｂ｝によって表されるコマンド構造に機能シーケンス｛ｃ，ｇ｝を追加することによって入手することができる。メッセージ８４０の受信時に、デバイスのそれぞれは、提案されたコマンド構造に投票するかどうかを独立に判定することができる。上で詳細に説明したように、各デバイスは、より大きい提案番号を使用する提議に応答した場合、または現在の提案番号を使用して提案されたコマンド構造に既に投票しており、その、前に投票されたコマンド構造が現在提案されているコマンド構造のどのプレフィックスとも等しくない場合を除いて、提案されたコマンド構造に投票することができる。
デバイス１１〜１５のどれもが、より大きい番号の提案に応答しておらず、現在の提案番号を使用して前に提案されたコマンド構造に投票していないので、デバイスのそれぞれは、メッセージ８４０によって提案されたコマンド構造に投票することができる。したがって、図９ｆに移ると、デバイス１１〜１５のそれぞれが、それぞれメッセージ８５１〜８５５をリーダー１３に送信することによって、提案されたコマンド構造に投票するものとして図示されている。デバイス１１〜１５は定足数を構成するので、リーダー１３は、提案されたコマンド構造が選択されたと判定することができ、図９ｇに示されているように、メッセージ８６０を介して他のデバイスに知らせることができる。同様に、リーダーは、メッセージ８６１を介して、クライアント２０がメッセージ８００を介して要求した機能「ｇ」の実行の結果についてクライアント２０に知らせることができる。さらに、リーダーは、提案されたコマンド構造が選択されたことを、メッセージ８６２を介してラーナーデバイス３０および３１に知らせることができる。あるいはまた、上で詳細に説明したように、リーダー１３が、機能の実行の結果についてデバイス３０および３１に単純に知らせることができる。
上の詳細な説明からわかるように、一般化されたフォールトトレラントコンセンサスアルゴリズムは、分散コンピューティングシステムが、単に個々の機能に対するコンセンサスではなく、異なる順序の機能の交換可能な対を有する機能のシーケンスの間の同等性を認識するコマンド構造に対するコンセンサスを達成することを可能にすることができる。したがって、リーダーデバイスは、前に選択されたコマンド構造に１つまたは複数の新しい機能を追加することによって形成されるより大きいコマンド構造を提案し続けることができ、これによって、システムに新しい機能を選択させ、実行させ続けることができる。しかし、コマンド構造を提案する単一のポイントとしてのリーダーデバイスの存在が、交換可能なコマンドの対でも同一の順序で選択されることを保証する。分散コンピューティングシステムの構成デバイスが、クライアントから直接に要求を受信することを可能にすることによって、上で説明したコマンド構造の柔軟性を使用して、要求の送信とその要求に対する応答の送信の間で少なくとも１つのメッセージ遅延を除去することができる。
一般化されたメッセージ遅延削減フォールトトレラントコンセンサスアルゴリズム
図１０ａに移ると、リーダーデバイス１３は、コンセンサスを達成し、それ以上の提案がないことを知ったならば、システム１０が一般化されたメッセージ遅延削減フォールトトレラントコンセンサスアルゴリズムを使用することを可能にすることができる。上で説明したように、提案番号が、システムによって使用されるアルゴリズムのタイプに相関しない場合に、リーダーは、メッセージ９００に似たメッセージで、最後に選択されたコマンド構造が安全であることと、リーダーが使用していた提案番号も安全であることを単純に示すことができる。しかし、提案番号が、システムによって使用されるアルゴリズムのタイプに相関する場合には、リーダー１３は、一般化された低メッセージ遅延アルゴリズムに対応する、リーダーが知っている前に使用された提案番号のどれよりも大きい提案番号を選択することができ、図８ａに示された形でその提案番号をデバイス１１〜１５に提案することができる。定足数のデバイスが、図８ｂに示された形などで、新たに選択された提案番号に合意する場合に、リーダー１３は、一般化された低メッセージ遅延アルゴリズムに対応する新しい提案番号を送信し、その提案番号および前に選択されたコマンド構造が安全であることを示すことができる。たとえば、図１０ａに示されているように、リーダー１３が、一般化された低メッセージ遅延アルゴリズムに対応する選択された提案番号２０１を有し、定足数のデバイスからの合意を得たならば、リーダーは、提案番号２０１および機能シーケンス｛ａ，ｂ，ｃ，ｇ｝によって表されるコマンド構造が安全であることを示すメッセージ９００を送信することができる。各デバイスは、提案番号を対応するアルゴリズムに相関させるデータベースを維持することができる。その結果、メッセージ９００の受信時に、デバイス１１〜１５のそれぞれは、提案番号２０１が一般化された低メッセージ遅延アルゴリズムに対応することを知ることができ、したがって、クライアントから直接に受信された要求に応答するのにその提案番号を使用することができる。代替案では、メッセージ９００に、クライアントから直接に要求を受け入れ、その要求を２０１という提案番号を有するものとして扱うことの、デバイス１１から１５への明示的指示を含めることができる。
図１０ｂに移ると、クライアント２０が、変数「ｈ」によって表される機能を実行することを要求するメッセージ９１０をデバイス１１〜１５に送信するものとして図示されている。上で示したように、デバイス１１〜１５のそれぞれは、クライアント２０の要求を、２０１の提案番号を有する提案として扱うことができ、上で詳細に説明した形で、要求された機能に投票するかどうかを判定することができる。図１０ｃに移ると、リーダー１３が、機能シーケンス｛ａ，ｂ，ｃ，ｇ｝によって表されるコマンド構造が安全であることを前に示したので、デバイス１１〜１５のそれぞれは、安全を示すコマンド構造に要求された機能を追加することによって作成されるコマンド構図（図示のように機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ｝によって表されるコマンド構造になる）に投票することによって、要求された機能に投票することができる。デバイス３０などのラーナーデバイスは、デバイスをポーリングすること、またはデバイスの投票を示すメッセージ９１１〜９１５などのメッセージを自動的に受信することのいずれかによって、デバイスの投票について知ることができる。ラーナーデバイスは、定足数のデバイスがあるコマンド構造を選択したかどうかを判定することができ、定足数があるコマンド構造を選択した場合に、ラーナーデバイスは、コマンドの同等のシーケンスを実行することができ、その結果を、要求元のクライアントデバイス２０を含む任意のデバイスに供給することができる。その結果、図１０ｃに示されているように、ラーナーデバイス３０は、少なくとも定足数のデバイスが、要求された機能を含むコマンド構造に投票したと判定した後に、クライアントデバイスにメッセージ９２０を送信し、クライアント２０によって要求された機能「ｈ」の実行の結果を供給することができる。
上で詳細に説明したように、デバイス１１〜１５のそれぞれは、ラーナーデバイスとしても働くことができ、それら自体が要求されたコマンドを実行することができ、これによって、システム１０の状態を独立に維持することができる。その場合に、各デバイスは、他のデバイスのそれぞれに、コマンド構造への投票をシグナリングすることができる。したがって、図１０ｄに移ると、デバイス１１〜１５のそれぞれが、機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ｝によって表されるコマンド構造への投票について他のデバイスに知らせるメッセージ９２１〜９２５を他のデバイスのそれぞれに送信するものとして図示されている。どのデバイスでも、定足数のデバイスがコマンド構造に投票したと判定するのに十分な数のメッセージ９２１〜９２５を受信したならば、コマンドの同等のシーケンスを実行することができ、その実行の結果を、クライアントデバイスを含む任意のデバイスに供給することができる。したがって、図１０ｄに示されているように、デバイス１１〜１５のそれぞれは、定足数が機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ｝によって表されるコマンド構造を選択したことを知ったならば、機能「ｈ」を実行し、メッセージ９３１〜９３５を介するなど、その結果をクライアント２０に供給することができる。
しかし、いくつかの状況で、２つまたはそれ以上のクライアントデバイスが、ほぼ同時に分散コンピューティングシステム１０に要求を送信する場合がある。その場合に、要求は、デバイスにさまざまな順序で到着する可能性がある。たとえば、図１１ａに、両方がほぼ同時に要求メッセージを送信するクライアント２０およびクライアント３１を示す。クライアント２０は、変数「ｄ」によって表される機能の実行を要求するメッセージ１０００を送信し、クライアント３１は、変数「ｅ」によって表される機能の実行を要求するメッセージ１００１を送信する。分散コンピューティングシステム１０のデバイス１１〜１５のうちのいくつかは、メッセージ１０００を最初に受信する可能性があり、他のデバイスは、メッセージ１００１を最初に受信する可能性がある。上で詳細に説明したように、デバイスは、そのデバイスが最初に受信したメッセージによって要求される機能がどれであれ、既に選択されたコマンド構造にその機能を追加することができる。
図１１ｂに移ると、デバイス１１〜１３が、メッセージ１０００を最初に受信したものとして図示され、デバイス１４〜１５が、メッセージ１００１を最初に受信したものとして図示されている。したがって、デバイス１１〜１５が、上で詳細に説明した形でラーナーデバイス３０に投票を報告する場合に、デバイス１１〜１３は、機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ，ｄ｝によって表されるコマンド構造に票を投じることを示すメッセージ１０１１〜１０１３を送信することができ、デバイス１４〜１５は、機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ，ｅ｝によって表されるコマンド構造に票を投じることを示すメッセージ１０１４〜１０１５を送信することができる。以上のように、デバイスのそれぞれが投票したコマンド構造は、どちらのメッセージが最初に受信されたにせよ、要求された機能すなわち「ｄ」または「ｅ」のいずれかを、機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ｝によって表される既に選択されているコマンド構造に追加することによって得られたものである。
要求１０００および１００１は、ほぼ同時に送信されたので、要求１０００を最初に受信したデバイスすなわち図１１ｂに示された例示的な状況ではデバイス１１〜１３は、そのすぐ後に要求１００１を受信する可能性が高い。同様に、図１１ｂの例示的な状況でメッセージ１００１を最初に受信したデバイス１４〜１５は、すぐに要求１０００を受信する可能性が高い。これらのデバイスは、後者の要求を受信したならば、上で詳細に説明したものに類似する形でその要求に投票することができる。したがって、図１１ｃに移ると、デバイス１１〜１３が、メッセージ１００１によって要求された機能を追加された、これらのデバイスが前に投票したコマンド構造を含むコマンド構造に投票するものとして図示されている。同様に、デバイス１４〜１５は、メッセージ１０００によって要求された機能を追加された、デバイス１４〜１５が前に投票したコマンド構造を含むコマンド構造に投票するものとして図示されている。したがって、それぞれデバイス１１〜１３からのメッセージ１０２１〜１０２３は、これらのデバイスが機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ，ｄ，ｅ｝によって表されるコマンド構造に投票したことを示し、それぞれデバイス１４〜１５からのメッセージ１０２４〜１０２５は、これらのデバイスが機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ，ｅ，ｄ｝によって表されるコマンド構造に投票したことを示す。
前に説明したように、そのような競合は、高速Ｐａｘｏｓアルゴリズムに、機能「ｄ」および「ｅ」を一意に順序付ける試みで追加のメッセージ遅延を導入させる。しかし、機能「ｄ」および「ｅ」が交換可能である場合に、上で詳細に説明したようにこれらを順序付ける必要はなく、メッセージ１０２１〜１０２３のコマンド構造は、コマンド構造１０２４〜１０２５と等しい。言い換えると、デバイス１１〜１５のそれぞれは、機能「ｄ」および「ｅ」が交換可能である場合に、同等のコマンド構造に投票しており、これらのコマンド構造に関するコンセンサスに達している。したがって、図１１ｄに示されているように、機能「ｄ」および「ｅ」が交換可能である場合に、ラーナーデバイス３０は、任意の順序で機能「ｄ」および「ｅ」の両方を実行することができ、その結果を、メッセージ１０３０および１０３１を介してめいめいの要求元クライアントに供給することができる。したがって、一般化されたメッセージ遅延削減フォールトトレラントアルゴリズムは、２つまたはそれ以上の要求がほぼ同時に送信された時であっても、要求された機能のすべての対が交換可能であるならば、追加のメッセージ遅延を導入しない。もちろん、機能「ｄ」および「ｅ」が交換可能でない場合に、一般化されたフォールトトレラントコンセンサスアルゴリズムを使用して、「ｄ」または「ｅ」のいずれかを最初に選択し、上で詳細に説明した方法でデバイス１１〜１５に適当なコマンド構造を提案することによって、コンセンサスを達成することができる。
図１１ｅに移ると、一般化されたメッセージ遅延削減フォールトトレラントアルゴリズムの代替実施形態が示されている。上で説明したように、デバイス１１〜１５のそれぞれが、ラーナーデバイスとして働くこともできる。その場合に、これらのデバイスは、コマンド構造に投票するときに、その投票を示すメッセージを他のデバイスのそれぞれに送信することができる。したがって、図１１ｅに示されているように、デバイス１１〜１５は、それぞれメッセージ１０４１〜１０４５を互いに送信することができる。図１１ｂと同様に、デバイス１１〜１３は、メッセージ１０００を最初に受信したものとして図示されており、デバイス１４〜１５は、メッセージ１００１を最初に受信したものとして図示されている。したがって、メッセージ１０４１〜１０４３は、機能シーケンス｛ａ，ｂ，ｃ，ｇ，ｈ｝によって表される前に選択されたコマンドシーケンスに機能「ｄ」を追加することによって得られたコマンド構造への投票を示し、メッセージ１０４４〜１０４５は、その代わりに機能「ｅ」を追加することによって得られたコマンド構造への投票を示す。
上と同様に、メッセージ１０００または１００１のいずれかを最初に受信した後に、各デバイスは、２つのメッセージのうちの他方を受信し、これに応答する可能性が高い。その結果、図１１ｆに示されているように、デバイス１１〜１３は、前に投票されたコマンド構造に機能「ｅ」を追加することによって得られたコマンド構造に投票したことを示すメッセージ１０５１〜１０５３を送信することができ、デバイス１４〜１５は、前に投票されたコマンド構造に機能「ｄ」を追加することによって得られたコマンド構造に投票したことを示すメッセージ１０５４〜１０５５を送信することができる。上で詳細に説明したように、機能「ｄ」および「ｅ」が交換可能である場合に、デバイスによって投票されたコマンド構造の両方が、同等である。その結果、各デバイスは、そのコマンド構造が選択されたと判定することができ、図１１ｇに示されているように、機能「ｄ」および「ｅ」の両方を独立に実行し、それぞれメッセージ１０６１〜１０６５および１０７１〜１０７５を介してめいめいのクライアント２０および３１に結果を供給することができる。
機能「ｄ」および「ｅ」が交換可能でない場合に、図１１ｅ〜ｇのシステムは、図１１ｂ〜ｄのシステムと同一の形で一般化されたフォールトトレラントコンセンサスアルゴリズムを使用することに頼る必要はない。代わりに、投票するデバイス１１〜１５のそれぞれが、システム全体の状態も維持するので、各デバイスは、メッセージ１０４１〜１０４５および１０５１〜１０５５の受信時に、競合が発生したことを検出することができる。その場合に、各デバイスは、上で高速Ｐａｘｏｓアルゴリズムに関して詳細に説明したものと類似の方法で、リーダーデバイスが行うことを予想することを試みることができる。具体的に言うと、各デバイスは、一般化された低メッセージ遅延アルゴリズムに同様に対応する新しい提案番号を選択することができ、その新しい提案番号を使用して、メッセージ８３１〜８３５に類似するメッセージをすべての他のデバイスに送信することができる。上で説明したように、新しい提案番号は、提案が行われたことをデバイスが知っているすべての提案番号より大きいものとすることができる。デバイスのそれぞれが、新しい提案番号に関する他のデバイスからのメッセージを受信したならば、各デバイスは、リーダーデバイスが使用するものと同一の所定の判断基準を使用して、安全なコマンド構造に機能シーケンス｛ｄ，ｅ｝または機能シーケンス｛ｅ，ｄ｝を追加したコマンド構造のどちらを提案するかを判定することができる。判定したならば、デバイスは、新しいコマンド構造に投票し、その投票を他のデバイスに送信することができる。各デバイスが同一のコマンド構造を選択していなければならず、図１０ｄに示したものに類似する動作を再開することができる。リーダーによって使用される所定の判断基準は、受信されたメッセージに依存する可能性があるので、いくつかのデバイスが故障した場合、またはいくつかのメッセージが過度の遅延を経験する場合に、異なるデバイスがメッセージの同一のセットを受信しない場合がある。その結果、メッセージの異なるセットを受信したデバイスが、同一の新しいコマンド構造を独立に選択しない場合がある。その場合に、第２の競合が発生し得る。同一の競合の継続的な再発生を避けるために、システムは、同一の競合が複数回発生する場合に、上で説明した一般化されたフォールトトレラントコンセンサスアルゴリズムなど、リーダーデバイスに頼って競合を避ける一般化されたコンセンサスアルゴリズムに頼ることができる。それでも、すべての故障していないデバイスが送信されたすべてのメッセージを受信する通常の場合に、上で説明した機構は、２つの競合する要求がほぼ同時に送信される状況で、クライアントの要求の受信と応答の送信の間のメッセージ遅延の数を減らすことができる。
上で詳細に説明したように、高速Ｐａｘｏｓアルゴリズムは、Ｐａｘｏｓアルゴリズムによって使用される定足数より多数のデバイスとして定足数を定義することができる。同様に、一般化されたメッセージ遅延削減フォールトトレラントコンセンサスアルゴリズムは、上で説明した一般化されたフォールトトレラントコンセンサスアルゴリズムより多数のデバイスを定足数として使用することができる。すべてが同等であれば、一般化されたメッセージ遅延削減フォールトトレラントコンセンサスアルゴリズムは、より効率的な分散コンピューティングシステムを提供することができる。しかし、不十分な個数のデバイスが動作している場合に、上で説明した一般化されたフォールトトレラントコンセンサスアルゴリズムを使用することができる。その結果、リーダーデバイスまたはラーナーデバイスが、故障についてシステム１０の他のデバイスを監視することができる。十分な個数のデバイスが故障した場合に、リーダーは、一般化されたフォールトトレラントコンセンサスアルゴリズムに対応する提案番号を選択することができ、上で詳細に説明したアルゴリズムを実施することができる。さらに、当業者に既知のように、タイムアウト、ｐｉｎｇに応答しないことなど、デバイスの故障を検出できる多数の機構がありえる。どの機構でも、本発明の実施形態によって、故障の検出に使用することができるが、実際に故障がないときに故障をシグナリングする可能性がある機構は、より非効率的な動作を引き起こす可能性がある。
同様に、単一の機能を複数回選択するか実行することも、非効率的な動作または不正な動作を引き起こす可能性がある。クライアントがある機能を複数回要求したので、その機能の複数の要求に異なる機能識別子が割り当てられるように、要求された機能に一意の機能識別子を割り当てることができる。そのような機能識別子を使用して、クライアントによって要求された機能のそれぞれが、要求ごとに１回だけ選択されるか実行されることを保証することができる。本発明の実施形態によって企図されている機構の１つは、新しいコマンド構造を生成するために前に投票されたコマンド構造に機能を追加するときに、機能識別子を検査する。機能識別子が、その機能がコマンド構造に既に存在することを示す場合に、そのコマンド構造にその機能を追加する試みが、コマンド構造の変化をもたらさないものとすることができる。その結果、重複した機能は選択されなくなる。本発明の実施形態によって企図されている代替機構は、機能の選択されたシリーズを実行するときに機能識別子を検査する。機能識別子が、その機能が既に実行されていることを示す場合に、実行するデバイスは、重複した機能を無視することができる。その結果、重複した機能が選択された場合であっても、その機能が実行されなくなる。
リーダーデバイスおよびラーナーデバイスに、上で説明したアルゴリズムの実行を助けることができる情報を含めることができるが、分散コンピューティングシステム１０の構成デバイス１１〜１５は、投票するデバイスとしてのみ働く場合に、情報の少数の要素だけを維持する必要がある。具体的に言うと、各投票するデバイスは、提案番号の使用を提案するリーダーからのメッセージにそのデバイスが応答した最大の提案番号、そのデバイスが票を投じた最大の提案番号、およびそのデバイスが前に投票した、その提案番号に対応するコマンド構造を維持することができる。
デバイスによって使用されるメモリの量は、チェックポイントコマンドの使用を介してさらに減らすことができる。上で示したように、チェックポイントコマンドは、すべての他のコマンドと交換可能でないコマンドとすることができる。その結果、チェックポイントコマンドは、コマンド構造内の固定された点を定義する。具体的に言うと、チェックポイントは、すべてのコマンド構造を、それぞれにチェックポイントコマンドを追加されたより小さいコマンド構造のシリーズから作成することを可能にする。したがって、デバイスは、現在投票されているコマンド構造と共に、より小さいコマンド構造のシリーズのうちの最新のものを実行した後の状態だけを記憶すればよい。
図１２ａに移ると、チェックポイントコマンドの例示的実装が示されている。リーダーデバイスまたはその代わりに図１２ａに示されたクライアントデバイス２０などのクライアントデバイスが、メッセージ１１００を介してデバイス１１〜１５にチェックポイントコマンドを実行する要求を送信することによって、変数「Ｃ」によって表されるチェックポイントコマンドを提案することができる。メッセージ１１００の受信時に、デバイスのそれぞれが、上で詳細に説明した方法で、そのチェックポイントコマンドを追加されたコマンド構造に投票するかどうかを判定することができる。
図１２ｂに、デバイス１１〜１５が前に投票したコマンド構造にチェックポイントコマンドを追加することによって形成されるコマンド構造に投票するデバイス１１〜１５を示す。したがって、たとえば、デバイス１１〜１３は、機能シーケンス｛ｈ，ｄ，ｅ，Ｃ｝によって表されるコマンド構造に投票するものとして図示され、デバイス１４〜１５は、機能シーケンス｛ｈ，ｅ，ｄ，Ｃ｝によって表されるコマンド構造に投票するものとして図示されている。デバイスのそれぞれは、その投票情報を、それぞれメッセージ１１１１〜１１１５を介して、ラーナーデバイス３０などのラーナーデバイスに投票することができる。ラーナーデバイス３０は、定足数のデバイスがコマンド構造を選択したと判定するのに十分な数のメッセージを受信したならば、メッセージ１１２０によって示されているように、チェックポイントコマンドが選択されたことを要求元のデバイス２０に知らせることができる。あるいはまた、図１２ｃに示されているように、デバイスのそれぞれが、上で詳細に説明した形で互いに投票メッセージ１１２１〜１１２５を送信することができ、定足数のデバイスがチェックポイント機能に投票したことをそれぞれが独立に判定し、その後、チェックポイントコマンドが選択されたことの指示を、メッセージ１１３１〜１１３５を介して要求元のデバイス２０に送信することができる。
チェックポイントコマンドを選択した後に、デバイスのそれぞれは、チェックポイントコマンドで終わるコマンド構造を実行した後の状態だけを記憶する必要がある。図１２ｄに移ると、メッセージ１１４０を介して送信されるデバイス２０による後続要求が、変数「ｋ」によって表される機能を実行する要求として図示されている。チェックポイントコマンドが前に選択されたので、デバイス１１〜１５のそれぞれは、ヌルコマンド構造に「ｋ」を追加することによって形成されるコマンド構造に投票することによって、機能「ｋ」に投票することができる。さらに、前に選択されたチェックポイントコマンドの識別子も指定することができ、その結果、これらのデバイスが実際に合意していることを判定することができるようになる。たとえば、チェックポイントが、１０個の機能ごとにその後に選択される場合に、２０番目の機能の後のデバイスの状態と３０番目の機能の後のデバイスの状態の間に、大きい相違がある可能性がある。その結果、図１２ｅに示されているように、デバイス１１〜１５のそれぞれは、機能シーケンス｛ｋ｝によって表されるコマンド構造に投票することができ、投票されたコマンド構造の前にどのチェックポイントがあるかの指示を供給することができる。図１２ｅに示されているように、チェックポイントコマンドに、上で詳細に説明した形でコマンド識別子を割り当てることができ、そのコマンド識別子を使用することができる。あるいはまた、各チェックポイントに順次番号を付け、その番号を代わりに送信することができる。その後、デバイスの投票を、メッセージ１１５１〜１１５５を介してラーナーデバイス３０に送信することができ、ラーナーデバイス３０は、図１２ｅに示されているように、メッセージ１１６０を介して機能「ｋ」の実行の結果を要求元のクライアント２０に供給することができる。あるいはまた、図１２ｆに示されているように、デバイス１１〜１５が、投票を互いにアナウンスするメッセージ１１７１〜１１７５を送信することができ、定足数のデバイスが機能「ｋ」に投票したと独立に判定した後に、機能「ｋ」の実行の結果を供給するメッセージ１１８１〜１１８５をクライアント２０に送信することもできる。
しかし、上で示したように、デバイスは、単にコマンド構造を保管するのではなく、送信もする。たとえば、デバイス１１〜１５のそれぞれが、その投票について別のデバイスに知らせようとするたびに、コマンド構造を送信することができる。本発明の実施形態によって企図されている、送信される情報の量を減らす機構の１つは、コマンド構造の性質を利用して、新しい情報だけを送信する。具体的に言うと、上で説明したように、コマンド構造は、新たに要求された機能または機能のシリーズをプレフィックスコマンド構造に追加することによって作成することができる。さらに、プレフィックスコマンド構造は、前に投票され、おそらく既に送信されている。したがって、新たに投票されたコマンド構造を送信するのではなく、送信するデバイスは、受け取るデバイスが既に知っている新たに投票されるコマンド構造の最大のプレフィックスについて知ることができる。送信するデバイスは、次に、新たに投票されるコマンド構造を生成するためにプレフィックスコマンド構造に追加される追加の機能または機能のシリーズだけを送信する必要がある。本質的に、送信するデバイスは、コマンド構造全体を送信するのではなく、受け取るデバイスがコマンド構造を組み立てるために必要とする情報だけを送信する。
本発明の原理を適用できる多数の可能な実施形態に鑑みて、図面に関して本明細書で説明した実施形態が、例示的であることだけを意図され、本発明の範囲を制限するものと解釈されてはならないことを認められたい。たとえば、当業者は、ソフトウェアで示された図示された実施形態の要素を、ハードウェアで実施することができ、その逆が可能であり、また、図示された実施形態を、本発明の趣旨から逸脱せずに配置および詳細を変更できることを認めるであろう。したがって、本明細書に記載の本発明は、請求項およびその均等の範囲に含めることができるすべてのそのような実施形態を企図したものである。
本発明の実施形態を実装できる例示的な分散コンピューティングシステムを全般的に示すブロック図である。 本発明の実施形態を実装できる例示的なコンピューティングデバイスを全般的に示すブロック図である。 本発明の実施形態によって企図されるコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図される一般化されたコンセンサスアルゴリズムの動作を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図されるマルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作の一態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のもう１つの態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。 本発明の実施形態によって企図される低メッセージ遅延マルチフェーズの一般化されたコンセンサスアルゴリズムの動作のさらなる態様を全般的に示す図である。
符号の説明
１０ 分散コンピューティングシステム
１１、１２、１３、１４、１５、３０、３１ コンピューティングデバイス
１３０ システムメモリ
１３１ ＲＯＭ
１３３ ＢＩＯＳ
１３２ ＲＡＭ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１００ コンピューティングデバイス
１２０ 処理ユニット
１９０ ビデオインターフェース
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
１２１ システムバス
１４０ ノンリムーバブル不揮発性メモリインターフェース
１５０ リムーバブル不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１７０ ネットワークインターフェース
１７１ 一般的なネットワーク接続
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１６１ マウス
１６２ キーボード
１８０ リモートコンピューティングデバイス

Claims (37)

  1. 分散コンピューティングシステムで提案されたコマンド構造を選択する方法であって、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造であり、
    前記分散コンピューティングシステム内の第１定足数のデバイスに前記提案されたコマンド構造を送信するステップであって、前記提案されたコマンド構造は、提案番号に関連する、送信するステップと、
    前記提案されたコマンド構造の受け入れを示す受け入れメッセージを受信するステップであって、受け入れるデバイスは、前記提案番号より大きい提案された提案番号に応答しておらず、かつ前記提案番号を使用して提案された前記提案されたコマンド構造のプレフィックスに前に投票した場合、または前記提案番号を使用して提案されたどのコマンド構造にも前に投票していない場合、受け入れメッセージを送信することができる、受信するステップと、
    前記受け入れメッセージは第２定足数のデバイスから受信された場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと
    を備えることを特徴とする方法。
  2. 前記分散コンピューティングシステム内の第３定足数のデバイスに、提議される次の提案番号を送信するステップと、
    前記提議された次の提案番号より大きい提議された提案番号に前に応答していない応答デバイスから応答メッセージを受信するステップであって、前記応答メッセージは、前記提議された提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの前記応答デバイスによる約束として働き、前記応答メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、前記応答デバイスによって事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、前記デバイスが応答したすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、受信するステップと
    をさらに備えることを特徴とする請求項１に記載の方法。
  3. 応答メッセージが第４定足数のデバイスから受信された場合、前記提案されたコマンド構造は、前記第４定足数のデバイスからの前記応答メッセージで示される前に受け入れられたコマンド構造、または定足数の第１組のすべての基礎コマンド構造をプレフィックスとして有する共通コマンド構造のいずれかであることを特徴とする請求項２に記載の方法。
  4. 前記提案されたコマンド構造の前記送信は、前に送信されたコマンド構造の識別子および１つまたは複数の機能を送信するステップを含み、前記前に送信されたコマンド構造に前記１つまたは複数のコマンドを追加するステップは、前記提案されたコマンド構造をもたらすことを特徴とする請求項１に記載の方法。
  5. 前記提案されたコマンド構造がチェックポイントコマンドで終わる場合、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに備えることを特徴とする請求項１に記載の方法。
  6. 分散コンピューティングシステムで提案されたコマンド構造を選択する方法であって、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造であり、
    要求された機能を実行する要求をクライアントから受信するステップと、
    提案されたコマンド構造を形成するために前記要求された機能を前に受け入れられたコマンド構造に追加するステップと、
    前記提案されたコマンド構造を提案番号に関連付けるステップであって、前記提案番号は、一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、関連付けるステップと、
    前に応答された提案番号が前記提案番号より大きくない場合、前記提案されたコマンド構造を受け入れるステップと、
    前記提案されたコマンド構造が受け入れられた場合、前記提案されたコマンド構造を識別する受け入れメッセージを送信するステップと
    を備えることを特徴とする方法。
  7. 前記受け入れメッセージの前記送信は、前記分散コンピューティングシステムの他のデバイスに前記受け入れメッセージを送信するステップを含み、
    前記分散コンピューティングシステムの他のデバイスから他のデバイスの受け入れメッセージを受信するステップと、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと
    をさらに備えることを特徴とする請求項６に記載の方法。
  8. 前記提案されたコマンド構造は選択されなかったと判定された場合、
    後続提案番号を選択するステップであって、前記後続提案番号は、前記提案番号より大きく、前記後続提案番号は、前記一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、選択するステップと、
    前記分散コンピューティングシステムの前記他のデバイスに情報メッセージを送信するステップであって、前記情報メッセージは、前記後続提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの約束として働き、前記情報メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、応答されたすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、送信するステップと、
    所定の判断基準に基づいて、他のデバイスの情報メッセージから、後続の提案されたコマンド構造を選択するステップと、
    前記後続の提案されたコマンド構造を前記後続提案番号に関連付けるステップと、
    前に応答された提案番号が前記後続提案番号より大きくない場合、前記後続の提案されたコマンド構造を受け入れるステップと、
    前記後続の提案されたコマンド構造は受け入れられた場合、前記後続の提案されたコマンド構造を識別する後続受け入れメッセージを送信するステップと
    をさらに備えることを特徴とする請求項７に記載の方法。
  9. 前記受け入れメッセージの前記送信は、前記受け入れメッセージをラーナーデバイスに送信するステップを含み、前記ラーナーデバイスは、
    前記分散コンピューティングシステムの他のデバイスから前記他のデバイスの受け入れメッセージを受信するステップと、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと、
    前記提案されたコマンド構造が選択されたと判定された場合、前記要求された機能を実行するステップと、
    前記要求された機能の前記実行の結果を前記クライアントに送信するステップと
    を実行することを特徴とする請求項６に記載の方法。
  10. 前記ラーナーデバイスは、提案されたコマンド構造が選択されないと判定する場合、前記方法は、リーダーデバイスを選択するステップをさらに備え、前記リーダーデバイスは、前記分散コンピューティングシステム内の第１定足数のデバイスに、提議された次の提案番号を送信するステップと、前記分散コンピューティングシステム内の第２定足数のデバイスに、後続の提案されたコマンド構造を送信するステップとを実行し、前記後続の提案されたコマンド構造は、所定の判断基準に基づいて、前記提議された次の提案番号の前記送信に応答して送信されたメッセージから選択され、さらに、前記後続の提案されたコマンド構造は、前記提議された次の提案番号に関連することを特徴とする請求項９に記載の方法。
  11. 前記提案されたコマンド構造の前記送信は、前に送信されたコマンド構造の識別子および１つまたは複数の機能を送信するステップを含み、前記前に送信されたコマンド構造への前記１つまたは複数の機能の追加は、前記提案されたコマンド構造をもたらすことを特徴とする請求項６に記載の方法。
  12. 前記提案されたコマンド構造はチェックポイントコマンドで終わる場合、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに含むことを特徴とする請求項６に記載の方法。
  13. 分散コンピューティングシステムで提案されたコマンド構造を選択するコンピュータ実行可能命令を有するコンピュータ可読媒体であって、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造であり、前記コンピュータ実行可能命令は、
    前記分散コンピューティングシステム内の第１定足数のデバイスに前記提案されたコマンド構造を送信するステップであって、前記提案されたコマンド構造は、提案番号に関連する、送信するステップと、
    前記提案されたコマンド構造の受け入れを示す受け入れメッセージを受信するステップであって、受け入れるデバイスは、前記提案番号より大きい提案された提案番号に応答しておらず、かつ前記提案番号を使用して提案された前記提案されたコマンド構造のプレフィックスに前に投票した場合、または前記提案番号を使用して提案されたどのコマンド構造にも前に投票していない場合、受け入れメッセージを送信することができる、受信するステップと、
    前記受け入れメッセージが第２定足数のデバイスから受信された場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと
    を実行することを特徴とするコンピュータ可読媒体。
  14. 前記コンピュータ実行可能命令は、
    前記分散コンピューティングシステム内の第３定足数のデバイスに、提議される次の提案番号を送信するステップと、
    前記提議された次の提案番号より大きい提議された提案番号に前に応答していない応答デバイスから応答メッセージを受信するステップであって、前記応答メッセージは、前記提議された提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの前記応答デバイスによる約束として働き、前記応答メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、前記応答デバイスによって事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、前記デバイスが応答したすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、受信するステップと
    をさらに実行することを特徴とする請求項１３に記載のコンピュータ可読媒体。
  15. 前記コンピュータ実行可能命令が応答メッセージを第４定足数のデバイスから受信した場合、前記提案されたコマンド構造は、前記第４定足数のデバイスからの前記応答メッセージで示される前に受け入れられたコマンド構造、または定足数の第１組のすべての基礎コマンド構造をプレフィックスとして有する共通コマンド構造のいずれかであることを特徴とする請求項１４に記載のコンピュータ可読媒体。
  16. 第１機能が既に追加されている第１コマンド構造に前記第１機能を追加することは、前記第１コマンド構造を変更しないことを特徴とする請求項１３に記載のコンピュータ可読媒体。
  17. 前記提案されたコマンド構造を送信する前記コンピュータ実行可能命令は、前に送信されたコマンド構造の識別子および１つまたは複数の機能を送信するコンピュータ実行可能命令を含み、前記前に送信されたコマンド構造に前記１つまたは複数の機能を追加するステップは、前記提案されたコマンド構造をもたらすことを特徴とする請求項１３に記載のコンピュータ可読媒体。
  18. 前記提案されたコマンド構造がチェックポイントコマンドで終わる場合、前記コンピュータ実行可能命令は、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに実行することを特徴とする請求項１３に記載のコンピュータ可読媒体。
  19. 分散コンピューティングシステムで提案されたコマンド構造を選択するコンピュータ実行可能命令を有するコンピュータ可読媒体であって、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造であり、前記コンピュータ実行可能命令は、
    要求された機能を実行する要求をクライアントから受信するステップと、
    提案されたコマンド構造を形成するために前記要求された機能を前に受け入れられたコマンド構造に追加するステップと、
    前記提案されたコマンド構造を提案番号に関連付けるステップであって、前記提案番号は、一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、関連付けるステップと、
    前に応答された提案番号は前記提案番号より大きくない場合、前記提案されたコマンド構造を受け入れるステップと、
    前記提案されたコマンド構造が受け入れられた場合、前記提案されたコマンド構造を識別する後続受け入れメッセージを送信するステップと
    を実行することを特徴とするコンピュータ可読媒体。
  20. 前記受け入れメッセージを送信する前記コンピュータ実行可能命令は、前記分散コンピューティングシステムの他のデバイスに前記受け入れメッセージを送信するコンピュータ実行可能命令を含み、前記コンピュータ実行可能命令は、
    前記分散コンピューティングシステムの他のデバイスから前記他のデバイスの受け入れメッセージを受信するステップと、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと
    をさらに実行することを特徴とする請求項１９に記載のコンピュータ可読媒体。
  21. 前記提案されたコマンド構造は選択されなかったと判定された場合、前記コンピュータ実行可能命令は、
    後続提案番号を選択するステップであって、前記後続提案番号は、前記提案番号より大きく、前記後続提案番号は、前記一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、選択するステップと、
    前記分散コンピューティングシステムの前記他のデバイスに情報メッセージを送信するステップであって、前記情報メッセージは、前記後続提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの約束として働き、前記情報メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、応答されたすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、送信するステップと、
    所定の判断基準に基づいて、他のデバイスの情報メッセージから、後続の提案されたコマンド構造を選択するステップと、
    前記後続の提案されたコマンド構造を前記後続提案番号に関連付けるステップと、
    前に応答された提案番号が前記後続提案番号より大きくない場合、前記後続の提案されたコマンド構造を受け入れるステップと、
    前記後続の提案されたコマンド構造が受け入れられた場合、前記後続の提案されたコマンド構造を識別する後続受け入れメッセージを送信するステップと
    をさらに実行することを特徴とする請求項２０に記載のコンピュータ可読媒体。
  22. 前記提案されたコマンド構造は選択されないと判定される場合、前記コンピュータ実行可能命令は、リーダーデバイスを選択するステップを実行し、前記リーダーデバイスは、前記分散コンピューティングシステム内の第１定足数のデバイスに、提議された次の提案番号を送信するステップと、前記分散コンピューティングシステム内の第２定足数のデバイスに、後続の提案されたコマンド構造を送信するステップとをさらに実行し、前記後続の提案されたコマンド構造は、所定の判断基準に基づいて、前記提議された次の提案番号の前記送信に応答して送信されたメッセージから選択され、さらに、前記後続の提案されたコマンド構造は、前記提議された次の提案番号に関連することを特徴とする請求項２０に記載のコンピュータ可読媒体。
  23. 前記受け入れメッセージの前記送信は、前記受け入れメッセージをラーナーデバイスに送信するステップを含み、前記ラーナーデバイスは、
    前記分散コンピューティングシステムの他のデバイスから前記他のデバイスの受け入れメッセージを受信するステップと、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと、
    前記提案されたコマンド構造は選択されたと判定された場合、前記要求された機能を実行するステップと、
    前記要求された機能の前記実行の結果を前記クライアントに送信するステップと
    を実行することを特徴とする請求項１９に記載のコンピュータ可読媒体。
  24. 前記ラーナーデバイスは、提案されたコマンド構造が選択されないと判定する場合、前記コンピュータ実行可能命令は、リーダーデバイスを選択するステップをさらに実行し、前記リーダーデバイスは、前記分散コンピューティングシステム内の第１定足数のデバイスに、提議された次の提案番号を送信するステップと、前記分散コンピューティングシステム内の第２定足数のデバイスに、後続の提案されたコマンド構造を送信するステップとを実行し、前記後続の提案されたコマンド構造は、所定の判断基準に基づいて、前記提議された次の提案番号の前記送信に応答して送信されたメッセージから選択され、さらに、前記後続の提案されたコマンド構造は、前記提議された次の提案番号に関連することを特徴とする請求項２３に記載のコンピュータ可読媒体。
  25. 第１機能が既に追加されている第１コマンド構造に前記第１機能を追加することは、前記第１コマンド構造を変更しないことを特徴とする請求項１９に記載のコンピュータ可読媒体。
  26. 前記提案されたコマンド構造を送信する前記コンピュータ実行可能命令は、前に送信されたコマンド構造の識別子および１つまたは複数の機能を送信するコンピュータ実行可能命令を含み、前記前に送信されたコマンド構造への前記１つまたは複数の機能の追加は、前記提案されたコマンド構造をもたらすことを特徴とする請求項１９に記載のコンピュータ可読媒体。
  27. 前記提案されたコマンド構造がチェックポイントコマンドで終わる場合、前記コンピュータ実行可能命令は、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに実行することを特徴とする請求項１９に記載のコンピュータ可読媒体。
  28. 分散コンピューティングシステム内のコンピューティングデバイスであって、
    前記分散コンピューティングシステム内の第１定足数のデバイスに提案されたコマンド構造を送信するステップであって、前記提案されたコマンド構造は、提案番号に関連し、さらに、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造である、送信するステップと、
    前記提案されたコマンド構造の受け入れを示す受け入れメッセージを受信するステップであって、受け入れるデバイスは、前記提案番号より大きい提議された提案番号に応答しておらず、かつ前記提案番号を使用して提案された前記提案されたコマンド構造のプレフィックスに前に投票した場合、または前記提案番号を使用して提案されたどのコマンド構造にも前に投票していない場合、受け入れメッセージを送信することができる、受信するステップと
    を実行するネットワークインターフェースと、
    前記受け入れメッセージは第２定足数のデバイスから受信された場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップ
    を実行する処理ユニットと
    を備えることを特徴とするコンピューティングデバイス。
  29. 前記ネットワークインターフェースは、
    前記分散コンピューティングシステム内の第３定足数のデバイスに、提議される次の提案番号を送信する追加ステップと、
    前記提議された次の提案番号より大きい提議された提案番号に前に応答していない応答デバイスから応答メッセージを受信する追加ステップであって、前記応答メッセージは、前記提議された提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの前記応答デバイスによる約束として働き、前記応答メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、前記応答デバイスによって事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、前記デバイスが応答したすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、受信する追加ステップと
    を実行することを特徴とする請求項２８に記載のコンピューティングデバイス。
  30. 応答メッセージが第４定足数のデバイスから受信された場合、前記提案されたコマンド構造は、前記第４定足数のデバイスからの前記応答メッセージで示される前に受け入れられたコマンド構造、または定足数の第１組のすべての基礎コマンド構造をプレフィックスとして有する共通コマンド構造のいずれかであることを特徴とする請求項２８に記載のコンピューティングデバイス。
  31. 前記提案されたコマンド構造がチェックポイントコマンドで終わる場合、前記ネットワークインターフェースは、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに実行することを特徴とする請求項２８に記載のコンピューティングデバイス。
  32. 分散コンピューティングシステム内のコンピューティングデバイスであって、
    要求された機能を実行する要求をクライアントから受信するステップと、
    提案されたコマンド構造を形成するために前記要求された機能を前に受け入れられたコマンド構造に追加するステップであって、コマンド構造は、機能の同等なシーケンスのすべてを表し、より大きいコマンド構造のプレフィックスは、前記より大きいコマンド構造を得るために１つまたは複数の機能を追加できるようなより小さいコマンド構造である、追加するステップと、
    前記提案されたコマンド構造が受け入れられた場合、前記提案されたコマンドを識別する受け入れメッセージを送信するステップと
    を実行するネットワークインターフェースと、
    前記提案されたコマンド構造を提案番号に関連付けるステップであって、前記提案番号は、一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、関連付けるステップと、
    前に応答された提案番号は前記提案番号より大きくない場合、前記提案されたコマンド構造を受け入れるステップと
    を実行する処理ユニットと
    を備えることを特徴とするコンピューティングデバイス。
  33. 前記受け入れメッセージの前記送信は、前記分散コンピューティングシステムの他のデバイスに前記受け入れメッセージを送信するステップを含み、前記ネットワークインターフェースは、
    前記分散コンピューティングシステムの他のデバイスから他のデバイスの受け入れメッセージを受信するステップ
    をさらに実行し、前記処理ユニットは、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップ
    をさらに実行することを特徴とする請求項３２に記載のコンピューティングデバイス。
  34. 前記提案されたコマンド構造は選択されなかったと判定された場合、前記ネットワークインターフェースは、
    前記分散コンピューティングシステムの前記他のデバイスに情報メッセージを送信するステップであって、前記情報メッセージは、後続提案番号より小さい提案番号に関連するコマンド構造を受け入れないことの約束として働き、前記情報メッセージは、（１）デバイスが受け入れた最大の提案番号であって、前記デバイスが受け入れた最大の提案番号は、事前に容認された、前に受け入れられたコマンド構造に関連するすべての他の提案番号より大きい、デバイスが受け入れた最大の提案番号、（２）前記デバイスが受け入れた最大の提案番号に関連する前に受け入れられたコマンド構造、および（３）デバイスが応答した最大の提案番号であって、前記デバイスが応答した最大の提案番号は、応答されたすべての他の提議された提案番号より大きい、デバイスが応答した最大の提案番号を含む、送信するステップと、
    前記後続の提案されたコマンド構造が受け入れられた場合、前記後続の提案されたコマンド構造を識別する後続受け入れメッセージを送信するステップと
    をさらに実行し、前記処理ユニットは、
    前記後続提案番号を選択するステップであって、前記後続提案番号は、前記提案番号より大きく、前記後続提案番号は、前記一般化された低メッセージ遅延フォールトトレラントコンセンサスアルゴリズムの使用を示す、選択するステップと、
    所定の判断基準に基づいて、他のデバイスの情報メッセージから、後続の提案されたコマンド構造を選択するステップと、
    前記後続の提案されたコマンド構造を前記後続提案番号に関連付けるステップと、
    前に応答された提案番号は前記後続提案番号より大きくない場合、前記後続の提案されたコマンド構造を受け入れるステップと
    をさらに実行することを特徴とする請求項３３に記載のコンピューティングデバイス。
  35. 前記受け入れメッセージの前記送信は、前記受け入れメッセージをラーナーデバイスに送信するステップを含み、前記ラーナーデバイスは、
    前記分散コンピューティングシステムの他のデバイスから前記他のデバイスの受け入れメッセージを受信するステップと、
    定足数の前記受信された他のデバイスの受け入れメッセージが、その前記提案されたコマンド構造がプレフィックスであるコマンド構造を識別する場合、前記提案されたコマンド構造は前記分散コンピューティングシステムによって選択されたと判定するステップと、
    前記提案されたコマンド構造が選択されたと判定された場合、前記要求された機能を実行するステップと、
    前記要求された機能の前記実行の結果を前記クライアントに送信するステップと
    を実行することを特徴とする請求項３２に記載のコンピューティングデバイス。
  36. 前記提案されたコマンド構造がチェックポイントコマンドで終わる場合、前記ネットワークインターフェースは、前記提案されたコマンド構造の前記選択について前記分散コンピューティングシステムに知らせるステップであって、その結果、各デバイスは、前記提案されたコマンド構造の構成機能の実行の後にその状態を保存し、前記提案されたコマンド構造の後に選択されたコマンド構造を保存し、前記提案されたコマンド構造を破棄することができる、知らせるステップをさらに実行することを特徴とする請求項３２に記載のコンピューティングデバイス。
  37. 機能のアレイを含むコマンド構造であって、交換可能でない前記機能の対は、機能の前記対内の各機能に関して順序付けられ、交換可能である前記機能の対は、機能のすべての同等のシーケンスを機能の前記アレイから判定することを可能にする形で示され、機能の各同等のシーケンスは、機能のシーケンスを実行するデバイスの同等の状態をもたらし、さらに、１クライアントからの１機能の複数の要求がそれぞれ異なる機能識別子を割り当てられるように、各機能に割り当てられた機能識別子によって示されるように第１機能が既に機能の前記アレイに含まれる場合、前記コマンド構造への前記第１機能の追加は前記コマンド構造を変更しないことを特徴とするコマンド構造。
JP2005338653A 2004-11-23 2005-11-24 一般化されたＰａｘｏｓ Active JP4986442B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/996,351 US7698465B2 (en) 2004-11-23 2004-11-23 Generalized Paxos
US10/996,351 2004-11-23

Publications (2)

Publication Number Publication Date
JP2006155614A true JP2006155614A (ja) 2006-06-15
JP4986442B2 JP4986442B2 (ja) 2012-07-25

Family

ID=36204309

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005338653A Active JP4986442B2 (ja) 2004-11-23 2005-11-24 一般化されたＰａｘｏｓ

Country Status (5)

Country Link
US (1) US7698465B2 (ja)
EP (1) EP1659500B1 (ja)
JP (1) JP4986442B2 (ja)
AT (1) ATE428979T1 (ja)
DE (1) DE602005013891D1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010277467A (ja) * 2009-05-29 2010-12-09 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム
WO2011096319A1 (ja) * 2010-02-04 2011-08-11 株式会社トライテック 分散コンピューティングシステム、分散コンピューティング方法及び分散コンピューティング用プログラム
JP2011253390A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム
JP2011253391A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム
JP2012033108A (ja) * 2010-08-02 2012-02-16 Trytech Co Ltd 分散コンピューティングシステムの処理方法
WO2015186191A1 (ja) * 2014-06-03 2015-12-10 株式会社日立製作所 データ管理システム及びデータ管理方法
WO2016067426A1 (ja) * 2014-10-30 2016-05-06 株式会社日立製作所 分散コンピューティングシステム及び分散処理方法

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7620680B1 (en) * 2002-08-15 2009-11-17 Microsoft Corporation Fast byzantine paxos
US7856502B2 (en) * 2004-06-18 2010-12-21 Microsoft Corporation Cheap paxos
US7849223B2 (en) * 2007-12-07 2010-12-07 Microsoft Corporation Virtually synchronous Paxos
US20110178984A1 (en) * 2010-01-18 2011-07-21 Microsoft Corporation Replication protocol for database systems
US8825601B2 (en) 2010-02-01 2014-09-02 Microsoft Corporation Logical data backup and rollback using incremental capture in a distributed database
US8719432B1 (en) 2010-04-30 2014-05-06 Amazon Technologies, Inc. System and method for determining staleness of data received from a distributed lock manager
US8654650B1 (en) 2010-04-30 2014-02-18 Amazon Technologies, Inc. System and method for determining node staleness in a distributed system
US8458517B1 (en) 2010-04-30 2013-06-04 Amazon Technologies, Inc. System and method for checkpointing state in a distributed system
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
US8694639B1 (en) 2010-09-21 2014-04-08 Amazon Technologies, Inc. Determining maximum amount of resource allowed to be allocated to client in distributed system
US8589479B2 (en) 2010-11-22 2013-11-19 Infosys Limited Distributed registry for device discovery using quorum consensus protocol
US8694647B2 (en) * 2011-03-18 2014-04-08 Microsoft Corporation Read-only operations processing in a paxos replication system
US9201742B2 (en) * 2011-04-26 2015-12-01 Brian J. Bulkowski Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm
US9203900B2 (en) 2011-09-23 2015-12-01 Netapp, Inc. Storage area network attached clustered storage system
US8683170B1 (en) 2011-09-23 2014-03-25 Netapp, Inc. Consistent distributed storage communication protocol semantics in a clustered storage system
US8849995B1 (en) * 2011-09-30 2014-09-30 Amazon Technologies, Inc. Managing host computing devices
US9690679B2 (en) 2011-10-31 2017-06-27 Hewlett Packard Enterprise Development Lp Transaction commitment and replication in a storage system
US9456053B2 (en) 2011-12-14 2016-09-27 Level 3 Communications, Llc Content delivery network
US9172670B1 (en) * 2012-01-31 2015-10-27 Google Inc. Disaster-proof event data processing
US10754710B1 (en) 2012-06-20 2020-08-25 Amazon Technologies, Inc. Transactional watch mechanism
US10630566B1 (en) 2012-06-20 2020-04-21 Amazon Technologies, Inc. Tightly-coupled external cluster monitoring
US9578130B1 (en) 2012-06-20 2017-02-21 Amazon Technologies, Inc. Asynchronous and idempotent distributed lock interfaces
US10191959B1 (en) 2012-06-20 2019-01-29 Amazon Technologies, Inc. Versioned read-only snapshots of shared state in distributed computing environments
US9342358B2 (en) 2012-09-14 2016-05-17 General Electric Company System and method for synchronizing processor instruction execution
US9256426B2 (en) 2012-09-14 2016-02-09 General Electric Company Controlling total number of instructions executed to a desired number after iterations of monitoring for successively less number of instructions until a predetermined time period elapse
US9063721B2 (en) 2012-09-14 2015-06-23 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9632828B1 (en) 2012-09-24 2017-04-25 Amazon Technologies, Inc. Computing and tracking client staleness using transaction responses
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
CN103914313B (zh) * 2012-12-31 2017-06-27 北京新媒传信科技有限公司 一种paxos实例更新方法、设备及系统
US9171019B1 (en) 2013-02-19 2015-10-27 Amazon Technologies, Inc. Distributed lock service with external lock information database
US9553951B1 (en) 2013-04-24 2017-01-24 Amazon Technologies, Inc. Semaphores in distributed computing environments
WO2015172107A1 (en) 2014-05-09 2015-11-12 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US9760529B1 (en) 2014-09-17 2017-09-12 Amazon Technologies, Inc. Distributed state manager bootstrapping
CN105763519A (zh) * 2014-12-18 2016-07-13 华为技术有限公司 一种一致性控制方法，装置及系统
US9852221B1 (en) 2015-03-26 2017-12-26 Amazon Technologies, Inc. Distributed state manager jury selection
GB2554250B (en) 2015-07-02 2021-09-01 Google Llc Distributed storage system with replica location selection
US10083217B2 (en) * 2015-11-26 2018-09-25 International Business Machines Corporation Method and system for upgrading a set of replicated state machine processes
EP3193256B1 (en) * 2016-01-12 2018-08-01 Politechnika Poznanska A fault-tolerant data processing computer system and method for implementing a distributed two-tier state machine
US11218418B2 (en) 2016-05-20 2022-01-04 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
CN106357604B (zh) * 2016-08-18 2019-07-23 苏州超块链信息科技有限公司 一种一致性数据累积协同组装方法
CN108924240B (zh) * 2018-07-19 2022-08-12 腾讯科技（深圳）有限公司 基于一致性协议的分布式处理方法、装置及存储介质
US11194680B2 (en) 2018-07-20 2021-12-07 Nutanix, Inc. Two node clusters recovery on a failure
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up
CN115835368B (zh) * 2023-02-24 2023-06-02 深圳锦沃科技有限公司 一种去中心化的多基站时间槽同步方法、系统及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261085A (en) * 1989-06-23 1993-11-09 Digital Equipment Corporation Fault-tolerant system and method for implementing a distributed state machine
JP2005502957A (ja) * 2001-09-06 2005-01-27 ビーイーエイ　システムズ，　インコーポレイテッド 厳密に一回のキャッシュフレームワーク
JP2005196763A (ja) * 2003-12-30 2005-07-21 Microsoft Corp 簡略化されたｐａｘｏｓ
JP2006004434A (ja) * 2004-06-18 2006-01-05 Microsoft Corp 分散障害許容型コンピューティングシステムにおける効率のよいレプリカセットの変更
JP2006004433A (ja) * 2004-06-18 2006-01-05 Microsoft Corp Ｃｈｅａｐｐａｘｏｓ

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6226710B1 (en) * 1997-11-14 2001-05-01 Utmc Microelectronic Systems Inc. Content addressable memory (CAM) engine
US6470346B2 (en) * 1998-10-07 2002-10-22 Millennium Pharmaceuticals, Inc. Remote computation framework
US6779112B1 (en) * 1999-11-05 2004-08-17 Microsoft Corporation Integrated circuit devices with steganographic authentication, and steganographic authentication methods
US6671821B1 (en) 1999-11-22 2003-12-30 Massachusetts Institute Of Technology Byzantine fault tolerance
US6691171B1 (en) * 2002-02-01 2004-02-10 Micrel, Inc. Method and system for address lookup in data communication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261085A (en) * 1989-06-23 1993-11-09 Digital Equipment Corporation Fault-tolerant system and method for implementing a distributed state machine
JP2005502957A (ja) * 2001-09-06 2005-01-27 ビーイーエイ　システムズ，　インコーポレイテッド 厳密に一回のキャッシュフレームワーク
JP2005196763A (ja) * 2003-12-30 2005-07-21 Microsoft Corp 簡略化されたｐａｘｏｓ
JP2006004434A (ja) * 2004-06-18 2006-01-05 Microsoft Corp 分散障害許容型コンピューティングシステムにおける効率のよいレプリカセットの変更
JP2006004433A (ja) * 2004-06-18 2006-01-05 Microsoft Corp Ｃｈｅａｐｐａｘｏｓ

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010277467A (ja) * 2009-05-29 2010-12-09 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム
WO2011096319A1 (ja) * 2010-02-04 2011-08-11 株式会社トライテック 分散コンピューティングシステム、分散コンピューティング方法及び分散コンピューティング用プログラム
US8775500B2 (en) 2010-02-04 2014-07-08 Tritech Inc. Distributed computing system having leader signaled agents to execute task after data acquisition completion
JP2011253390A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム
JP2011253391A (ja) * 2010-06-02 2011-12-15 Trytech Co Ltd 分散コンピューティングシステム
JP2012033108A (ja) * 2010-08-02 2012-02-16 Trytech Co Ltd 分散コンピューティングシステムの処理方法
US8745126B2 (en) 2010-08-02 2014-06-03 Tribeth Inc. Method of processing distributed computing system
WO2015186191A1 (ja) * 2014-06-03 2015-12-10 株式会社日立製作所 データ管理システム及びデータ管理方法
JPWO2015186191A1 (ja) * 2014-06-03 2017-04-20 株式会社日立製作所 データ管理システム及びデータ管理方法
WO2016067426A1 (ja) * 2014-10-30 2016-05-06 株式会社日立製作所 分散コンピューティングシステム及び分散処理方法
US10489340B2 (en) 2014-10-30 2019-11-26 Hitachi, Ltd. Distributed computing system and distributed processing method

Also Published As

Publication number Publication date
EP1659500B1 (en) 2009-04-15
DE602005013891D1 (de) 2009-05-28
EP1659500A2 (en) 2006-05-24
JP4986442B2 (ja) 2012-07-25
US20060136781A1 (en) 2006-06-22
ATE428979T1 (de) 2009-05-15
US7698465B2 (en) 2010-04-13
EP1659500A3 (en) 2007-08-01

Similar Documents

Publication Publication Date Title
JP4986442B2 (ja) 一般化されたＰａｘｏｓ
US7249280B2 (en) Cheap paxos
US7555516B2 (en) Fast Paxos recovery
JP4976661B2 (ja) Ｃｈｅａｐｐａｘｏｓ
US7558883B1 (en) Fast transaction commit
US7711825B2 (en) Simplified Paxos
US8005888B2 (en) Conflict fast consensus
EP1617331B1 (en) Efficient changing of replica sets in distributed fault-tolerant computing system
Lamport et al. Cheap paxos
EP2434729A2 (en) Method for providing access to data items from a distributed storage system
EP3694148A1 (en) Configuration modification method for storage cluster, storage cluster and computer system
Aguilera et al. Reconfiguring replicated atomic storage: A tutorial
JP5900094B2 (ja) データ整合システム、データ整合方法およびデータ整合プログラム
Liskov From viewstamped replication to Byzantine fault tolerance
JP5342395B2 (ja) 計算機システムおよびその方法
Vieira et al. Seamless paxos coordinators
CN112702206A (zh) 一种主备集群部署方法及系统
Snyder et al. Robustness infrastructure for multi-agent systems
Nath Fault tolerance of the application manager in Vigne
Kemme et al. Self-Configuration and Elasticity
Turner Unbounded Pipelining in Dynamically Reconfigurable Paxos Clusters

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081112

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110624

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110906

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111206

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111227

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120327

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120417

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120424

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4986442

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150511

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250