JP2005196763A - 簡略化されたｐａｘｏｓ - Google Patents

Abstract

【課題】 故障を許容する形で分散コンピュータシステムを運用するフォールトトレラントな簡略化アルゴリズム。
【解決手段】 ３つのコンピュータデバイスを備えるシステムは、任意の提案機能を行うのに２つのデバイスが同意するだけでよい。そのため、提案機能への投票を求める際に、リーダデバイスはその提案機能に対する自身の投票も送信できる。これにより、受信デバイスはそれ自身の投票で定足数を満たせるようになる。結果、受信デバイスは、さらなるメッセージなしでその提案機能を実行すべきかどうかを決定できる。さらに、デバイスは、提案機能を実行する場合に機能を要求したクライアントにその結果を直接送信でき、メッセージ遅延を省くことができる。提案機能を選択し実行するのに使われるデバイスの定足数がそれ自体ある定足数で選択される場合、システムのデバイスの１つは限定された計算能力または記憶容量をもつ安価なデバイスとすることができる。
【選択図】 図８ａ

Description

本発明は、一般に、分散コンピューティングに関し、より詳細には、少数のコンピューティングデバイスを用いた効率的なフォールトトレラント（ｆａｕｌｔ ｔｏｌｅｒａｎｔ）な分散コンピューティングに関する。

ストレージ空間およびプロセシング機能の増大を含め、パーソナルコンピューティングデバイスがより強力になるにつれ、平均的なユーザが毎日のタスクを行う上でこれらの資源を消費する割合がますます小さくなりつつある。そのため、今日のパーソナルコンピューティングデバイスの多くは、それらのコンピューティング能力がほとんどのユーザのそれらに対する要求よりも大きく上回っているため、十分にそれらの潜在能力が使用されていないことが多い。強力な最新のパーソナルコンピューティングデバイスの未使用資源から利用法や価値を引き出す次第に人気を得つつある方法として、分散コンピューティングシステムがある。分散コンピューティングシステムでは、コンピューティングデバイスが互いに協調して行動することによって、データおよびコンピュータ計算資源へのより信頼できるアクセスを提供する。

余剰なコンピューティング能力を使用するための有益なメカニズムを提供することに加え、分散システムはまた、より大規模でより高価なコンピューティングデバイスのパフォーマンスおよびストレージ能力を達成するために、専用の安価なコンピューティングデバイスで構成することができる。分散システムのさらなる利点は、単一のより大規模なコンピューティングデバイスであれば動作不能になってしまうような物理的困難に直面しても動作し続ける能力があることである。このような困難には、電源異常の持続、荒天、浸水、テロ活動などが含まれる。

個々のメンバであるコンピューティングデバイスが、ネットワークから切断されたり、スイッチが切られたり、システム誤動作が生じたり、あるいはその他の理由で使用不能になる高いリスクを補償するために、冗長性を用いることによって、分散コンピューティングシステムが動作可能であり続けるようにすることができる。そのため、いずれか１つのパーソナルコンピューティングデバイス上に格納されている情報は、少なくとも１つのさらなるパーソナルコンピューティングデバイス上に重複して格納することができ、それによって、それらのパーソナルコンピューティングデバイスの１つが故障しても、その情報にはそれまで通りアクセスすることができる。

分散コンピューティングシステムは、完全な冗長性を実施することができ、その場合、システム内のあらゆるデバイスが同一のタスクを行い、同一の情報を格納する。このようなシステムによって、デバイスが１つを除いてすべて故障した場合でも、ユーザが有用な操作を実行し続けることができるようにする。あるいは、このようなシステムを使用して、同じ情報の複数のコピーを、ある地域全体に分散することができる。例えば、多国籍企業は、世界規模の分散コンピューティングシステムを確立することができる。

しかし、分散コンピューティングシステムは、システムを構成する個々のデバイスを正しく同期させることの複雑さのために、維持することが難しいことがある。個々のプロセスにわたるタイムキーピングは良くても困難であるため、状態マシンアプローチを使用して個々のデバイス間のアクティビティを調整することが多い。状態マシンは、１組の状態、１組のコマンド、１組の応答、および、各応答／状態ペアを各コマンド／状態ペアにリンクするクライアントコマンドによって記述することができる。状態マシンは、その状態を変更し、応答を生成することによってコマンドを実行することができる。そのため、状態マシンを、その現在の状態およびそれが行おうとしているアクションによって完全に記述することができ、それによって、正確なタイムキーピングを用いる必要をなくしている。

状態マシンの現在の状態は、それゆえ、以前の状態、それ以降に実行されたコマンド、およびそれらのコマンドが実行された順番に依存する。２つまたはそれ以上の状態マシンの間の同期を維持するために、共通の初期状態を確立することができ、各状態マシンは、初期状態から開始して、同一のコマンドを同一の順番で実行することができる。それゆえ、ある状態マシンを別の状態マシンに同期させるためには、その別の状態マシンによって実行されるコマンドの判定を行う必要がある。同期の問題は、それゆえ、実行されるコマンドの順番を判定する問題、より具体的には、ある与えられたステップに対して実行する特定のコマンドを判定する問題になる。

与えられたステップに対してどのコマンドが実行されるべきかを判定するための１つのメカニズムは、Ｐａｘｏｓアルゴリズムとして知られている。Ｐａｘｏｓアルゴリズムでは、個々のデバイスのいずれかがリーダとして働き、ある与えられたコマンドをシステム内のあらゆるデバイスによる実行のために提案しようとすることができる。あらゆるこのような提案は、それらの提案をより容易に追跡できるように、提案番号と共に送ることができる。このような提案番号は、それらのデバイスが実行すべきコマンドに同意しようと試みているその特定のステップに対し、いかなる関係も持っている必要はない。最初に、リーダは、自分が提出するつもりの提案に対する提案番号を示唆することができる。残りのデバイスのそれぞれは、次に、自分が投票（ｖｏｔｅ）した最後の提案の指示、またはどの提案にも投票してないことの指示と共に、リーダの提案番号の示唆に対して応答することができる。リーダは、様々な応答を通して、それらのデバイスによって投票された何らかの他の提案がないとわかると、前のメッセージで示唆した提案番号を用いて、与えられたクライアントコマンドがそれらのデバイスによって実行されるべきであることを提案することができる。各デバイスは、その段階で、そのアクションに投票するか、またはそれを拒否するかを判断することができる。デバイスは、別のリーダによる異なる提案番号の示唆に応答している場合にのみ、アクションを拒否するべきである。定足数（ｑｕｏｒｕｍ）として知られる十分な数のデバイスがその提案に投票した場合、その提案されたアクションは同意されたということで、各デバイスは、そのアクションを行い、その結果を送信することができる。このようにして、デバイスのそれぞれは、アクションを同じ順番で行い、それによって、すべてのデバイスの間で同じ状態を維持することができる。

一般に、Ｐａｘｏｓアルゴリズムは、上記のように、デバイスによって投票された前の提案をリーダが知ることができるようにする最初のフェーズと、リーダが実行のためのクライアントコマンドを提案することができる第２のフェーズの２つのフェーズで考えることができる。リーダは、前の提案について知ると、第１のフェーズを頻繁に繰り返す必要はない。代わりに、リーダは第２のフェーズを頻繁に繰り返し、分散コンピューティングシステムにより複数のステップで実行することができる一連のクライアントコマンドを提案することができる。このようにして、各ステップについて分散コンピューティングシステムによって行われる各クライアントコマンドを、Ｐａｘｏｓアルゴリズムの１つのインスタンスと考えることができるが、リーダは、所与のステップについてデバイスが提案されたクライアントコマンドに投票するまで、次のステップについて別のクライアントコマンドを提案するのを待つ必要はない。

全体としての分散コンピューティングシステムは、状態マシンとしてモデル化することができる。そのため、完全な冗長性を実装する分散コンピューティングシステムは、デバイスのそれぞれに全体のシステムの状態を複製させることができる。このようなシステムは、各デバイスが同じ状態を維持することを要求する。いくつかのデバイスが、あるクライアントコマンドが実行されたと信じ、デバイスの第２のグループが、異なるクライアントコマンドが実行されたと信じた場合、全体のシステムはもはや単一の状態マシンとして動作しなくなる。このような状況を回避するため、過半数のデバイスは、システムによる実行のための提案されたクライアントコマンドを選択するよう一般に要求されることがある。それぞれが過半数を有する、任意の２つのデバイスグループは、少なくとも１つのデバイスを共有しているはずなので、その少なくとも１つの共通のデバイスに依拠するＰａｘｏｓアルゴリズムなどのメカニズムを実装することによって、それぞれが過半数を含む２つのグループが異なる提案クライアントコマンドを選択するのを防ぐことができる。

The article "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 paper entitled "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

しかし、Ｐａｘｏｓアルゴリズムは、クライアントが分散システムに対するコマンド実行の要求を送信する時点と、そのクライアントがそのコマンドの実行による結果を受信する時点との間にメッセージ遅延を付加する。具体的には、たとえクライアントがリーダに要求を送信しても、また、たとえリーダが提案に関して以前の投票についてすでに知っていて、そのため、Ｐａｘｏｓアルゴリズムの第１フェーズを完了していたとしても、クライアントからの要求の送信と、そのクライアントへの結果の送信の間には依然として２つまたはそれ以上のメッセージ遅延が生じることがある。

それゆえ、本発明の一実施形態では、より少数のデバイスを有するフォールトトレラントなシステムが、より効率的なＰａｘｏｓアルゴリズムを実装することができ、また、クライアントからの要求の送信とクライアントへの結果の送信との間に多くても単一のメッセージ遅延しか生じさせない。

別の実施形態では、より効率的なＰａｘｏｓアルゴリズムが提示され、この場合、リーダが２種類の第２フェーズのメッセージを一緒に送ることができ、受信側コンピューティングデバイスは、追加のメッセージ遅延を生じさせることなく、その要求の実行の結果を判定することができる。

さらなる実施形態では、リーダのコンピューティングデバイスは結果を知らされる者である必要がなく、分散コンピューティングシステム中のその他のコンピューティングデバイスは、実行されたコマンドの結果をより素早く知ることができる。さらに、このより効率的なＰａｘｏｓアルゴリズムの実行に参加していないコンピューティングデバイスも、クライアントコンピューティングデバイスと同様に、結果を知らされる者になることができる。

さらに別の実施形態では、このより効率的なＰａｘｏｓアルゴリズムの実行に参加しているコンピューティングデバイスの少なくとも１つのコンピューティングデバイスが安価なコンピューティングデバイスとすることができ、可能性として限定されたコンピューティング機能およびメモリストレージ機能を有するものであってよい。

本明細書の記述は、主として分散コンピューティングシステム中のコンピューティングデバイスの動作に焦点を当てているが、この記述は、別個のプロセッサ上または別個のメモリ空間内など、単一のコンピューティングデバイス上で稼働しているプロセスにも等しく適用できることが理解されよう。そのため、さらなる実施形態は、複数のプロセッサ環境においてより効率的なＰａｘｏｓアルゴリズムの動作を含み、複数のプロセッサが物理的に１つまたは複数のコンピューティングデバイスに位置しているか、また複数バーチャルマシン環境では、複数のバーチャルマシンが１つまたは複数のコンピューティングデバイスによって実行されているかどうかを問わない。本発明のさらなる特徴および利点は、添付の図面を参照しながら説明する以下の例示的実施形態の詳細な説明から明らかとなるであろう。

添付の特許請求の範囲は、本発明の特徴を詳細に定めているが、本発明、およびその目的と利点は、添付の図面と共に以下の詳細な説明から最もよく理解できる。

分散コンピューティングシステムは、いくつかの個々のパーソナルコンピューティングデバイス、サーバコンピューティングデバイス、またはシステムに参加するのに十分なプロセッサおよびストレージ能力を有するその他のデバイスを含むことができる。分散コンピューティングシステムは、それを構成するコンピューティングデバイスの能力をまとめることによって、大きく増大したプロセッシング能力およびストレージ空間を提供することができ、または冗長性を実装して、複数のデバイスが同じ情報にアクセスすることができるようにする。そのため、分散コンピューティングシステムの一般的な利用法の１つは、共通のネットワークに付加された多くの異なるパーソナルコンピューティングデバイスの未使用のプロセッシング能力およびストレージ空間をまとめることである。このような分散コンピューティングシステムは、どのデバイスが現在システムの一部であるか、どのデバイス上にある所与の１組の情報が格納されているかなど、システムに関する情報を維持することができる。この情報は、デバイスがそれらの機能およびストレージ空間をまとめるために必要な場合があり、結果として、各デバイスがコピーを含むことがある。システムのデバイス間での情報の同期化は、以下に説明する状態マシンアプローチによって促進することができる。

あるいは、分散コンピューティングシステムのますます共通になりつつある利用法は、様々な形態の情報に対するセントラルストレージリポジトリとして機能することができるネットワークサーバについてのものである。このような分散システムは、セントラルストアとの通信を求めるあらゆるクライアントが、通信すべき、都合の良い効率的なデバイスを見つけることができるように、その分散システムを構成するデバイスのすべてにセントラルストアを複製しようとする。さらに、システムの分散されているという性質上、停電、浸水、政情不安などの地域的な出来事は、少数のコンピューティングデバイスに影響するだけであり、全体のシステムは正しく動作し、また情報およびその他のサービスへのアクセスをクライアントに提供し続けることができる。

このような分散コンピューティングシステムは、状態マシンと考えることができ、このマシンの将来の状態は、現在の状態および取るべきアクションによって規定される。そのため、この分散コンピューティングシステムを各構成デバイスは、全体のシステムの状態マシンを独立して実行することができる。この状態マシンアプローチは、非同期に実施することができる。したがって、構成デバイスにわたる正確な共時性（ｓｙｎｃｈｒｏｎｙ）を維持する必要がなく、また、デバイス間の同期化は、すべてのデバイスに初期状態を設定し、その後、同じ機能を同じ順番で実行することによって達成することができる。同期化を維持するための一般的な方法は、分散コンピューティングシステムの構成デバイスが、次の機能を実行する前にその機能に同意できるようにし、実行された機能のリストを維持することである。このようにして、あらゆるデバイスは同じ状態を有することができ、また、１つのデバイスが故障しても、そのデバイスが実行した最後の機能を判定し、その最後の機能以降に同意された機能をリストから識別し、それらの機能を実行するだけでよい。

サーバとして機能する分散コンピューティングシステムは、特に、多国籍企業のセントラルデータベースや人気のあるワールドワイドウェブサイトなど、大量の情報を多様なセットのクライアントにサービスする場合に役立つ。このような状況においては、多数のクライアントは、サーバとして機能している分散コンピューティングシステムからの情報を要求することができる。複数のデバイスにわたってサーバ機能を実装することにより、より多くのクライアントにパラレルにサービスすることができ、それによって、全体的なシステムのスループットが向上する。また、全体としてのサーバは、増大した冗長性のためにはるかに故障しにくくなる。

構成コンピューティングデバイスが実行すべき次の機能に同意することができるメカニズムの１つが、Ｐａｘｏｓアルゴリズムとして知られている。Ｐａｘｏｓアルゴリズムでは、以下にさらに説明するように、任意のデバイスがリーダとして働き、分散コンピューティングシステム内のその他のデバイスに提案番号の示唆を送信することができる。その他のデバイスは、そのデバイスがすでに投票した最大の提案番号を有する提案の指示か、またはそのデバイスが以前のどの提案にも投票していないことの指示のいずれかで応答することができる。リーダは、その他のデバイスから応答を受け取ると、どの機能を提案すべきかを判断し、提案した機能に対する投票を要求することができる。各デバイスは、その提案の最初の送信後で、要求された投票の前のいずれかの時点において、より大きい提案番号の提示に対して応答していない限り、その提案に投票することになる。定足数のデバイスがその提案に投票した場合、その提案が受諾され、リーダは、そのすべてのデバイスに、同意された機能を実行することを要求するメッセージを送信することができる。

しかし、Ｐａｘｏｓアルゴリズムは、クライアントの要求の受信とクライアントへの結果の送信との間に一連のメッセージ遅延を生じさせる。具体的には、クライアントの要求を受信した時点において、Ｐａｘｏｓアルゴリズムの第１フェーズが以前に完了していて、リーダには使用すべき適切な提案番号がわかっていると想定すると、リーダは、適切な提案番号を使って、Ｐａｘｏｓアルゴリズムを実行するその他のデバイスに投票の要求を送ることができる。このステップは１つのメッセージ遅延を生じさせる可能性がある。その後、Ｐａｘｏｓアルゴリズムを実行するその他のデバイスは、リーダに投票を返すことができるが、これは第２のメッセージ遅延を生じさせる可能性がある。リーダは、定足数のデバイスから投票を受け取ると、それらのデバイスにクライアントの要求を実行するよう命令することができる。同時に、リーダ自身もクライアントの要求を実行することができ、その結果をクライアントに返すことができる。そのため、クライアントとリーダの間の送信を勘定しなくても、Ｐａｘｏｓアルゴリズムは、クライアントの要求と応答の間の２つまたはそれ以上のメッセージ遅延を生じさせる可能性がある。

以下に詳細に示すように、十分に少数の構成コンピューティングデバイスを有する分散コンピューティング環境においてメッセージを組み合わせることによって、クライアントの要求とクライアントへの応答の間の少なくとも１つのメッセージ遅延を取り除くことができる。

（分散コンピューティング環境）
同様の参照番号が同様の構成要素を指す図面を見ると、本発明が、図１に示す例示的な分散コンピューティングシステム１０などの分散コンピューティングシステムに実施されているものとして示されている。わかりやすくするために、図１に示すように、すべて相互に接続されているコンピューティングデバイス１１〜１３を備える分散コンピューティングシステム１０を参照しながら本発明を説明する。当業者であれば理解されるように、本発明は、すべての分散コンピューティング環境に適用可能であり、提示の目的で簡略化した図１の例示的な分散コンピューティングシステムによってどのような形であれ限定されることを意図したものではない。

図１はまた、単一のクライアントコンピューティングデバイス２０を示している。ただし、本発明は、任意の数のクライアントコンピューティングデバイスを有する環境において動作するよう意図されたものである。クライアントコンピューティングデバイス２０は、分散コンピューティングシステム１０への汎用の通信接続を有するものとして示されている。当業者であれば知っているように、このような通信接続は、任意の通信媒体およびプロトコルを使用することができ、また、クライアントコンピューティングデバイス２０が分散コンピューティングシステム１０の中の１つまたは複数のコンピューティングデバイスと通信することを可能にすることができる。

さらに、図１は、分散コンピューティングシステム１０の一部としては示されていないが、システム１０に対する一般的な通信接続を維持しているコンピューティングデバイス３０および３１を示している。上記のように、その通信接続は任意の通信媒体およびプロトコルを使用することができ、また、コンピューティングデバイス３０および３１が分散コンピューティングシステム１０の中の１つまたは複数のコンピューティングデバイスと通信することを可能にすることができる。以下にさらに詳説するように、コンピューティングデバイス３０および３１は、システム１０の一部ではなくても、システム１０によって行われた実行の結果を知ることができる。

必ずしも必要ではないが、本発明を、コンピューティングデバイスによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的な文脈で説明する。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、当業者は、本発明がハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む、多くの様々なコンピューティングデバイスで実施できることを理解するであろう。上述のように、本発明はまた、タスクが通信ネットワークを介してリンクされたリモート処理デバイスによって実行される、分散コンピューティングシステム１０などの分散コンピューティング環境においても実施することができる。分散コンピューティング環境では、プログラムモジュールはローカルおよびリモートのメモリ記憶デバイスの両方に配置することができる。

図２を見ると、本発明を実施することができる例示的なコンピューティングデバイス１００が示されている。コンピューティングデバイス１００は、適切なコンピューティングデバイスの一例にすぎず、本発明の使用または機能の範囲に関して何ら限定を示唆することを意図したものではない。例えば、例示的コンピューティングデバイス１００は、図１に示すコンピューティングデバイス１１〜１３、２０、または３０〜３１のいずれかを厳密に表すことを意図したものではない。例示的コンピューティングデバイス１００は、メモリパーティション、バーチャルマシン、複数のプロセッサ、または１つの物理的コンピューティング構造が以下に記載のアクションを複数のコンピューティングデバイスによるものとして行うことができるようにする同様のプログラミング技術を通じて、これらのコンピューティングデバイスの１つまたは複数を実装することができる。さらに、コンピューティングデバイス１００は、図２に示す周辺機器のいずれか１つまたは組合せに関するいかなる依存性または要件を有するものと解釈されるべきではない。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的な文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。分散コンピューティング環境では、タスクは、通信ネットワークを介してリンクされているリモート処理デバイスによって実行することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含む、ローカルおよびリモートのコンピュータ記憶媒体の両方に配置することができる。

コンピューティングデバイス１００のコンポーネントには、処理装置１２０、システムメモリ１３０、そしてシステムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１が含まれるが、それらに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、そして様々なバスアーキテクチャのいずれかを使用したローカルバスを含む、いくつかのタイプのバス構造のうちのいずれであってもよい。例として、限定ではなく、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。さらに、処理装置１２０は、１つまたは複数の物理プロセッサを含むことがある。

コンピュータ１００は、一般に、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピューティングデバイス１００によってアクセスできる任意の利用可能な媒体とすることができ、揮発性および不揮発性の両媒体、リムーバブルおよび非リムーバブルな両媒体を含む。例として、限定ではなく、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報のストレージのための、任意の方法または技術で実装された、揮発性および不揮発性、リムーバブルおよび非リムーバブルの両媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくはその他の光ディスクストレージデバイス、磁気カセット、磁気テープ、磁気ディスクストレージデバイスもしくはその他の磁気ストレージデバイス、または所望の情報を格納するために使用することができ、コンピューティングデバイス１００によってアクセスできる任意のその他の媒体が含まれるが、それらに限定されない。通信媒体は、一般に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他のトランスポートメカニズムなどの変調データ信号に具体化し、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号中に情報を符号化するように信号の特性の１つまたは複数を設定または変更した信号を意味する。例として、限定ではなく、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線およびその他の無線媒体などの無線媒体が含まれる。上記のいずれの組み合わせもコンピュータ可読媒体の範囲内に含まれるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１、ランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間の情報の転送を助ける基本ルーチンが入っている基本入出力システム（ＢＩＯＳ）１３３は、通常、ＲＯＭ１３１に格納されている。ＲＡＭ１３２は、通常、処理装置１２０によって直ぐにアクセス可能であり、そして／または現在操作中のデータおよび／またはプログラムモジュールを収容している。例として、限定ではなく、図２は、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６およびプログラムデータ１３７を図示している。

コンピューティングデバイス１００はまた、その他のリムーバブル／非リムーバブルな揮発性／不揮発性コンピュータ記憶媒体も含むことができる。例にすぎないが、図２には、非リムーバブルな不揮発性磁気媒体との間で読取りまたは書込みを行うハードディスクドライブ１４１、リムーバブルな不揮発性磁気ディスク１５２との間で読取りまたは書込みを行う磁気ディスクドライブ１５１、およびＣＤ−ＲＯＭまたはその他の光媒体などのリムーバブルな不揮発性光ディスク１５６との間で読取りまたは書込みを行う光ディスクドライブ１５５を示している。この例示的な動作環境で使用できるその他のリムーバブル／非リムーバブルな、揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれるが、それらに限定されない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの非リムーバブルなメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などのリムーバブルなメモリインターフェースによってシステムバス１２１に接続されている。

上記に説明し、図２に示したドライブおよび関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータのストレージをコンピューティングデバイス１００に提供する。図２では、例えば、ハードディスクドライブ１４１を、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７を格納するものとして示している。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６およびプログラムデータ１３７と同じであっても、または異なっていてもよいことに注意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６およびプログラムデータ１４７には、少なくともそれらが異なるコピーであることを示すために、ここでは異なる番号を付している。ユーザは、キーボード１６２、および一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介して、コンピューティングデバイス１００にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどが含まれ得る。これらおよびその他の入力デバイスは、システムバスに結合されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインターフェースおよびバス構造によって接続することもできる。モニタ１９１またはその他のタイプの表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６などのその他の周辺出力デバイスを含むことができ、それらは、出力周辺インターフェース１９５を介して接続することができる。

コンピューティングデバイス１００は、１つまたは複数のリモートコンピュータへの論理接続を使って、図１に示すようなネットワーク化された環境で動作することができる。図２は、リモートコンピューティングデバイス１８０への一般のネットワーク接続１７１を示している。一般のネットワーク接続１７１および図１に示したネットワーク接続は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ワイヤレスネットワーク、イーサネット（登録商標）プロトコルやトークンリングプロトコルに準拠するネットワーク、またはインターネットやワールドワイドウェブを含むその他の論理、物理もしくはワイヤレスネットワークを含む、様々な異なるタイプのネットワークおよびネットワーク接続のいずれであってもよい。

ネットワーキング環境において使用する場合、コンピューティングデバイス１００は、ネットワークインターフェースまたはアダプタ１７０を介して一般のネットワーク接続１７１に接続されている。このインターフェースまたはアダプタは、有線またはワイヤレスのネットワークインターフェースカード、モデムまたは同様のネットワーキングデバイスとすることができる。ネットワーク化環境においては、コンピューティングデバイス１００に関して説明したプログラムモジュールまたはその一部は、リモートのメモリストレージデバイスに格納することができる。図示したネットワーク接続は例示にすぎず、コンピュータ間の通信リンクを確立するためのその他の手段を用いることができることを理解されよう。

以下の説明では、別途記載がない限り、本発明を、１つまたは複数のコンピューティングデバイスによって実行されるアクト（ａｃｔ）および動作（ｏｐｅｒａｔｉｏｎ）の記号表現に関連して説明する。このように、時にコンピュータ実行されているものとして参照されるこのようなアクトおよび動作には、構造化された形態でデータを表す電気信号のコンピューティングデバイスの処理装置による操作が含まれることを理解されるであろう。この操作は、データを変換し、またはデータをコンピューティングデバイスのメモリシステム中のロケーションに維持し、それによって、当業者によく知られたやり方で、コンピューティングデバイスの動作を再構成またはその他の方法で変更する。データが維持されるデータ構造は、そのデータのフォーマットによって定義された特定のプロパティを有するメモリの物理的ロケーションである。しかし、本発明を前述の状況で説明しているが、当業者であれば、以下に記載の様々なアクトおよび動作もハードウェアに実装できることを理解するであろうように、限定することを意味するものではない。

（概観）
本発明によれば、リーダがＰａｘｏｓアルゴリズムの第１フェーズを完了した後、またはその他現在のステップについて正しい提案番号を確立した後、リーダは投票のためにクライアントの要求を提出することができる。クライアントの要求の実行に関する投票を要求するメッセージとともに、リーダは、その要求の実行に関する自分自身の投票を送ることもできる。３つのコンピューティングデバイスを有する分散コンピューティングシステムでは、それらのデバイスのいずれか２つが過半数であり、システムのデバイスの過半数未満しか故障しない限り、分散システムの正しい動作が維持されるのに十分な定足数となり得る。２つのデバイスが定足数を構成することができるので、任意の他のデバイスが、投票に対するリーダの要求をリーダの投票とともに受け取った場合に、そのデバイスもクライアントの要求の実行に投票することになるならば、リーダとその他のデバイスを含む定足数が存在することになるであろう。結果として、そのデバイスが、もしクライアントの要求の実行に投票するならば、さらなるメッセージを待つことなく、その要求の実行に進み、その結果をクライアントに提供することができる。

上述のように、３つのデバイスのシステムでは、任意の２つのデバイスが定足数を形成する。そのため、リーダが、投票の要求とともに自分自身の投票を送るとき、他の２つのデバイスのいずれかがリーダと同様に投票することを選ぶならば、定足数を満たすことができる。さらに、他の２つのデバイスは、すでにリーダの投票を受け取っており、それら自身の投票についても知っているので、さらなるメッセージを待つことなく、定足数がクライアントの要求の実行に投票したかどうかを判断することができ、そのため、適切な場合には、クライアントの要求を行い、さらなるメッセージ遅延なく、その結果をクライアントに返すことができる。

メッセージまたはストレージおよびプロセッシング能力を節約するために、リーダは定足数の投票について知る必要はない。リーダの投票が、投票の要求とともに送られるので、その他のデバイスは、リーダの投票とそれら自身の投票に基づいて、クライアントの要求を実行するのに定足数が同意したかどうかを個々に判断することができる。しかし、リーダへの明示的な返信がなく、リーダはその他のデバイスの投票について知ることができない可能性がある。しかし、リーダが定足数の投票について知ることは必要ではない。そのため、投票の結果を示すメッセージをリーダに送ることができるし、あるいは、メッセージを節約するために、またはリーダのストレージまたはプロセッシング能力を節約するために、リーダはそのようなメッセージを受け取る必要はない。

リーダは定足数の投票について知る必要はないが、クライアントに加えて他のコンピューティングデバイスが、クライアントの要求の実行の結果について知りたいと望む場合がある。結果として、クライアントの要求が実行されるべきであると判断し、その要求を実行するデバイスは、その結果をクライアントと、他のコンピューティングデバイスとに送ることができる。このような他のコンピューティングデバイスには、分散コンピューティングシステムにおいて冗長性を維持するためにＰａｘｏｓアルゴリズムを使用しているデバイス、およびＰａｘｏｓアルゴリズムの一部ではないかもしれないが、システムによって行われた実行の結果について知りたがっているその他のデバイスを含むことができる。

リーダなど、冗長性を維持するためにＰａｘｏｓアルゴリズムを使用しているデバイスのいくつかは、クライアントの要求についてのいかなる特定の投票または実行の結果について知る必要がないので、そのようなデバイスは、限定されたストレージまたはプロセッシング能力を有する安価なコンピューティングデバイスで実装することができる。さらに、そのような安価なデバイスは、定足数を選択するために必要とされる程度でＰａｘｏｓアルゴリズムに参加できるだけであり、それらの関与と、結果的に、必要な最低限のプロセッシングまたはストレージ能力がさらに低減される。

（状態マシン）
図１に示す分散システム１０のような分散環境では、デバイス間の協調は難しいタスクとなることがある。協調するファクタとして時間に依拠することに内在する難しさを回避するための１つのメカニズムは、ある機能の実行によって状態マシンをある状態から別の状態に動かす状態マシンに関して、分散コンピューティングシステムをモデル化することである。そのため、状態マシンは、１組の状態、１組のコマンド、１組の応答、および各応答／状態ペアを、各コマンド／状態ペアにリンクする機能に関連して記述することができる。状態マシンのクライアントは、その状態マシンがある機能を実行することを要求するコマンドを発行することができる。その機能は次に状態マシンの状態を変更し、応答を生成する。

分散コンピューティングシステムを構成する個々のデバイスは、それぞれ、システムの状態マシンを実行することができる。デバイスは、それゆえ、初期状態を判定し、次いで、そこから同じ機能を同じ順番で実行することにより、協調させることができる。あるデバイスの同期は、単にそのデバイスが実行した最後の機能を判定し、他のデバイスによって実行された機能の順番リストでその機能を特定し、そしてそのデバイスにまだ実行していない機能を順番リストから実行するように指示することによって行うことができる。このような状態マシンアプローチは、その内容がすべて参照により本明細書に組み込まれる非特許文献１において最初に提案された。

（Ｐａｘｏｓアルゴリズム）
状態マシンアプローチを使用することにより、図１に示した分散コンピューティングシステム１０の構成デバイス１１〜１３の同期化を、行われるべき機能、およびそれらを行うべき順番に同意することにより達成することができる。行われる機能に同意するための１つの方法として、Ｐａｘｏｓアルゴリズムが知られている。Ｐａｘｏｓアルゴリズムによって、システム１０は、デバイスが前もって警告することなく動作を停止する可能性がある障害に直面した場合にも、正しく動作することができるようになる。Ｐａｘｏｓアルゴリズムは、全体としてシステムがある機能を行う前に、少なくとも定足数のデバイスがその機能に同意することを要求する。Ｐａｘｏｓアルゴリズムでは、定足数はシステムの特定の要件に応じて、単なる過半数であってもよいし、またはそれよりも多くのデバイスを含むこともある。しかし、定義では、定足数は、任意の２つの定足数が少なくとも１つの正しく機能するデバイスを共通に有するのに十分に大きくすることができる。

一貫性を維持するために、システム１０は、機能のパフォーマンスを１ステップにつき単一の機能に限定することができる。それゆえ、ある与えられた１ステップについて単一の機能のみを選択することが望ましいことがある。任意の２つの定足数は少なくとも１つの正しく機能するデバイスを共通に有するので、あらゆるデバイスが１つの提案にのみ投票することを要求することによって、１ステップを超えない選択を保証することができるであろう。しかし、いくつかのデバイスが同時にリーダとして働く場合には、このような要求は行き詰まりの原因となるであろう。というのは、どの提案も定足数によって同意されず、しかも、どのデバイスも定足数が最終的に満たされ得るように異なる機能の提案に対して投票することができないという可能性があるためである。

Ｐａｘｏｓアルゴリズムは、マルチステッププロセスによってこの問題を解決する。それによれば、デバイスはその投票を変更することが許されるが、リーダは自分自身が提案する機能に束縛される。Ｐａｘｏｓアルゴリズムを使用すると、リーダは、以前に提案された機能について知らない限り、自分が選ぶ任意の機能を提案することができる。リーダが、定足数中の少なくとも１つのデバイスがすでに投票した、少なくとも１つの以前に提案された機能について知っている場合に、リーダは、その自分が知っている以前に提案された機能のうち一番最近のものを提案することができる。各デバイスは、そのデバイスが投票した一番最近の提案を追跡する必要があるだけである。デバイスが、投票することを約束した提案を受け取り、その間に別の提案に投票することを約束していなかった場合、デバイスはその提案に対して投票をキャストすることができる。デバイスは、ある提案が、以前に投票することを約束したその他どの提案の番号よりも提案番号が大きい場合にのみ、その提案に対して投票することを約束することができる。提案番号の使用により、システムは、複雑で費用のかかる、構成デバイス間のクロックの同期化の必要なく、正しい動作を達成できるようになる。一般に、一番最近の提案が最も大きい提案番号を有する。そうでない場合には、以下に説明するように、無視することができる。ある提案に投票することを約束する際、デバイスは、そのデバイスが以前に投票することを約束した、現在の提案番号よりは小さい最大の提案番号を、投票を求めているリーダに送信することもできる。このようにして、リーダは、常に以前の提案について知ることができる。

図３ａを参照して、図示のように、３つのデバイス１１〜１３を含む例示的な分散コンピューティングシステム１０を使って、Ｐａｘｏｓアルゴリズムをより詳細に説明する。このような環境では、定足数は、２つまたはそれ以上のデバイスの任意のグループとして定義することができる。なぜなら、このような定義により、あらゆる定足数が少なくとも１つのデバイスを共通して有することが保証されることになるからである。図３ａに示すように、デバイス１３はリーダの地位を担い、システムがある与えられた機能を実行するという提案の提案番号を示唆する、メッセージ２００をデバイス１１および１２に送信することができる。デバイス１３はデバイスとリーダの両方として機能することができるので、それ自身にもメッセージ２００を送る。ただし、このような送信はそのデバイスに対して内部的に処理することができ、物理的に送信する必要はない。デバイス１３は、より大きい提案番号を有する以前の提案がないことを確実にするにあたって、任意の大きさの提案番号を選択することができる。さらに、デバイス１３自体が以前の提案に関して投票している場合があるので、デバイス１３は、デバイス１３が知っているどの提案よりも大きい提案番号を選択することができる。

提案はそれらの提案番号に基づいて順序付けすることができるので、２つまたはそれ以上のデバイスが２つまたはそれ以上の異なる提案に対して同じ提案番号を使用するのを防ぐことによって、効率性を得ることができる。それゆえ、デバイスは、提案を送信するデバイスの媒体アクセス制御（ＭＡＣ）アドレスなど、デバイス特有のプロパティに基づくメカニズムを用いることによって、提案番号を選択することができる。あるいは、デバイス間で提案番号を区切ることができ、各デバイスにその区分内からのみ提案番号を選択することを要求する。提案番号を区切る方法の１つは、「ｉ番目」のデバイスに、システム中のデバイスの数を法として「ｉ」と合同な（ｃｏｎｇｒｕｅｎｔ）提案番号を与えることであろう。

以下に示すように、Ｐａｘｏｓアルゴリズムは、いくつかのデバイスがリーダとして働く場合にも動作することができるので、デバイスがリーダの地位を担うメカニズムは重要ではない。それでも、異なるデバイスが同時に自分がリーダであると信じる機会を最低限に抑えるメカニズムは、システムの効率性を向上させることができる。例えば、ＭＡＣアドレスなど、デバイス特有のプロパティに基づくメカニズムは、同時に複数のリーダを有する機会を低減することができる。このようなメカニズムの１つは、単に、最小のＭＡＣアドレスを有する、正しく機能するデバイスを次のリーダとなるように選択することであろう。加えて、リーダ選択メカニズムは、あるデバイスが、リーダとして働いている別のデバイスから所定の時間内にメッセージをすでに受け取っている場合に、そのデバイスがリーダになろうとすることを妨げて、リーダシップを有するデバイスが絶えず変わることを防ぐことができる。そのようにリーダシップが絶えず変わることにより、システムの動作に非効率性を導入する可能性がある。

図３ｂを見ると、新しい提案番号を示唆するメッセージ２００などのメッセージを受信すると、デバイス１１および１２のそれぞれは、メッセージ２００によって示唆された提案番号より小さい最大の提案番号と、その提案番号によって提案された機能であって、そのそれぞれのデバイスが投票をキャストした機能を示すメッセージで応答することができる。リーダによって使用された提案番号よりも大きい提案番号に投票をキャストしている場合、デバイスは、リーダからのそのメッセージを無視することができ、または以下に説明するように、そのより大きい提案番号にかかわらず、最後の投票の情報で応答することができる。図３ｂに示す例示的な条件において、デバイス１２は以前に提案番号７０に投票しており、それは、システム１０が変数「ｙ」によって識別される機能を実行することを提案したものである。そのため、デバイス１２は、メッセージ２００に応答して、それが機能「ｙ」の実行を提案した提案番号７０に最後に投票したことを示すメッセージ２１２を送信することができる。同様に、デバイス１１は以前に提案番号３０に投票しており、それは、システム１０が変数「ｚ」によって識別される機能を実行することを提案したものである。メッセージ２１１は、それゆえ、デバイス１１のこの最後の投票の情報をデバイス１３に伝達することができる。デバイス１３は、何ら提案を受け取らず、それゆえ、以前にどの提案にも投票をキャストしていない可能性がある。それゆえ、デバイス１３は、メッセージ２１３で示すように、ヌル応答を返すことができる。この場合も、上述のように、デバイス１３からそれ自身に送られたメッセージは、デバイス１３によって内部的に処理することができるが、説明の目的で図示している。

図３ｃを見ると、リーダ１３は、メッセージ２１１〜２１３を受け取ると、定足数のうちの任意のメンバによって投票された、最大の提案番号を有する機能に等しくなるように、提案すべき適切な機能を決定することができる。定足数のメンバがどれも、以前のどの提案にも投票していなかった場合には、リーダは、自分が提案したいと思うどの機能でも自由に選択する。それゆえ、図３ｂに示すメッセージ２１１〜２１３が与えられると、デバイス１３は、機能「ｙ」の実行に対する投票を求めることを選択でき、その機能は、リーダ１３が知っている最大の提案番号を有する提案である提案番号７０の一部としてデバイス１２によって投票されたものである。しかし、図３ａ〜３ｅに示すシステム１０は３つのデバイスを含むので、定足数はわずか２デバイスでよい。そのため、リーダ１３は、デバイス１１および１３のみから提案に対する投票を求めるだけで十分である。このようなケースでは、デバイス１２は選択された定足数のメンバではないので、リーダ１３は機能「ｙ」を提案する必要はない。代わりに、リーダ１３は、機能「ｚ」を提案することができ、その機能は、デバイス１１によって提案番号３０の一部として投票されたものである。提案番号３０が定足数中のデバイスによって投票された最大の提案番号であるため、リーダは、機能「ｚ」を投票のために提出すべきものとして選択することができる。

提案番号を示唆するメッセージ２００は、リーダ１３が選択すべき適切な提案番号を決定することができるメカニズムとして働き、また、以前に提案されたそれよりも小さい番号の提案すべてについてリーダが知ることを可能にするので、リーダ１３は、メッセージ２００などのメッセージを複数送る必要がある可能性があり、以前のメッセージの提案番号が小さすぎる場合には、徐々に大きい提案番号を示唆する。リーダに多数のメッセージを送ることを要求するのではなく、各デバイスは、リーダによって示唆された提案番号が以前に提案に対して投票したものよりも大きいか小さいかにかかわらず、自分が投票した最大の番号の提案で応答することができる。このようにして、リーダ１３は以前の投票についてより効率的に知ることができ、機能を提案するために用いる提案番号をより正確に選択することができる。

図３ｃを見ると、リーダ１３が、システム１０のすべてのデバイスからなる定足数を選択し、システム１０による機能「ｙ」の実行に関する投票を求めるメッセージ２２０を送信しているのが示されている。メッセージ２２０を受信すると、各デバイスは、機能「ｙ」に投票すべきかどうかを決定することができる。デバイスは、現在、投票が要求されている提案よりも大きい提案番号を有する新たな提案の示唆に応答していない限りは、機能に投票することができる。そのため、図３ｃに示した例について、デバイス１１〜１３のいずれかが、図３ｃに示すようにリーダ１３がメッセージ２２０を送信する前に、１００よりも大きい提案番号を有する新たな提案に対する別の示唆を受信し、応答していた場合、そのデバイスは、メッセージ２２０によって投票が求められている機能に投票しない場合がある。

図３ｄを見ると、デバイス１１〜１３のそれぞれは、自分が１００よりも大きい提案番号を有する新たな提案に対する他のどの示唆にも応答していないことを独立して判断することができる。それゆえ、それらが応答した新たな提案に対する最後の示唆が、現在の提案よりも大きい番号を有する提案に対してではないので、デバイス１１および１３は、その提案に投票し、それらの投票をメッセージ２３１および２３３中にそれぞれ示すことができる。前述のように、メッセージ２３３は説明の目的のために示されており、デバイス１３に対して内部的に処理することができる。しかし、デバイス１２は、メッセージ２２０の送信前のいずれかの時に、１００よりも大きい提案番号を有する新たな提案に対する示唆を受け取り、応答している場合がある。それゆえ、メッセージ２２０を受信すると、デバイス１２は、自分がすでに１００よりも大きい番号を有する新たな提案の示唆に応答していると判断することができ、それゆえ、提案１００に投票することができないであろう。結果として、図３ｄに示すように、デバイス１２は、それが提案番号１５０を有する提案の示唆に対して応答していることをリーダ１３に知らせるメッセージ２３２で応答する。リーダ１３は、デバイス１２の投票が必要であると判断する場合には、１５０よりも大きい提案番号を有する以外にはメッセージ２２０と同様の別のメッセージを送ることができる。あるいは、デバイス１２は、メッセージ２２０に応答する必要はなく、デバイス１３は、デバイス１２の投票を必要とする場合には、任意の大きさの提案番号を有する提案でさらなる投票を試みることができる。理解されるように、デバイス１２がリーダ１３に対してそのより大きい提案番号を示さない場合、リーダは推測しなければならず、複数のメッセージを通して適切な大きさの提案番号を推測するために資源を無駄にすることになるであろう。

しかし、デバイス１１および１３は定足数を構成するのに十分なので、リーダ１３は、デバイス１２の投票がなくてもその提案が受諾されたと判断することができ、図３ｅに示すようなメッセージ２４０で、デバイス１１および１２のそれぞれが機能「ｙ」を実行することを要求することができる。デバイス１１および１３は定足数を構成するが、その定足数は、リーダ１３が投票に対する提案を提出した定足数と同じものではなく、その定足数にはデバイス１２を含んでいた。しかし、上述のように、リーダは、提案が受諾されたかどうかを判断するのに、定足数からの投票を受け取ればよく、必ずしも要求を送信したのと同じ定足数である必要はない。上述のＰａｘｏｓアルゴリズムは、その動作におけるどの所与のステップについても、１つの機能のみが選択されてシステム１０によって実行されることを保証する。例えば、以前に動作していなかった別のデバイスが動作するようになり、システム１０に再び参加した場合、そのデバイスはシステムが「ｙ」を選択し実行したのと同じステップについて、「ｙ」とは異なる機能を提案しようとするかもしれない。このようなデバイスが１００よりも小さい提案番号を有する提案を送った場合、それはデバイス１１および１３によって無視される。というのは、デバイス１１および１３は、図３ｄに示すように提案番号１００に関してすでに投票しているためである。他方、そのデバイスが、提案番号１３０など、１００よりも大きい提案番号を有する提案を送信した場合には、デバイス１１および１３は、それらが提案番号１００で機能「ｙ」に投票したことを示すメッセージを返すであろう。デバイス１２は、図３ｄに示すように、投票していない場合があるので、提案番号３０で機能「ｚ」に投票したことを示すメッセージ２１２で応答する場合があるであろう。

その新たなデバイスは、次いで、ある定足数の中で、すなわち、定義によりデバイス１１〜１３の少なくともいくつかを含むであろう定足数の中で最大の提案を選択し、その提案において提案された機能を投票のために提出することができるであろう。そのため、提案１３０について、この新たなデバイスは、投票のために機能「ｙ」を提出することになる。各デバイスは、次いで上述のアルゴリズムに従って、提案１３０に関する投票をすることができるであろう。特定のステップについて機能「ｙ」を実行するという前の決定を変更しない提案１３０が選択されるか、またはその間にあまりに多くのデバイスが別の提案に対して投票することを約束したために提案１３０が失敗するかのいずれかであろう。しかし、理解されるように、提案が通過すると、すべての他の提案が同じ機能を提案し、そして、定義によって、すべてのデバイスはその同じ機能に対してのみ投票することができる。このように、Ｐａｘｏｓアルゴリズムは、システム１０のあらゆるデバイスが所与のステップについて同じ機能を実行することを保証する。

上述のように、Ｐａｘｏｓアルゴリズムのアプリケーションは、分散コンピューティングシステムが所与のステップについて実行すべき機能を選択できるようにすることができる。上述のステップを繰り返すことによって、分散コンピューティングシステムは、一連のステップとして実行されるべき一連の機能に同意することができ、それによって、継続的に動作するシステムを形成することができる。このようにして、分散コンピューティングシステムは、１つまたは複数のクライアントから要求を受け取ることができ、それらの要求を実行することができ、そしてその結果をクライアントに返すことができる。

図４ａを参照して、システム１０は、すでにいくつかのステップについて動作している可能性がある。例えば、図４ａに示す例示的なシステム１０において、一番最近、実行されたステップがステップ２４であり、ステップ２５が現在のステップである可能性がある。しかし、以前にリーダとして働いていたデバイスが故障したか、または単に何のクライアントの要求も受け取っていない可能性がある。クライアント２０は、図示したように、図４ａ中の変数「ｘ」によって表される機能を実行する要求を、メッセージ３００を使ってデバイス１３に送ることができる。デバイス１３は、上記のメカニズムなどの任意の数のメカニズムに従って、自分がリーダになるよう試みるべきであると判断する。このように、デバイス１３は、次の提案に提案番号１００の使用を示唆し、その提案がなされるべきステップを含むメッセージ３０１を送信することができる。図４ａの例示的な分散コンピューティングシステム１０において、デバイス１３は、その他のデバイス１１および１２によってステップ２３および２４がすでに決定され、実行されていることを知らない。そのため、メッセージ３０１は、ステップ２３に１００という番号の提案を示唆していることを示している。

複数のステップを実行するシステムでのアルゴリズムの動作をはかどらせるために、メッセージ３０１などのメッセージを、ステップ２３以上のすべてのステップについて番号が１００の提案を示唆するものとして理解することができる。このようにして、リーダ１３は、すでに決定されたあらゆるステップについて知るまで、メッセージ３０１などのメッセージを断続的に送信する必要がなくなる。代わりに、リーダ１３は、以下に示すように、単一のメッセージの往復を通して、すでに実行されたステップについて知ることができる。

図４ｂを見ると、分散コンピューティングシステム１０のデバイス１１〜１３からの応答メッセージ３１１〜３１３が示されている。デバイス１１は、例えば、ステップ２３について機能「ｙ」が実行され、ステップ２４について機能「ｚ」が行われたことを記録している。そのため、メッセージ３０１を受信すると、デバイス１１は、２３以上のすべてのステップ、この場合ステップ２３および２４について行われているとして格納している機能を示すメッセージ３１１で応答することができる。さらに、デバイス１１は、２５以上のステップについてそれが投票した最大の提案番号を有する提案の指示を提供することができる。そのため、図４ｂに示す例では、メッセージ３１１は、デバイス１１が２５よりも大きいステップについては何の提案にも投票しておらず、ステップ２５については機能「ｂ」を提案する提案番号１６０に投票したことも示すことができる。システム１０内で送信されるメッセージの数を減らすために、デバイスは、その所与のステップについて実行された機能について知らない場合に、それらの最大の提案番号の投票で応答しさえすればよい。そのため、デバイス１１は、ステップ２５ではなく、ステップ２３および２４について機能が実行されたということを知っていたので、ステップ２３および２４については実行された機能と、ステップ２５についてはそれが投票した最大の番号の提案で応答している。

上述のように、デバイス１３は、リーダと、投票側デバイスの両方として機能することができる。このように、デバイス１３は、メッセージ３０１などのメッセージを自分自身に送ることができ、メッセージ３１３などのメッセージで自分自身に応答することができる。このようなメッセージは、内部的にデバイス１３に送信されることになるので、説明の目的でのみ図に示している。さらに、デバイス１３は、機能が実行されたことを知っているステップについて、どれが最大のステップ番号を有するステップであるかをチェックすることができ、デバイス１３は投票した上記のすべてのステップの提案について、どれが最大の提案番号であるかをチェックすることができるので、メッセージ３１３はヌルインジケータ以外の何らかの情報を含むことはほとんどない。

状態マシンの現在の状態は、実行された機能だけでなく、それらの機能が実行された順番にも依存する場合がある。それゆえ、あるデバイスが、ある所与のステップについてどの機能が実行されたかを知らない場合、そのデバイスがそのステップを超えてどの機能も実行すべきではないか、またはそのデバイスが順番以外で機能を実行し、そのデバイスの状態が分散コンピューティングシステムの状態とは異なってしまう状況が生じることがある。例えば、無条件に新しい状態を指定する機能など、いくつかの機能は、デバイスの現在の状態に依存しない。このような機能は、現在のステップよりも低いステップ番号を有するステップの機能がまだ実行されていなくても、実行することができる。同様に、データベースへの書込みなど、以前のステップのすべてを知らなくても出力を計算することができる機能は、順番通りではなく部分的に実行して、クライアントに送信すべき出力を生成することもできる。しかし、一般に、機能は、以前のすべての機能が実行されるまでは実行されるべきではない。それゆえ、デバイスは、常に、そのデバイスが逃したステップについてどの機能が実行されたかを知ろうと試みることができる。図４ａに示すように、デバイス１３がメッセージ３０１を送るとき、そのメッセージは、デバイス１３がステップ２３が次のステップであると信じていること、そしてステップ２２を通じて同意された機能を実行したという暗示的なステートメントである。ステップ２３よりも下のステップの機能を逃したデバイスは、それゆえ、デバイス１３がステップ２２を通じてすべての機能を実行したことを知り、その機能をデバイス１３から要求することができる。

図４ｂを見ると、デバイス１２は、ステップ１２について何の機能が実行されたかを知らない。結果として、デバイス１２は、ステップ１３〜２３について実行された機能を知っている場合であっても、ステップ１１以降のいかなる機能も実行することができないでいる場合がある。そのため、メッセージ３１２において、デバイス１２は、ステップ１２の機能をリーダ１３から要求することができる。さらに、デバイス１２は、ステップ２３よりも大きい番号のステップについてどの提案にも投票していないことを示すことができる。

あるデバイスがあまりに多くのステップを逃している場合、それが逃したステップすべての機能をすべて送信するよりも、単にそのデバイスに現在の状態を知らせる方がより効率的であることがある。デバイスがあまりに多くのステップを逃さないようにするためのメカニズムの１つとして、各デバイスまたはデバイスの集まりが、状態の様々な部分または全状態のスナップショットを定期的に取得することができるようにすることがある。それゆえ、別のデバイスの状態を、最新のスナップショット以降に実行された機能とともに適切なスナップショットをそのデバイスに送ることによって更新することができるであろう。さらに、状態の個々の部分のチェックサムを使用することによって、別のデバイスの状態を、その現在のコピーとは異なる状態の部分をその別のデバイスに送るだけで、更新することができるであろう。

メッセージ３１１〜３１３を受け取る結果、リーダ１３は、それまで知らなかったステップ２３および２４を実行し、ステップ２５について提案すべき適切な機能を決定しようと試みることができる。また、ステップ２５を通じてすべてのステップをまだ実行していない他のデバイスを更新しようと試みることができる。元々、リーダ１３は、メッセージ３０１において１００の提案番号を示唆したが、デバイス１１は、それがすでにステップ２５について１００よりも大きい提案番号を有する提案に投票したことを示すメッセージ３１１で応答した。その結果、リーダ１３は、自分が知っている最大の提案番号よりも大きい提案番号を選択し、図４ｃに示すメッセージ３２０など、別の示唆メッセージを送信することができる。あるいは、デバイス１１は、メッセージ３０１における提案番号１００の示唆を、その提案番号が、デバイス１１がすでに投票した提案の提案番号よりも小さかったという理由で、単に無視している場合もあるであろう。このような場合には、リーダは、その初期の示唆を無視したデバイスを捕らえようとして、提案番号を増やすことによって、再試行したであろう。見て分かるように、デバイスが、それらがすでに投票した提案の提案番号よりも小さい提案番号を有する提案の示唆を無視した場合、リーダは、示唆する提案番号を大きくしながら、何度か試みざるを得ない。このような複数のメッセージは、非効率的な場合がある。それゆえ、デバイスがすでに投票した提案の提案番号よりも提案番号が小さい場合でも、新たな提案番号のすべての示唆に対してデバイスが応答することが望ましい場合がある。というのは、それによって、リーダは、示唆すべき適切な提案番号をより正確に決定することができ、複数のメッセージを回避することができるためである。

図４ｃを見ると、リーダ１３は、以前にデバイスが投票していることをリーダ１３が知っているどの提案の番号よりも大きい提案番号を示唆しようとし、メッセージ３２０に示すような提案番号２００などの、より大きい提案番号を示唆することができる。さらに、リーダ１３は、以前に実行された機能に関する情報を、ステップ２５までの選択された機能のすべてをすでに実行しているどのデバイスにも提供することもできる。それゆえ、図に示すように、リーダ１３は、変数「ｅ」によって表される機能がステップ１２について実行されたこと、そして変数「ｙ」および「ｚ」によって表される機能がステップ２３および２４についてそれぞれ実行されたことをデバイス１２に示すメッセージ３２１を送ることもできる。

図４ｄでは、次に、デバイス１１〜１３は、図４ｂで上記に示したのと同様の方法で応答することができる。ただし、デバイス１１〜１３は、ステップ２３および２４について実行された機能についてデバイス１３に知らせる必要はない。というのは、デバイス１３はすでにそれらのステップについて知っており、ステップ２５を参照する提案メッセージ３２０および３２１をすでに送っているためである。さらに、メッセージ３３１〜３３３は、デバイスが投票した可能性のある追加の提案についてなど、追加の情報を含むことができる。例えば、デバイス１２が、メッセージ３１２とメッセージ３３２の送信の間のある時点で、提案番号１９０を有する提案に投票した可能性がある。結果として、メッセージ３１２は、デバイス１２が以前にステップ２５についてのどの提案に対しても投票をキャストしていないかもしれないことを示すことができるが、メッセージ３３２は、デバイス１２が２５よりも大きいステップについてどの提案にもまだ投票していないが、ステップ２５について提案１９０には投票したことを示すことができる。しかし、提案番号のそれぞれはリーダ１３がメッセージ３２０で送信した、示唆された提案番号よりも小さいので、リーダは、メッセージ３２０の中で指定した提案番号２００を有する機能の提案に進むことができる。

図４ｅを見ると、リーダ１３は、メッセージ３４０によって示されるように、提案を選択して提案番号２００として提出するのに十分な情報を持っている。メッセージ３４０は、デバイス１１〜１３が、システムがステップ２５について機能「ｂ」を実行することを提案する提案２００に関する投票をするように要求している。前述のように、ともに定足数のメンバであるデバイス１１および１２は、機能「ｂ」の実行を提案する提案に以前に投票しており、その定足数のその他のメンバはどれも、それよりも大きい番号のどの提案にも投票していないので、リーダ１３は、クライアント２０がメッセージ３００中で機能「ｘ」の実行を要求したという事実にもかかわらず、提案番号２００について機能「ｂ」を提案することができる。このようにして、Ｐａｘｏｓアルゴリズムは、１つまたは複数のデバイスの故障またはそれらの通信の障害などにより提案されたが完了していない以前の機能が正しい順番で実行できるよう保証する。

図４ｆは、デバイス１１〜１３が、ステップ２５について、メッセージ３５１〜３５３で機能「ｂ」をそれぞれ提案する提案２００に投票していることを示している。前述のように、デバイスは、メッセージ３２０とメッセージ３４０の受信の間で、より大きい提案番号を有する異なる提案に投票することを約束していない限り、ある提案に投票することができる。リーダ１３は、メッセージ３５１〜３５３を受け取ると、図４ｇに示すように、デバイス１１および１２にステップ２５について機能「ｂ」を実行するように命令するメッセージ３６０を送信することができる。リーダ１３自身も、その機能が定足数によって選択されたことを知っているので、その機能を実行することができる。

しかし、メッセージ３００でクライアント２０によって要求された機能は、図４ｇに示す時点ではまだシステム１０によって実行されていない。システム１０にこのクライアントの要求を実行させるために、リーダ１３は、上述の図３ａ〜ｅおよび４ａ〜ｇで示した完全なＰａｘｏｓアルゴリズムの短縮を行なうことができる。

結果として、上述のＰａｘｏｓアルゴリズムを２つの一般的なフェーズに分割することができる。第１のフェーズは、リーダが、定足数のデバイスによって投票された以前の提案について知ることを備える。第１フェーズは、図３ａおよび３ｂで示すように、リーダによる提案番号の示唆と、定足数のその他のメンバによる応答の１回の繰返し、または図４ａ〜ｄによって示すように、提案番号の示唆と応答の複数回の繰返しを含むことができる。第２のフェーズは、リーダが、提案機能を投票のために提出することと、投票を受け取ることと、その提案が十分な数のデバイスによって投票された場合には同意された機能を実行するようそれらのデバイスに命令することとを備える。第２フェーズの例は、図３ｃ〜ｅおよび４ｅ〜ｇによって示されている。

リーダは、その他の提案について知り、現在および将来のステップのすべてについて確実な提案番号を見つけると、失敗しない限り、または別のデバイスがリーダになろうとしない限り、さらなる情報を求める必要はない。それゆえ、Ｐａｘｏｓアルゴリズムの第１フェーズはそれほど頻繁に行われなくてもよく、一方、第２フェーズは、ステップ数を増やしながら繰り返し行われる可能性があり、それによって、分散コンピューティングシステムが一連の機能に同意し実行することができるようにし、またアクティブな稼働状態を維持できるようにする。

図５ａを見ると、図４ａ〜ｇの例示的な分散コンピューティングシステム１０が、上記に詳説したステップ２５に続くさらなるステップ２６を実行しているのが示されている。図４ａ〜ｄに示し、上記に詳説したように、Ｐａｘｏｓアルゴリズムの第１フェーズの結果として、リーダ１３は、デバイス１１〜１３のどれもステップ２５より上のどの提案についても投票しておらず、それゆえ、提案番号２００は、ステップ２５よりも大きいステップについてのすべての提案にとって安全であることをすでに知っている。それゆえ、図５ａに示すように、リーダは、ステップ２６について、再び第１フェーズを行う必要がなくＰａｘｏｓアルゴリズムの第２フェーズを開始することができ、クライアントによってメッセージ３００中で要求された機能「ｘ」の実行に対する投票を求めるメッセージ４００を送ることができる。デバイス１１〜１３のそれぞれは、次に、メッセージ４１１〜４１３で、図５ｂに示すように、投票で応答することができる。定足数のデバイスのそれぞれは、その機能の実行に投票しているので、リーダ１３は、図５ｃに示すように、デバイス１１および１２がステップ２６について機能「ｘ」を実行することをメッセージ４２０で通知することができる。さらに、リーダ１３は、投票が成功したことを知っているので、機能「ｘ」を実行することができ、そしてその機能の実行の結果を、メッセージ４２１としてクライアントに、またはメッセージ４２２として、デバイス３０および３１などのその他の関係しているコンピューティングデバイスに送ることができる。メッセージ４２１および４２２は、メッセージ４２０と同時に、またはメッセージ４２０の前後でも送ることができる。

見て分かるように、リーダが確立され、すべてのこれからのステップ番号について、定足数のデバイスによって投票された様々な最大の番号の提案を知ると、そのリーダは、Ｐａｘｏｓアルゴリズムの第１フェーズを繰り返すことなく、投票のための提案を求めることができる。図５ａに示すメッセージは、図４ｇのメッセージ３６０の送信の後に送信されるものとして示されているが、リーダ１３は、デバイスが１つの提案に投票するまで、その後のステップについての別の提案を送るのを待つ必要はない。それゆえ、図４ｅに示すように、メッセージ３４０を送ると、リーダ１３は、図５ａに示すメッセージ４００を送ることができ、そして、そのようにして、ステップ２６よりも大きいステップについては、提案番号２００を使って一連の機能を提案し続けることができる。このような非同期のやり方で動作することによって、全分散コンピューティングシステムは、以前のステップについての投票について知るまで待つことによりスローダウンする必要はない。

以前は機能していなかったデバイスなど、別のデバイスがリーダになろうとする場合にも、それが原因でシステムが不適切に動作することはなく、アルゴリズムの第１フェーズが繰り返されるだけであろう。例えば、別のデバイスがリーダになろうとした場合、そのデバイスは、いくつかのデバイスが応答するであろう提案番号を提案する可能性がある。第２のリーダによって申し出た提案番号に応答すると、それらのデバイスは次に、第１のリーダが投票を求めたときに、第１のリーダにそのより大きい番号の提案について知らせるか、または、第１のリーダによる要求を無視して、その提案に関して投票するかもしれない。投票したデバイスの数が不十分であるために提案が失敗すると、第１のリーダは、最初に第１フェーズを再び行い、次に、それらのデバイスに示唆できる十分に大きい提案番号であると信じる番号を選択することによって、再び、提案を通過させようと試みるであろう。このようにして、第２のリーダは、システムを遅延させるだけであり、分散コンピューティングシステム側に不適切な動作の原因となることはないであろう。

上述のＰａｘｏｓアルゴリズムのステップを実装するデバイスは、このアルゴリズムに使用される情報を格納する変数を維持することができる。例えば、デバイスがどの機能が選ばれたのか知らない各ステップについて、デバイスは、それらが応答した最大の提案番号を有する提案の提案番号と、それらが投票した最大の提案番号を有する提案の提案番号と、それらが投票した最大の提案番号を有する提案によって提案された値を格納することができ、そのデバイスがリーダである場合には、それが発行した最後の提案の提案番号をさらに格納することができる。さらに、デバイスは、それらがそのような情報を持っているステップすべてについてどの機能が選択されたかを記録することができる。あるいは、上述のように、デバイスは、ある与えられた時間におけるその状態のスナップショットと、その時間以降にのみ実行された機能を格納することができるであろう。このような変数は、揮発性ストレージ１３０、または図２に示したハードディスク１４１、フロッピー（登録商標）ディスク１５２、光ディスク１５６などの不揮発性ストレージに格納することができる。

Ｐａｘｏｓアルゴリズムに関するさらなる情報は、その内容がすべて参照により本明細書に組み込まれる非特許文献２において見つけることができる。

（簡略化されたＰａｘｏｓアルゴリズム）
標準のＰａｘｏｓアルゴリズムの上記の詳細な説明からわかるように、Ｐａｘｏｓアルゴリズムを実装する分散コンピューティングシステムへのクライアントの要求の送信と、システムからのクライアントの要求への応答の送信との間には一連のメッセージ遅延が生じる可能性がある。クライアントの要求を受け取るデバイスが、すでに、標準Ｐａｘｏｓアルゴリズムの第１フェーズをすでに完了したリーダデバイスである場合でも、メッセージ遅延が生じる可能性がある。例えば、図６ａを見ると、これまでの図の分散コンピューティングシステム１０が示されており、これまでのリーダ１３が、変数「ｗ」によって表される機能をシステムが実行することを要求するクライアント２０からのクライアント要求５００を受信している。リーダ１３はすでにＰａｘｏｓアルゴリズムの第１フェーズを行っており、他のデバイスはどれも投票を求めようと試みていないため、リーダは、システム１０にクライアントの要求５００を実行させるために、Ｐａｘｏｓアルゴリズムの第２フェーズを行うだけでよい。それゆえ、クライアントの要求５００を受信すると、リーダ１３は、システムの次のステップ、現在の例ではステップ２７について、提案番号２００として、機能「ｗ」の実行に対する投票を求めるメッセージ５０１を送信することができる。メッセージ５０１の送信は、１つのメッセージ遅延を生じさせる可能性がある。デバイス１１〜１３のそれぞれは、次いで、図６ｂにメッセージ５１１〜５１３で示すように投票で応答することができる。メッセージ５１１〜５１３の送信は、別のメッセージ遅延を生じさせる可能性がある。定足数のデバイスのそれぞれはその機能の実行に投票しているので、リーダ１３は、図６ｃに示すように、デバイス１１および１２がステップ２７について機能「ｗ」を実行することをメッセージ５２０で知らせることができる。さらに、リーダ１３は、投票が成功したことを知るので、機能「ｗ」を実行することができ、その機能の実行の結果を、メッセージ５２１としてクライアントに、またはメッセージ５２２として、デバイス３０および３１などのその他の関係するコンピューティングデバイスに送信することができる。それゆえ、標準Ｐａｘｏｓアルゴリズムは、クライアントの要求メッセージ５００の受信とクライアントへの返信メッセージ５２１の送信との間に、少なくとも２つのメッセージ遅延を生じさせる可能性がある。

本発明の一実施形態では、標準Ｐａｘｏｓアルゴリズムの第２フェーズを修正することによって、少なくとも１つのメッセージ遅延を回避することができる。３つのコンピューティングデバイスを備えるシステム１０のような分散コンピューティングシステムでは、いずれかの２つのデバイスが過半数を形成することができる。任意の２つの過半数は、少なくとも１つのデバイスを共通に有するので、３つのデバイスのシステム中の任意の２つのデバイスは、Ｐａｘｏｓアルゴリズムを実行する目的として定足数にもなり得る。そのため、任意の２つのデバイスが提案された機能の実行に同意する場合、その提案された機能は、システムによって選択され、実行することができる。リーダは、この２つのデバイスの定足数の１デバイスとなってもよい。それゆえ、その他の２つのデバイスのいずれかがある提案された機能の実行に投票するならば、定足数がその機能を選択したことになる。

リーダが、特定の機能に対する投票の要求とともに、その機能に対するリーダの投票の指示を送信すれば、１つのメッセージ遅延を回避することができる。別のデバイスがそのようなメッセージを受け取ると、そのデバイスは、それ自身で、何らのさらなるメッセージなしで、提案された機能の実行に投票する定足数を満たす。それゆえ、そのデバイスが、提案された機能に投票すべきであると判断し、その同じ提案された機能に対するリーダの投票をすでに受信していれば、そのデバイスは、自分自身とリーダで構成される定足数がその機能の実行に投票したことも判断できる。定足数がその機能の実行に投票しているので、デバイスは、何らかのさらなるメッセージを受け取ることなく、安心してその機能を実行することができる。デバイスが、その機能を実行すると、その結果をクライアント、または任意の他の関係するデバイスに送信することができ、それによって標準Ｐａｘｏｓアルゴリズムに比べ、１つのメッセージ遅延を取り除くことができる。

図７ａを見ると、これまでの図のシステム１０に関連して、本発明の一実施形態の動作が示されている。図６ａの場合と同様に、リーダ１３は、図７ａでメッセージ６００として示したクライアントの要求を受け取って、変数「ｖ」によって表される機能を実行することができる。リーダ１３は、次いで、デバイス１１および１２の両方に、提案された機能に関する投票の要求を含むだけでなく、提案された機能に賛成するリーダの投票の指示を備えるメッセージ６０１を送信することができる。そのため、図７ａのメッセージ６０１は、上記の図６ａのリーダのメッセージ５０１には存在しなかった追加の情報を含んでいる。具体的には、メッセージ６０１は、リーダ１３が上記の図６ｂのメッセージ５１３まで送信しなかった情報も含んでいる。

図７ｂを見ると、デバイス１１および１２は、デバイス１３が提案された機能にすでに投票していることを知っているので、また、任意の２つのデバイスがシステム１０の定足数を構成するので、デバイス１１および１２は、提案された機能に投票するのであれば、その提案された機能を独立して実行することができる。そのため、図７ｂに示すように、デバイス１１および１２は、提案された機能に投票することを決定することができる。デバイス１１および１２はそれぞれ自身の投票を知っており、また提案した機能に賛成するデバイス１３の投票も知っているので、デバイス１１および１２は、定足数がその提案された機能に投票していること、それゆえその機能を実行して間違いないことを独立に知る。デバイス１１および１２は、それゆえ、その機能を実行し、機能「ｖ」の実行の結果を、直接クライアント２０に、または任意のその他のコンピューティングデバイスに、図７ｂに示すようにメッセージ６１１および６１２で提供することができる。それゆえ、見て分かるように、提案とともに投票を送ることによって、メッセージ６１１または６１２の形態で、クライアントの要求６００とシステムの応答の間の唯一のメッセージ遅延は、メッセージ６０１を送る際の遅延である。

本発明によって企図されている別の実施形態では、リーダ１３は、システム１０中の他の１つのデバイスのみを選択して、定足数を満たし、要求された機能の実行の結果をアナウンスする。それゆえ、図８ａを見ると、図７ａの代わりが示されている。具体的には、図８ａに示すように、リーダ１３は、クライアントの要求７００を受け取ると、要求された機能に関する投票の要求と、その機能に対するリーダの投票の指示とを備える１つのメッセージ７０１のみをデバイス１１に送ることができる。上記のように、デバイス１１が、その機能に投票することを決定すると、それ自身とリーダで構成する定足数がその機能に投票したことを知り、その機能を安心して実行し、その結果をクライアント２０およびその他の関係するデバイスに提供することができる。そのため、図７ｂの代わりとして図示する図８ｂに示すように、デバイス１１は、要求された機能の実行の結果をクライアント２０およびその他の関係するデバイス３０および３１に知らせることができるだけでなく、デバイス１１はデバイス１２にも実行された機能の結果を知らせることができる。しかし、デバイス１２はシステムの状態の現在のコピーを維持しようとすることができるので、デバイス１１は、選択された機能と、その機能がどのステップのために選択されたかの指示を提供することもできる。そのため、クライアント２０およびその他の関係するデバイス３０および３１に送られたメッセージ７１１は、選択された機能の実行の結果を含む必要があるだけであるが、デバイス１２は、機能「ｖ」がステップ２８について選択されたことを示し、機能「ｖ」の実行の結果を提供するメッセージ７２１を受け取ることができる。

図７ａおよび７ｂならびに８ａおよび８ｂに示す実施形態のいずれにおいて、要求された機能を実行するデバイスは、リーダ１３に、機能「ｖ」が選択された事実を送信し、機能「ｖ」の実行の結果を提供することができる。それによって、リーダは、システムの状態の現在のコピーを維持することを可能にする。あるいは、リーダ１３は、システムの状態を維持する必要がなく、デバイスが機能を実行してさらなるメッセージをリーダに送信する必要なくす。

リーダがシステムの状態を維持するかどうかにかかわらず、システムの状態の２つのコピーが維持される限り、システム１０は失敗を許容できる。例えば、リーダ１３がシステムの状態のコピーを維持しておらず、デバイス１１および１２がコピーを維持している場合、デバイス１１および１２のいずれかが故障しても、システムは、リーダ１３と、２つのデバイス１１および１２のうち動作可能な一方のみとで動作し続けることができるであろう。送信されるメッセージは、図８ａおよび８ｂに示されているものと同様であり、この場合、リーダは１つのデバイスのみにメッセージを送る。

システム１０のデバイス間で送信されるメッセージの数を最小限に抑えるために、本発明の実施形態は、結果メッセージをキャッシュし、それらをバッチメッセージとしてリーダ、または機能の実行の結果を急いで知る必要がない任意のその他のデバイスに送ることを企図している。そのため、リーダがシステムの状態のバックアップコピーを維持していなかった場合には、図８ｂに示すメッセージ７１１などの結果メッセージを送信デバイス側でキャッシュすることができ、所定の時間経過後に、あるいは、十分な数のメッセージがキャッシュされた後に、それらの結果メッセージを、複数の結果メッセージが入っているバッチメッセージとしてリーダに送ることができるであろう。このような技術は、デバイス３０および３１などのその他のデバイスへのメッセージについても同様に使用することができる。結果メッセージをキャッシュし、それらを所定の時間経過後にバッチメッセージとして送信することによって、送られるメッセージの数を減らすことができ、それによって、ネットワークの輻輳および送信デバイスのネットワークインターフェースにおける負荷を低減する。

リーダが要求された機能の実行の結果を受け取ることができない場合もあるので、その他のメカニズムを使って、リーダによって送信された、投票の要求およびリーダの投票が入っているメッセージを、デバイス１１および１２などのその他のデバイスが実際に受信したかどうかを検証することができる。本発明によって企図される一実施形態では、デバイス１１および１２は、それらがリーダのメッセージを受信したことを知らせるために、小さな受信応答メッセージをリーダ１３に送信することができる。さらに、この受信応答メッセージを、上述の方法で、キャッシュし、所定の時間経過後にバッチメッセージとして送信することもできる。本発明によって企図される別の一実施形態では、信頼できる下位のトランスポートメカニズムを使用することができる。当業者にはわかるであろうが、信頼できるトランスポートメカニズムは、独立してメッセージの送信を検証し、必要に応じて、独立してメッセージのキャッシュおよび再送信を行う。結果として、信頼できる下位トランスポートメカニズムを使用することにより、コンセンサスアルゴリズムの一環としての明示的なメッセージ認証の必要がなくなる。

上記に詳説した、このより効率的なＰａｘｏｓアルゴリズムは、同じく上記に詳説した標準Ｐａｘｏｓアルゴリズムのフォールトトレラントなプロパティを保持している。具体的には、図に示した３つのデバイスのシステム１０は、１つの故障を許容することができる。例えば、デバイス１２が故障した場合、いずれかの２つのデバイス、すなわち、本例ではリーダ１３とデバイス１１が定足数を構成し、実行すべき機能を選択できるので、システムは、図８ａおよび８ｂに関連して上記に説明した方法で動作し続けることができるであろう。

デバイス１３が故障した場合、またはデバイス１１または１２の一方がリーダになろうとし、システム１０に提案を提出しようと試みた場合には、リーダデバイスが以前の提案を知り、適切な提案番号を決定することができるように、上記に詳説した標準Ｐａｘｏｓアルゴリズムの第１フェーズを行わなければならない場合がある。しかし、上述したように、一般に予測される動作条件のもとでは、Ｐａｘｏｓアルゴリズムの第１フェーズが行われる頻度はＰａｘｏｓアルゴリズムの第２フェーズよりも少ない。それゆえ、Ｐａｘｏｓアルゴリズムの第２フェーズからメッセージ遅延を取り除くことによって、標準Ｐａｘｏｓアルゴリズムの第１フェーズがリーダに情報を提供するために依然として時に行われるとしても、一般に予測される動作条件のもとで、上記のアルゴリズムによりクライアントに対する応答が速くなる。

（安価なデバイスを用いた簡略化されたＰａｘｏｓアルゴリズム）
上述したように、Ｐａｘｏｓアルゴリズムを使って、任意のタイプのコンピューティングデバイスで構成されたシステムを用いてフォールトトレラントな分散コンピューティングを提供することができる。例にすぎないが、分散コンピューティングシステムは、世界規模で冗長性を提供する高速な専用サーバコンピューティングデバイスで構成することができ、または安価な冗長性のあるプロセッシングおよびストレージを収益が限定されている組織または研究機関に提供するパーソナルコンピューティングデバイスの未使用資源のみで構成することができる。しかし、実行すべき機能を選択するのに必要とされるコンピューティングデバイスの定足数が、ある定足数のコンピューティングデバイスによってそれ自体選択される場合、さらなるコンピューティング資源を節約することができる。具体的には、上記のアルゴリズムを、１つのデバイスがきわめて低いプロセッシングパワーまたはストレージ能力を備えることができる分散コンピューティングシステムによって実装することができる。このようにして、コンピューティングの割当量（ｃｏｍｐｕｔｉｎｇ ｂｕｄｇｅｔ）を主に分散コンピューティングシステムのその他のデバイスに割り振ることができ、それによって、最低限のプロセッシングパワーまたはストレージ能力のみを備えることができるその１つのデバイスに最低限の財源（ｍｏｎｅｔａｒｙ ｂｕｄｇｅｔ）を割り振る必要がある一方で、より強力なコンピューティングデバイスの購入が可能となる。

図９ａを見ると、２つのコンピューティングデバイス１１および１３、そしてパーソナルデジタルアシスタント（ＰＤＡ）の形態で示した安価なコンピューティングデバイス１４を有する分散コンピューティングシステム１９が示されている。デバイス１４はＰＤＡとして示されているが、デバイス１１および１３が任意のタイプのコンピューティングデバイスとすることができるのと同様に、それが任意のタイプのコンピューティングデバイスとすることができることを当業者は理解するであろう。しかし、より強力なコンピューティングデバイス１１および１３を購入し、ＰＤＡ、プログラム可能な計算機、さらにはデジタル腕時計などのデバイスを含む、よりパワーの劣るコンピューティングデバイス１２を購入することによって、財源を最も効率的に使用することができるようになる。

投票のための提案を提出するのに先立って、リーダ１３は、投票を行い選択されると、提案された機能を行うことになる動作定足数（ｏｐｅｒａｔｉｏｎａｌ ｑｕｏｒｕｍ）を選択しようと試みることができる。動作定足数の選択は、上記に詳説した提案機能の選択と同様の方法で行うことができる。デバイス１３は、上記に詳説したように、すでに自分自身をリーダデバイスとして確立しているので、動作定足数の提案に移ることができる。そのため、図９ａに示すように、リーダ１３は、提案する動作定足数へのリーダの投票とともに、特定の動作定足数への投票の要求を送ることができる。図９ａに示した特定の例では、リーダ１３は、デバイス１１および１３を備える動作定足数を提案し、その提案およびその投票をデバイス１１および１４の両方に送る。

図９ｂを見ると、デバイス１１および１４のそれぞれが、提案された動作定足数に同意し、その同意をシステム１９のその他のデバイスに通知しているのが示されている。上述したように、本発明によって企図される別の実施形態により、デバイス１３がたった１つのメッセージ８００をデバイス１４などに送ることができる。このような場合、デバイス１４は、デバイス１１および１３に動作定足数の選択について知らせるメッセージ８１４を、それらに送ることができるであろう。

動作定足数が選択されると、それを使って、提案された機能に投票し、実行することができる。それゆえ、図１０ａを見ると、リーダ１３は、クライアント２０から要求９００を受け取って、変数「ｕ」によって表される機能を実行することができる。前述のように、リーダ１３は、要求された機能を実行する提案を、その提案に対するリーダの投票とともにメッセージ９０１で送ることができる。しかし、動作定足数はデバイス１１および１３として選択されているので、デバイス１３は、メッセージ９０１をデバイス１１に送るだけでよい。

図１０ｂを見ると、デバイス１１は、メッセージ９０１に含まれた提案に投票すべきであると判断すると、デバイス１１はそれ自身とデバイス１３が機能「ｕ」の実行に投票したことを知っているので、機能「ｕ」の実行に移ることができる。そのため、図１０ｂに示すように、デバイス１１は、追加のメッセージを待つことなく、機能「ｕ」を実行し、その結果をクライアント２０にメッセージ９１１で送ることができる。上述したように、システムの状態のコピーを維持することもできるリーダは、機能「ｕ」の実行の結果だけでなく、ステップ３０について機能「ｕ」が選択されたことの指示も提供するデバイス１１からのメッセージ９２１を受け取ることができる。あるいは、デバイス１１は、単に、機能「ｕ」の選択の指示だけを送ることができ、デバイス１３がシステム状態の自分自身のコピー上で機能「ｕ」を実行できるようにする。

見て分かるように、デバイス１１および１３は、計算労力の大部分を行うことができ、また、システムの状態を維持することができ、かなりのストレージ資源を必要とする可能性がある。一方、デバイス１４は単に、デバイス１１および１３の動作定足数を選択した定足数の一部であった点で参加しただけである。そのため、前述したように、デバイス１４は安価なデバイスとすることができる。

分散コンピューティングシステム１９は、前に例示し、説明したシステム１０が許容できるのと同様に、依然として１つのデバイスの故障を許容することができる。例えば、図１１ａを見ると、デバイス１１が故障したものとして示されている。デバイス１１の故障は、ピング（ｐｉｎｇｉｎｇ）やタイムアウトなど、様々な手段のいずれかを通してデバイス１３によって検出することができる。デバイス１１はもはや正しく機能していないので、デバイス１３は、動作定足数を、自分自身だけで構成される動作定足数に変更することを提案できる。動作定足数を過半数よりも少なくすることができるが、このような方法で動作定足数を修正する決定は、システム１９の従来の定足数で行うことができ、この定足数は、過半数とすることができる。そのため、デバイス１３は、動作定足数を変更する提案と、その提案に対するそれ自身の投票とを備えるメッセージ１０００を、デバイス１４に送る。

デバイス１４は限定されたプロセッシングまたはストレージ能力を有する安価なデバイスとすることができるので、上記に詳説したように、本発明の一実施形態により、デバイス１４は、以前により大きい提案番号を有する別のメッセージに応答していない限り、それが受け取るあらゆる提案に投票することができる。結果として、デバイス１４は大量の情報を格納する必要がなく、また大規模な処理を行う必要もない。図１１ｂを見ると、デバイス１４は、デバイス１３を含む動作定足数にそれが投票したことを示すメッセージ１０１４でデバイス１３に応答することができる。デバイス１３は、次いで、それ自身、分散コンピューティングシステム１９の定足数として働く。

図１２を見ると、クライアント２０は、変数「ｔ」によって表された機能をシステム１９に実行させる要求１１００を、リーダ１３に送ることができる。しかし、図１１ａおよび１１ｂに示すように、新たな動作定足数はデバイス１３を含むのみである。それゆえ、クライアントの要求１１００を受け取ると、デバイス１３は、その要求を実行すべきかどうかを決定することができ、その要求を実行する場合には、その結果を、リターンメッセージ１１０１の形態でクライアント２０に送信することができる。図１２に示す動作定足数はデバイス１３を含むのみなので、デバイス１３は、クライアントの要求１１００を他のどのデバイスにも提案する必要がなく、要求された機能を実行すべきかどうかを自分だけで決定することができる。同様に、デバイス１３は、要求された機能を実行することを決定すると、この場合も他のどのデバイスからも同意を要求することなく、実行を行い、その結果をクライアント２０に返信することができる。

しかし、当業者であれば理解されるように、分散コンピューティングシステム１９が１つだけのデバイスを用いて状態マシンを実装できるようにすることの欠点は、そのデバイスが故障すると、システムの状態の重複コピーを備えたデバイスが他にはないということである。図１３ａを見ると、デバイス１３は故障しているものとして示されている。一方で、デバイス１１は修理されたものとして示されている。そのため、デバイス１１は、クライアントの要求１２００を受け取ると、デバイス１１のみを含むように動作定足数を変更しようと試みることができる。デバイス１１は現在のリーダデバイスではなかったので、ステップ３１について、３００の提案番号を提案する提案メッセージ１２０１を送ることによって、リーダになることを試みることができる。以下に詳説するように、デバイス１１は、それが知っている以前の最大の提案番号よりも大きい提案番号を選択することができる。デバイス１１は、図１０ａのメッセージ９０１で示すように、ステップ３０について使用されている２００という提案番号について知っているので、デバイス１１は、リーダになろうとするときに、より大きい提案番号を選択することができる。同様に、デバイス１１は、図１０ｂのメッセージ９１１で示すように、ステップ３０に対する機能の実行について知っているので、ステップ３１の機能を提案しようとすることができる。

しかし、図１１ｂのメッセージ１０１４で示すように、デバイス１４はすでにステップ３１に対する投票をキャストしている。それゆえ、上記に詳説した方法で、デバイス１４はデバイス１１にその以前の投票について知らせることができる。図１３ｂを見ると、デバイス１４が最後の投票メッセージ１２１４をデバイス１１に送っているのが示されており、デバイス１４が以前に動作定足数をデバイス１３として設定する、ステップ３１についての提案に投票していることを知らせている。デバイス１１は、次いで、適切な動作定足数がデバイス１３を含み得ると判断し、３１よりも大きいステップについて、デバイス１３を含む動作定足数を提案しようと試みることができる。あるいは、デバイス１１は、任意のその他の機能を提案する前に、デバイス１３が再び動作するのを単に待つことができる。どちらのイベントにおいても、デバイス１１は、デバイス１３がそれだけで定足数を構成したときに何の機能を実行したかを知るまでは、機能を実行することができない。システム１９は、それゆえ、デバイス１３が修理または再開されるまで、さらなる機能を実行できない場合がある。

本発明によって企図される別の実施形態では、動作定足数の選択は、機能の各投票の前に行うことができる。このようにして、現在、動作しているデバイスのみが動作定足数の一部になることができる。しかし、当業者にはわかるように、デバイスがあまり故障しない場合には、このような実施形態は非効率的になることがある。

見て分かるように、デバイス１４などのデバイスに課される要求を減らすことによって、分散コンピューティングシステムのデバイスの１つを、限定されたコンピュテーション能力およびストレージ容量を有する安価なデバイスとして選択することができる。それでも、全体的な分散コンピューティングシステムはフォールトトレラントな方法で動作し続けることができ、安価なデバイスを使用することの唯一の欠点は、故障のために動作定足数が１つのデバイスのみによって実装されている場合に、そのデバイスが、別のデバイスが修理または交換される前に故障すると、システムは、そのシステムを最後に実装していたデバイスが修理されるまで、たとえそれまでに定足数の動作デバイスが存在するとしても、待つことを余儀なくされる場合があるということである。

本発明の原理を適用できる多くの考えられる実施形態に照らして、図面に関連して本明細書に記載した実施形態は例示を目的としたものにすぎず、本発明の範囲を限定するものとして解釈されるべきではないことを認識されたい。例えば、当業者は、ソフトウェアで示した例示の実施形態のいくつかの構成要素をハードウェアで実装できること、またその逆も可能であること、あるいは、例示の実施形態を、本発明の趣旨から逸脱することなく配置および詳細において修正できることを認識されよう。それゆえ、本明細書に記載の本発明は、添付の特許請求の範囲およびその均等の範囲内に含まれるすべてのそのような実施形態を企図している。

本発明の一実施形態を実施することができる例示的な分散コンピューティングシステムを一般的に示すブロック図である。 本発明の一実施形態を実施することができる例示的なコンピューティングデバイスを一般的に示すブロック図である。 本発明の一実施形態によって意図されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図されたマルチステップコンセンサスアルゴリズムの短縮版の動作を一般的に示す図である。 本発明の一実施形態によって意図された簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた簡略化されたコンセンサスアルゴリズムのさらなる動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた簡略化されたコンセンサスアルゴリズムのさらなる動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いた別の簡略化されたコンセンサスアルゴリズムのさらなる動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いたさらに別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。 本発明の一実施形態によって意図された安価なデバイスを用いたさらに別の簡略化されたコンセンサスアルゴリズムの動作を一般的に示す図である。

符号の説明

１０、１９ 分散コンピューティングシステム
１１〜１３、３０、３1 コンピューティングデバイス
１４ 安価なコンピューティングデバイス
２０ クライアントコンピューティングデバイス
１００ コンピューティングデバイス
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ その他のプログラムモジュール
１３７ プログラムデータ
１４０ 非リムーバブル不揮発性メモリインターフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ リムーバブル不揮発性メモリインターフェース
１５１ 磁気ディスクドライブ
１５２ リムーバブルな不揮発性磁気ディスク
１５５ 光ディスクドライブ
１５６ リムーバブルな不揮発性光ディスク
１６０ ユーザ入力インターフェース
１６１ マウス
１６２ キーボード
１７０ ネットワークインターフェース
１７１ 一般的なネットワーク接続
１８０ リモートコンピューティングデバイス
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ

Claims (38)

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. 動作定足数の提案と、前記動作定足数の提案に対する投票と、第２の提案識別子と、第２のステップ識別子とをさらに受信することであって、前記動作定足数の提案に対する投票は、前記第２のステップ識別子によって識別された第２のシステムステップにおいて前記分散コンピューティングシステムの第２の定足数が前記動作定足数の提案を選択したかどうかを前記コンピューティングデバイスに判断できるようにし、前記第２の提案識別子が以前に応答した提案識別子以上の場合、前記動作定足数の提案を選択することと、前記動作定足数の提案の選択についての指示を送信することとを特徴とする請求項３３に記載のコンピューティングデバイス。
38. 前記分散コンピューティングシステムの前記第２の定足数は、前記コンピューティングデバイスと第２の送信デバイスとを備え、前記第２の送信デバイスは、前記動作定足数の提案と、前記動作定足数の提案に対する投票と、前記第２の提案識別子と、前記第２のステップ識別子とを送信しており、前記コンピューティングデバイスは、安価なコンピューティングデバイスであることを特徴とする請求項３７に記載のコンピューティングデバイス。
    

Images