JP2008217135A - 情報管理装置 - Google Patents

Abstract

【課題】リソースを適切に分配し、複数のＤＨＴを管理する情報管理装置を得ること。
【解決手段】本発明にかかる情報管理装置は、ピアツーピアネットワークにおいて、自身に接続するユーザ端末の呼制御に必要であり、かつ所定条件に基づいてグループ化されたユーザ情報を、他の装置との間で分散管理するために、リソースを分割して複数のリソースブロックを生成し、その使用状況を管理するリソース管理部（１２２）と、グループ毎に個別にリソースブロックを割り当てて、いずれか一つのグループのユーザ情報を管理するピア、を複数個生成可能なピア制御部（１２１）と、各ピアに分散されるユーザ情報を管理するユーザ情報管理部（１２４）と、ピア制御部（１２１）が生成した各ピアが管理するユーザ情報と同じグループに属するユーザ情報を管理しかつ他の情報管理装置内に生成されたピアに関する情報を管理するピア情報管理部（１２３）と、を備える。
【選択図】 図２

Description

本発明は、ネットワークを介して行う情報共有技術に関するものであり、特に、Ｐ２Ｐネットワークを構成する各装置のリソースに応じて、各装置がネットワーク情報を分散管理する情報管理技術に関するものである。

近年、通信オペレータ各社がコアネットワークのオールＩＰ化を表明し、音声・映像・データサービスを共通の枠組みで提供するためのサービスプラットフォームとしてＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）やＭｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎ（ＭＭＤ）を構築することによって、固定系と移動系を融合するＦｉｘｅｄ Ｍｏｂｉｌｅ Ｃｏｎｖｅｒｇｅｎｃｅ（ＦＭＣ）が注目されている。ＩＭＳやＭＭＤなどのサービスプラットフォームでは、下記非特許文献１において規定されたＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）を呼の制御に採用しており、ＳＩＰによって電話転送などの電話に対する拡張機能やプレゼンス、インスタントメッセージ、モビリティ制御などを統一的に扱うことができる。これらの機能を支えるためのＳＩＰエンティティとしてＳＩＰサーバがあるが、最近ではＳＩＰサーバへの負荷の集中などを原因とするトラブルが発生している（下記非特許文献２参照）。

一方、大規模分散環境においてデータを効率的に配置、発見するためのメカニズムとしてピアツーピア（Ｐ２Ｐ）によって情報をネットワーク中に分散する分散ハッシュテーブル（ＤＨＴ：Distributed Hash Table）が注目を集めている。このＤＨＴは、以下の特徴を持つ。
・情報はシステムに参加しているノード群で分散管理されている。
・各ノードは一意のＩＤと関連付けられる。
・各ノードは容易にＤＨＴネットワークへ参加、離脱が可能である。
・ネットワークに属する任意の二つのノード間で通信が可能である。
・任意のノードに対して、比較的少ないホップ数でたどり着くことができる。
・リンク先となれるノードにトポロジ的制約がある。

また、各ノードは以下の機能を持つ。
・ノードのＤＨＴネットワークへの参加。
・ノードのＤＨＴネットワークからの離脱。
・ノードへの情報の登録。
・ノードに登録された情報の取得。
・他ノードの要求に応じたルーティング機能。
・任意のノードとの直接通信。
・ＤＨＴネットワークを安定的に維持するための機能。

ここで、下記非特許文献３に記載されたＣｈｏｒｄなどの多くのＤＨＴアルゴリズムでは、Ｎ個のホストからなるシステムにおいて、“Ｏ（ｌｏｇＮ）”のホストにメッセージを送るだけで目的のデータを発見することができる。ＣｈｏｒｄをＤＨＴアルゴリズムに用いるＳＡＭＰ（下記非特許文献４参照）では、ＳＩＰ端末のＳＩＰ−ＵＲＩをＤＨＴによって複数のＳＩＰサーバに分散する方法が提案されている。また、Ｐ２ＰＳＩＰ（下記非特許文献５参照）では、ＳＡＭＰ同様にＳＩＰ−ＵＲＩをＤＨＴによって分散する方法が提案され、さらに、端末が送出するＳＩＰメッセージのヘッダ部分にＰ２Ｐのリンク情報を付加することでＤＨＴのメンテナンスを行う方法が提案されている。なお、下記特許文献１においては、ＤＨＴによって端末のプレゼンスやグループ情報を格納する方法が開示されている。

特開２００６−２４４２２３号公報 J.Rosenberg，et al，"SIP：Session Initiation Protocol"，IETF RFC 3261，2002. "IP電話のここが危ない"，日経NETWORK 2006年12月号，pp.22-35，日経BP社，2006. I.Stoica，R.Morris，D.Karger，M.F.Kaashoek，H.Balakrishnan，"Chord：A Scalable Peer-to-peer Lookup Service for Internet Applications"，ACM SIGCOMM 2001，pp.149-160，Aug.2001． S.Pack，K.Park，Y.Choi，"SAMP：Scalable Application-Layer Mobility Protocol"，IEEE Communications Magazine，Vol.44，No.6，pp.86-92，Jun.2006. D.Bryan，B.Lowekamp，C.Jennings，"A P2P Approach to SIP Registration and Resource Location"，IETF Internet Draft，draft-bryan-sipping-p2p-03.txt，Oct.2006.

上述したように、上記非特許文献４および５においては、ＳＩＰ−ＵＲＩをＤＨＴによって分散する方法が開示されている。しかしながら、上記非特許文献４には、ＳＩＰサーバ間のルーティングやメッセージについての記載がされていない。また、上記非特許文献５に記載の技術では、ＳＩＰ端末がＤＨＴを持つことを前提としており、モバイル端末を想定した場合、Ｐ２Ｐネットワークへの加入・離脱といった制御メッセージが大量に発生し、またモバイル端末は遅延変動が大きいことが予想される。そのため、ＤＨＴを持つノードはできるだけ静的であることが望まれている。

また、今後、家庭のホームゲートウェイや企業内の小型基地局の設置が進み、これらのノードがイントラネット／インターネットを経由して相互に接続する環境においては、ホームゲートウェイや小型基地局の一つの機能として、ＤＨＴによって分散されたＳＩＰサーバの一部の機能を搭載することも可能になると考えられる。その際、家庭や企業内で利用されＳＩＰを呼制御に用いるアプリケーションや組織などを単位としたグループが形成されると予想されるため、一つのノード下では複数のグループが同時に存在する。したがって、多くのグループを制御するために、各ノードが自身のリソースを適切に分配し同時に複数のＤＨＴを管理する機能の実現が望まれている。なお、上記特許文献１では、ＤＨＴによって端末のプレゼンスやグループ情報を格納する方法が示されているが、離脱中のメッセージの取り扱いに注力された記載内容であり、複数のグループ情報の管理については示されていない。

本発明は、上記に鑑みてなされたものであって、Ｐ２Ｐネットワークにおいて、各ノードが自身のリソースを適切に分配し、複数のＤＨＴ（分散ハッシュテーブル）を管理する機能を提供する情報管理装置を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、ピアツーピアネットワークにおいて、自身に接続するユーザ端末の呼制御に必要であり、かつ所定条件に基づいてグループ化されたユーザ情報を、他の装置との間で分散管理する情報管理装置であって、リソースを分割して複数のリソースブロックを生成し、その使用状況を管理するリソース管理手段と、前記グループ毎に個別に前記リソースブロックを割り当てて、いずれか一つのグループのユーザ情報をテーブル化して管理するピア、を複数個生成可能なピア制御手段と、各ピアに分散されるユーザ情報を管理するユーザ情報管理手段と、前記ピア制御手段が生成した各ピアが管理するユーザ情報と同じグループに属するユーザ情報を管理しかつ他の情報管理装置内に生成されたピアに関する情報を含んだピア情報を管理するピア情報管理手段と、を備えることを特徴とする。

この発明によれば、各装置は、自身のリソースに応じて提供可能な仮想ノード（Peer）の数（リソース分割数）を決定して複数の仮想ノードを生成し、各仮想ノードがグループ情報を個別に管理することとしたので、装置単位で、複数のユーザ情報を同時に管理することができる、という効果を奏する。

以下に、本発明にかかる情報管理装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

ここで、以下の実施の形態の説明において用いる用語について定義する。
「Ｐ２Ｐ制御装置」：Ｐ２Ｐネットワークを構成するノードを示す。これは、ホームゲートウェイや基地局などを想定するが、ＰＣなどでも実現可能である。
「Ｐｅｅｒ」：Ｐ２Ｐ制御装置のもつリソースに応じて一つのＰ２Ｐ制御装置内に仮想的に作られる複数のノード。それぞれが独立したＰｅｅｒ（ピア）として働く。
「Ｐｅｅｒ−ＩＤ」：全ハッシュ空間上で一意なピアの識別子。ピアのＩＰアドレスとピア内のリソース識別番号を組み合わせた値をハッシュ関数（たとえばＳＨＡ−１）を用いて生成されたハッシュ値を指す。
「ユーザ端末装置」：ＳＩＰアプリケーションなどを利用する端末およびアプリケーション。
「Ｕｓｅｒ−ＩＤ」：全ハッシュ空間上で一意なＵｓｅｒ（ユーザ）の識別子。
「Ｇｒｏｕｐ」：ＤＨＴを単位として作られるグループ。グループ情報は、一つまたは複数のＰｅｅｒにより管理（分散管理）される。各ピアは、グループの情報を分散ハッシュテーブル（ＤＨＴ）によって分散管理する。

実施の形態１．
図１は、本発明にかかる情報管理装置を含んだ分散型コミュニケーションシステムの基本構成例を示す図である。この分散型コミュニケーションシステムは、情報管理装置に相当するＰ２Ｐ制御装置１１０〜１７０と、ユーザ端末装置２１０および２２０と、により構成される。なお、後述する他の実施の形態において説明する分散型コミュニケーションシステムの基本構成例も同様である。

図１に示したように、Ｐ２Ｐ制御装置１１０、１２０および１５０はグループ＃Ａを形成する。同様に、Ｐ２Ｐ制御装置１２０、１３０および１４０がグループ＃Ｂを形成し、Ｐ２Ｐ制御装置１５０、１６０および１７０がグループ＃Ｃを形成する。すなわち、Ｐ２Ｐ制御装置１２０は、グループ＃Ａとグループ＃Ｂの二つのグループに参加し、Ｐ２Ｐ制御装置１５０は、グループ＃Ａとグループ＃Ｃの二つのグループに参加する。また、ユーザ端末装置２１０および２２０は、Ｐ２Ｐ制御装置に接続し音声通話などのアプリケーションを利用する機能を有する。

図２は、各Ｐ２Ｐ制御装置の構成例を示す図であり、Ｐ２Ｐ制御装置は、Ｐｅｅｒ制御部１２１と、リソース管理部１２２と、Ｐｅｅｒ情報管理部１２３と、Ｕｓｅｒ情報管理部１２４と、により構成される。

図３は、Ｐ２Ｐ制御装置１２０が管理するリソース情報の一例を示す図である。なお、このリソース情報は、リソース管理部１２２により管理（保持）される。また、他のＰ２Ｐ制御装置も同様のリソース情報を管理している。

図４，図５は、それぞれ、Ｐ２Ｐ制御装置１２０が管理するＰｅｅｒ情報（ピア情報）の一例，Ｕｓｅｒ情報（ユーザ情報）の一例を示す図である。なお、Ｐｅｅｒ情報は、Ｐｅｅｒ情報管理部１２３により管理され、Ｕｓｅｒ情報は、Ｕｓｅｒ情報管理部１２４により管理される。また、他のＰ２Ｐ制御装置も同様の情報を管理している。

つづいて、本実施の形態の動作について、動作の詳細を示したフローチャートである図６〜図１４を用いて説明する。

Ｐ２Ｐ制御装置１２０のリソース管理部１２２は、電源投入時など、装置が起動すると、図６に示したメイン処理を開始し、まず、自装置の備えるＣＰＵパワーやＲＡＭ容量、通信帯域幅などのリソースに応じて、例えば、ｆ（ＣＰＵパワー，ＲＡＭ容量，通信帯域幅）などの関数を用いて、自装置で提供可能な仮想ノード数、すなわちリソース分割数Ｎを決定し、自装置のリソースをＮ個に仮想的に分割する（ステップＳ１０１）。なお、ＣＰＵパワー，ＲＡＭ容量，通信帯域幅を全て使用する場合に限定するものではない。たとえば、これらの中の少なくとも一つを使用するなどとしてもよい。

ステップＳ１０１のリソース分割処理が終了すると、Ｐ２Ｐ制御装置１２０のＰｅｅｒ制御部１２１は、Ｐ２Ｐ制御装置１２０の配下に位置しているユーザ端末装置からのメッセージを受信したかどうかを確認する（ステップＳ１０２）。確認の結果、ユーザ端末装置からメッセージを受信した場合（ステップＳ１０２，Ｙｅｓ）、図７に示したＵｓｅｒメッセージ解析処理を開始する（ステップＳ１１０）。ここでは、特定のＩＰ電話ソフトウェアなどのソフトウェアを単位としたグループグループ＃Ａに所属するユーザ端末装置２１０（ユーザＡとする）からメッセージを受信した場合について動作説明を行う。

図７に示したＵｓｅｒメッセージ解析処理において、Ｐ２Ｐ制御装置１２０のＰｅｅｒ制御部１２１は、メッセージ内容が「Ｕｓｅｒ登録要求」、例えばＲＦＣ３２６１で規定されるＳＩＰのＲＥＧＩＳＴＥＲメッセージのようなＵｓｅｒ登録要求メッセージであるかどうかを判定し（ステップＳ１１１）、Ｕｓｅｒ登録要求を受信したと判定した場合（ステップＳ１１１，Ｙｅｓ）、図９に示したＵｓｅｒ登録要求メッセージ受信処理を開始する（ステップＳ１５０）。なお、ステップＳ１１１において受信したメッセージがＵｓｅｒ登録要求ではないと判断し（ステップＳ１１１，Ｎｏ）、さらにメッセージ内容がＵｓｅｒ削除要求であると判断した場合（ステップＳ１１３，Ｙｅｓ）に実行するＵｓｅｒ削除要求メッセージ受信処理については、後述する他の実施の形態において説明する。

図９に示したＵｓｅｒ登録要求メッセージ受信処理において、Ｐｅｅｒ制御部１２１は、ユーザＡから受信したＵｓｅｒ登録要求メッセージに含まれるＧｒｏｕｐ−ＩＤ、すなわちグループ＃Ａに対応するＰｅｅｒ（ピア）が自装置（Ｐ２Ｐ制御装置１２０）内にすでに生成されているかを確認し（ステップＳ１５１）、生成されていなければ（ステップＳ１５１，Ｎｏ）、図１０に示したＰｅｅｒ生成処理を開始する（ステップＳ２１０）。

図１０に示したＰｅｅｒ生成処理では、先にリソース管理部１２２が仮想的に分割したＮ個のリソースから空きリソースを検索し（ステップＳ２１１）、空きリソースが存在すれば、その一部を割り当てる（ステップＳ２１２）。このステップＳ２１２でリソースを割り当てて生成するピアをピアＡと呼ぶ。その後、Ｐｅｅｒ制御部１２１がグループ＃Ａに対応するＰ２ＰネットワークへピアＡのＰｅｅｒ登録処理（図１１参照）を開始する（ステップＳ２３０）。

ここで、本実施の形態における動作例ではＰ２Ｐネットワークを構築するアルゴリズムとして、Ｃｈｏｒｄを用い、各Ｐ２Ｐ制御装置が管理するピア情報とユーザ情報の範囲は決まっているものとして説明する。

図１１に示したＰｅｅｒ登録処理では、まず、例えばＨａｓｈ(ＩＰ−Ａｄｄｒｅｓｓ−ｏｆ−Ｐｅｅｒ＿Ａ，Ｒｅｓｏｕｒｃｅ−ＩＤ）などのハッシュ関数を用いて、ピアＡのピアＩＤ、すなわちＰｅｅｒ−ＩＤ＿Ａを生成する（ステップＳ２３１）。つぎに、あらかじめ決められた初期接続ノード（ここではＰ２Ｐ制御装置１１０とする）に対してＰｅｅｒ−ＩＤ＿Ａを含むＰｅｅｒ登録要求メッセージを送信する（ステップＳ２３２）。ここで、Ｐｅｅｒ登録要求メッセージの送信先となる初期接続ノードは、ユーザ端末装置を収容可能なＰ２Ｐ制御装置の一つである場合もあるし、図示していないユーザ端末装置を収容不可能な装置の場合もある。なお、ステップＳ２１１において空きリソースが存在しないと判断した場合（ステップＳ２１１，Ｎｏ）に実行するリソース再配置処理については、後述する他の実施の形態において説明する。

Ｐｅｅｒ登録要求メッセージを受信したＰ２Ｐ制御装置１１０において、Ｐｅｅｒ制御部１２１は、図１３に示したＰｅｅｒ登録要求メッセージ受信処理を開始する（ステップＳ１９０）。Ｐｅｅｒ登録要求メッセージ受信処理では、受信メッセージであるＰ２Ｐ制御装置１２０からのＰｅｅｒ登録要求メッセージに含まれるグループＩＤおよびピアＩＤを解析し、自装置のＰｅｅｒ情報管理部１２３に登録可能なＩＤか、すなわち自装置が管理するピア情報（図４参照）の責任範囲に含まれるピアＩＤかどうかを判定する（ステップＳ１９１）。

ステップＳ１９１において登録可能と判断した場合（ステップＳ１９１，Ｙｅｓ）、Ｐ２Ｐ制御装置１１０のＰｅｅｒ制御部１２１は、該当するピア（ここでは仮にピアＢとする）の管理するピア情報へ登録し（ステップＳ１９２）、登録完了をあらわすＰｅｅｒ−ＯＫメッセージおよびＰ２Ｐネットワーク構築に必要なピア情報とユーザ情報をコンテキスト転送として送信し（ステップＳ１９３）、Ｐｅｅｒ登録要求メッセージ受信処理を終了する。

一方、ステップＳ１９１において登録不可能なピアＩＤと判断した場合、すなわち他のＰ２Ｐ制御装置の備えるピア情報に登録されるべきと判断した場合、受信したピアＩＤに最も近いピア（ピアＩＤが最も近いピア）を自装置のピア情報から検索する（ステップＳ１９４）。そして、検索の結果得られたピア情報を転送先ピア情報としてＰｅｅｒ登録要求メッセージの送信元（Ｐ２Ｐ制御装置１２０）へ通知し（ステップＳ１９５）、Ｐｅｅｒ登録要求メッセージ受信処理を終了する。

Ｐ２Ｐ制御装置１２０は、上記ステップＳ２３２において送信したＰｅｅｒ登録要求メッセージの応答としてＰｅｅｒ−ＯＫメッセージおよびコンテキスト転送を受信した場合、すなわちピア情報とユーザ情報の転送が行われた場合（ステップＳ２３３，Ｙｅｓ）、受信した情報を自装置の管理するＰｅｅｒ情報管理部１２３およびＵｓｅｒ情報管理部１２４に追加し（ステップＳ２３４）、Ｐｅｅｒ登録処理が終了する。またこれに伴いＰｅｅｒ生成処理（図１０参照）も終了する。これに対して、Ｐｅｅｒ−ＯＫの代わりに転送先ピア情報を受信した場合、Ｐ２Ｐ制御装置１２０（Ｐｅｅｒ制御部１２１）は、他にＰｅｅｒ登録要求メッセージを送信すべき装置があることから、受信した転送先ピア情報が示す転送先（この例ではＰ２Ｐ制御装置１５０とする）に対して、再度Ｐｅｅｒ登録要求メッセージを送信する（ステップＳ２３２）。以降、Ｐｅｅｒ登録要求メッセージの要求元であるＰ２Ｐ制御装置１２０は、Ｐｅｅｒ−ＯＫメッセージを受信するまで、この動作を繰り返す。

図９に示したＵｓｅｒ登録要求メッセージ受信処理の説明に戻り、Ｐｅｅｒ生成処理が完了または、グループ＃Ａに対応するピアが生成済みであった場合（ステップＳ１５１，Ｙｅｓ）、図１２に示したＵｓｅｒ登録処理を開始する（ステップＳ２２０）。Ｕｓｅｒ登録処理では、例えばＨａｓｈ（ＳＩＰ−ＵＲＩ−ｏｆ−Ｕｓｅｒ＿Ａ）などのハッシュ関数を用いて、最初にユーザＡのユーザＩＤ、すなわちＵｓｅｒ−ＩＤ＿Ａを生成し（ステップＳ２２１）、ピア情報（図４参照）の中からＵｓｅｒ−ＩＤ＿Ａの登録先として、生成したユーザＩＤに最も近いピアＩＤ（Peer-ID）を持つＰ２Ｐ制御装置を初期接続ノードとして選択する。そして、選択したノード（初期接続ノード）に対してＵｓｅｒ−ＩＤ＿Ａを含むＵｓｅｒ登録要求メッセージを送信する（ステップＳ２２２）。

ステップＳ２２２において送信されたＵｓｅｒ登録要求メッセージの送信先であるＰ２Ｐ制御装置１１０においても他のＰ２Ｐ制御装置と同様に、Ｐｅｅｒ制御部１２１が、図６に示した処理を継続して実行している。すなわちユーザからメッセージを受信したかどうか（ステップＳ１０２）およびピアからメッセージを受信したかどうか（ステップＳ１０４）を定期的に監視し、また、グループ削除タイマの監視（ステップＳ１３０）、リソース監視（ステップＳ１４０）を実行している。

そして、ピアからのメッセージ受信を検出し（ステップＳ１０４，Ｙｅｓ）、ピアメッセージ解析処理を実行した結果（ステップＳ１２０）、ステップＳ２２２において送信されたＵｓｅｒ登録要求メッセージを受信したと判断すると、Ｐ２Ｐ制御装置１１０のＰｅｅｒ制御部１２１は、図１４に示したＵｓｅｒ登録要求メッセージ受信処理を開始する（ステップＳ１７０）。

Ｕｓｅｒ登録要求メッセージ受信処理では、受信したメッセージに含まれるユーザＩＤを解析し、自装置のＵｓｅｒ情報管理部１２４に登録可能なＩＤかどうかを判定する（ステップＳ１７１）。ユーザＩＤが登録可能である場合は、該当するピアの管理するＵｓｅｒ情報へ登録する（ステップＳ１７２）。そして登録完了を示すＵｓｅｒ−ＯＫメッセージを返送し（ステップＳ１７３）、Ｕｓｅｒ登録要求メッセージ受信処理を終了する。

一方、ステップＳ１７１において登録不可能なユーザＩＤ、すなわち他のＰ２Ｐ制御装置が備えるＵｓｅｒ情報に登録されるべきユーザＩＤであると判断した場合（ステップＳ１７１，Ｎｏ）、受信したユーザＩＤに最も近いピアＩＤを自装置のピア情報から検索する（ステップＳ１７４）。そして、検索の結果得られたピア情報を転送先ピア情報としてＵｓｅｒ登録要求メッセージの送信元（Ｐ２Ｐ制御装置１２０）へ通知し（ステップＳ１７５）、Ｕｓｅｒ登録要求メッセージ受信処理を終了する。

Ｐ２Ｐ制御装置１２０は、上記ステップＳ２２２において送信したＵｓｅｒ登録要求メッセージの応答としてＵｓｅｒ−ＯＫメッセージを受信すると（ステップＳ２２３，Ｙｅｓ）、そのメッセージをユーザＡ（ユーザ端末装置２１０）に転送し（ステップＳ２２４）、図１２に示したＵｓｅｒ登録処理を終了する。これに対して、Ｕｓｅｒ−ＯＫメッセージの代わりに転送先ピア情報を受信した場合、Ｐｅｅｒ制御部１２０は、他にＵｓｅｒ登録要求メッセージを送信すべき装置があることから、受信した転送先ピア情報が示す転送先（この例ではＰ２Ｐ制御装置１５０）に対して、再度Ｕｓｅｒ登録要求メッセージを送信する（ステップＳ２２２）。以降、要求元のＰ２Ｐ制御装置１２０は、Ｕｓｅｒ−ＯＫメッセージを受信するまで、この動作を繰り返す。

ユーザ登録処理（図１２参照）が完了すると、リソース管理部１２２は、自装置で管理するグループ＃Ａのグループ削除タイマをクリアする（ステップＳ１５２）。なお、グループ削除タイマの起動条件などについては、後述する実施の形態において説明する。

このように、本実施の形態においては、Ｐ２Ｐ制御装置は、自身のリソースに応じて自装置で提供可能な仮想ノード（Peer）の数（リソース分割数Ｎ）を決定し、各仮想ノードがグループ情報を個別に管理することとした。これにより、Ｐ２Ｐ制御装置は、複数のユーザ情報を同時に管理することができる。

実施の形態２．
つづいて、実施の形態２について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。本実施の形態は、上述した実施の形態１と比較して、Ｕｓｅｒ登録要求メッセージ受信処理のみが異なる。具体的には、実施の形態１で説明した図９の処理を図１５に示した処理に置き換えたものとなる。そのため、ここでは図１５に示した処理を中心に説明を行う。

Ｐ２Ｐ制御装置のＰｅｅｒ制御部１２１は、図６に示したメイン処理を実行中にユーザ端末装置からメッセージを受信し（ステップＳ１０２）、その解析を行った結果、Ｕｓｅｒ登録要求メッセージを受信したと判断すると、図１５に示したＵｓｅｒ登録要求メッセージ受信処理を開始する。

図１５に示したＵｓｅｒ登録要求メッセージ受信処理では、まずＵｓｅｒ登録処理を実行する（ステップＳ２２０）。このＵｓｅｒ登録処理は、実施の形態１において説明したものと同一（図１２参照）であるため説明は省略する。

Ｕｓｅｒ登録処理が完了すると、リソース管理部１２１は、Ｕｓｅｒ登録要求メッセージに含まれるグループＩＤ、すなわちグループ＃Ａに対応するピアが自装置内にすでに生成されているかどうかを確認し（ステップＳ２６１）、生成されていなかった場合（ステップＳ２６１，Ｎｏ）、Ｐｅｅｒ生成処理を開始する（ステップＳ２１０）。このＰｅｅｒ生成処理は、実施の形態１において説明したものと同一（図１０参照）であるため説明は省略する。

Ｐｅｅｒ生成処理が完了または、グループ＃Ａに対応するピアが生成済みであった場合（ステップＳ２６１，Ｙｅｓ）、リソース管理部１２２は、自装置で管理するグループ＃Ａのグループ削除タイマをクリアする（ステップＳ２６２）。

このように、本実施の形態においては、Ｕｓｅｒ登録処理をＰｅｅｒ生成処理よりも先に実行することとした。これにより、ユーザ端末装置に対して登録完了メッセージを低遅延で送信することができる。

実施の形態３．
つづいて、実施の形態３について説明する。上述した実施の形態１および２で示した動作例では、Ｐ２Ｐ制御装置がＵｓｅｒ登録要求メッセージを受信することによって、一つまたは複数のＰｅｅｒ生成処理（図１０参照）を行った。しかしながら、Ｐ２Ｐネットワーク全体のコンテキストに対してピアが必要以上に存在することもある。すなわち、たとえばピア数とユーザ数がともに「Ｘ」であると１つのピアが管理するコンテキストの数は「１」となり、逆にピア数が「１」でユーザ数が「Ｘ」であると１つのピアあたりのユーザ数は「Ｘ」となり、いずれの場合も適切に分散されているとはいえない。そこで、本実施の形態では、Ｐｅｅｒ登録処理において、Ｐｅｅｒ生成の必要性を判断する処理を追加し、その判断結果に応じてＰｅｅｒを生成する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。

本実施の形態は、上述した実施の形態１と比較して、Ｐｅｅｒ登録処理およびＰｅｅｒ登録要求メッセージ受信処理が異なる。具体的には、実施の形態１において図１１，図１３に示した処理を、図１６，図１７に示した処理に置き換えたものとなる。そのため、ここでは図１６，図１７に示した処理を中心に説明を行う。

Ｐ２Ｐ制御装置のＰｅｅｒ制御部１２１は、図６に示したメイン処理を実行中にユーザ端末装置からメッセージを受信し（ステップＳ１０２）、その解析を行った結果、Ｕｓｅｒ登録要求メッセージを受信したと判断すると、図９に示したＵｓｅｒ登録要求メッセージ受信処理を開始する。

図９に示したＵｓｅｒ登録要求メッセージ受信処理においては、Ｐｅｅｒ制御部１２１は、ユーザＡから受信したＵｓｅｒ登録要求メッセージに含まれるＧｒｏｕｐ−ＩＤ、すなわちグループ＃Ａに対応するＰｅｅｒ（ピア）が自装置（Ｐ２Ｐ制御装置１２０）内にすでに生成されているかを確認し（ステップＳ１５１）、生成されていなければ（ステップＳ１５１，Ｎｏ）、図１０に示したＰｅｅｒ生成処理を開始する（ステップＳ２１０）。

図１０に示したＰｅｅｒ生成処理では、先にリソース管理部１２２が仮想的に分割したＮ個のリソースから空きリソースを検索し（ステップＳ２１１）、空きリソースが存在すれば、その一部を割り当てる（ステップＳ２１２）。このステップＳ２１２でリソースを割り当てて生成するピアをピアＡと呼ぶ。その後、Ｐｅｅｒ制御部１２１がグループ＃Ａに対応するＰ２ＰネットワークへピアＡのＰｅｅｒ登録処理（図１６参照）を開始する（ステップＳ２３０）。

図１６に示したＰｅｅｒ登録処理では、例えば、Ｈａｓｈ(ＩＰ−Ａｄｄｒｅｓｓ−ｏｆ−Ｐｅｅｒ＿Ａ＋Ｒｅｓｏｕｒｃｅ−ＩＤ）などのハッシュ関数を用いて、最初にピアＡのピアＩＤ、すなわちＰｅｅｒ−ＩＤ＿Ａを生成し（ステップＳ２８１）、あらかじめ決められた初期接続ノード（ここではＰ２Ｐ制御装置１１０とする）に対してＰｅｅｒ−ＩＤ＿Ａを含むＰｅｅｒ登録要求メッセージを送信する（ステップＳ２８２）。ここで、Ｐｅｅｒ登録要求メッセージの送信先となる初期接続ノードは、ユーザ端末装置を収容可能なＰ２Ｐ制御装置の一つである場合もあるし、図示していないユーザ端末装置を収容不可能な装置の場合もある。

Ｐｅｅｒ登録要求メッセージを受信したＰ２Ｐ制御装置１１０のＰｅｅｒ制御部１２１は、図１７に示したＰｅｅｒ登録要求メッセージ受信処理を開始する。なお、実施の形態１において説明したＰｅｅｒ登録要求メッセージ受信処理（図１３参照）と同じ処理については、同一のステップ番号を付してその説明を省略する。

図１７に示したＰｅｅｒ登録要求メッセージ受信処理では、ステップＳ１９１において、受信したＰｅｅｒ登録要求メッセージに含まれるピアＩＤが自装置のＰｅｅｒ情報管理部１２３に登録可能と判断した場合（ステップＳ１９１，Ｙｅｓ）、Ｐ２Ｐ制御装置１１０のＰｅｅｒ制御部１２１は、受信したＰｅｅｒ登録要求メッセージに含まれるグループＩＤに対応するピアが管理しているコンテキスト数を調査し、ピアの新規生成が必要かどうかを判断する（ステップＳ２７２）。ステップＳ２７２において調査を行った結果、コンテキスト数があらかじめ決められた一定数以下であれば、ピアの新規生成は不要と判断し（ステップＳ２７２，Ｎｏ）、Ｐｅｅｒ登録要求メッセージに対する応答として、ピア生成が不要であることを表すＰｅｅｒ生成不要メッセージを送信する（ステップＳ２７５）。一方、ピア生成が必要と判断した場合（ステップＳ２７２，Ｙｅｓ）、実施の形態１と同様に、Ｐｅｅｒ情報追加処理を行い（ステップＳ１９２）、Ｐｅｅｒ−ＯＫメッセージとピア情報およびユーザ情報とを送信する（ステップＳ１９３）。

Ｐ２Ｐ制御装置１２０は、上記ステップＳ２８２において送信したＰｅｅｒ登録要求メッセージの応答としてＰｅｅｒ生成不要メッセージを受信した場合、先にピア生成のため確保したリソースを解放し（ステップＳ２８４）、図１６に示したＰｅｅｒ登録処理を終了する。またこれに伴い図１０に示したＰｅｅｒ生成処理を終了する。Ｐｅｅｒを生成する必要がない場合、Ｐ２Ｐ制御装置１２０は、ユーザ登録要求メッセージをあらかじめ決められた初期接続ノード（Ｐ２Ｐ制御装置１１０）へ転送する。初期接続ノードは、Ｐ２Ｐ制御装置の一つであることから、その後の動作は、実施の形態１に記載のＵｓｅｒ登録要求メッセージ受信処理（図９参照）と同様である。

なお、本実施の形態においては、実施の形態１のＰｅｅｒ登録処理およびＰｅｅｒ登録要求メッセージ受信処理を変更した（上述した処理に置き換えた）場合について説明を行ったが、実施の形態２のＰｅｅｒ登録処理およびＰｅｅｒ登録要求メッセージ受信処理を上述した処理に置き換えてもよい。

このように、本実施の形態においては、Ｐｅｅｒ登録要求メッセージ受信処理を受信した場合に、ピアの新規生成が必要かどうかを判断し、必要と判断した場合にのみ新規生成動作を行うこととした。これにより、ユーザ数に対してピア数が必要以上に大きくなるのを防止して、各ピアに対して情報を適切に分散する制御を実現できる。

実施の形態４．
つづいて、実施の形態４について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。上述した実施の形態においては、Ｐｅｅｒ生成処理（図１０参照）においてリソース管理部１２２が空きリソースを発見できることを前提として説明を行ったが、本実施の形態では、Ｐｅｅｒ生成処理において空きリソースが発見できなかった場合の動作について説明する。

本実施の形態は、上述した実施の形態の動作に対して図１８に示したリソース再配置処理および図１９に示したＰｅｅｒ離脱処理を追加したものとなる。以下に、これらの処理を実施の形態１の動作に対して追加した場合について説明する。なお、実施の形態１において説明した処理と同じ処理については同一のステップ番号を付して説明を省略する。

Ｐ２Ｐ制御装置のＰｅｅｒ制御部１２１は、図６に示したメイン処理を実行中にユーザ端末装置からメッセージを受信し（ステップＳ１０２）、その解析を行った結果、Ｕｓｅｒ登録要求メッセージを受信したと判断すると、図９に示したＵｓｅｒ登録要求メッセージ受信処理を開始する。

図９に示したＵｓｅｒ登録要求メッセージ受信処理において、Ｐｅｅｒ制御部１２１は、ユーザＡから受信したＵｓｅｒ登録要求メッセージに含まれるＧｒｏｕｐ−ＩＤ、すなわちグループ＃Ａに対応するＰｅｅｒ（ピア）が自装置（Ｐ２Ｐ制御装置１２０）内にすでに生成されているかを確認し（ステップＳ１５１）、生成されていなければ（ステップＳ１５１，Ｎｏ）、図１０に示したＰｅｅｒ生成処理を開始する（ステップＳ２１０）。

図１０に示したＰｅｅｒ生成処理では、先にリソース管理部１２２が仮想的に分割したＮ個のリソースから空きリソースを検索し（ステップＳ２１１）、空きリソースが見つからなかった場合（ステップＳ２１１，Ｎｏ）、図１８に示したリソース再配置処理を開始する（ステップＳ２４０）。リソース再配置処理では、すでに生成済みのピアの中から、Ｐ２Ｐネットワークから離脱させるピアを決定し（ステップＳ２４１）、決定したピアを対象として、図１９に示したＰｅｅｒ離脱処理を行う（ステップＳ２５０）。ステップＳ２５０を実行して上記選択したピアに割り当てていたリソースを解放することにより、空きリソースを作る。このときリソースを解放するピアは、管理するコンテキスト数が少ないピアを優先的に選択する，生成時刻の古いピアを優先的に選択する，などの方法をとる。ここでは、ピアＣを選択したものとして説明する。

図１９に示したＰｅｅｒ離脱処理では、ピアＣの管理するユーザ情報をＰ２Ｐネットワーク上で隣接するピアＢおよびピアＤへ引き継ぎ、さらに、隣接するピアＢおよびピアＤが、管理するピア情報を更新することで、Ｐ２Ｐネットワークを更新する（ステップＳ２５１）。詳細は具体的なＤＨＴアルゴリズム（たとえば代表的なＤＨＴアルゴリズムであるＣｈｏｒｄ）の動作に従うものとする。コンテキストの引き継ぎ処理が終了するとピアＣに割り当てていたリソースを解放し（ステップＳ２５２）、Ｐｅｅｒ離脱処理が終了する。またこれに伴い図１８に示したリソース再配置処理も終了する。

その後、リソース管理部１２２は、解放したリソースをピア生成のために割り当てる（図１０、ステップＳ２１２）。このステップＳ２１２でリソースを割り当てて生成するピアをピアＡと呼ぶ。そして、Ｐｅｅｒ制御部１２１がグループ＃Ａに対応するＰ２ＰネットワークへピアＡのＰｅｅｒ登録処理（図１１参照）を開始する（ステップＳ２３０）。Ｐｅｅｒ登録処理以降の動作は実施の形態１と同様である。

なお、本実施の形態においては、リソース再配置処理およびＰｅｅｒ離脱処理を実施の形態１に対して追加した場合について説明したが、これに限らず、これらの動作を実施の形態２および３の動作に対して追加することも可能である。

このように、本実施の形態においては、リソース不足によりピアの生成ができない場合に、所定の条件に基づいて生成済みのピアを選択し、それを離脱させて、新たにピアを生成するためのリソースを確保することとした。これにより、リソースが不足している状態においても新たにピアを生成することができる。

実施の形態５．
つづいて、実施の形態５について説明する。ピアの参加や離脱により各ピアの責任範囲、すなわち管理するコンテキストが変更されるため、各ピアの管理するコンテキスト数は増減する。そこで、本実施の形態では、Ｐ２Ｐ制御装置に空きリソースがあり、かつピアの管理するコンテキスト数が一定数以上になった場合に管理するコンテキスト数を削減する方法について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。

本実施の形態は、上述した実施の形態の動作に対して図２０に示したリソース監視処理を追加したものとなる。以下に、この処理を実施の形態１の動作に対して追加した場合について説明する。なお、実施の形態１において説明した処理と同じ処理については同一のステップ番号を付して説明を省略する。

ピアＡ、ピアＢおよびピアＣが同一のＰ２Ｐネットワークに属するとき、ピアＢが何らかの理由によりＰ２Ｐネットワークから離脱することになると、ピアＢは、実施の形態４で説明したＰｅｅｒ離脱処理（図１９参照）を実行し、コンテキスト管理変更のためＰ２Ｐネットワーク上で隣接するピアＡおよびピアＣへコンテキスト（すなわちピア情報とユーザ情報）を送信する。この動作により、ピアＡは、もともと管理していたユーザ情報（ユーザ情報ａとする）に、ピアＢから引き継いだユーザ情報（ユーザ情報ｂとする）加えたユーザ情報（ユーザ情報ａ＋ユーザ情報ｂ）を新たに管理することになる。以下は、この状態を元に説明する。

リソース管理部１２２は、定期的に図２０に示したリソース監視処理を行う。リソース監視処理では、まず各リソース使用状況を調査し（ステップＳ１４１）、高負荷なピアが存在するかどうかを確認する（ステップＳ１４２）。ここで、上述した「ユーザ情報ａ＋ユーザ情報ｂ」のコンテキストを管理するピアＡが高負荷なピアとすると、リソース管理部１２２は、装置内の空きリソースを検索し、空きリソースがあるかどうかを確認する（ステップＳ１４３）。空きリソースが見つかった場合は（ステップＳ１４３，Ｙｅｓ）、そのリソースを用いてＰｅｅｒ生成処理を開始する（ステップＳ２１０）。ステップＳ２１０のＰｅｅｒ生成処理は、実施の形態１において説明したＰｅｅｒ生成処理と同様である（図１０参照）。ピアＡと同一のグループＩＤをもつＰ２Ｐネットワークにピアを追加することによって、一つのピアあたりの管理するコンテキスト数を軽減させることができる。

一方、上記ステップＳ１４３において空きリソースが見つからなかった場合は（ステップＳ１４３，Ｎｏ）、すでに生成済みのピアの中から、Ｐ２Ｐネットワークから離脱させることが可能なピアがあるかどうかを確認し（ステップＳ１４４）、離脱可能なピアがあれば（ステップＳ１４４，Ｙｅｓ）そのピアに対するＰｅｅｒ離脱処理を行う（ステップＳ２５０）。これにより、リソースを解放して空きリソースを作る。このときリソースを解放するピアは、生成済みピアのうち、管理するコンテキスト数が少ないピアを優先的に選択する，生成時刻の古いピアを優先的に選択する，などの方法をとる。なお、Ｐｅｅｒ離脱処理は、実施の形態４において説明したＰｅｅｒ離脱処理（図１９参照）と同様であり、Ｐｅｅｒ生成処理は、実施の形態１において説明したＰｅｅｒ生成処理（図１０参照）と同様である。

なお、本実施の形態においては、実施の形態１に対してリソース監視処理を追加した場合について説明を行ったが、実施の形態２〜４に対してリソース監視処理を追加することも可能である。

このように、本実施の形態においては高負荷状態のピアを検出した場合、空きリソースを新たに割り当ててピアを生成する、または、離脱可能なピアが存在すればそれを離脱させて解放されたリソースを割り当ててピアを生成することとした。これにより、特定のピアが高負荷状態となった場合に、負荷を分散させることができる。

実施の形態６．
つづいて、実施の形態６について説明する。上述した実施の形態においては、Ｐ２Ｐ制御装置１２０の起動時にリソース分割数Ｎを決定することとしたが、本実施の形態では、これに加えて、装置起動後もリソース監視処理を実行して定期的にリソース分割数Ｎの値を適切な値に保つ動作について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。

本実施の形態は、上述した実施の形態の動作に対して図２１に示したリソース監視処理を追加したものとなる。以下に、この処理を実施の形態１の動作に対して追加した場合について説明する。なお、実施の形態１において説明した処理と同じ処理については同一のステップ番号を付して説明を省略する。

本実施の形態のリソース管理部１２２は、定期的に図２１に示したリソース監視処理を行う。図２１に示したリソース監視処理では、ピア間の通信遅延やスループットを測定し、この結果を用いて、自装置で提供可能な仮想ノード数、すなわちリソース分割数Ｎを再計算する（ステップＳ３０１）。再計算は、例えば、ｇ（Ｎ，伝送遅延，スループット）などの関数を用いて行う。そして、再計算を実行して得られたリソース分割数Ｎとすでに生成済みのピアの数（ｎ）を比較し（ステップＳ３０２）、比較結果が「ｎ＞Ｎ」の場合（ステップＳ３０２，Ｙｅｓ）、すでに生成済みのピアの中から（Ｎ−ｎ）個の離脱させるピアを決定し（ステップＳ３０３）、決定したピアに対して実施の形態４で示した離脱処理（図１９参照）を実行してリソースを解放する（ステップＳ２５０）。このとき、（Ｎ−ｎ）個のピアを選択するために、管理するコンテキスト数が少ないピアを優先的に選択する，生成時刻の古いピアを優先的に選択する，などの方法をとる。

なお、本実施の形態においては、リソース監視処理を実施の形態１に対して追加した場合について説明したが、これに限らず、この動作を実施の形態２〜５の動作に対して追加することも可能である。

このように、本実施の形態においてはリソース監視処理を定期的に行い、リソース分割数を再計算し、再計算して得られた分割数と生成済みのピア数とを比較した結果に基づいて、分散制御を行うこととした。これにより、リソース分割数を柔軟に変更することができる。

実施の形態７．
つづいて、実施の形態７について説明する。本実施の形態では、上述した実施の形態４と同様に、Ｐｅｅｒ生成処理において空きリソースが発見できなかった場合の動作について説明する。ここでは、実施の形態４で示した動作とは異なる動作（代替動作）について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。

本実施の形態は、上述した実施の形態の動作に含まれるＰｅｅｒ生成処理（図１０参照）に代えて、図２２に示したピア生成処理を実行するようにしたものである。以下に、本実施の形態の動作を説明する。なお、実施の形態１において説明した処理と同じ処理については同一のステップ番号を付して説明を省略する。

Ｐ２Ｐ制御装置のＰｅｅｒ制御部１２１は、図６に示したメイン処理を実行中にユーザ端末装置からメッセージを受信し（ステップＳ１０２）、その解析を行った結果、Ｕｓｅｒ登録要求メッセージを受信したと判断すると、図９に示したＵｓｅｒ登録要求メッセージ受信処理を開始する。

図９に示したＵｓｅｒ登録要求メッセージ受信処理において、Ｐｅｅｒ制御部１２１は、ユーザＡから受信したＵｓｅｒ登録要求メッセージに含まれるＧｒｏｕｐ−ＩＤ、すなわちグループ＃Ａに対応するＰｅｅｒ（ピア）が自装置（Ｐ２Ｐ制御装置１２０）内にすでに生成されているかを確認し（ステップＳ１５１）、生成されていなければ（ステップＳ１５１，Ｎｏ）、図２２に示したＰｅｅｒ生成処理を開始する（ステップＳ２１０）。

図２２に示したＰｅｅｒ生成処理では、先にリソース管理部１２２が仮想的に分割したＮ個のリソースから空きリソースを検索し（ステップＳ２１１）、空きリソースが見つからなかった場合（ステップＳ２１１，Ｎｏ）、リソース管理部１２２は、リソース割り当てを行わずにＰｅｅｒ生成処理を終了する。そして、Ｕｓｅｒ登録処理を実行する（図９、ステップＳ２２０）。Ｕｓｅｒ登録処理では、例えばＨａｓｈ（ＳＩＰ−ＵＲＩ−ｏｆ−Ｕｓｅｒ＿Ａ）などのハッシュ関数を用いて、最初にユーザＡのユーザＩＤ、すなわちＵｓｅｒ−ＩＤ＿Ａを生成し（ステップＳ２２１）、あらかじめ決められた初期接続ノード（ここではＰ２Ｐ制御装置１１０とする）に対してＵｓｅｒ−ＩＤ＿Ａを含むＵｓｅｒ登録要求メッセージを送信する（ステップＳ２２２）。ここで、Ｕｓｅｒ登録要求メッセージの送信先となる初期接続ノードは、Ｐ２Ｐ制御装置の一つである場合もある。

Ｐ２Ｐ制御装置１２０のＰｅｅｒ制御部１２１は、上記ステップステップＳ２２２において送信したＵｓｅｒ登録要求メッセージの応答としてＵｓｅｒ−ＯＫメッセージを受信すると（ステップＳ２２３）、そのメッセージをユーザＡ（ユーザ端末装置２１０）に転送し（ステップＳ２２４）、図１２に示したＵｓｅｒ登録処理を終了する。このＵｓｅｒ登録処理の終了によって、空きリソースが発見できなかった場合のユーザ端末装置２１０の登録が完了する。

このように、本実施の形態においては、ユーザ端末装置からＵｓｅｒ登録要求メッセージを受信したＰ２Ｐ制御装置が、新規にピアを生成する必要があるにもかかわらず空きリソースが存在しない場合には、ピアの生成を行わずに、これに続くＵｓｅｒ登録処理を実行することとした。これにより、既存のピアを強制的に離脱させることなくユーザ登録処理を実行することができる。

実施の形態８．
つづいて、実施の形態８について説明する。本実施の形態においては、図２３および図２４に示したＵｓｅｒ削除要求メッセージ受信動作、および図２４に示したグループ削除タイマ監視処理、について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。また、ここではＰ２Ｐ管理装置１２０が行うＵｓｅｒ削除要求メッセージ受信動作およびグループ削除タイマ監視処理について説明する。

Ｐ２Ｐ管理装置１２０において、リソース管理部１２２が、図６に示したメイン処理のステップＳ１０１を実行後、Ｐｅｅｒ制御部１２１は、Ｐ２Ｐ制御装置１２０の配下に接続しているユーザ端末装置からのメッセージを受信したかどうかを確認する（ステップＳ１０２）。確認の結果、ユーザ端末装置からメッセージを受信した場合（ステップＳ１０２，Ｙｅｓ）、図７に示したＵｓｅｒメッセージ解析処理を開始する（ステップＳ１１０）。

図７に示したＵｓｅｒメッセージ解析処理において、Ｐ２Ｐ制御装置１２０のＰｅｅｒ制御部１２１は、メッセージ内容が「Ｕｓｅｒ登録要求」、「Ｕｓｅｒ削除要求（例えばＳＩＰのＢＹＥメッセージのようなＵｓｅｒ削除要求メッセージ）」のいずれかに該当するかどうかを確認し（ステップＳ１１１、Ｓ１１３）、Ｕｓｅｒ削除要求を受信したと判定した場合（ステップＳ１１１，Ｎｏ、ステップＳ１１３，Ｙｅｓ）、図２３に示したＵｓｅｒ削除要求メッセージ受信処理を開始する（ステップＳ１６０）。

図２３に示したＵｓｅｒ削除要求メッセージ受信処理では、まず、Ｕｓｅｒ削除要求メッセージに含まれるグループＩＤ、すなわちグループ＃Ａに対応するピアが自装置内にすでに生成されているかどうかを確認する（ステップＳ１６１）。確認の結果、自装置内で管理していると判断した場合（ステップＳ１６１、Ｙｅｓ）、例えばＨａｓｈ（ＳＩＰ−ＵＲＩ−ｏｆ−Ｕｓｅｒ＿Ａ）などのハッシュ関数を用いて、最初にユーザＡのユーザＩＤ、すなわちＵｓｅｒ−ＩＤ＿Ａを生成する（ステップＳ１６２）。つぎに、ピア情報の中からＵｓｅｒ＿ＩＤ＿Ａのユーザ情報を保持しているピアとして最も近いピアＩＤを持つＰ２Ｐ制御装置を初期接続ノードとして選択し、この初期接続ノードへＵｓｅｒ−ＩＤ＿Ａを含むＵｓｅｒ削除要求メッセージを送信する（ステップＳ１６３）。ここでは、Ｐ２Ｐ制御装置１１０が初期接続ノードとして選択されたものとする。

Ｕｓｅｒ削除要求メッセージを受信した初期接続ノードであるＰ２Ｐ制御装置１１０は、受信したメッセージに含まれるユーザＩＤを自装置のＵｓｅｒ情報管理部１２４が管理中かどうかを判定する（ステップＳ１８１）。判定結果が管理中を示す場合（ステップＳ１８１，Ｙｅｓ）、Ｕｓｅｒ情報を削除し（ステップＳ１８２）、削除完了を示すＵｓｅｒ−ＯＫメッセージを送信する（ステップＳ１８３）。これに対して、上位ステップＳ１８１において上記ユーザＩＤを管理中でない（他のＰ２Ｐ制御装置が管理中）と判断した場合（ステップＳ１８１，Ｎｏ）、受信したユーザＩＤに最も近いピアＩＤの検索処理を自装置が管理しているピア情報を対象として実行し（ステップＳ１８４）、検索の結果得られたピア情報を転送先ピア情報としてＵｓｅｒ削除要求メッセージの送信元（Ｐ２Ｐ制御装置１２０）へ通知する（ステップＳ１８５）。

Ｐ２Ｐ制御装置１２０は、上記ステップステップＳ１６３において送信したＵｓｅｒ削除要求メッセージの応答としてＵｓｅｒ−ＯＫメッセージを受信すると（ステップＳ１６３，Ｙｅｓ）、そのメッセージをユーザＡに対して転送する（ステップＳ１６５）。これに対して、Ｕｓｅｒ−ＯＫメッセージの代わりに転送先ピア情報を受信した場合、Ｐ２Ｐ制御装置１２０（Ｐｅｅｒ制御部１２１）は、他にＵｓｅｒ削除要求メッセージを送信すべき装置があることから、受信した転送先ピア情報が示す転送先（この例ではＰ２Ｐ制御装置１５０）に対して、再度Ｕｓｅｒ削除要求メッセージを送信する（ステップＳ１６３）。以降、Ｕｓｅｒ削除要求メッセージの要求元であるＰ２Ｐ制御装置１２０は、Ｕｓｅｒ−ＯＫメッセージを受信するまで、同一グループに属するＰ２Ｐ制御装置に対してこの動作を繰り返す。

Ｕｓｅｒ−ＯＫメッセージを受信した場合（ステップＳ１６４，Ｙｅｓ）、リソース管理部１２２は、自装置内でグループ＃Ａに割り当てたリソースを解放してよいかどうかを判定する（ステップＳ１６６）。すなわち、Ｐ２Ｐ制御装置１２０の配下にグループ＃Ａに属するユーザ端末装置が存在するかどうかを確認する。そして、配下にグループ＃Ａに属するユーザ端末装置が存在しないことが確認された場合、グループ削除タイマを始動し（ステップＳ１６７）、ユーザ削除処理を終了する。

一方、上記ステップＳ１６１において、Ｕｓｅｒ削除要求メッセージに含まれるグループＩＤ、すなわちグループ＃Ａに対応するピアが自装置内で管理されていないと判断した場合（ステップＳ１６１、Ｎｏ）、あらかじめ決められたＰ２Ｐ制御装置１１０へメッセージを転送し、そのメッセージを受信したＰ２Ｐ制御装置１１０が上述した処理と同様の処理（ユーザ削除処理）を実行する。

Ｐ２Ｐ制御装置１２０のＰｅｅｒ制御部１２１は、上述したＵｓｅｒ削除要求メッセージ受信処理（図２３参照）を経て始動されたグループ削除タイマを、メイン処理（図６参照）実行中に、グループ削除タイマ監視処理にて監視する（図６、ステップＳ１３０）。図２５に示したグループ削除タイマ監視処理では、動作中のタイマが満了したかを判定し（ステップＳ１３１）、満了時には（ステップＳ１３１，Ｙｅｓ）、グループ＃Ａに対応するピアのＰｅｅｒ離脱処理を実行する（ステップＳ２５０）。なお、ここで実行するＰｅｅｒ離脱処理は、実施の形態４において説明したものと同様である（図１９参照）。Ｐｅｅｒ離脱処理を実行することにより、グループ＃Ａの情報はＰ２Ｐ制御装置１２０から削除される。

なお、本実施の形態においては、実施の形態１の場合を例としてＵｓｅｒ削除要求メッセージ受信動作，グループ削除タイマ監視処理動作について説明を行ったが、他の実施の形態２〜７におけるＵｓｅｒ削除要求メッセージ受信動作，グループ削除タイマ監視処理動作も同様である。

以上のような手順を実行することにより、登録済みのユーザ情報を削除することができ、また、削除したユーザと同じグループに属するユーザが他に存在しない場合には、リソースを解放することができる。

実施の形態９．
つづいて、実施の形態９について説明する。本実施の形態においては、図２６に示したリソース監視処理、について説明する。なお、本実施の形態にかかる分散型コミュニケーションシステムの基本構成およびＰ２Ｐ制御装置の構成は、実施の形態１と同様である。また、ここではＰ２Ｐ管理装置１２０が行うリソース監視処理について説明する。

上述した実施の形態において説明した動作、Ｐ２Ｐ制御装置１２０がＵｓｅｒ登録要求メッセージを受信することによって、一つまたは複数のＰｅｅｒ生成処理（図１０参照）を行った。しかし、これらの動作例では、Ｐ２Ｐネットワーク全体のコンテキストに対してピアが必要以上に存在することもある。すなわち、ピア数とユーザ数がともにＸである場合、１つのピアが管理するコンテキストは１となり、逆にピア数が１でユーザ数がＸである場合には、１つのピアあたりのユーザ数はＸとなり、いずれも適切に分散されているとはいえない。そこで、本実施の形態では、リソース管理部１２２が定期的にユーザ数を監視する動作例を説明する。

Ｐ２Ｐ管理装置１２０のリソース管理部１２２は、定期的に図２６に示したリソース監視処理を行う。リソース監視処理では、まず各ピアの管理するコンテキストのうちユーザ情報の数を調査する（ステップＳ３２１）。つぎに、調査結果に基づいて不要なピアが存在しているかどうかを確認する（ステップＳ３２２）。不要なピアが存在するかどうかの判断は、管理しているユーザ情報の数があらかじめ決められた一定数以下のピア（一定数以下のユーザ情報しか管理していないピア）を発見した場合に、Ｐ２Ｐネットワーク中にピアが過剰に存在する（不要なピアが存在する）と判断する。ステップＳ３２２における確認の結果、不要なピアが存在していると判断した場合（ステップＳ３２２，Ｙｅｓ）、一定数以下のユーザ情報しか管理していないピアを不要なピアとして、その離脱処理を開始する（ステップＳ２５０）。なお、ピアの離脱処理は、実施の形態４で示したとおりである（図１９参照）。

このように、本実施の形態において、Ｐ２Ｐ管理装置は、不要なピアが存在していないかどうかを定期的に監視し、不要なピアを発見した場合には、そのピアを離脱させることとした。これにより、Ｐ２Ｐネットワーク中のピアの数を適切な値に保つようにリソース管理を行うことができる。

以上のように、本発明にかかる情報管理装置は、Ｐ２Ｐネットワーク上での情報管理に有用であり、特に、ネットワークを構成する各装置の能力を考慮して、情報を分散管理する場合に適している。

本発明にかかる情報管理装置を含んだ分散型コミュニケーションシステムの基本構成例を示す図である。 Ｐ２Ｐ制御装置の構成例を示す図である。 Ｐ２Ｐ制御装置が管理するリソース情報の一例を示す図である。 Ｐ２Ｐ制御装置が管理するＰｅｅｒ情報（ピア情報）の一例を示す図である。 Ｐ２Ｐ制御装置が管理するＵｓｅｒ情報（ユーザ情報）の一例を示す図である。 メイン処理を示すフローチャートである。 Ｕｓｅｒメッセージ解析処理を示すフローチャートである。 Ｐｅｅｒメッセージ解析処理を示すフローチャートである。 Ｕｓｅｒ登録要求メッセージ受信処理を示すフローチャートである。 Ｐｅｅｒ生成処理を示すフローチャートである。 Ｐｅｅｒ登録処理を示すフローチャートである。 Ｕｓｅｒ登録処理を示すフローチャートである。 Ｐｅｅｒ登録要求メッセージ受信処理を示すフローチャートである。 Ｕｓｅｒ登録要求メッセージ受信処理を示すフローチャートである。 実施の形態２のＵｓｅｒ登録要求メッセージ受信処理を示すフローチャートである。 実施の形態３のＰｅｅｒ登録要求メッセージ受信処理を示すフローチャートである。 実施の形態３のＰｅｅｒ登録要求メッセージ受信処理を示すフローチャートである。 リソース再配置処理を示すフローチャートである。 Ｐｅｅｒ離脱処理を示すフローチャートである。 リソース監視処理を示すフローチャートである。 実施の形態６のリソース監視処理を示すフローチャートである。 実施の形態７のＰｅｅｒ生成処理を示すフローチャートである。 Ｕｓｅｒ削除要求メッセージ受信処理を示すフローチャートである。 Ｕｓｅｒ削除要求メッセージ受信処理を示すフローチャートである。 グループ削除タイマ監視処理を示すフローチャートである。 実施の形態９のリソース監視処理を示すフローチャートである。

符号の説明

１１０，１２０，１３０，１４０，１５０，１６０，１７０ Ｐ２Ｐ制御装置
１２１ Ｐｅｅｒ制御部
１２２ リソース管理部
１２３ Ｐｅｅｒ情報管理部
１２４ Ｕｓｅｒ情報管理部
２１０，２２０ ユーザ端末装置

Claims (17)

1. ピアツーピアネットワークにおいて、自身に接続するユーザ端末の呼制御に必要であり、かつ所定条件に基づいてグループ化されたユーザ情報を、他の装置との間で分散管理する情報管理装置であって、
   リソースを分割して複数のリソースブロックを生成し、その使用状況を管理するリソース管理手段と、
   前記グループ毎に個別に前記リソースブロックを割り当てて、いずれか一つのグループのユーザ情報をテーブル化して管理するピア、を複数個生成可能なピア制御手段と、
   各ピアに分散されるユーザ情報を管理するユーザ情報管理手段と、
   前記ピア制御手段が生成した各ピアが管理するユーザ情報と同じグループに属するユーザ情報を管理しかつ他の情報管理装置内に生成されたピアに関する情報を含んだピア情報を管理するピア情報管理手段と、
   を備えることを特徴とする情報管理装置。
2. 前記リソース管理手段は、ＣＰＵリソース、ＲＡＭ容量および通信帯域幅の少なくともいずれか一つに基づいて前記リソースの分割数を決定することを特徴とする請求項１に記載の情報管理装置。
3. ピアの新規生成処理を実行している他の情報管理装置からピア登録要求メッセージを受信した場合、
   前記ピア制御手段は、生成済みのピアが管理している管理しているユーザ情報であるコンテキストの数に基づいて、当該ピア登録要求メッセージが指定するピアの登録の必要性を判断し、登録が必要と判断した場合にピア登録処理を実行することを特徴とする請求項１または２に記載の情報管理装置。
4. ピアの新規生成が必要であるにもかかわらず前記リソース管理手段が管理しているリソースブロックに未使用のものがない場合、
   前記ピア制御手段は、生成済みのピアのいずれか一つのピアを離脱させてリソースブロックを解放し、解放したリソースブロックを使用してピアの新規生成処理を実行することを特徴とする請求項１、２または３に記載の情報管理装置。
5. 前記ピア制御手段は、管理しているコンテキスト数が少ないピアを優先的に離脱させることを特徴とする請求項４に記載の情報管理装置。
6. 前記ピア制御手段は、生成時刻の古いピアを優先的に離脱させることを特徴とする請求項４に記載の情報管理装置。
7. ユーザ端末からのユーザ端末登録要求メッセージの受信に伴いピアの新規生成が必要と判断したにもかかわらず、前記リソース管理手段が管理しているリソースブロックに未使用のものがない場合、
   前記ピア制御手段は、受信したユーザ端末登録要求メッセージを他の情報管理装置へ転送することを特徴とする請求項１〜６のいずれか一つに記載の情報管理装置。
8. 前記リソース管理手段が、一定数以上のコンテキストを管理している高負荷状態のピアを検出し、かつ前記リソース管理手段が管理しているリソースブロックに未使用のものがある場合、
   前記ピア制御手段は、高負荷状態ピアが管理しているユーザ情報グループと同じグループのユーザ情報を管理するピアを新たに生成し、同じグループに属するピア数を増加させることを特徴とする請求項１〜７のいずれか一つに記載の情報管理装置。
9. 前記リソース管理手段は、定期的に通信遅延、スループットなどの通信状態を表す情報を測定し、当該測定結果に基づいて前記リソースの分割数を再決定することを特徴とする請求項１〜８のいずれか一つに記載の情報管理装置。
10. 前記ピア制御手段は、前記リソース管理手段により前記再決定された分割数と、現存するピアの数と、を比較し、分割数が現存するピアの数よりも少ない場合、分割数と現存するピアの数が同一となるように、現存するピアの中から選択したピアを離脱させてリソースブロックを解放することを特徴とする請求項９に記載の情報管理装置。
11. 前記ピア制御手段は、管理しているコンテキスト数が少ないピアを優先的に離脱させることを特徴とする請求項１０に記載の情報管理装置。
12. 前記ピア制御手段は、生成時刻の古いピアを優先的に離脱させることを特徴とする請求項１０に記載の情報管理装置。
13. ユーザ端末からの要求により当該ユーザ端末の登録済みユーザ情報を削除した結果、当該削除したユーザ情報に対応するユーザ端末と同一グループのユーザ端末が配下に存在しない状態となった場合、
    前記ピア制御手段は、当該グループのユーザ情報を管理するためのピアを離脱させてリソースブロックを解放することを特徴とする請求項１〜１２のいずれか一つに記載の情報管理装置。
14. 前記ピア制御手段は、
    ユーザ端末からユーザ端末登録要求メッセージを受信した場合、当該ユーザ端末登録要求メッセージに含まれるグループＩＤに基づいて、当該グループＩＤと同じグループＩＤを含んだユーザ情報を管理するためのピアを新規生成する必要があるかどうかを判断し、新規生成が必要と判断した場合には、前記リソースブロックのいずれか一つを用いたピアの新規生成処理を実行して前記ピア情報管理手段が管理しているピア情報を更新し、
    さらに、
    更新した後のピア情報に基づいて前記ユーザ端末登録要求メッセージに含まれるユーザ情報を管理するピアを有する情報管理装置の候補を選択し、当該候補に対して当該ユーザ端末登録要求メッセージを転送してユーザ情報の登録を行うことを特徴とする請求項１〜１３のいずれか一つに記載の情報管理装置。
15. 前記ピア制御手段は、
    ユーザ端末からユーザ端末登録要求メッセージを受信した場合、前記ピア情報管理手段が管理しているピア情報に基づいて当該ユーザ端末のユーザ情報を管理するピアを有する情報管理装置の候補を選択し、当該候補に対して当該ユーザ端末登録要求メッセージを転送してユーザ情報の登録を行い、
    さらに、
    前記ユーザ端末登録要求メッセージに含まれるグループＩＤに基づいて、当該グループＩＤと同じグループＩＤを含んだユーザ情報を管理するためのピアを新規生成する必要があるかどうかを判断し、新規生成が必要と判断した場合には、前記リソースブロックのいずれか一つを用いたピアの新規生成処理を実行して前記ピア情報管理手段が管理しているピア情報を更新することを特徴とする請求項１〜１３のいずれか一つに記載の情報管理装置。
16. 前記ピア制御手段は、管理しているコンテキスト数が規定値以下となったピアを離脱させてリソースブロックを解放することを特徴とする請求項１〜１５のいずれか一つに記載の情報管理装置。
17. 前記ユーザ情報をＳＩＰ（Session Initiation Protocol）のユーザ情報とすることを特徴とする請求項１〜１６のいずれか一つに記載の情報管理装置。

Images