JP2005124171A - 保証された分散型の障害通知を提供する方法 - Google Patents

Abstract

【課題】 保証された分散型の障害通知方法を提供すること。
【解決手段】 障害通知（ＦＮ）機能により、アプリケーションがこの機能を使用してＦＮグループを作成することができ、アプリケーションはＦＮグループにアプリケーション状態を関連付ける。アプリケーションは、ＦＮグループ中のノード上のＦＮ機能に障害ハンドラを登録し、各障害ハンドラは、特定のＦＮグループに関連する。所与のノード上で、ＦＮ機能がＦＮグループ中の障害を知った場合、この機能は、そのノード上の関連する障害ハンドラを実行する。アプリケーションによって検出されたシステム障害は、この機能を使用している他のＦＮグループメンバに伝えられる。この機能は、この機能が実施されているオーバーレイネットワーク中で発生したシステム障害を検出し、他のＦＮグループメンバに障害通知を伝える。
【選択図】 図２

Description

本発明は一般に、分散システムにおける障害通知に関し、より詳細には、分散システム中のノードがそのシステムのどの部分の障害の通知をも受け取ることを保証する方法に関する。

分散システムを構築する際の難題の１つは、システムの一部分が、システム中の他のどこかで発生している重要な障害状態について何も知らないままでいる状況を回避することである。システム中のノード上で稼動するアプリケーションは、データ、リソース、変数、動作条件などのアプリケーション状態について相互に依拠する。したがって、システム中の障害を知らないことは、不正確な挙動と孤立状態の両方を生じる可能性がある。例えば、分散システム中のノードＡ、Ｂ、Ｃを考えてみる。ノードＢおよびＣ上で稼動するアプリケーションは、現在温度Ｔなど、特定のアプリケーション状態についてノードＡに依拠する。ノードＡに障害が発生した場合、あるいはノードＡＢ間またはＡＣ間の通信リンクに障害が発生した場合は、アプリケーション状態はもはや有効ではない。ノードＡに障害が発生したことをノードＢおよびＣが知らない場合、ノードＢおよびＣは、Ｔの現在値が有効であると見なす。しかし、実際のＴが変化したとき、無効なＴを使用するノードＢおよびＣ上のアプリケーションは、誤った結果を生むことになる。したがって、システム中の障害をノードに通知するための障害検出通知サービスが必要とされる。

分散コンピュータシステムにおける障害検出は難しい。分散システムに関する基礎研究によれば、クラッシュしたリモートコンピュータと、非常にゆっくりと稼動しているリモートコンピュータと、ダウンしているネットワークと、その他いくつかの障害シナリオとの間を見分けることは一般に不可能である。このため、障害検出サービスは、すべての障害を完全に報告することはできず、いくつかの状況下での障害を報告するだけである。

以前の障害検出サービスは、複数のコンピュータ上で同じプログラムを並行して実行することによって信頼性および可用性を達成しようとする分散コンピューティング環境で使用されてきた。これらのシステムでは、あらゆる入力がすべてのコンピュータに送られる。この「ロックステップ複製」（ｌｏｃｋ−ｓｔｅｐ ｒｅｐｌｉｃａｔｉｏｎ）または「仮想同期性」（ｖｉｒｔｕａｌ ｓｙｎｃｈｒｏｎｙ）と呼ばれることもあるコンテキストでは、複数のコンピュータのそれぞれがすべての入力を受け取り、何らかの計算をし、（通常は）何らかの出力をユーザに返信する。次いでユーザは、（もし応答が同一でない場合は）おそらくは最も頻繁に現れた応答を決定的なものと考えることによって、応答を集約する。したがって、複数のコンピュータのそれぞれが、グループ中の他のすべてのコンピュータの識別に関して合意する必要がしばしばある。この場合、障害検出サービスの役割は、障害が発生したコンピュータを検出して、この情報をグループのすべてのメンバに伝搬することである。障害検出サービスは一般に、グループメンバシップサービスと密接に統合される。グループメンバシップサービスは、どのコンピュータが分散コンピューティング環境に参加することができるか（場合により、新しいコンピュータの中に加わることから、障害が発生したと思われるコンピュータに取って代わることまで）という問題に対して権限を有する、各コンピュータが実行するローカルサービスである。これらの障害検出サービスは一般に、多数のマシンを同時に扱うのには適さず、また一般に、信頼できるメッセージング基盤が継続的に機能することを条件として、信頼できる障害通知を提供する。

別の障害検出サービスは、いくつかの障害に直面した際に他のどのコンピュータが機能しているかに関してほとんどのコンピュータが合意することを確実にしようとするものだが、すべての障害時にではない。例えば、この障害通知サービスは、完全に到達不可能（ｕｎｒｅａｃｈａｂｌｅ）になったコンピュータだけを検出し、コンピュータのいくつかの対だけが通信できなくなるような通信障害は検出しない。さらに、この障害通知サービスは、複数の小グループを確立することをサポートせず、障害検出サービスに参加しているすべてのコンピュータが、同様に参加している他のすべてのコンピュータを意識していることが必要である。

D. Karger, P. Klein, and R. Tarjan. "A Randomized Linear-Time Algorithm to Find Minimum Spanning Trees." Journal of the Association for Computing Machinery, 42(2), 1995 M. Castro and P. Druschel and A. Kermarrec and A. Rowstron, "Scribe: A Large-Scale and Decentralized Application-Level Multicast Infrastructure," IEEE Journal on Selected Areas in Communications (JSAC) (Special issue on Network Support for Multicast Communications), 20(8), Oct. 2002

したがって、障害通知グループの形成を可能にし、障害通知グループに影響するシステム障害がグループ中のあらゆるコンピュータに確実に通知されることを保証する、軽量かつ分散型の障害通知サービスが、当技術分野で必要とされている。

本発明は一般に、ネットワーク中のコンピュータのグループ上で動作する分散システム中で障害通知を保証する方法を対象とする。本発明によれば、分散システム中のコンピュータのグループによって障害通知（ＦＮ）グループが形成される。ＦＮグループは、システム中のすべてのコンピュータ間で形成することもでき、システム中のコンピュータの任意のサブセット間で形成することもできる。さらに、システム中の同じコンピュータセット上で、重複する複数のＦＮグループが使用されてもよい。このＦＮグループのメンバには、ＦＮグループ中のメンバに影響する分散システム中のどんな障害も確実に通知され、それによりグループメンバは、障害に応答して適切な措置を講じることができる。あるノード上にＦＮグループが（前に作成されたために）存在する場合、このノード上のアプリケーションは、ＦＮグループについての障害ハンドラを登録することによって、このグループに状態を関連付けることができる。本発明は、障害状況がＦＮグループに影響するときは常に障害ハンドラが呼び出されることを保証し、次いで障害ハンドラは、状態に対して適切に作用することができる。障害ハンドラを所望のグループに正しく関連付けることができるように、ＦＮグループを作成する動作では、このＦＮグループが知られるための一意識別子も作成する。

ＦＮグループ中のコンピュータが障害の発生を確認したとき、このコンピュータは、このＦＮグループのための障害通知を、到達可能なすべてのＦＮグループメンバに伝える。障害通知を受け取ったＦＮグループメンバであって、（一意識別子で示される）このＦＮグループについての障害ハンドラを保持するメンバは、障害ハンドラを呼び出すべきであると認識する。次いで、このＦＮグループに関連する障害ハンドラがグループメンバによって実行され、適切なアプリケーションレベルの動作（例えばガーベージコレクション（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｉｏｎ）がアプリケーション状態に対して実施される。ＦＮグループメンバが到達不可能だがクラッシュはしていない場合、このメンバもやはり障害を知ることになる。すなわち、特定のＦＮグループの継続的な存在を確認するピーン（ｐｉｎｇ）を他のＦＮグループメンバから受け取ることができないことは、このＦＮグループが死んでいることの明示的な通知を受け取るのと同じ効果を有する。

ノードは、それらが属するあらゆるＦＮグループについての障害ハンドラを登録している必要はない。例えば、特定のノードＡは、別のノードＢが到達可能かどうかを監視するために、それ自体とノードＢとを含むＦＮグループを作成すことができるが、この時点では、２つのノード間でアプリケーションレベルの協調動作を開始する必要はない。この例では、ノードＢには、この障害通知グループについての障害ハンドラを登録する理由はない。

障害が発生したかどうかを確認するために、本発明は３つの方法を提供する。ある方法では、各ＦＮグループメンバが、他のあらゆるＦＮグループメンバに直接にピーンする。ピーンされたＦＮグループメンバがピーンに応答できない場合、ピーンを送ったＦＮグループメンバは、ＦＮグループに障害通知を伝える。第２の方法では、ツリートポロジを使用してピーン義務を分散させる。各ＦＮグループメンバはツリー中のノードとして確立され、各ノードは、ツリー中の隣接ノードだけにピーンする義務を負う。この場合もやはり、ピーンされたＦＮグループメンバがピーンに応答できない場合、ピーンを送ったＦＮグループメンバは、ＦＮグループに障害通知を伝える。

障害が発生したかどうかを確認するための第３の方法では、本発明は既存のオーバーレイネットワークの最上部で実施される。オーバーレイネットワークは、ネットワーク中のコンピュータへのアプリケーションレベルのルーティングを提供し、基礎をなすネットワークレベルのルーティングプロトコル（例えばインターネットプロトコル（ＩＰ）ルーティング）に依拠してアプリケーションレベルのルーティングを実施する。オーバーレイネットワークを維持するために、各コンピュータは、オーバーレイネットワーク中のコンピュータのサブセットのリストを保持し、これらのコンピュータに定期的にピーンして、これらのコンピュータが生きているかどうか確認する。本発明はこのオーバーレイ維持を利用して、オーバーレイネットワーク中のノードが有するリスト中のコンピュータが死んでいる場合、すなわち予想どおりにピーンに応答しなかった場合には、ノードが本発明に通知することを必要とする。次いで本発明は、報告されたオーバーレイ障害がＦＮグループの２つのメンバ間の通信パスに沿ったものかどうかを決定する。オーバーレイ障害が２つのＦＮグループメンバ間のパスを切断する場合は、障害通知がすべてのＦＮグループメンバに伝えられる。

本発明の他の特徴および利点は、添付の図を参照しながら進める、例示的な実施形態に関する以下の詳細な記述から明らかになるであろう。

本発明の特徴については添付の特許請求の範囲に詳細に述べるが、本発明は、その目的および利点と合わせて、添付の図面と共に以下の詳細な記述を読めば最もよく理解することができる。

図面に目を向けると、適したコンピューティング環境で実施されているものとして本発明が示されており、これらの図面では、同じ参照番号は同じ要素を示す。必須ではないが本発明は、プログラムモジュールなど、パーソナルコンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含めて、その他のコンピュータシステム構成でも実施できることは、当業者なら理解するであろう。本発明は分散コンピューティング環境で実施することもでき、その場合、タスクは通信ネットワークを介してリンクされたリモート処理デバイスによって実施される。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリ記憶デバイスに位置することができる。

図１に、本発明を実施するのに適したコンピューティングシステム環境の例１００を示す。コンピューティングシステム環境１００は、適したコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲についてどんな制限も意味しない。またコンピューティング環境１００は、この例示的な動作環境１００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存や要件を有するものとも解釈すべきではない。

本発明は、その他多くの汎用または専用コンピューティングシステム環境または構成でも機能する。本発明で使用するのに適すると思われる周知のコンピューティングシステム、環境、および／または構成の例には、限定しないがパーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータや、これらのシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

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

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータシステム１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、限定しないが処理ユニット１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ）ローカルバス、およびＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス（メザニンバスとも呼ばれる）が含まれる。

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

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３が記憶されている。ＲＡＭ１３２は通常、処理ユニット１２０がすぐにアクセス可能な、かつ／または処理ユニット１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７を示す。

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

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

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、図１にはメモリ記憶デバイス１８１しか示していないが、通常はパーソナルコンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、インターネットでよくみられる。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１上にあるものとして示す。図示のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。

次に、図１Ｂを参照して、本発明を使用することのできるネットワーク化された環境の例について述べる。この例示的なネットワークは、雲で表すネットワーク１１１を介して相互に通信する複数のコンピュータ１１０を含む。ネットワーク１１１は、ルータ、ゲートウェイ、ハブなど、周知のコンポーネントを含むものとすることができ、コンピュータ１１０が有線媒体および／または無線媒体を介して通信できるようにする。１つまたは複数のコンピュータは、ネットワーク１１１を介して相互に対話するとき、他のコンピュータに対するクライアント、サーバ、またはピアとして働くことができる。したがって、本明細書に含まれる特定の例ではこれらすべてのタイプのコンピュータには言及しないが、本発明の様々な実施形態は、クライアント、サーバ、ピア上で、またはこれらの組合せで実施することができる。

以下の記述では、特に指示がない限り、１つまたは複数のコンピュータによって実施される動作および象徴的な操作表現に関して本発明を述べる。したがって、このような動作および操作は、コンピュータによって実行されるものとして述べる場合があるが、データを構造化形式で表す電気信号をコンピュータの処理ユニットによって処理することを含むことは、理解されるであろう。この処理は、コンピュータのメモリシステム中の各位置でデータを変形または維持し、これにより、コンピュータの動作は、当業者によく理解される方式で再構成されるかさもなければ改変される。データが維持される場所であるデータ構造は、データのフォーマットで定められる特定のプロパティを有する、メモリの物理位置である。ただし、本発明を前述のコンテキストで述べるが、これは限定を意味するのではなく、以下に述べる様々な動作および操作はハードウェア中で実施することもできることを当業者なら理解するであろう。

本発明によれば、障害通知（ＦＮ）機能は、ネットワーク１１１中のコンピュータ１１０の分散グループのメンバのいずれかが障害通知をグループの他のあらゆる生きているメンバに通信できることを保証する。ＦＮ機能は、ネットワーク１１１中のコンピュータ１１０上で実行されるアプリケーション、サービス、オペレーティングシステム、またはその他の任意のソフトウェア中で実施される。ＦＮ機能は、ネットワーク１１１中のコンピュータ１１０上で稼動する他のアプリケーションへのアプリケーションプログラムインタフェース（ＡＰＩ）を提供する。本明細書で使用される「アプリケーション」という語は、本発明のＦＮ機能を使用するソフトウェアを指し、限定しないが分散システム、分散アプリケーション、ミドルウェアが含まれる。

コンピュータ１１０は、ネットワーク１１１中の「ノード」と呼ばれる。「障害通知（ＦＮ）グループ」は、ＦＮ機能を提供すると共に分散システムとして働く協働ノードのグループを指し、ＦＮグループのすべてのメンバは、システム中の障害を確実に知る。図２に本発明を階層的に抽象化したものを示すが、これは、ＦＮ機能２００が、アプリケーション２０１と、通信リンク２０３で相互に接続されたノード２０２との間の媒介として働くのを示している。ノードのグループ上で稼動する分散アプリケーションは、ＦＮ機能を使用してＦＮグループを作成し、それにより、分散アプリケーションを実行しているすべてのノードがシステム障害を知るようにする。

本発明の一実施形態の例示的な適用例を通して、本発明は、障害通知の受信を保証するものとして概念的に理解されるであろう。あらゆるグループメンバが、「ＯＫか？」というメッセージを使用して、他のあらゆるグループメンバに定期的にピーンするというＦＮグループを考えてみる。ノード障害、ネットワーク切断、ネットワーク分割、一時的な過負荷など、いずれかの理由でＯＫでないグループメンバは、何らかのピーンに応答できなくなる。この応答失敗を、本明細書では一般に通信障害と呼ぶ。果たされなかったピーンを開始したグループメンバ、したがって通信障害を検出したグループメンバは、このＦＮグループについてのすべてのピーンにそれ自体で応答するのを止めることによって、また任意選択で障害通知メッセージを他の到達可能なＦＮグループメンバに渡すことによって、グループの残りに障害通知が伝搬することを保障する。したがって、本発明は、通信障害の個別の観察がグループ通知に変換されることを保障する。この方式は、どんなパターンの切断、分割、または障害も、クラッシュしていないあらゆる参加者が確実に受け取れる障害通知に変える。

引き続き本発明のこの例示的な適用例を考えながら、障害発見時に明示的な障害通知メッセージが送られるという本発明の別の実施形態について述べる。明示的な障害通知メッセージの効果は、グループ内のいくらかの参加者がグループの他のメンバとまだ通信することができるかどうかにかかわらず、クラッシュしていないあらゆる参加者によって、定期的なピーン期間の２倍以内で経験されることが保証される。というのは、本発明が実施する明示的な通知は、明示的な通知メッセージを送るノードが、明示的な通知メッセージを実際に送ることに加えて、グループの継続的な存在を確認するピーンに応答するのを止めることによって、実施されるからである。この文書の残りの部分において「グループが通知を受ける」という語は、さらに詳述されない場合、すべてのグループメンバへの何らかの障害通知送信を意味し、任意選択で障害通知メッセージの明示的な送達の試みも含むものと理解されたい。

本発明の第１の実施形態によれば、分散システム中で障害通知を保証する方法が提供される。この方法では、ネットワーク中の複数のノードを含むＦＮグループが作成される。障害通知グループは、障害通知グループのいくつかまたはすべてのノード上で稼動する分散アプリケーションの障害処理メソッドに関連付けられる。障害通知グループ中のノード間の通信障害（前述のように、通信リンク障害、ノード障害、またはその他の何らかの原因を反映したものである場合がある）が、障害通知グループ中のノードによって検出される。通信障害が検出されると、障害通知が伝えられる。障害通知グループのノードが障害通知を受け取ると、障害通知グループに関連する障害処理メソッドがこのノード上に存在すればそれが実行される。

ＦＮグループの作成は、作成主ノード上で稼動するアプリケーションが、ＦＮグループに含めるノードのセットと共にＣｒｅａｔｅＧｒｏｕｐ（グループ作成）インタフェースを呼び出すことによって開始する。この呼出しは、ＦＮグループについての、大域的に一意の障害通知識別子（ＦＮＩＤ）を生成する。セット中の各ノードが何らかの順序で（場合によっては同時に）接触を受け、ノードの存在が検証される。セット中のすべてのノードにうまく接触できる場合、すなわち、作成主ノードと他のＦＮグループメンバとの間に生きた通信リンクがある場合は、ＦＮグループはすべてのメンバ上でうまく確立され、「成功」が作成主アプリケーションに返される。

ＦＮグループを作成するアプリケーションは、障害ハンドラを作成主ノードにインストールすることによって、アプリケーション状態をこのグループに関連付ける。さらに、作成主ノード上のアプリケーションは、ＦＮグループメンバのいくつかまたはすべてに対して、アプリケーション特有の方式で、ＦＮグループのＦＮＩＤと共にアプリケーション状態を招待メッセージ中で明示的に送る。招待メッセージを受け取った各ＦＮグループメンバは、次いで、招待メッセージに含まれるアプリケーション状態およびＦＮＩＤに関連するこのＦＮグループについての障害ハンドラを確立する。障害ハンドラは、招待メッセージを受け取ったノード上で稼動するアプリケーションおよび関連するアプリケーション状態に特有である。例えば、障害ハンドラは、ＦＮグループに関連するアプリケーション状態のガーベージコレクションを実施するものとすることもでき、あるいは新しいＦＮグループを使用してアプリケーション状態の再確立を試みるものとすることもでき、あるいは単に任意のコードを実行するものとすることもできる。

ＦＮグループについての障害通知が受け取られた場合、このＦＮグループに関連するインストール済みのアプリケーション状態があれば、アプリケーションによってガーベージコレクションされるか、そうでない場合は更新される。アプリケーションが、存在しないＦＮグループにハンドラを関連付けようとした場合は、障害ハンドラはすぐに呼び出される。この挙動は、それまでＦＮグループを意識していたＦＮグループメンバに障害通知が届かないことがないように、まず第一に保証することの一部である。ＦＮグループを作成する試みは、常に２つの可能な結果のうちの一方をもたらす。すなわち、（１）ＦＮグループの作成が成功し、作成主アプリケーションにＦＮグループＩＤが通知されたか、（２）ＦＮグループの作成が失敗し、作成主アプリケーションに失敗が通知されたかである。ＦＮグループ作成の成功に続いて、作成主アプリケーションはその後、グループＩＤ、およびグループに関連付けられる任意のアプリケーション状態をグループメンバに通信し、それにより、障害通知時にこの状態に対して作用する障害ハンドラをグループメンバが確立できるようにする。

図３ａに、アプリケーションがＦＮ機能を利用してＦＮグループを作成するときにＦＮ機能によって実行される方法を示す。ステップ３００で、ＦＮ機能は、ＦＮグループについてのノードのセットを受け取る。ステップ３１０で、ＦＮ機能は、セット中のあらゆるノードと接触し、潜在的なＦＮグループノードとうまく通信することができるかどうか判定する。ステップ３２０で、ＦＮ機能がすべての潜在的ＦＮグループノードとうまく通信できると判定した場合は、ステップ３３０に進む。そうでない場合はステップ３４０に進み、ＦＮ機能はＦＮグループの作成が失敗したことを通知する。ステップ３３０で、ＦＮ機能はＦＮＩＤを生成し、このＦＮＩＤをアプリケーションに返して、ＦＮグループがうまく作成されたことを示す。

図３ｂに、ＦＮ機能からＦＮＩＤを受け取った後にアプリケーションによって実行される方法を示す。ステップ３５０で、アプリケーションは、ＦＮ機能からＦＮＩＤを受け取る。ステップ３６０で、アプリケーションは、ＦＮグループノード上のアプリケーションにメッセージを送り、ＦＮグループのＦＮＩＤ、およびＦＮＩＤに関連するアプリケーション状態を示す。ＦＮグループノード上のアプリケーションは、ＦＮＩＤとアプリケーション状態とを含むメッセージを受け取り、次いで、そのノード上のＦＮ機能を使用して、アプリケーション障害処理メソッドをＦＮＩＤに登録する。この登録は、後で説明するＦＮ機能のＲｅｇｉｓｔｅｒＦａｉｌｕｒｅＨａｎｄｌｅｒ（障害ハンドラ登録）関数を呼び出すことによって実施する。作成主ノード上のアプリケーションもまた、同様にして障害処理メソッドを登録する。

この手法の利点は、ＦＮグループノード上のアプリケーションが、確立することのできないグループについて知ることがない点である。これは、アプリケーション状態および関連する障害ハンドラを確立したのに、結局その後すぐに障害ハンドラが呼び出されてアプリケーション状態をガーベージコレクションしなければならないだけに終わる場合が、より少ないことを意味する。第２の利点は、ＦＮグループおよびそれに関連する任意の状態に関する情報をグループメンバに通信するかどうか、またいつどのように通信するかについて、アプリケーションがより多くのフレキシビリティを有する点である。

ＦＮグループに参加する各ノード上のアプリケーションは、ＲｅｇｉｓｔｅｒＦａｉｌｕｒｅＨａｎｄｌｅｒ関数を使用して、そのＦＮグループ中での障害通知のための障害ハンドラを登録する。この関数は、障害処理メソッドおよびＦＮＩＤをそのパラメータとし、ＦＮＩＤを障害処理メソッドに登録する。障害処理メソッドは、障害が検出されたために、またはＦＮグループメンバの１つのメンバ上でアプリケーションが障害イベントを明示的に伝えたためにそのＦＮＩＤを有するＦＮグループが通知を受けたときは、常に呼び出される。ＲｅｇｉｓｔｅｒＦａｉｌｕｒｅＨａｎｄｌｅｒが、障害が発生したものとすでに伝えられたＦＮＩＤパラメータ、または存在しないＦＮＩＤパラメータと共に呼び出された場合は、障害処理メソッドがすぐに呼び出される。

ＲｅｇｉｓｔｅｒＦａｉｌｕｒｅＨａｎｄｌｅｒ関数がアプリケーションによって呼び出されると、ＦＮ機能は、障害処理メソッドをＦＮＩＤに関連付ける。したがって、このＦＮＩＤを示す障害通知が受け取られたときは、ＦＮ機能は、ＦＮＩＤがこれらのアプリケーション障害処理メソッドに関連するものと認識し、これらの障害処理メソッドを実行する。

ＦＮグループが作成された後、ＦＮグループノード上のアプリケーションは、ＦＮグループメンバ間に障害がなかったときでも、ＳｉｇｎａｌＦａｉｌｕｒｅ（障害信号）関数を呼び出すことによって障害通知を明示的に伝えることができる。ＳｉｇｎａｌＦａｉｌｕｒｅ関数は、障害通知が伝えられることになるＦＮグループのＦＮＩＤをそのパラメータとする。アプリケーションがこの関数を呼び出すことがあるのには、多くの理由がある。このようなシナリオの一例は、アプリケーションが、そのアプリケーション特有の目的には通信リンクが不十分であると（ＦＮ機能はおそらくこのリンクを介してどうにか通信しているにもかかわらず）決定したときである。前述の本発明の実施形態では、ＳｉｇｎａｌＦａｉｌｕｒｅが呼び出されると、ＦＮ機能は、ＦＮグループについてのピーンメッセージに応答するのを止めることによって、障害をＦＮグループメンバに通知する。しかしＦＮ機能は、このＦＮグループに関係のないメッセージ、例えば別のＦＮグループについてのピーンメッセージにはまだ応答することになる。追加の実装形態では、到達可能なＦＮグループメンバに明示的な障害通知メッセージも送ることができる。

図４ａに、ＣｒｅａｔｅＧｒｏｕｐ、ＲｅｇｉｓｔｅｒＦａｉｌｕｒｅＨａｎｄｌｅｒ、ＳｉｇｎａｌＦａｉｌｕｒｅ関数を含む、本発明のこの実施形態のＡＰＩを示す。図４ｂには、後述する本発明の別の実施形態のＡＰＩを示す。

ＦＮグループ中の各ノードは、ＦＮグループの継続的な存在を定期的に検証するために、ＦＮグループ中の１つまたは複数の他のノードへの接続性を維持しなければならない。この接続性を維持するのに使用される方法は、スケーラビリティ、信頼性、ユーザのセキュリティ要件によって決まる。ＦＮグループ中の接続性を維持する方法の１つでは、作成主ノードが、すべてのＦＮグループメンバに、ＦＮグループ中の他のメンバを通知する。次いで、ＦＮグループ中の各ノードは、ＦＮグループ中の他のあらゆるノードに定期的にピーンする（このピーンは、ユーザデータグラムプロトコル（ＵＤＰ）ピーンとして、またはＴＣＰソケットを開いて、またはよく知られた任意の数の生死チェック方法のうちの１つとして実施することができる）。通信障害が検出された場合、例えばピーンされたノードが応答できなかった場合は、障害通知がＦＮグループの残りに伝えられる。定期的なピーン送信によってＯ（ｎ^２）のメッセージの複雑さが必要とされるので、この手法は、中程度のサイズのＦＮグループに対してもあまりスケール（ｓｃａｌｅ）しない。さらに、ネットワークピーントラフィックの総計は、システム中に存在するＦＮグループの数において加法的な傾向がある。しかし、どんなインフラストラクチャサポートも必要ないという利点がある。

ＦＮグループ通知は不必要に生成されることがあり、このような通知を偽陽性と呼ぶ。例えば、偽陽性の原因の１つは、一時的なリンク障害である。本発明は、偽陽性の数を最小限に抑えることを試みる。この方法の偽陽性率は、追加の障害にそれ自体が寄与することになるかもしれないどんな第三者「媒介」ノードも生死監視および接続性監視に関与しないことによって助けられている。しかし、すべてのＯ（ｎ^２）潜在的通信パスが監視されるので、またほとんどのアプリケーションは実際にはこれらのパスの小さいサブセットしか使用しないので、実際に使用されているパスだけが監視されたなら見えたであろう一時的通信障害よりもずっと多くの一時的通信障害を観察する可能性がある。

この手法によって受ける通知待ち時間は短く、最悪の場合の待ち時間は２タイムアウト期間であり、平均的な場合の待ち時間は１タイムアウト期間未満である。最も重要なのは、この手法がセキュリティ攻撃を非常に受けにくいことである。システム中のどんな悪意あるノードも、悪意あるノード自体以外のノードによって引き起こされた障害通知をＦＮグループのメンバが受け取るのを妨げることはできない。また、少なくともＦＮグループメンバが障害通知の送信元を認証するための何らかの手段を有する場合は、悪意あるノードは、それが属するＦＮグループに対してしかサービス拒否（ＤｏＳ）攻撃を開始することができない。

したがって、分散システム中で障害通知を保証する方法が提供される。障害通知が失敗しないことを確実にすることにより、本発明は、協働して処理したい状態を有するノード間での障害処理を大幅に単純化する。本発明は、ＦＮグループのすべてのメンバに、グループに影響するどんな障害状況も効率的かつ確実に通知する。本発明を使用するアプリケーションは、障害メッセージが届かなかったり、システム中に孤立状態が残ったりすることを心配する必要はない。

本発明の別の実施形態では、障害通知グループを作成するための代替方法が提供される。前の実施形態と同様、ＦＮグループの作成は、作成主ノードにおけるアプリケーションが、ＦＮグループに含めるノードのセットと共にＣｒｅａｔｅＧｒｏｕｐインタフェースを呼び出すことによって開始する。前の実施形態とは異なり、この関数は、ノードセットパラメータに加えてアプリケーション状態もパラメータとする。図４ｂに、修正されたＡＰＩを示す。

本発明のこの実施形態は、ＦＮグループについての、大域的に一意の障害通知識別子（ＦＮＩＤ）を生成する。セット中の各ノードが何らかの順序で（場合によっては同時に）接触を受け、確立されつつある新しいＦＮグループに加わるよう要求される。この招待メッセージには、確立されつつあるＦＮグループのＦＮＩＤ、ならびにＦＮグループに関連付けられるアプリケーション状態が含まれる。ＦＮグループ中のすべての招待されたノードがうまくＦＮグループに加わった場合は、成功が作成主アプリケーションに返される。前の実施形態と同様、ＦＮグループ中の各ノードにあるアプリケーションは、ＦＮＩＤに関連するアプリケーション状態についての障害ハンドラを確立する。

いずれかのＦＮグループメンバに到達不可能な場合は、ＦＮグループの確立は失敗し、「失敗」が作成主ノードのアプリケーションに返され、すでに招待メッセージを受け取ったすべてのノードに通知される。ＦＮグループのことを知ったが、その後で到達不可能になったグループメンバも同様に、他のＦＮグループメンバと通信できないことによって障害を検出する。この検出された障害により、障害が発生したグループに関連するすべてのアプリケーション状態に対して、アプリケーション特有の障害処理（例えばガーベージコレクション）が行われる。

図５に、アプリケーションがＦＮ機能を利用してＦＮグループを作成するときにＦＮ機能によって実行される方法を示す。ステップ５００で、ＦＮ機能は、ＦＮグループについてのノードのセットと、ＦＮグループに関連付けるアプリケーション状態を受け取る。ステップ５１０で、ＦＮ機能はＦＮＩＤを生成する。ステップ５２０で、ＦＮ機能は、ＦＮＩＤとアプリケーション状態とを含む招待メッセージを、ノードセット中の各ノードに送る。ステップ５３０で、すべてのノードがうまく招待メッセージを受け取った場合は、ステップ５４０に進み、ＦＮ機能は、ＦＮグループがうまく作成されたことをアプリケーションに通知し、ＦＮＩＤを返す。すべてのノードがうまく招待メッセージを受け取らなかった場合は、ステップ５５０に進み、ＦＮ機能は、すでに招待メッセージを受け入れることによってＦＮグループに加わったＦＮグループノードに、障害通知メッセージを発行する。ステップ５６０で、ＦＮ機能は、ＦＮグループがうまく作成されなかったことをアプリケーションに通知する。アプリケーションは、前の実施形態と同様に障害ハンドラを登録する。

したがって、ＦＮグループを作成する試みは、常に２つの可能な結果のうちの一方をもたらす。すなわち、（１）ＦＮグループの作成が成功し、ＦＮグループメンバはグループに関連付けるアプリケーション状態を受け取り、ＦＮグループメンバは障害通知時のグループについての（例えばその状態をガーベージコレクションするための）障害ハンドラを確立したか、（２）ＦＮグループの作成が失敗し、ＦＮグループに関連付けるアプリケーション状態を通知されたＦＮグループメンバは、その障害ハンドラが呼び出された（おそらく障害ハンドラにその状態をガーベージコレクションさせた）かである。したがって、ＦＮグループ作成中（または作成後）に失敗すると、ＦＮグループに関連するすべての状態は回収される。

本発明の別の実施形態では、接続性を維持するための別の方法が提供される。接続性および生死を監視するために、ＦＮグループのノード間でスパニングツリーを構築する。スパニングツリーを構築するには、ＦＮグループ中の各ノードをグラフ中の頂点と考え、グラフ中のあらゆるノードがグラフ中で循環せずに接続されるようにノード間の接続を生み出す。これらの接続は、スパニングツリーに似たルーティングトポロジを実現する。ノード間の接続は、第１ノードが第２ノードへのポインタを子ノードとして記録し、第２ノードも同様に第１ノードへのポインタを親ノードとして記録したときに形成される。

例えば、図６に例示的なスパニングツリーを示すが、作成主ノードであるノード１がツリーのルートノードであり、ノード１はノード２および３へのポインタを記録しており、ノード２および３はノード１の子ノードである。ノード２と３は両方とも、ノード１へのポインタをその親ノードとして記録している。ノード２はまた、その子ノードであるノード４へのポインタも記録している。ノード４は、ノード２へのポインタをその親ノードとして記録しており、ノード５および６へのポインタをその子ノードとして記録している。ノード３、５、６は、ポイントする子ノードを持たず、したがってスパニングツリーのリーフである。

この接続性維持方法では、ツリー中の各ノードは、それに隣接するノードだけにピーンする。ツリー中で、ノードが親子関係の一部である場合に、それらのノードは隣接している。例えば図６で、ノード４はノード２、５、６に隣接するが、ノード３はノード１に隣接するだけである。各ノードはその親ノードおよび子ノードにピーンするだけなので、ピーントラフィックの量が削減される。障害が検出されたとき、検出したノードは、ＦＮグループについてのピーンに応答するのを止める。さらに、スパニングツリーを使用して、障害通知をその親ノードおよび子ノードに送ることによって障害通知メッセージを広めることもできる。障害通知を受け取ったノードは、障害通知をその親および子ノードに転送する。この結果、スパニングツリー中のあらゆるノード、すなわちＦＮグループ中のあらゆるノードは、最終的に、果たされなかったピーンを通して通信障害を検出することによって、または明示的な障害通知メッセージを受け取ることによって障害を知る。

この方法は大規模なグループをサポートするが、システムが多量のＦＮグループを含む場合は、やはりかなりの量のプロービング（ｐｒｏｂｉｎｇ）トラフィックを生成する。ピーントラフィックはＦＮグループのメンバノード間だけで生じるが、ＦＮグループ内のすべての可能な通信パスを監視することはないという点で、この方法の偽陽性率は、直接ピーン方法の偽陽性率とほぼ同様のはずであり、おそらくそれよりもやや低い。スパニングツリーを介した通知メッセージの同報通信を素早く行うことができると仮定すると、平均的な場合の通知待ち時間もほぼ同様のはずである。最悪の場合の通知待ち時間は、使用されるツリー構築アルゴリズムの詳細によって決まる。当技術分野で周知の例示的なスパニングツリーアルゴリズムが記載されており（例えば、非特許文献１参照。）、この文献の全体を参照により本明細書に組み込む。この論文の方法は、各パスに課されるコストを入力とする。当技術分野で周知のパスコスト割当て方法の１つは、往復パス待ち時間をコストとして使用するものであり、待ち時間は３つの別々の試行の中央値をとることによって推定される。

この方法のセキュリティ攻撃の受けやすさは、悪意あるグループメンバノードに関してのものである。グループに属さないノードは、障害通知メッセージがグループメンバに送達されないようにすることはできず、偽の障害通知メッセージを注入してＤｏＳ攻撃を開始することもできない。しかし、悪意あるグループメンバは、他のメンバに本物の障害通知が聞こえないようにすることができ、またＤｏｓ攻撃を開始することができる。この方法のスパニングツリー手法は、直接ピーン方法よりもよくスケールするが、システムが多くのグループを含むときは、やはり余分なプロービングトラフィックを生じる。

本発明の別の実施形態によれば、接続性を維持するための別の方法が提供される。この方法は、既存のオーバーレイネットワークを使用して接続性および生死を監視する。オーバーレイネットワークは、基礎をなすルーティングトポロジ（すなわちＩＰルーティング）の最上部に存在して機能する、オーバーレイノード間のアプリケーションレベルのルーティングトポロジである。適したオーバーレイネットワーク実装形態の１つとしてＳｋｉｐＮｅｔが、本願の譲受人に譲渡され、全体を参照により本明細書に組み込む米国特許出願第１０／３５６９６１号明細書に記載されている。任意のオーバーレイネットワークを使用することができるが、この接続性維持方法は、オーバーレイネットワークがオーバーレイネットワーク中のノード間で能動的にピーンを実施してネットワーク中の生死および接続性を維持するときに、最も有利である。本発明のこの実施形態は、基礎をなすルーティング技術によって提供されるＦＮグループメンバ間の直接的な接続性を、オーバーレイネットワークによって提供される接続性で置き換えることによって、スケーラブルなオーバーレイルーティング技術を利用してＦＮグループ中の接続性を監視する。

図７に、例示的なオーバーレイネットワークトポロジを示す。オーバーレイネットワークは、オーバーレイネットワーク中のノード１〜１２の間でアプリケーションレベルのルーティングを提供する。オーバーレイネットワーク中の各ノードは、通信リンクを共に確立したノードのルーティングテーブルを維持する。例えば図７では、ノード２は、そのルーティングテーブル中でノード１および３へのポインタを維持し、ノード３は、そのルーティングテーブル中でノード２、４、７へのポインタを維持する。したがって、ノード４がノード１にメッセージを送る場合、このメッセージは、ノード４と１の間のオーバーレイルーティングパス中でノード３および２を横断しなければならない。ネットワーク中の生死および接続性を維持するために、各ノードは、そのルーティングテーブル中のノードに定期的にピーンする。あるノードがピーンに応答できない場合、ピーンの送信元は、そのルーティングテーブルを更新して、応答しないノードを削除する。あるノードが、そのルーティングテーブル中にないノードからピーンを受け取った場合、その新しいノードへのポインタでそのルーティングテーブルを更新することができる。

ＦＮ機能を既存のオーバーレイネットワークの最上部で実施するために、オーバーレイネットワークは、次のことを提供にしなければならない。すなわち、１）オーバーレイネットワークの中をメッセージがルーティングされる結果として、あらゆる中間ノード上でアプリケーションレベルのアップコール（ｕｐｃａｌｌ）が行われること（オーバーレイネットワークから見ればＦＮ機能はアプリケーションとして扱われる）、および、２）ノードのルーティングテーブルが変更される結果として、その変更を詳述するアプリケーションレベルのアップコールが行われることであり、変更は、オーバーレイ通信障害と、オーバーレイネットワーク中に新しい近隣ノードが出現したことで生じた変更とのどちらかである場合がある。すなわち、各オーバーレイノードは、ノードを横断するすべてのメッセージと、すべてのルーティングテーブル変更を、ＦＮ機能に通知しなければならない。

ＦＮグループ中の接続性を監視するためのこの方法では、障害通知を広めるためのマルチキャストツリーが構築される。マルチキャストツリーは、基本的には前述のようなＦＮグループノードのスパニングツリーだが、ＦＮグループの作成主ノードと、ＦＮグループの他のすべてのノードとの間のオーバーレイルーティングパス中の、あらゆるノードも含む。構築できるマルチキャストツリーのタイプの１つは、スクライブ（Ｓｃｒｉｂｅ）ツリーであり（例えば、非特許文献２参照。）、この文献の全体を参照により本明細書に組み込む。本発明は、ＦＮ機能が、マルチキャストツリーに加わることになるあらゆるノード上で稼動していると仮定する。

マルチキャストツリーは、ＦＮグループが作成主ノードによって作成されるときに構築される。アプリケーションが、ＦＮＩＤ（および場合によっては前述のようにアプリケーション状態）を含むセットアップメッセージを各ＦＮグループノードに送ると、セットアップメッセージは、ＦＮグループＩＤとルーティングパス近隣ノードとを記憶する内部状態を設定する。この内部状態は、作成主ノードとＦＮグループノードとの間のオーバーレイルーティングパス中でセットアップメッセージが横断する各ノードで使用される。この内部状態は、このノードが、このノードで受け取るすべてのメッセージ、ならびにすべてのルーティングテーブル変更情報を、このノード上で稼動するＦＮ機能に送達すべきであることを指示する。セットアップメッセージが作成主ノードとＦＮグループノードとの間のオーバーレイルーティングパス中のノードを横断するのに伴って、パス中の各ノードは、メッセージを送ってきたノードへのＦＮグループポインタを記録する。ＦＮグループノードからの確認メッセージが、記録されたポインタを使用して同じパス中のオーバーレイノードを横断するのに伴って、各ノードは再び、確認メッセージを送ってきたノードへのＦＮグループポインタを記録する。この結果、作成主ノードと、ＦＮグループに特に関連するＦＮグループノードとの間のオーバーレイルーティングパス中に、双方向通信リンクが生み出される。

本発明の別の実施形態では、マルチキャストツリーを生み出すのに必要なのは、セットアップメッセージだけである。セットアップメッセージが作成主ノードとＦＮグループノードとの間のオーバーレイルーティングパス中のノードを横断するのに伴って、パス中の各ノードは、メッセージを送ってきたノードへのＦＮグループポインタを記録する。この実施形態では、パス中の各ノードは、オーバーレイルーティングパス中の次のノードへのＦＮグループポインタも記録し、このノードにセットアップメッセージを転送する。これは、オーバーレイネットワークが「ＮｅｘｔＨｏｐ」呼出しをサポートするときに達成され、この呼出しは、メッセージが引き続きルーティングされたとき次にどのオーバーレイノードに遭遇することになるかを、オーバーレイノード上で稼動するＦＮ機能に通知することができる。この結果、作成主ノードと、ＦＮグループに特に関連するＦＮグループノードとの間のオーバーレイルーティングパス中に、双方向通信リンクが生み出される。

本発明の別の実施形態では、セットアップメッセージは２つのメッセージに分割され、一方は、グループ作成主と、接触を受けている特定のメンバとの間を直接に移動し、他方は、オーバーレイによって提供されたルーティングパスを使用してルーティングされる。直接のメッセージは、グループを確立するのに十分なものであり、このメッセージによってＦＮ機能は、作成主ノードにおけるグループをアプリケーションに知らせる。ルーティングされるメッセージもまた、ＦＮグループに関する障害通知を回避するために、その後すぐに完了しなければならない。セットアップ後、オーバーレイパスに沿って接続性が維持される。

図８ａに、オーバーレイネットワーク中で作成主ノードからセットアップメッセージを受け取った各ノードで、ＦＮ機能によって実行される方法を示す。ステップ８００で、ノード上のＦＮ機能は、セットアップメッセージをノードから受け取る。ステップ８１０で、ＦＮ機能は、ノード中で内部状態をセットアップする。ステップ８２０で、ＦＮ機能は、メッセージを送ってきたノードへのポインタを記録する。ステップ８３０で、ＦＮ機能は、オーバーレイルーティングパス中の次のノードにセットアップメッセージを転送する。図８ｂに、オーバーレイネットワーク中でＦＮグループノードから確認メッセージを受け取った各ノードで、ＦＮ機能によって実行される方法を示す。ステップ８４０で、ノード上のＦＮ機能は、確認メッセージをノードから受け取る。ステップ８５０で、ＦＮ機能は、メッセージを送ってきたノードへのポインタを記録する。ステップ８６０で、ＦＮ機能は、ステップ８２０で記録したポインタが指すノードにメッセージを転送する。

図７のオーバーレイネットワークで、ノード１、４、５、８がＦＮグループ中のノードであると考えてみる。作成主ノードであるノード４は、ＦＮグループの確立中または確立後に、セットアップメッセージをノード１、５、８に送る（すなわち、あらゆるノードの到達可能性が判定される）。メッセージはノード３によって受け取られ、内部状態がノード３中で設定される。ＦＮグループに関連するノード４へのポインタが、ノード３で記録される。次いでメッセージは、ノード２（ノード１へのオーバーレイルーティングパス中の次のノード）と、ノード７（ノード５および８へのオーバーレイルーティングパス中の次のノード）に転送される。ノード２および７は、このプロセスを繰り返し、内部状態を設定し、ＦＮグループに関連する３へのポインタを記録する。ノード２は、メッセージをノード１に転送し、ノード７は、メッセージをノード６（ノード５へのオーバーレイルーティングパス中の次のノード）およびノード８に転送する。ノード６は、このプロセスを繰り返し、内部状態を設定し、ＦＮグループに関連するノード７へのポインタを記録し、メッセージをノード５に転送する。

メッセージがノード１、５、８で受け取られると、これらのノードは、メッセージを送ってきたノードへのポインタを記録する。これらのノードはまた、メッセージヘッダから、それらがセットアップメッセージの意図された受信側であると決定する。メッセージを転送し続ける代わりに、ノード１、５、８は、確認メッセージを作成主ノード４に返信する。確認メッセージは、セットアップメッセージによって生み出されたポインタパスを使用して、オーバーレイルーティングパスを横断して作成主ノードに戻る。したがって、確認メッセージは、セットアップメッセージと同じオーバーレイルーティングパスを横断する。オーバーレイルーティングパス中で確認メッセージを受け取った各ノードは、メッセージを送ってきたノードへのポインタを記録する。

例えば、ノード５は確認メッセージをノード６に転送し、ノード６はノード５へのポインタを記録する。ノード６は確認メッセージをノード７に転送し、ノード７はノード６へのポインタを記録する。ノード７は確認メッセージをノード３に転送し、ノード３はノード７へのポインタを記録する。ノード３は確認メッセージをノード４に転送し、ノード４はノード３へのポインタを記録する。ノード１および８も同様に、確認メッセージをノード４に送る。ノード４がＦＮグループ中のすべてのノードから確認メッセージを受け取ったとき、作成主ノードであるノード４は、ＦＮグループがうまく作成されたと決定する。マルチキャストツリーもうまく作成されており、図９にこのトポロジを示す。このマルチキャストツリーは、ＦＮグループの各ノード（ノード１、４、５、８）を含み、また、ＦＮグループノードと作成者ノードであるノード４との間の各ルーティングパス中のあらゆるノードを含む。したがって、このマルチキャストツリーは以下の表現で表される。
パスＰ_１，４＝ノード１、２、３、４
パスＰ_５，４＝ノード５、６、７、３、４
パスＰ_８，４＝ノード８、７、３、４
上の表現で、Ｐ_ｎ，ｃは、ＦＮグループノードｎからＦＮグループ作成主ノードｃへのオーバーレイノードのパスである。したがって以下のとおりである。
マルチキャストツリーＴ＝Ｐ_１，４∪Ｐ_５，４∪Ｐ_８，４
したがって、マルチキャストツリーＴは、オーバーレイネットワークのノード１〜８を含む。図１０に、オーバーレイネットワークの上に重ねられたマルチキャストツリーＴを点線で示す。

セットアップメッセージがＦＮＩＤおよびアプリケーション状態を含んでいた場合は、ＦＮグループ中の各ノードは、セットアップメッセージを受け取ると、アプリケーション状態とＦＮＩＤとに関連する障害処理メソッドを確立する。ＦＮグループがうまく作成されない（すなわちＦＮグループの少なくとも１つのノードに到達できない）場合、作成主ノードは、このＦＮグループについてのピーンに応答するのを止め、すでにセットアップメッセージを受け取ったノードに障害通知を送る。次いで、セットアップメッセージを受け取って障害処理メソッドを確立したノードは、障害通知を受け取ると、障害処理メソッドを実行する（それによりアプリケーション状態をガーベージコレクションする）。セットアップメッセージがＦＮＩＤおよびアプリケーション状態を含んでいなかった場合は、作成主ノードは、ＦＮグループがうまく作成された後で、ＦＮＩＤおよびアプリケーション状態をＦＮグループノードに送る。

オーバーレイネットワーク中の各ノードは、隣接ノードに定期的にピーンして、そのルーティングテーブル中のノードの生死および接続性を監視する。マルチキャストツリーはオーバーレイネットワークの最上部で確立されるので、マルチキャストツリー中の隣接ノードは、必然的にオーバーレイネットワーク中の隣接ノードである。マルチキャストツリー中のノードがそのルーティングテーブルに変更を加えたときは、そのノードは、そのノード上で稼動するＦＮ機能に通知する。ルーティングテーブルの変更が単に新しいノードの追加である場合は、その変更は無視される。しかし、あるノードが隣接ノードにピーンしたのに、ピーンされたノードが応答しない場合は、ピーンしたノードはそのルーティングテーブルを改変して、応答のないノードを削除する。ノードは、一杯になって異なるノードで置き換えられたときにもルーティングテーブルから削除される。ＦＮ機能は、この変更の通知を受け、オーバーレイルーティングテーブルの変更がＦＮグループに影響するかどうか判定する。例えば、図１０のノード６が、それ自体とノード１０との間のオーバーレイ通信障害を検出した場合、ノード１０はＦＮグループに関連するマルチキャストツリー中にはないので、ノード６上のＦＮ機能は、この結果生じるルーティングテーブル変更は無視することになる。しかし、ノード６におけるルーティングテーブル変更が、ノード５へのオーバーレイパス中の通信障害を示した場合は、ＦＮ機能は、このオーバーレイネットワーク通信障害がＦＮグループ中のノード間の通信障害でもあると判定することになる。

図１１に、ルーティングテーブル変更報告を受け取ったときにＦＮ機能によって実行される方法を示す。ステップ１１００で、ＦＮ機能は、ルーティングテーブル変更報告から、マルチキャストツリー中の隣接ノードでもあるオーバーレイノードとのオーバーレイ通信に障害が発生しているかどうかを判定する。そうでない場合は、ステップ１１０１で、ＦＮ機能はルーティングテーブル変更を無視する。しかし、障害が発生したオーバーレイノードがマルチキャストツリー中の隣接ノードであった場合は、ステップ１１０２で、ＦＮ機能は、マルチキャストツリー中のすべての到達可能な隣接ノードに障害通知メッセージを送る。ステップ１１０３で、ＦＮ機能は、障害が検出されたマルチキャストツリーに関連するＦＮＩＤについての障害ハンドラが確立されているかどうか判定する。確立されている場合は、ステップ１１０４で、ＦＮ機能は、このＦＮＩＤについて確立された障害処理メソッドを呼び出す。確立されていない場合は、ＦＮ機能はステップ１１０５に直接進む。ステップ１１０５で、ＦＮ機能は、障害ハンドラをＦＮＩＤから分離する。ステップ１１０２〜１１０５はまた、障害通知メッセージを受け取ったあらゆるノード上のＦＮ機能によっても実施される。

この障害通知プロセスを例示するために、図１０のノード６に障害が発生し、もはや隣接するオーバーレイノードからのピーンに応答していないと仮定する。ノード７は、ノード６がピーンに応答できないとき、オーバーレイネットワーク通信障害を検出する。ノード７は、そのルーティングテーブルを変更してノード６を削除し、ノード７上で稼動するＦＮ機能にこの変更を通知する。ノード７上のＦＮ機能は、ノード６がマルチキャストツリー中のノードなので、ノード６とノード７の間のオーバーレイネットワーク通信障害がＦＮグループ中の少なくとも２つのノード間の通信障害を意味することを決定する。これに応答して、ノード７は、マルチキャストツリー中でまだ到達可能な隣接ノード、すなわちノード３および８に障害通知メッセージを送る。ノード３が障害通知メッセージを受け取ると、メッセージはノード３上で稼動するＦＮ機能に渡される。障害通知メッセージは、障害が検出されたＦＮＩＤを示す。次いで、ノード３上のＦＮ機能は、このＦＮＩＤに関連する１つまたは複数のマルチキャストツリー中の隣接ノードに障害通知メッセージを転送する。

この場合、障害通知メッセージはノード２および４に転送される。ノード２上のＦＮ機能は、ノード３で実施されたプロセスを繰り返し、その隣接ノードであるノード１に障害通知メッセージを転送する。障害通知メッセージがノード１、４、８で受け取られると、メッセージはＦＮ機能に渡される。ＦＮ機能は、メッセージ中のＦＮＩＤがそのノード上に登録済み障害ハンドラを有することを認識する。したがって、ＦＮ機能は、このＦＮＩＤについて確立された障害処理メソッドを呼び出す。次いで、ＦＮグループはもはや存在しないので、障害ハンドラはＦＮＩＤから分離される。

ノード６で障害が発生したので、ノード５は障害通知メッセージを受け取ることができない。しかし、ノード５がノード６からのピーン応答を受け取ることができないとき、ノード５は、そのルーティングテーブルからノード６を削除し、ノード５上のＦＮ機能にこの変更を通知する。ＦＮ機能は、ノード６がマルチキャストツリー中の隣接ノードなので、ノード５と６の間のオーバーレイネットワーク通信障害がマルチキャストツリーに関連するＦＮグループ中の少なくとも２つのノード間の通信障害を意味することを決定する。ＦＮ機能は、通信障害が検出されたＦＮグループのＦＮＩＤがノード５上の障害ハンドラに関連することを認識する。したがって、ＦＮ機能は、このＦＮＩＤについて確立された障害処理メソッドを呼び出し、障害ハンドラはこのＦＮＩＤから登録解除される。マルチキャストツリー中で到達可能なノードは他にないので、ノード５は障害通知メッセージを転送しない。

別法として、オーバーレイネットワーク通信障害が報告されなくても、ノード上のアプリケーションは障害通知メッセージを伝える。アプリケーションがＦＮグループ中の別のノードにメッセージを送ったのに応答を受け取れない場合、アプリケーションは、ＦＮ機能を使用して、他のＦＮグループノードからのＦＮグループメッセージに応答するのを止めて、これらの他のノードがＦＮグループ中の障害を検出するようにすることにより、ＦＮグループ中の障害を知らせることができる。さらに、この実装形態では、マルチキャストツリー中のすべての到達可能なノードに障害通知メッセージを送ることもできる。

ＦＮ機能によって使用されるオーバーレイルーティングリンクは両側からピーンされるので（オーバーレイによってピーンされない場合はＦＮ機能によって）、ピーンが失敗すると、２つの結果的な動作のうちの一方が行われる。すなわち、（１）リンクの他方の側からの対応するピーンもまた失敗し、その結果、第１の通知メッセージによって到達不可能なマルチキャストの部分をカバーする第２の通知メッセージがもたらされるか、（２）リンクの他方の側からの対応するピーンが成功し、その場合に、ピーンされたマルチキャストツリーノードが、グループに関する障害通知を伝えたことの指示と共にピーンに応答するかである。次いで、やはりこの結果、第１の通知メッセージによってカバーされなかった生死連鎖の部分をカバーする第２の通知メッセージがもたらされる。いずれの場合も、結果として、マルチキャストツリーのあらゆるクラッシュしていないノードは、最終的には障害通知メッセージを受け取ることになる。これは、さらにノード障害またはリンク障害が発生した場合でも同じである。というのは、追加の障害報告および対応する通知メッセージが生じるだけだからである。

述べたこの手法は、中間ノードに障害が発生したとき、またはオーバーレイルーティングテーブルが変化したときは常に偽陽性を生じる可能性があり、それにより、もはやマルチキャストツリーリンクとルーティングテーブルリンクとの間には直接的な対応がなくなる。本発明は、ＦＮ機能内で自動修復機能を実施することによって、これらの偽陽性の多くをマスクする。ＦＮグループノードが通信障害を検出したとき、ＦＮグループノードは、アプリケーションの障害ハンドラをすぐに呼び出すのではなく、ＦＮグループについての新しいマルチキャストツリーを確立しようとする。新しいＦＮグループをタイムアウト期間中にうまく確立することができない場合は、各グループメンバノードは、保留中障害通知をアプリケーションに送達する。

本発明は、重複するマルチキャストツリーを有する複数のＦＮグループがあるとき、共用による節約を得ることができる。各オーバーレイネットワークピーンメッセージは、対応するオーバーレイルーティングリンクを含むマルチキャストツリーのＦＮグループすべてを効果的に監視している。さらに、２つのオーバーレイノード間で、このリンクを介して通知メッセージが送られるべきすべてのＦＮグループについてのＦＮＩＤをエンコードした単一の障害通知メッセージを送ることができる。また、アプリケーションは、複数の同時ＦＮグループを確立することもできる。

クラッシュ回復および遅いクロックに対処するために、各ノードは、監視しているＦＮグループのセットを交換および比較することができなければならない。潜在的に多くのグループがあるので、単純にＦＮＩＤのリストを交換することは高くつく可能性がある。そうではなく本発明は、一方向ハッシュ関数を使用して、ノードが監視しているＦＮＩＤのセットに対する「チェックサム」を生成する。このチェックサムは、２つのノードが最後にそれらのＦＮＩＤリストを相互に比較したときから何も変化がないことを確認するために、２つのノード間で安価に交換することができる。この結果、完全なＦＮＩＤリストは、ノードによって監視されているグループのセットが変化したときにだけ交換すればよい。チェックサムの交換は、関連するチェックサムを生死ピーンメッセージに含め、場合によっては応答メッセージにも含めることによって、あらゆるオーバーレイネットワーク生死ピーンと共に行われる。

この方法のスケーラビリティは、提示された他の方法よりもずっとよい。この方法は、ネットワークプローブトラフィックの負担が、維持されているＦＮグループの数から独立している唯一の方法である。自動修復により、本発明は低い偽陽性率を実現する。自動修復を実施するコストは、ＦＮグループのいずれか所与の２つのメンバ間のオーバーレイルーティングパス上にあるオーバーレイノードの平均数、ならびにオーバーレイメンバのチャーンレート（ｃｈｕｒｎ ｒａｔｅ）に依存する。中間ノードの数は、オーバーレイに属するノードの数と、オーバーレイが呈するいずれかの「ローカル性」（ｌｏｃａｌｉｔｙ）プロパティとの両方に依存する。例えば、ＳｋｉｐＮｅｔがオーバーレイネットワークとして使用される場合、メンバが相互にローカルであるグループは、オーバーレイネットワークを介して任意の２つのグループメンバを接続するのに必要な中間ルーティングホップ（ｉｎｔｅｒｍｅｄｉａｔｅ ｒｏｕｔｉｎｇ ｈｏｐｓ）の数が減少するので、より低い自動修復率を受ける。

この方法の通知待ち時間は、内輪でグループ単位のスパニングツリー方法の通知待ち時間と同様だが、例外として、通知メッセージがとる通信ホップの数は、通常はＯ（ｌｏｇ ｎ）（ｎはオーバーレイネットワーク中のノード数）になり、Ｏ（ｌｏｇ ｍ）（ｍは単一のグループ中のノード数）にはならない。残念ながら、この設計のセキュリティ攻撃の受けやすさは、他のどの設計よりもかなり高い。各ＦＮグループは、ＦＮグループのメンバでないノードが正しく挙動するものと信用しなければならない。実際、任意のオーバーレイメンバは正しく生死を監視して障害通知を転送するものと信用されなければならないので、信用できない第三者をオーバーレイに含めると、第三者ＤｏＳ攻撃を防ぐのが困難になる。したがって、この方法によって提供されるセキュリティのレベルが許容できない場合は、前に論じた他の２つの方法のうちの一方を代わりに使用すべきである。

クラッシュから回復すると、ＦＮ機能を稼動させているノードは、障害が発生したこと、およびいずれかのＦＮグループに関連する古いアプリケーション状態をクリーンアップすべきであることを知る。アプリケーション状態が揮発性記憶装置に記憶される場合は、クラッシュがノードのためのこのクリーンアップを実施してしまっている場合がある。また、回復したノードは、障害通知が他のグループメンバに伝搬されたかどうかわからない場合がある。したがって本発明では、ノードが、生死をチェックするメッセージの一部として、それらの生きているＦＮグループのリストを能動的に比較する必要がある。不一致があれば、すでに障害が発生したといくらかのグループメンバによって考えられているいずれかのグループに関する通知をトリガすることによって解決される。

本発明の一実施形態では、ノードが切断による障害通知を生成するのは、２つのノードがタイムアウト期間中に何らかのトラフィックを交換することができなかった場合だけである。したがって、タイムアウト期間よりも長く続かない一時的なノードクラッシュおよび通信障害は、それによってアプリケーションが明示的に障害通知をトリガしない限り、マスクされる。

本発明の別の実施形態では、安定記憶装置を使用して、短期間のノードクラッシュをマスクすることを試みる。クラッシュから回復したノードは、それが参加しているすべてのＦＮグループがまだ生きていると見なす。このノードを外界と確実に調和させるには、ＦＮＩＤの能動的な比較で十分である。さらに、互換性の問題もない。すなわち、安定記憶装置を利用するノードが、安定記憶装置を利用しないノードと共存することができる。クラッシュから回復したノード上の通信障害はやはり、それが参加しているすべてのＦＮグループに障害を引き起こすことになる。

本発明は、ＦＮグループの何らかのサブセットのメンバ間におけるすべての通信が不可能な場合、ＦＮ機能が最終的に通知することを保証する。しかし、あるＦＮグループメンバがなお、メッセージを確実に別のグループメンバに送ろうと試み、意図された受信側に何らかの不具合が気付かれないまま、この試みを失敗に終わらせることがあるかもしれない。例えば無線ネットワーク中では、リンク条件により、生死ピーンメッセージなどの小さいメッセージだけは届くが、より大きいメッセージは届かない場合がある。ノードが明示的に通信できることを保証するために、または通信できないことにノードが気付くことを保証するために、本発明では、ノード上で稼動するアプリケーションが通信を試みて失敗した（したがって通知をトリガしたいと思っている）場合、アプリケーションはノード上のＦＮ機能に通知する必要がある。したがって、送信が失敗したとき、通知に値する障害が発生する。

本発明はまた、非推移的なまたは非対称の接続性障害にも対処する。２つのノードが、直接通信することはできないが、第三者からくるメッセージには両方とも応答していた場合、これらのノードは、確実なメッセージを交換しようとするときだけしか障害を経験しないかもしれない。本発明はそれでもなお、どちらかの側がこの時点で送信障害のために通知をトリガするなら、生きているすべてのＦＮグループメンバに通知が聞こえることを保証する。

本発明はさらに、ＦＮグループメンバが、肯定応答されるトラフィックと肯定応答されないトラフィックの混合トラフィックを生成する場合にも対処する。例えば、あるノードが、伝送制御プロトコル（ＴＣＰ）を介した制御ストリームと共に、ユーザデータグラムプロトコル（ＵＤＰ）を介したストリーミングビデオを送信する場合がある。アプリケーションは、どの送達障害が通知のトリガに値するかを決定する。本発明はアプリケーションのトラフィックを監視せず、したがって、肯定応答を期待したのではないトラフィックだけを送信したアプリケーションは、通知をトリガすべきか否かわからないかもしれない。信頼性のないリンクが障害通知に値すると決定する義務は、アプリケーションに委ねられている。

本発明の原理を適用することのできる多くの可能な実施形態に鑑みて、図面を参照して本明細書に述べた実施形態は、例示的なものに過ぎず、本発明の範囲を限定するものと考えるべきではないことを理解されたい。例えば、本発明の趣旨を逸脱することなく、ソフトウェアで示した例示の実施形態の要素をハードウェアで実現することやその逆を行うこともでき、あるいは例示の実施形態の構成および詳細を修正することもできることは、当業者なら理解するであろう。したがって、本明細書に述べた本発明は、添付の特許請求の範囲およびその均等物の範囲内に含めることのできるすべての実施形態を企図する。

本発明が存在する例示的なコンピュータシステムを一般に示すブロック図である。 本発明が機能する例示的なネットワーク環境を一般に示すブロック図である。 本発明におけるアプリケーション、障害通知機能、ネットワークノードの間の対話を示すブロック図である。 本発明による障害通知グループの作成を示す流れ図である。 本発明を使用して障害通知グループを作成する際にアプリケーションによって実施されるステップを示す流れ図である。 本発明のアプリケーションプログラムインタフェースを表す擬似コードの図である。 本発明の別のアプリケーションプログラムインタフェースを表す擬似コードの図である。 本発明の別の実施形態による障害通知グループの作成を示す流れ図である。 本発明の例示的なスパニングツリー障害通知トポロジを示す図である。 例示的なオーバーレイネットワーク中のノードの通信トポロジを示す図である。 本発明におけるマルチキャスト障害通知ツリーの作成中にセットアップメッセージを受け取ったノードによって実施されるステップを示す流れ図である。 本発明におけるマルチキャスト障害通知ツリーの作成中に確認を受け取ったノードによって実施されるステップを示す流れ図である。 本発明の例示的なマルチキャスト障害通知ツリーの通信トポロジを示す図である。 図７のオーバーレイネットワーク通信トポロジの上に重ねられた、本発明の例示的なマルチキャスト障害通知ツリーの通信トポロジを示す図である。 通信障害が検出されたときに本発明のマルチキャスト障害通知ツリー中のノードによって実施されるステップを示す流れ図である。

符号の説明

１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ その他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定型な不揮発性メモリインタフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ 取外し可能な不揮発性メモリインタフェース
１６０ ユーザ入力インタフェース
１６１ マウス
１６２ キーボード
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
１１０ コンピュータ
１１１ ネットワーク
２００ ＦＮ機能
２０１ アプリケーション
２０２ ノード

Claims (52)

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. 前記ノードが前記マルチキャストツリーのメンバであった場合は、前記マルチキャストツリー中の隣接ノードからのメッセージに応答しないことによって前記隣接ノードに障害通知を伝えることを特徴とする請求項３６に記載の方法。
39. 前記ノードが前記マルチキャストツリーのメンバであった場合は、前記障害処理メソッドを実行することを特徴とする請求項３６に記載の方法。
40. ネットワーク中の複数のノード上で動作する分散システム中で障害通知を保証する方法であって、前記複数のノードはオーバーレイネットワーク中のノードのサブセットであり、
    障害通知ツリーに加わるステップと、
    前記ツリー中の隣接ノードへの通信リンクにおける障害を確認するステップと、
    前記障害が確認されたときに障害通知を伝えるステップと
    を含むことを特徴とする方法。
41. 前記障害通知ツリーに加わるステップは、
    オーバーレイルーティングパスを介して作成主ノードから第１のメッセージを受け取るステップと、
    前記第１のメッセージを送ってきたオーバーレイノードへのポインタを記録するステップと、
    前記オーバーレイルーティングパス中の次のノードを介して、障害通信グループ中のノードに前記第１のメッセージを転送するステップと
    を含むことを特徴とする請求項４０に記載の方法。
42. 前記次のノードへのポインタを記録するステップをさらに含むことを特徴とする請求項４１に記載の方法。
43. 前記障害通知ツリーに加わるステップはさらに、
    前記オーバーレイルーティングパスを介して前記障害通知グループ中のノードから第２のメッセージを受け取るステップと、
    前記第２のメッセージを送ってきたオーバーレイノードへのポインタを記録するステップと、
    前記第１のメッセージを送ってきたオーバーレイノードを介して、前記作成主ノードに前記第２のメッセージを転送するステップと
    を含むことを特徴とする請求項４１に記載の方法。
44. 障害を確認するステップは、共に前記障害通知グループ中にある２つのノード間の通信障害と、共に前記障害通知グループ中にない２つのノード間の通信障害とを区別するステップを含むことを特徴とする請求項４０に記載の方法。
45. 障害を確認するステップは、前記障害通知グループの修復に１回または複数回にわたって失敗したステップを含むことを特徴とする請求項４０に記載の方法。
46. 障害を確認するステップは、前記オーバーレイネットワーク中のノードへの通信リンクに障害が発生したことを確認し、前記ノードが前記マルチキャストツリーのメンバであったかどうかを判定するステップを含むことを特徴とする請求項４０に記載の方法。
47. 前記ノードが前記マルチキャストツリーのメンバであった場合は、前記マルチキャストツリー中の隣接ノードからのメッセージに応答しないことによって前記隣接ノードに障害通知を伝えることを特徴とする請求項４６に記載の方法。
48. コンピュータ可読媒体に組み入れられたアプリケーションプログラムインタフェースであって、
    障害通知グループを作成して前記障害通知グループに一意識別子を割り当てるための第１の関数と、
    アプリケーションの障害処理メソッドを前記一意識別子に関連付けるための第２の関数と、
    前記障害通知グループに障害通知を伝えるための第３の関数とを備えることを特徴とするアプリケーションプログラムインタフェース。
49. 前記第１の関数は、ノードのセットを表す第１のパラメータと、前記第１の関数の結果である前記一意識別子を返す第２のパラメータとを備えることを特徴とする請求項４８に記載のアプリケーションプログラムインタフェース。
50. 前記第１の関数は、ノードのセットを表す第１のパラメータと、アプリケーション状態を表す第２のパラメータと、前記第１の関数の結果である前記一意識別子を返す第３のパラメータとを備えることを特徴とする請求項４８に記載のアプリケーションプログラムインタフェース。
51. 前記第２の関数は、前記障害処理メソッドを表す第１のパラメータと、前記一意識別子を表す第２のパラメータとを備えることを特徴とする請求項４８に記載のアプリケーションプログラムインタフェース。
52. 前記第３の関数は、前記一意識別子を表す第１のパラメータを備えることを特徴とする請求項４８に記載のアプリケーションプログラムインタフェース。
    

Images