ピアツーピアネットワークのノードの個別再起動
本発明は、ノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５のセットから形成されるピアツーピアネットワークＮを再起動するための方法に関する。上記の方法は、再起動すべき第１のノードおよびこのノードから既知のノードのセットを特定し、各再起動すべきノードが再起動の前に実行されるステップと、既知のノードの中から次のノードを選択するステップと、（前のステップで選択された）次のノードの識別子を含むメッセージＭを既知のノードに送信するステップとを含む。メッセージを受け取ると、各ノードは、上記ノードと再起動すべきノードとの間で複製されるセッションＤを特定すること、さらに上記セッションの複製を含む、複製されたセッションをバックアップするステップと、メッセージの内容に基づいて、上記ノードが次のノードであるかどうかを確認し、上記の場合、該ノードを再起動すべきノードとみなすステップとを実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ピアツーピアネットワークに関する。こうしたネットワークは、自己管理する相互に接続されたノードのセットで構成される。
【背景技術】
【０００２】
こうしたピアツーピアネットワークは、様々な用途、特に通信に使用することができる。これらの用途の一部については、ノードはデータを保存しなければならない。このデータは、通信セッションに関連するデータである可能性があり、同じセッションに属するいかなる新しいイベントに対しても再び見つけられなければならない。ピアツーピアネットワークは、分散メモリとして使用することができ、各ノードが、分散ハッシュテーブルを介してアクセスできるデータの一部を保存する。
【０００３】
一部の用途では、高い耐障害性を必要とする。したがって、ネットワークのノードのうちの１つの障害が、このノードが保存していたデータの部分を不可逆的に破壊しないようにするために、別のノードにこのデータを複製することができる。この従来の冗長メカニズムは、「バディレプリケーション（ｂｕｄｄｙ ｒｅｐｌｉｃａｔｉｏｎ）」として知られ、ピアツーピアネットワークに影響を及ぼす大多数の障害に対する耐性をシステムに与える。
【０００４】
こうしたピアツーピアネットワークの実装については、Ｉａｎ Ｓｔｏｉｃａ、Ｒｏｂｅｒｔ Ｍｏｒｒｉｓ、Ｄａｖｉｄ Ｋａｒｇｅｒ、Ｍ．Ｆｒａｎｓ Ｋａａｓｈｏｅｋ、およびＨａｒｉ Ｂａｌａｋｒｉｓｈｎａｎによる論文、「Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ」、ＡＣＰ ＳＩＧＣＯＭＭ ２００１、Ｓａｎ Ｄｉｅｇｏ、ＣＡ、２００１年８月、１４９−１６０頁にさらに詳細に説明されている。
【０００５】
「コード（Ｃｈｏｒｄ）」ネットワークにおいて耐障害性を向上させる方法を説明する論文がある。例えば、Ｈａｉｆｅｎｇ Ｙｕ、Ｐｈｉｌｉｐ Ｂ．Ｇｉｂｂｏｎｓ、およびＳｕｍａｎ Ｎａｔｈによる論文、「Ａｖａｉｌａｂｉｌｉｔｙ ｏｆ ｍｕｌｔｉ−ｏｂｊｅｃｔ ｏｐｅｒａｔｉｏｎｓ」は、このようなネットワークでデータがどのように複製されるかを調べることを提案する。
【０００６】
ネットワークのノードのそれぞれは、システムが機能できるようにするソフトウェアモジュールを含んでいる。こうしたソフトウェアモジュールにより、ノードはあらかじめ定義されたプロトコルを使用して通信すること、他のノードからもしくはピアツーピアネットワーク外のシステムからの要求を処理すること、データの複製を管理することなどができる。
【０００７】
こうしたソフトウェアモジュールは時々変更する、または更新する必要がある可能性がある。たとえ行われているのは単に軽微な問題を修正する、または新しいが二次的な機能を提供する新しいバージョンのインストールであっても、ソフトウェア更新メカニズムはノードを一時的にシャットダウンする必要がある。
【０００８】
しかしながら、ピアツーピアネットワークでは、この再起動には２つの問題がある。
【０００９】
第１に、ノードはデータを保存していたので、再起動段階中にこのデータは保持されなければならない。
【００１０】
第２に、通信用途のような一部の用途については、ピアツーピアネットワークのサービスの連続性を保証することが重要である。言い換えれば、ノードを再起動中に、ピアツーピアネットワークは動作し続けて、そのサービスのユーザの装置に対して透過的に、意図されたアプリケーションサービスを提供しなければならない。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】Ｉａｎ Ｓｔｏｉｃａ、Ｒｏｂｅｒｔ Ｍｏｒｒｉｓ、Ｄａｖｉｄ Ｋａｒｇｅｒ、Ｍ．Ｆｒａｎｓ Ｋａａｓｈｏｅｋ、Ｈａｒｉ Ｂａｌａｋｒｉｓｈｎａｎ、「Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ」、ＡＣＰ ＳＩＧＣＯＭＭ ２００１、Ｓａｎ Ｄｉｅｇｏ、ＣＡ、２００１年８月、１４９−１６０頁
【非特許文献２】Ｈａｉｆｅｎｇ Ｙｕ、Ｐｈｉｌｉｐ Ｂ．Ｇｉｂｂｏｎｓ、Ｓｕｍａｎ Ｎａｔｈ、「Ａｖａｉｌａｂｉｌｉｔｙ ｏｆ ｍｕｌｔｉ−ｏｂｊｅｃｔ ｏｐｅｒａｔｉｏｎｓ」
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、こうした２つの問題を解決することである。
【課題を解決するための手段】
【００１３】
そのために、本発明は、ノードのセットで構成されるピアツーピアネットワークを再起動するための方法から成る。この方法は、再起動すべき第１のノードおよび再起動すべき該ノードに既知のノードのセットを特定するステップを含み、再起動すべき各ノードが、再起動前に：
既知のノードの中から１つのノードを選択するステップと、
再起動すべきノードが既知のノードに、（前述のステップ中に選択された）次のノードの識別子を含むメッセージを送信するステップと
を実行するという点、
および、メッセージを受信すると各ノードが、
そのノードと再起動すべきノードとの間の複製セッションを特定すること、およびこれらを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて、このノードが次のノードであるかどうかを確認し、そうである場合は該ノードを再起動すべきノードとみなすステップと
を実行するという点で革新的である。
【００１４】
本発明の一実施形態によれば、バックアップするステップは、再起動すべきノードが再起動されるまで待機し、次いでそのノードに複製されたセッションを複製することから成る。
【００１５】
メッセージは、次のノードの識別子を含むこともでき、その場合、バックアップするステップは、次のノードおよび再起動すべきノードを除く、既知のノードのいずれか１つに複製セッションを複製することから成る。
【００１６】
選択のステップは、再起動すべきノードが配置された処理装置とは異なる処理装置に配置されたノードの中から次のノードを特定することから成ることができる。
【００１７】
本発明のさらなる目的は、複数のノードの少なくとも一部が前述の方法を実施する、複数のノードを含むピアツーピアネットワークである。
【００１８】
したがって、本発明は、ネットワーク内で複製されたデータを動的に再配置するための戦略と結合されたノードを順次的に再起動するためのメカニズムを提案する。常に、再起動中でないノードが十分にアプリケーションサービスを提供することができる。
【００１９】
さらにこのメカニズムは、人の介入を必要とせず、各ノードが再起動すべき次のノードを自動的に特定する。
【００２０】
さらにノードは、このメカニズムを個別に実行することができる。このメカニズムは、中央装置または外部装置を必要としない。
【００２１】
本発明およびその利点は、ピアツーピアネットワークを概略的に示す添付の図面を参照して、次の説明においてさらに明確にわかるようになるであろう。
【図面の簡単な説明】
【００２２】
【図１】ピアツーピアネットワークＲを示す図である。
【発明を実施するための形態】
【００２３】
図１に示すピアツーピアネットワークＲは、ノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５で構成されている。ノード内に保存された各データは、他の別個のノードに複製される。したがって、ノードＮ１内に保存されたデータＤは、ノードＮ３に複製される。このように、ノードＮ１が作動しなくなる場合、このデータＤはピアツーピアネットワークＲ内で今まで通り利用できることになる。
【００２４】
ノードは、このデータの他に、ソフトウェアモジュールを有する。
【００２５】
こうしたソフトウェアモジュールは、ピアツーピアネットワークを管理する特定のメカニズムおよびアルゴリズムを実行するために使用される。こうした特定のメカニズムおよびアルゴリズムは、例えば上述の「コード」ドキュメントに従うものであることが可能である。
【００２６】
本発明によればノードは、前述のソフトウェアモジュールを更新するように構成されたソフトウェアモジュールをさらに有する。
【００２７】
後に説明するように、こうしたソフトウェアモジュールは、２つの機能、すなわち１つは再起動メッセージが受信されるとトリガされる機能、およびもう１つは再起動時にトリガされる機能を含む。
【００２８】
ノードのすべてが同じソフトウェアモジュールを有すると仮定する。この仮定により、本発明の概要を簡略化することができるが、本発明は、差別化されたノードを含むネットワークに適用するように構成されることが可能である。
【００２９】
発明の方法は、起動する第１のノードを特定する第１のステップを含む。
【００３０】
この方法の初期化は、外部装置が特定されたノードにメッセージを送信することによって行われる。この外部装置は、ピアツーピアネットワークの制御卓（ｃｏｎｔｒｏｌ ｃｏｎｓｏｌｅ）であることが可能であり、これによってプログラマーは、ノードに組み込まれたソフトウェアモジュールの更新または交換をトリガすることができる。
【００３１】
このメッセージは、特定されたノードによって受信され、これにより再起動機能がトリガされる。
【００３２】
この再起動機能は、特定されたノードに既知のノードの中から次のノードを選択するステップを含む。
【００３３】
この既知のノードのセットは、起動時は、ノードのセットに等しい。しかしながら、再起動が行われるとき、２つのセットは異なるものとなる。これは、ノードが再起動するとき、ノードは新しい識別子を取得し、同じマシンであるが、機能上異なるノードであるためである。結果として、発明の方法を通して、最初の既知のノードのセットに属するノードが徐々に少なくなる。
【００３４】
その（最初の）既知のノードのセット内で、自身の後に再起動することになるノードを選ばなければならない。この選択は、様々な基準を用いて行うことができる。
【００３５】
１つの効果的な基準は、自身の処理装置とは異なる処理装置に配置されたノードを選択することである。これは、ピアツーピアネットワークでは、一般にノードより少ない数のマシンまたは処理装置のセットにノードが配置されるからである。実際には、１つのマシンに通常複数のノードが配置される。再起動処理中のネットワークＮ上の負荷の不均衡を防ぐために、処理装置に依存する時間とともにノードの再起動を分散させることは有益である。このオプションは、一部のマシンが、所与の時間に他のノードよりもはるかに多くのノードを有し、それによってシステム性能の低下を引き起こす状況を防ぐ。
【００３６】
別の実装は、ピアツーピアネットワークに配置された分散ハッシュテーブル（ＤＨＴ）のリングに従うことから成ることが可能である。こうした２つの実装は、結合することもできる。
【００３７】
当然ながら、他の代替形態もまた可能であるが、次のノードは、外部の集中型装置が介入することなく、ピアツーピアネットワークのノード自体によって特定されることに注意することが重要である。本発明の利点の１つは、ピアツーピアネットワークによって管理される完全に独立した処理を提供することである。
【００３８】
再起動機能の第２のステップは、既知のノードのサブセットにメッセージＭを送信するステップである。このメッセージは、次のノードの識別子を含んでいる。このメッセージはまた、特定されたノード（メッセージの送信者）の識別子および既知のノードのサブセットの中のノードの識別子を含むことができる。
【００３９】
一組のメッセージＭが正常に送信されると、ノードは再起動することができる。当業者には知られているように、再起動は、他のノードとの開かれた（ｏｐｅｎ）通信チャネル（すなわちソケット）を終了するなど、いくつかの前処理操作を含むことができる。
【００４０】
再起動機能は、ノードが新しいセッションの作成をやめるクリティカルセクションに対応することができる。
【００４１】
本発明の方法はまた、前述のメッセージを受信することによってトリガされる受信機能を含む。
【００４２】
この受信機能は、複製されたセッションをバックアップするステップを含む。このステップは、メッセージを受信したノードとメッセージを送信したノードとの間で複製されるセッションを意味する、影響を受けたセッションをまず特定することから成る。どのノードが「最初の（ｐｒｉｍａｒｙ）」バージョンを有し、どれがコピーを有するかを知ることは重要ではなく、こうした２つのノード間で複製されるセッションを特定することのみが重要である。
【００４３】
送信ノードが再起動しなければならないとき、２つのコピーのうちの１つは、結局ピアツーピアネットワークから消滅することになり、ネットワークＮの起動段階中でも情報の冗長を維持することが課題である。
【００４４】
そのためには、いくつかの実施形態が可能である。
【００４５】
第１の実施形態では、ノードは、送信ノードが再起動するまで待機する。送信ノードが再びアクティブになる度に、ノードは事前に特定されたセッションのデータを送信ノード上に複製するステップをトリガする。
【００４６】
第２の実施形態では、ノードは安全なノードの特定をトリガし、その安全なノード上にセッションデータを複製する。
【００４７】
この安全なノードは、送信ノード、および再起動すべき次のノード（メッセージパラメータとして送信することができる）を除く、既知のノードのサブセット中のいかなるノードであってもよい。
【００４８】
受信機能はまた、受信ノードが送信ノードによって特定された次のノードであるかどうかを確認するステップを含む。そのためには、次のノードの識別子が、メッセージ内に含まれなければならない。この場合、受信ノードは、再起動すべきノードとみなされなければならず、その結果、再起動機能は自動的にトリガされる。
【００４９】
ノードのすべてが再起動すると、すなわち、最初の既知のノードのセットに属するいかなるノードももはや残っていない（これらのすべてが再起動し、識別子を変更した）とき、プロセスは終了する。
【００５０】
発明の方法によってセッションデータは保存され、プロセスを通して利用可能であり、ピアツーピアネットワークは作動し続ける。さらに、セッションデータは相変わらず複製され、ピアツーピアネットワークは耐障害性の要求を満たし続ける。
【技術分野】
【０００１】
本発明は、ピアツーピアネットワークに関する。こうしたネットワークは、自己管理する相互に接続されたノードのセットで構成される。
【背景技術】
【０００２】
こうしたピアツーピアネットワークは、様々な用途、特に通信に使用することができる。これらの用途の一部については、ノードはデータを保存しなければならない。このデータは、通信セッションに関連するデータである可能性があり、同じセッションに属するいかなる新しいイベントに対しても再び見つけられなければならない。ピアツーピアネットワークは、分散メモリとして使用することができ、各ノードが、分散ハッシュテーブルを介してアクセスできるデータの一部を保存する。
【０００３】
一部の用途では、高い耐障害性を必要とする。したがって、ネットワークのノードのうちの１つの障害が、このノードが保存していたデータの部分を不可逆的に破壊しないようにするために、別のノードにこのデータを複製することができる。この従来の冗長メカニズムは、「バディレプリケーション（ｂｕｄｄｙ ｒｅｐｌｉｃａｔｉｏｎ）」として知られ、ピアツーピアネットワークに影響を及ぼす大多数の障害に対する耐性をシステムに与える。
【０００４】
こうしたピアツーピアネットワークの実装については、Ｉａｎ Ｓｔｏｉｃａ、Ｒｏｂｅｒｔ Ｍｏｒｒｉｓ、Ｄａｖｉｄ Ｋａｒｇｅｒ、Ｍ．Ｆｒａｎｓ Ｋａａｓｈｏｅｋ、およびＨａｒｉ Ｂａｌａｋｒｉｓｈｎａｎによる論文、「Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ」、ＡＣＰ ＳＩＧＣＯＭＭ ２００１、Ｓａｎ Ｄｉｅｇｏ、ＣＡ、２００１年８月、１４９−１６０頁にさらに詳細に説明されている。
【０００５】
「コード（Ｃｈｏｒｄ）」ネットワークにおいて耐障害性を向上させる方法を説明する論文がある。例えば、Ｈａｉｆｅｎｇ Ｙｕ、Ｐｈｉｌｉｐ Ｂ．Ｇｉｂｂｏｎｓ、およびＳｕｍａｎ Ｎａｔｈによる論文、「Ａｖａｉｌａｂｉｌｉｔｙ ｏｆ ｍｕｌｔｉ−ｏｂｊｅｃｔ ｏｐｅｒａｔｉｏｎｓ」は、このようなネットワークでデータがどのように複製されるかを調べることを提案する。
【０００６】
ネットワークのノードのそれぞれは、システムが機能できるようにするソフトウェアモジュールを含んでいる。こうしたソフトウェアモジュールにより、ノードはあらかじめ定義されたプロトコルを使用して通信すること、他のノードからもしくはピアツーピアネットワーク外のシステムからの要求を処理すること、データの複製を管理することなどができる。
【０００７】
こうしたソフトウェアモジュールは時々変更する、または更新する必要がある可能性がある。たとえ行われているのは単に軽微な問題を修正する、または新しいが二次的な機能を提供する新しいバージョンのインストールであっても、ソフトウェア更新メカニズムはノードを一時的にシャットダウンする必要がある。
【０００８】
しかしながら、ピアツーピアネットワークでは、この再起動には２つの問題がある。
【０００９】
第１に、ノードはデータを保存していたので、再起動段階中にこのデータは保持されなければならない。
【００１０】
第２に、通信用途のような一部の用途については、ピアツーピアネットワークのサービスの連続性を保証することが重要である。言い換えれば、ノードを再起動中に、ピアツーピアネットワークは動作し続けて、そのサービスのユーザの装置に対して透過的に、意図されたアプリケーションサービスを提供しなければならない。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】Ｉａｎ Ｓｔｏｉｃａ、Ｒｏｂｅｒｔ Ｍｏｒｒｉｓ、Ｄａｖｉｄ Ｋａｒｇｅｒ、Ｍ．Ｆｒａｎｓ Ｋａａｓｈｏｅｋ、Ｈａｒｉ Ｂａｌａｋｒｉｓｈｎａｎ、「Ｃｈｏｒｄ： Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ」、ＡＣＰ ＳＩＧＣＯＭＭ ２００１、Ｓａｎ Ｄｉｅｇｏ、ＣＡ、２００１年８月、１４９−１６０頁
【非特許文献２】Ｈａｉｆｅｎｇ Ｙｕ、Ｐｈｉｌｉｐ Ｂ．Ｇｉｂｂｏｎｓ、Ｓｕｍａｎ Ｎａｔｈ、「Ａｖａｉｌａｂｉｌｉｔｙ ｏｆ ｍｕｌｔｉ−ｏｂｊｅｃｔ ｏｐｅｒａｔｉｏｎｓ」
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明の目的は、こうした２つの問題を解決することである。
【課題を解決するための手段】
【００１３】
そのために、本発明は、ノードのセットで構成されるピアツーピアネットワークを再起動するための方法から成る。この方法は、再起動すべき第１のノードおよび再起動すべき該ノードに既知のノードのセットを特定するステップを含み、再起動すべき各ノードが、再起動前に：
既知のノードの中から１つのノードを選択するステップと、
再起動すべきノードが既知のノードに、（前述のステップ中に選択された）次のノードの識別子を含むメッセージを送信するステップと
を実行するという点、
および、メッセージを受信すると各ノードが、
そのノードと再起動すべきノードとの間の複製セッションを特定すること、およびこれらを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて、このノードが次のノードであるかどうかを確認し、そうである場合は該ノードを再起動すべきノードとみなすステップと
を実行するという点で革新的である。
【００１４】
本発明の一実施形態によれば、バックアップするステップは、再起動すべきノードが再起動されるまで待機し、次いでそのノードに複製されたセッションを複製することから成る。
【００１５】
メッセージは、次のノードの識別子を含むこともでき、その場合、バックアップするステップは、次のノードおよび再起動すべきノードを除く、既知のノードのいずれか１つに複製セッションを複製することから成る。
【００１６】
選択のステップは、再起動すべきノードが配置された処理装置とは異なる処理装置に配置されたノードの中から次のノードを特定することから成ることができる。
【００１７】
本発明のさらなる目的は、複数のノードの少なくとも一部が前述の方法を実施する、複数のノードを含むピアツーピアネットワークである。
【００１８】
したがって、本発明は、ネットワーク内で複製されたデータを動的に再配置するための戦略と結合されたノードを順次的に再起動するためのメカニズムを提案する。常に、再起動中でないノードが十分にアプリケーションサービスを提供することができる。
【００１９】
さらにこのメカニズムは、人の介入を必要とせず、各ノードが再起動すべき次のノードを自動的に特定する。
【００２０】
さらにノードは、このメカニズムを個別に実行することができる。このメカニズムは、中央装置または外部装置を必要としない。
【００２１】
本発明およびその利点は、ピアツーピアネットワークを概略的に示す添付の図面を参照して、次の説明においてさらに明確にわかるようになるであろう。
【図面の簡単な説明】
【００２２】
【図１】ピアツーピアネットワークＲを示す図である。
【発明を実施するための形態】
【００２３】
図１に示すピアツーピアネットワークＲは、ノードＮ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５で構成されている。ノード内に保存された各データは、他の別個のノードに複製される。したがって、ノードＮ１内に保存されたデータＤは、ノードＮ３に複製される。このように、ノードＮ１が作動しなくなる場合、このデータＤはピアツーピアネットワークＲ内で今まで通り利用できることになる。
【００２４】
ノードは、このデータの他に、ソフトウェアモジュールを有する。
【００２５】
こうしたソフトウェアモジュールは、ピアツーピアネットワークを管理する特定のメカニズムおよびアルゴリズムを実行するために使用される。こうした特定のメカニズムおよびアルゴリズムは、例えば上述の「コード」ドキュメントに従うものであることが可能である。
【００２６】
本発明によればノードは、前述のソフトウェアモジュールを更新するように構成されたソフトウェアモジュールをさらに有する。
【００２７】
後に説明するように、こうしたソフトウェアモジュールは、２つの機能、すなわち１つは再起動メッセージが受信されるとトリガされる機能、およびもう１つは再起動時にトリガされる機能を含む。
【００２８】
ノードのすべてが同じソフトウェアモジュールを有すると仮定する。この仮定により、本発明の概要を簡略化することができるが、本発明は、差別化されたノードを含むネットワークに適用するように構成されることが可能である。
【００２９】
発明の方法は、起動する第１のノードを特定する第１のステップを含む。
【００３０】
この方法の初期化は、外部装置が特定されたノードにメッセージを送信することによって行われる。この外部装置は、ピアツーピアネットワークの制御卓（ｃｏｎｔｒｏｌ ｃｏｎｓｏｌｅ）であることが可能であり、これによってプログラマーは、ノードに組み込まれたソフトウェアモジュールの更新または交換をトリガすることができる。
【００３１】
このメッセージは、特定されたノードによって受信され、これにより再起動機能がトリガされる。
【００３２】
この再起動機能は、特定されたノードに既知のノードの中から次のノードを選択するステップを含む。
【００３３】
この既知のノードのセットは、起動時は、ノードのセットに等しい。しかしながら、再起動が行われるとき、２つのセットは異なるものとなる。これは、ノードが再起動するとき、ノードは新しい識別子を取得し、同じマシンであるが、機能上異なるノードであるためである。結果として、発明の方法を通して、最初の既知のノードのセットに属するノードが徐々に少なくなる。
【００３４】
その（最初の）既知のノードのセット内で、自身の後に再起動することになるノードを選ばなければならない。この選択は、様々な基準を用いて行うことができる。
【００３５】
１つの効果的な基準は、自身の処理装置とは異なる処理装置に配置されたノードを選択することである。これは、ピアツーピアネットワークでは、一般にノードより少ない数のマシンまたは処理装置のセットにノードが配置されるからである。実際には、１つのマシンに通常複数のノードが配置される。再起動処理中のネットワークＮ上の負荷の不均衡を防ぐために、処理装置に依存する時間とともにノードの再起動を分散させることは有益である。このオプションは、一部のマシンが、所与の時間に他のノードよりもはるかに多くのノードを有し、それによってシステム性能の低下を引き起こす状況を防ぐ。
【００３６】
別の実装は、ピアツーピアネットワークに配置された分散ハッシュテーブル（ＤＨＴ）のリングに従うことから成ることが可能である。こうした２つの実装は、結合することもできる。
【００３７】
当然ながら、他の代替形態もまた可能であるが、次のノードは、外部の集中型装置が介入することなく、ピアツーピアネットワークのノード自体によって特定されることに注意することが重要である。本発明の利点の１つは、ピアツーピアネットワークによって管理される完全に独立した処理を提供することである。
【００３８】
再起動機能の第２のステップは、既知のノードのサブセットにメッセージＭを送信するステップである。このメッセージは、次のノードの識別子を含んでいる。このメッセージはまた、特定されたノード（メッセージの送信者）の識別子および既知のノードのサブセットの中のノードの識別子を含むことができる。
【００３９】
一組のメッセージＭが正常に送信されると、ノードは再起動することができる。当業者には知られているように、再起動は、他のノードとの開かれた（ｏｐｅｎ）通信チャネル（すなわちソケット）を終了するなど、いくつかの前処理操作を含むことができる。
【００４０】
再起動機能は、ノードが新しいセッションの作成をやめるクリティカルセクションに対応することができる。
【００４１】
本発明の方法はまた、前述のメッセージを受信することによってトリガされる受信機能を含む。
【００４２】
この受信機能は、複製されたセッションをバックアップするステップを含む。このステップは、メッセージを受信したノードとメッセージを送信したノードとの間で複製されるセッションを意味する、影響を受けたセッションをまず特定することから成る。どのノードが「最初の（ｐｒｉｍａｒｙ）」バージョンを有し、どれがコピーを有するかを知ることは重要ではなく、こうした２つのノード間で複製されるセッションを特定することのみが重要である。
【００４３】
送信ノードが再起動しなければならないとき、２つのコピーのうちの１つは、結局ピアツーピアネットワークから消滅することになり、ネットワークＮの起動段階中でも情報の冗長を維持することが課題である。
【００４４】
そのためには、いくつかの実施形態が可能である。
【００４５】
第１の実施形態では、ノードは、送信ノードが再起動するまで待機する。送信ノードが再びアクティブになる度に、ノードは事前に特定されたセッションのデータを送信ノード上に複製するステップをトリガする。
【００４６】
第２の実施形態では、ノードは安全なノードの特定をトリガし、その安全なノード上にセッションデータを複製する。
【００４７】
この安全なノードは、送信ノード、および再起動すべき次のノード（メッセージパラメータとして送信することができる）を除く、既知のノードのサブセット中のいかなるノードであってもよい。
【００４８】
受信機能はまた、受信ノードが送信ノードによって特定された次のノードであるかどうかを確認するステップを含む。そのためには、次のノードの識別子が、メッセージ内に含まれなければならない。この場合、受信ノードは、再起動すべきノードとみなされなければならず、その結果、再起動機能は自動的にトリガされる。
【００４９】
ノードのすべてが再起動すると、すなわち、最初の既知のノードのセットに属するいかなるノードももはや残っていない（これらのすべてが再起動し、識別子を変更した）とき、プロセスは終了する。
【００５０】
発明の方法によってセッションデータは保存され、プロセスを通して利用可能であり、ピアツーピアネットワークは作動し続ける。さらに、セッションデータは相変わらず複製され、ピアツーピアネットワークは耐障害性の要求を満たし続ける。
【特許請求の範囲】
【請求項１】
ノード（Ｎ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５）のセットから形成されたピアツーピアネットワーク（Ｎ）を再起動するための方法であって、再起動すべき第１のノードおよび前記再起動すべきノードに既知のノードのサブセットを特定するステップを含み、再起動すべき各ノードが、再起動の前に、
既知のノードの中から１つのノードを選択するステップと、
前記再起動すべきノードが前記既知のノードに、前記次のノードの識別子を含んでいるメッセージ（Ｍ）を送信するステップと
を実行すること、ならびに、
メッセージを受信すると、各ノードが、
前記ノードと前記再起動すべきノードとの間で複製されるセッション（Ｄ）を特定すること、およびこれらを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて前記ノードが前記次のノードであるかどうかを確認し、そうである場合前記ノードを再起動すべきノードとみなすステップと
を実行することを特徴とする、方法。
【請求項２】
前記バックアップするステップが、前記再起動すべきノードが再起動するまで待機し、次いで前記複製されたセッションをこのノードに複製することから成る、請求項１に記載の方法。
【請求項３】
前記バックアップするステップが、前記次のノードおよび前記再起動すべきノードを除く、前記既知のノードのいずれか１つに前記複製セッションを複製することから成る、請求項１に記載の方法。
【請求項４】
選択のステップが、前記再起動すべきノードが配置される処理装置とは異なる処理装置に配置されたノードの中から次のノードを特定することから成り得る、請求項１から３のいずれか一項に記載の方法。
【請求項５】
複数のノードを含むピアツーピアネットワークであって、これらのノードの少なくとも一部が、次のノードの識別子を含んでいる、再起動すべきノードからのメッセージを受信すると、
前記ノードと前記再起動すべきノードとの間で複製されるセッション（Ｄ）を特定すること、およびこれらのセッションを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて、前記ノードが前記次のノードであるかどうかを確認し、そうである場合は前記ノードを再起動すべきノードとみなすステップと
を実行するための手段を所有する、ピアツーピアネットワーク。
【請求項１】
ノード（Ｎ１、Ｎ２、Ｎ３、Ｎ４、Ｎ５）のセットから形成されたピアツーピアネットワーク（Ｎ）を再起動するための方法であって、再起動すべき第１のノードおよび前記再起動すべきノードに既知のノードのサブセットを特定するステップを含み、再起動すべき各ノードが、再起動の前に、
既知のノードの中から１つのノードを選択するステップと、
前記再起動すべきノードが前記既知のノードに、前記次のノードの識別子を含んでいるメッセージ（Ｍ）を送信するステップと
を実行すること、ならびに、
メッセージを受信すると、各ノードが、
前記ノードと前記再起動すべきノードとの間で複製されるセッション（Ｄ）を特定すること、およびこれらを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて前記ノードが前記次のノードであるかどうかを確認し、そうである場合前記ノードを再起動すべきノードとみなすステップと
を実行することを特徴とする、方法。
【請求項２】
前記バックアップするステップが、前記再起動すべきノードが再起動するまで待機し、次いで前記複製されたセッションをこのノードに複製することから成る、請求項１に記載の方法。
【請求項３】
前記バックアップするステップが、前記次のノードおよび前記再起動すべきノードを除く、前記既知のノードのいずれか１つに前記複製セッションを複製することから成る、請求項１に記載の方法。
【請求項４】
選択のステップが、前記再起動すべきノードが配置される処理装置とは異なる処理装置に配置されたノードの中から次のノードを特定することから成り得る、請求項１から３のいずれか一項に記載の方法。
【請求項５】
複数のノードを含むピアツーピアネットワークであって、これらのノードの少なくとも一部が、次のノードの識別子を含んでいる、再起動すべきノードからのメッセージを受信すると、
前記ノードと前記再起動すべきノードとの間で複製されるセッション（Ｄ）を特定すること、およびこれらのセッションを再び複製することから成る、複製セッションをバックアップするステップと、
メッセージの内容に基づいて、前記ノードが前記次のノードであるかどうかを確認し、そうである場合は前記ノードを再起動すべきノードとみなすステップと
を実行するための手段を所有する、ピアツーピアネットワーク。
【図１】
【公表番号】特表２０１３−５１６６６９（Ｐ２０１３−５１６６６９Ａ）
【公表日】平成２５年５月１３日（２０１３．５．１３）
【国際特許分類】
【出願番号】特願２０１２−５４６４８４（Ｐ２０１２−５４６４８４）
【出願日】平成２２年１１月２２日（２０１０．１１．２２）
【国際出願番号】ＰＣＴ／ＦＲ２０１０／０５２４７０
【国際公開番号】ＷＯ２０１１／０８０４３１
【国際公開日】平成２３年７月７日（２０１１．７．７）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２５年５月１３日（２０１３．５．１３）
【国際特許分類】
【出願日】平成２２年１１月２２日（２０１０．１１．２２）
【国際出願番号】ＰＣＴ／ＦＲ２０１０／０５２４７０
【国際公開番号】ＷＯ２０１１／０８０４３１
【国際公開日】平成２３年７月７日（２０１１．７．７）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]