JP2009230686A - コンテンツ管理サーバ及びコンテンツ管理プログラム - Google Patents
コンテンツ管理サーバ及びコンテンツ管理プログラム Download PDFInfo
- Publication number
- JP2009230686A JP2009230686A JP2008078345A JP2008078345A JP2009230686A JP 2009230686 A JP2009230686 A JP 2009230686A JP 2008078345 A JP2008078345 A JP 2008078345A JP 2008078345 A JP2008078345 A JP 2008078345A JP 2009230686 A JP2009230686 A JP 2009230686A
- Authority
- JP
- Japan
- Prior art keywords
- host
- content management
- content
- server
- management server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】ＤＨＴを使用したＰ２Ｐのコンテンツ共有システムにおいて、オーバーレイネットワーク上で管理するコンテンツの管理割当の不公平を是正することができるコンテンツ管理サーバ及びコンテンツ管理プログラムを提供する。
【解決手段】コンテンツ管理サーバ１は、ホストＩＤによってコンテンツ管理サーバ１同士を識別するオーバーレイネットワークにおいて、少なくとも１以上の他のコンテンツ管理サーバ１と協同して、複数のコンテンツを管理するものにおいて、ホストＩＤ生成手段１５と、ホスト参加処理手段１１と、検索用ホストリスト記憶手段１９と、を備える。
【選択図】図１
【解決手段】コンテンツ管理サーバ１は、ホストＩＤによってコンテンツ管理サーバ１同士を識別するオーバーレイネットワークにおいて、少なくとも１以上の他のコンテンツ管理サーバ１と協同して、複数のコンテンツを管理するものにおいて、ホストＩＤ生成手段１５と、ホスト参加処理手段１１と、検索用ホストリスト記憶手段１９と、を備える。
【選択図】図１
Description
本発明は、ネットワーク上の複数のサーバによって、コンテンツを分散して管理するコンテンツ管理サーバ及びコンテンツ管理プログラムに関する。
従来、コンテンツをネットワーク上の複数のサーバによって管理するコンテンツ分散共有技術では、ネットワークで接続された各サーバが保有する映像、音声、データ等のファイルであるコンテンツを、当該ネットワーク上において、ユーザが使用するユーザ端末で利用できるようになっている。このため、コンテンツ分散共有技術では、ユーザ端末により、ユーザの所望のコンテンツがどのサーバに保存されているのかを高速に発見する方法が必要となる。
そして、コンテンツ分散共有技術は、中央集権型と分散型とに大別される。
中央集権型は、各サーバが保有するコンテンツの情報と、当該サーバのアドレスとをメタデータサーバと呼ばれる特定のコンテンツ管理用サーバに登録しておき、ユーザはユーザ端末によりメタデータサーバに問い合わせることによって、所望のコンテンツを発見できるようにしたものである。
中央集権型は、各サーバが保有するコンテンツの情報と、当該サーバのアドレスとをメタデータサーバと呼ばれる特定のコンテンツ管理用サーバに登録しておき、ユーザはユーザ端末によりメタデータサーバに問い合わせることによって、所望のコンテンツを発見できるようにしたものである。
分散型は、中央集権型のメタデータサーバに相当するものが存在せず、ネットワークに接続されるサーバにより構成されるオーバーレイネットワーク上で、各サーバが分散してコンテンツを管理するようにしたものである。
そして、中央集権型は、コンテンツ管理用サーバに登録されるサーバの数や、共有するコンテンツの数や、利用するユーザの数の増大により、当該コンテンツ管理用サーバの負荷が大きくなるため、小規模な広域分散共有に適しており、逆に、分散型は不特定多数の大規模な広域分散共有に適している。
分散型のコンテンツ共有方法として、Ｐ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）型のコンテンツ共有方法がある。
Ｐ２Ｐ型のコンテンツ共有方法は、非構造型と構造型とに分類されるが、ここでは、本発明に関係するＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）を使用した構造型Ｐ２Ｐによるコンテンツ共有方法について説明する。
Ｐ２Ｐ型のコンテンツ共有方法は、非構造型と構造型とに分類されるが、ここでは、本発明に関係するＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）を使用した構造型Ｐ２Ｐによるコンテンツ共有方法について説明する。
ＤＨＴを使用したＰ２Ｐでは、ネットワークに接続されるサーバによりオーバーレイネットワークが構成される。ネットワーク接続されるサーバは、当該サーバのアドレスから、予め決められた、あるハッシュ関数（例えば、ＳＨＡ−１、ＭＤ−５）により、ホストＩＤを生成し、このホストＩＤによりオーバーレイネットワーク内では各サーバを識別している。
そして、ＤＨＴを使用したＰ２Ｐでは、各サーバが保有するコンテンツについて、例えば、当該コンテンツのファイル名から、同様のハッシュ関数を使用してコンテンツＩＤを生成している。そして、オーバーレイネットワーク内では、コンテンツＩＤに近い値のホストＩＤを持つサーバが当該コンテンツを管理している。
ここで、コンテンツの管理とは、コンテンツＩＤと当該コンテンツを保有するサーバの情報（アドレスやポート番号）を保存することである。そして、コンテンツを利用したいユーザは、ユーザ端末によって、利用したいコンテンツのコンテンツＩＤから当該コンテンツＩＤに近い値のホストＩＤを持つサーバを、オーバーレイネットワーク上で発見し、当該コンテンツを保有しているサーバのアドレスを得ることができる。
ＤＨＴを使用したＰ２Ｐのコンテンツ共有方法の代表的な方法として、Ｃｈｏｒｄ（非特許文献１を参照）がある。このＣｈｏｒｄについて、図１０を参照して説明する。Ｃｈｏｒｄでは、図１０に示したように、ｎｏｄｅ ＩＤ（「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」：各サーバのホストＩＤ）を２次元の円周上に時計回りに並べて、オーバーレイネットワークを構成している。ここで、Ｃｈｏｒｄにおいて、自ホストＩＤの時計回りに隣接するサーバをｓｕｃｃｅｓｓｏｒと呼称し、逆方向に隣接するサーバをｐｒｅｄｅｃｅｓｓｏｒと呼称する。
また、図１０に示したように、Ｃｈｏｒｄにおいて、ファイルｉｄがｉｄａ、ｉｄｂ、ｉｄｃ、ｉｄｄのそれぞれのファイルの時計回りに近いｎｏｄｅ ＩＤ「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」のサーバによって管理されている。なお、「ａ」、「ｂ」、「ｃ」、「ｄ」は各サーバで保持しているファイル名を示している。
つまり、このＣｈｏｒｄでは、それぞれのファイルｉｄに時計回りに近いｎｏｄｅ ＩＤ（ホストＩＤ）が当該ファイルｉｄ（コンテンツＩＤ）の付けられたファイルを管理している。
そして、Ｃｈｏｒｄでは、ユーザ端末に公開するコンテンツは、当該コンテンツＩＤに近い値（時計回りに近い）のホストＩＤを持つサーバにより管理され、実際に公開しているコンテンツを保持しているサーバは、オーバーレイネットワーク上で当該コンテンツを管理するサーバとは無関係である。また、各サーバは、ｓｕｃｃｅｓｓｏｒ及びｐｒｅｄｅｃｅｓｓｏｒのホストＩＤを保持すると共に、フィンガー・テーブルと呼ばれる、他のサーバに検索要求を転送する際に用いる検索用テーブルを保持している。このフィンガー・テーブルは、ホストＩＤのビット長をｍとした場合、ｍ個のテーブルを保持することとしている。自サーバのホストＩＤをｋとした場合、フィンガー・テーブルのｉ番目のテーブルには、次の数式（１）で示すホストＩＤが保存されている。
ｔａｂｌｅ［ｉ］＝ｓｕｃｃｅｓｓｏｒ（（ｋ＋２ｉ）（ｍｏｄｕｌｏ２ｍ））
・・・数式（１）
・・・数式（１）
この数式（１）において、“ｍｏｄｕｌｏ”とは、合同式を表しており、ここでは、ｓｕｃｃｅｓｓｏｒのホストＩＤが、ｋ＋２ｉを２ｍで割ったときの剰余に等しいことを示している。この数式（１）では、他のサーバを検索する際の範囲が、２ｍの空間で、１／２の距離、１／４の距離、１／８の距離、・・・という範囲で検索することに相当している。
そして、検索要求を受けたサーバは、各サーバが保存するフィンガー・テーブルから、検索要求のコンテンツＩＤに近い値のホストＩＤを持つサーバに検索要求を転送する。これによって、オーバーレイネットワークに接続されているサーバ数をＮとすると、検索要求を行ったサーバのホストＩＤに近い値のホストＩＤを持つサーバを発見するまでの転送回数は平均ｌｏｇ２Ｎとなる。
また、Ｐ２Ｐのコンテンツ共有方法の他の方法として、Ｐａｓｔｒｙ（非特許文献２を参照）やＴａｐｅｓｔｒｙ（非特許文献３を参照）がある。検索用テーブルとして、Ｃｈｏｒｄでは２ｉ単位の距離を、これらＰａｓｔｒｙやＴａｐｅｓｔｒｙでは、ｂｉ単位（例えば、ｂ＝１６）にすることで、Ｃｈｏｒｄに比較して、当該検索用テーブルを小さくすることができると共に、高速に他のサーバを検索できるようにしたものである。
これらＰａｓｔｒｙやＴａｐｅｓｔｒｙにおける転送回数は平均ｌｏｇｂＮとなる。また、Ｐａｓｔｒｙでは、ホストＩＤを保持する隣接サーバの範囲を広げることで、近隣のサーバを検索する検索効率の改善を行っている。
さらに、オーバーレイネットワークにおいて、オーダー（１）、すなわち、転送回数１回で他のサーバの検索を可能にする方法として、ＯｎｅＨｏｐ（非特許文献４を参照）がある。このＯｎｅＨｏｐでは、オーバーレイネットワークに接続するすべてのサーバのホストＩＤを、すべてのサーバが保持しており、各サーバが保持する検索用テーブルのサイズが大きくなるが、オーダー（１）での検索が可能となっている。
また、ＯｎｅＨｏｐでは、サーバの接続（参加）や離脱を、オーバーレイネットワークのすべてのサーバに通知する必要があるため、図１１に示すように、オーバーレイネットワークを均等にｋ個（ここでは、円を４等分した４個）の領域（９０度の扇形）に分割し、各領域に存在するサーバの中で、Ｓｌｉｃｅ Ｌｅａｄｅｒを決定している。さらに、ｋ個に分割された領域内をｓ個（ここでは、９０度の扇形を３等分した３個）の領域（３０度の扇形）に分割し、各領域に存在するサーバの中で、Ｕｎｉｔ Ｌｅａｄｅｒを決定している。
そして、ＯｎｅＨｏｐでは、サーバの接続（参加）や離脱を検知したサーバ（通知元：△）は、Ｓｌｉｃｅ Ｌｅａｄｅｒ（同一領域内の○）に通知し（矢印１）、通知を受けたＳｌｉｃｅ Ｌｅａｄｅｒは、他のＳｌｉｃｅ Ｌｅａｄｅｒ（他の領域の○）に通知する（矢印２）。そして、Ｓｌｉｃｅ Ｌｅａｄｅｒは、自領域内のＵｎｉｔ Ｌｅａｄｅｒ（Ｓｌｉｃｅ Ｌｅａｄｅｒが属する自領域内の□）に通知されたことを通知する（矢印３）。このように、ＯｎｅＨｏｐでは、Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒへと通知する階層的構造により、サーバの接続や離脱等の情報をオーバーレイネットワーク内のすべてのサーバに通知する。
以上説明したように、ＤＨＴを使用したＰ２Ｐのコンテンツ共有方法では、サーバの接続（参加）や離脱があっても、オーバーレイネットワークの階層的な構造を保つ必要がある。このため、各サーバはＳｔａｂｉｌｉｚａｔｉｏｎと呼ばれる処理を行っている。このＳｔａｂｉｌｉｚａｔｉｏｎでは、ｓｕｃｃｅｓｓｏｒ、ｐｒｅｄｅｃｅｓｓｏｒ、各サーバが保持する検索用テーブル等に記録されたサーバに対して、生存確認用のパケットを定期的に送信することで、サーバの接続や離脱を検知して、各サーバが保持する検索用テーブルのメンテナンス（更新）を行っている。
また、ＤＨＴを使用したＰ２Ｐのコンテンツ共有方法で構築されるオーバーレイネットワークは、サーバが接続される物理ネットワークとは無関係に構築される。このため、オーバーレイネットワーク上では隣接しているサーバであっても、物理ネットワーク上では、遠距離に位置している場合があり、遠距離に位置するサーバの場合、多くの検索用パケットやネットワーク維持用パケットが、物理ネットワーク上で送信されてしまうという問題がある。また、物理ネットワーク上では遠距離に位置しているため、パケットの到着遅延や消失の割合が大きくなるという問題がある。
Ｉ．Ｓｔｏｉｃａ ｅｔ ａｌ，"Ｃｈｏｒｄ：Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋ ｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ" Ａ．Ｒｏｗｓｔｒｏｎ ｅｔ ａｌ，"Ｐａｓｒｔｙ：Ｓｃａｌａｂｌｅ，ｄｅｃｅｎｔｒａｌｉｚｅｄ ｏｂｊｅｃｔ ｌｏｃａｔｉｏｎ ａｎｄ ｒｏｕｔｉｎｇ ｆｏｒ ｌａｒｇｅ−ｓｃａｌｅ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｓｙｓｔｅｍｓ" Ｂ．Ｙ．Ｚｈａｏ ｅｔ ａｌ，"Ｔａｐｅｓｔｒｙ：Ａｎ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｆｏｒ Ｆａｕｌｔ−ｔｏｌｅｒａｎｔ Ｗｉｄｅ−ａｒｅａ Ｌｏｃａｔｉｏｎ ａｎｄ Ｒｏｕｔｉｎｇ" Ａ．Ｇｕｐｔａ，ｅｔ ａｌ、"Ｏｎｅ Ｈｏｐ Ｌｏｏｋｕｐｓ ｆｏｒ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｏｖｅｒｌａｙｓ"
Ｉ．Ｓｔｏｉｃａ ｅｔ ａｌ，"Ｃｈｏｒｄ：Ａ Ｓｃａｌａｂｌｅ Ｐｅｅｒ−ｔｏ−ｐｅｅｒ Ｌｏｏｋ ｕｐ Ｓｅｒｖｉｃｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎｓ" Ａ．Ｒｏｗｓｔｒｏｎ ｅｔ ａｌ，"Ｐａｓｒｔｙ：Ｓｃａｌａｂｌｅ，ｄｅｃｅｎｔｒａｌｉｚｅｄ ｏｂｊｅｃｔ ｌｏｃａｔｉｏｎ ａｎｄ ｒｏｕｔｉｎｇ ｆｏｒ ｌａｒｇｅ−ｓｃａｌｅ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｓｙｓｔｅｍｓ" Ｂ．Ｙ．Ｚｈａｏ ｅｔ ａｌ，"Ｔａｐｅｓｔｒｙ：Ａｎ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｆｏｒ Ｆａｕｌｔ−ｔｏｌｅｒａｎｔ Ｗｉｄｅ−ａｒｅａ Ｌｏｃａｔｉｏｎ ａｎｄ Ｒｏｕｔｉｎｇ" Ａ．Ｇｕｐｔａ，ｅｔ ａｌ、"Ｏｎｅ Ｈｏｐ Ｌｏｏｋｕｐｓ ｆｏｒ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｏｖｅｒｌａｙｓ"
しかしながら、ＤＨＴを使用したＰ２Ｐのコンテンツ共有方法で用いられるハッシュ関数により出力されるホストＩＤ又はコンテンツＩＤは、一般にハッシュ空間上で均等となる値が生成される。このため、オーバーレイネットワークに多数のコンテンツを蓄積するサーバと、少数のコンテンツを蓄積するサーバとが接続された（参加した）場合、それぞれのサーバが管理するコンテンツの数は、参加しているサーバの数により均等に分割したものとなる。つまり、各サーバが蓄積しているコンテンツ数の多寡に拘わらず、各サーバが管理するコンテンツ数は、コンテンツ数の合計をサーバ数で除算した数（平均値）となる。
この結果、図１２に示すように、多数のコンテンツを公開するサーバでは、管理するコンテンツの数が公開（蓄積）しているコンテンツの数に比べて少なくなる。逆に、少数のコンテンツを公開するサーバでは、管理するコンテンツの数が公開（蓄積）しているコンテンツの数に比べて多くなる。この結果、各サーバにおいて、コンテンツの管理割当が不公平になるという問題がある。
一般に、多数のコンテンツを公開（蓄積）しているサーバはＣＰＵ性能が高く、少数のコンテンツを公開（蓄積）しているサーバはＣＰＵ性能が低い場合が多いため、コンテンツの管理割当が不公平な場合、コンテンツをサーバ間で共有して管理するシステムにおいて、各サーバの性能差により、サーバ間で均等にユーザ端末からの要求を処理することができず、安定性が低下するおそれがある。例えば、多数のコンテンツを公開しているサーバに、ユーザ端末からの要求が集中した場合、実際にコンテンツを管理しているのは、少数のコンテンツを公開しているサーバであるので、処理がさばききれないと言う事態が生じる。
さらに、従来のホストＩＤの付与方法の問題点について、図１３を参照して説明する。この図１３において、「○」がホストＩＤを示し、「●」がコンテンツＩＤを示し、図中、右側の３つのホストＩＤをまとめてαとし、左側の１つのホストＩＤをまとめてβとする。そして、この図１３に示すように、物理ネットワーク上で近距離のサーバ、すなわち、αの３つのホストＩＤは、オーバーレイネットワーク上でもそれぞれ近距離になるように配置され、βの１つのホストＩＤは、オーバーレイネットワーク上ではαからすると遠距離に配置される。この結果、特定の地域に多くのサーバが集中している場合には、特定の地域から多くのコンテンツが公開されることになる。そして、公開されたコンテンツＩＤはハッシュ関数により、オーバーレイネットワーク上に均等に配置されるため、公開されたコンテンツは、大局的に見ると、サーバが参加している地域ごとに均等に管理することになる。すなわち、α、βで公開しているのはそれぞれ８個のコンテンツ（コンテンツＩＤ）であり、αからすれば、３つのホストＩＤ（３台のサーバ）によって８個のコンテンツを管理しているが、βからすれば、１つのホストＩＤ（１台のサーバ）によって８個のコンテンツを管理していることになる。このため、従来のホストＩＤの付与方法では、コンテンツの管理割当の不公平性はさらに増加することになる。
従来のホストＩＤの付与方法を、例えば、放送局において、コンテンツの共有に利用した場合では、一般に都心のセンター局に多数のサーバが配置され、そこから多数のコンテンツが公開されており、地方のローカル局に少数のサーバが配置され、そこから少数のコンテンツが公開されている。しかし、この場合、センター局のコンテンツの多くを、ローカル局のサーバが管理する状態になってしまう。すなわち、図１３を参照して説明したように、多数のサーバが管理するコンテンツ数（センター局で管理するコンテンツ数）と、少数のサーバが管理するコンテンツ数（ローカル局で管理するコンテンツ数）とが均等に割り当てられてしまうため、少数のサーバが管理するコンテンツ数は、１台当たりのサーバに換算すると、多数のサーバが管理するコンテンツ数よりも多くなってしまう。
そこで、本発明では、前記した問題を解決し、ＤＨＴを使用したＰ２Ｐのコンテンツ共有システムにおいて、オーバーレイネットワーク上において、管理するコンテンツの管理割当の不公平を是正することができるコンテンツ管理サーバ及びコンテンツ管理プログラムを提供することを目的とする。
前記課題を解決するため、請求項１に記載のコンテンツ管理サーバは、ホストＩＤによってコンテンツ管理サーバ同士を識別するオーバーレイネットワークであって、少なくとも１以上の他のコンテンツ管理サーバと協同して、複数のコンテンツを管理するコンテンツ管理サーバにおいて、ホストＩＤ生成手段と、ホスト参加処理手段と、検索用ホストリスト記憶手段と、を備え、前記ホストＩＤ生成手段は、前記オーバーレイネットワークにおいて公開するコンテンツのうちの所定数のコンテンツごとに、前記ホストＩＤとは特定のビットが異なるビット列を有する仮想ホストＩＤを生成し、前記検索用ホストリスト記憶手段は、前記仮想ホストＩＤと前記サーバアドレスとを対応付けた前記検索用ホストリストを記憶すること、を特徴とする。
かかる構成によれば、コンテンツ管理サーバは、ホストＩＤ生成手段によって、各コンテンツ管理サーバのオーバーレイネットワークにおけるサーバアドレスと予め設定したハッシュ関数とに基づいて、ホストＩＤを生成する。そして、コンテンツ管理サーバは、ホスト参加処理手段によって、ホストＩＤ生成手段で生成されたホストＩＤとサーバアドレスとを、他のコンテンツ管理サーバに通知することで、オーバーレイネットワークに、該当する当該コンテンツ管理サーバの登録を行う。また、コンテンツ管理サーバは、検索用ホストリスト記憶手段に、ホストＩＤ生成手段で生成された仮想ホストＩＤとサーバアドレスとを対応付けた検索用ホストリストを記憶する。このようにコンテンツ管理サーバでは、公開するコンテンツ数が増加しても、ホストＩＤ生成手段によって、仮想ホストＩＤを生成することで、当該コンテンツを管理するサーバを仮想的に設定することができる。
請求項２に記載のコンテンツ管理サーバは、請求項１に記載のコンテンツ管理サーバにおいて、ホストＩＤ生成手段が、物理ネットワーク上で所定距離内にあるコンテンツ管理サーバ同士に同一のＩＤを割り当てた位置識別ＩＤを、前記ホストＩＤの特定のビットに割り当てることで、物理ネットワーク上におけるコンテンツ管理サーバ間の距離を前記オーバーレイネットワーク上におけるコンテンツ管理サーバ間の距離に反映させ、管理用ホストリスト記憶手段と、スタビライゼーション処理手段と、を備えることを特徴とする。
かかる構成によれば、コンテンツ管理サーバは、管理用ホストリスト記憶手段に、ホストＩＤ生成手段で生成したホストＩＤに位置識別ＩＤを特定のビットに割り当てたホストＩＤとサーバアドレスとを対応付けた管理用ホストリストを記憶し、スタビライゼーション処理手段によって、オーバーレイネットワークにおいて、管理用ホストリスト記憶手段に記憶されている管理用ホストリストに存在するホストＩＤのコンテンツ管理サーバ宛に送信したパケットの返信の有無によって、各コンテンツ管理サーバが現在接続されているかどうかの確認を行う。このように、位置識別ＩＤによって、所定距離内にあるコンテンツ管理サーバが判明することになり、同一の位置識別ＩＤであれば、所定距離内、例えば、同一の建物内や地域内にコンテンツ管理サーバが存在していることになる。
請求項３に記載のコンテンツ管理プログラムは、ホストＩＤによってコンテンツ管理サーバ同士を識別するオーバーレイネットワークにおいて、少なくとも１以上の他のコンテンツ管理サーバと協同して、複数のコンテンツを管理するために、検索用ホストリスト記憶手段を備えたコンピュータを、ホストＩＤ生成手段、ホスト参加処理手段、として機能させ、前記ホストＩＤ生成手段が、前記オーバーレイネットワークにおいて公開するコンテンツのうちの所定数のコンテンツごとに、前記ホストＩＤとは特定のビットが異なるビット列を有する仮想ホストＩＤを生成し、前記検索用ホストリスト記憶手段は、前記ホストＩＤと前記サーバアドレスと対応付けたと共に前記仮想ホストＩＤと前記サーバアドレスとを対応付けた前記検索用ホストリストを記憶することを特徴とする。
かかる構成によれば、コンテンツ管理プログラムは、ホストＩＤ生成手段によって、各コンテンツ管理サーバのオーバーレイネットワークにおけるサーバアドレスと予め設定したハッシュ関数とに基づいて、ホストＩＤを生成する。そして、コンテンツ管理プログラムは、ホスト参加処理手段によって、ホストＩＤ生成手段で生成されたホストＩＤとサーバアドレスとを、他のコンテンツ管理サーバに通知することで、オーバーレイネットワークに、当該コンテンツ管理サーバの登録を行う。
請求項１、３に記載の発明によれば、コンテンツ管理サーバが管理するコンテンツの所定数ごとに、仮想ホストＩＤを生成することで、実際に公開しているコンテンツ数が増加するほど、当該仮想ホストＩＤにより管理するコンテンツ数も増加させることができるので、オーバーレイネットワーク上において、管理するコンテンツの管理割当の不公平を是正することができる。
請求項２に記載の発明によれば、オーバーレイネットワークにおいて、コンテンツ管理サーバが現在接続されているかどうかの確認を行う際に、管理用ホストリスト記憶手段に記憶されているホストＩＤのコンテンツ管理サーバ宛にパケットを送信しているので、物理的に所定距離内にあるコンテンツ管理サーバに対して行うことができ、送受信するパケット数を減少させることができる。
次に、本発明の実施形態について、適宜、図面を参照しながら詳細に説明する。
（コンテンツ管理サーバの構成）
図１はコンテンツ管理サーバのブロック図である。図１に示すように、コンテンツ管理サーバ１は、ネットワークを介し他のコンテンツ管理サーバ１と協同して複数のコンテンツを管理すると共に、ユーザが使用するユーザ端末２からの要求に従って管理しているコンテンツを送信するもので、パケット送受信手段３と、スタビライゼーション処理手段５と、ネットワーク管理用パケット処理手段７と、検索用パケット処理手段９と、ホスト参加処理手段１１と、コンテンツ登録処理手段１３と、ホストＩＤ生成手段１５と、管理用ホストリスト記憶手段１７と、検索用ホストリスト記憶手段１９と、コンテンツ管理情報記憶手段２１と、コンテンツ蓄積手段２３と、を備えている。
（コンテンツ管理サーバの構成）
図１はコンテンツ管理サーバのブロック図である。図１に示すように、コンテンツ管理サーバ１は、ネットワークを介し他のコンテンツ管理サーバ１と協同して複数のコンテンツを管理すると共に、ユーザが使用するユーザ端末２からの要求に従って管理しているコンテンツを送信するもので、パケット送受信手段３と、スタビライゼーション処理手段５と、ネットワーク管理用パケット処理手段７と、検索用パケット処理手段９と、ホスト参加処理手段１１と、コンテンツ登録処理手段１３と、ホストＩＤ生成手段１５と、管理用ホストリスト記憶手段１７と、検索用ホストリスト記憶手段１９と、コンテンツ管理情報記憶手段２１と、コンテンツ蓄積手段２３と、を備えている。
このコンテンツ管理サーバ１は、複数の他のコンテンツ管理サーバ１（図１では単にサーバ１と示している）とオーバーレイネットワークを構成しており、Ｐ２Ｐのコンテンツ共有方法を実現している。そして、このコンテンツ管理サーバ１は、ＯｎｅＨｏｐによるファイル共有に適応して、他のコンテンツ管理サーバ１の接続（参加）及び離脱を行うと共に、複数のコンテンツのオーバーレイネットワークへの登録等を行っている。
ユーザ端末２は、ユーザが使用するＰＣ等の端末であり、ネットワークを介して、コンテンツ管理サーバ１に対し、コンテンツの利用を要求するものである。なお、この図１では、１台しか図示していないが、実際には、複数台存在している。
パケット送受信手段３は、ユーザ端末２や他のコンテンツ管理サーバ１（双方を合わせて、単に外部ともいう）からの要求パケットの受信と、当該コンテンツ管理サーバ１から外部に対し要求パケットの送信を行うものである。また、このパケット送受信手段３は、送信した要求パケットに対応する外部からの応答パケットを受信するものである。
要求パケットは、外部に対し何らかの処理を要求するコマンドを含んだものであり、各コマンドに対応した固有データを含んだものである。この実施形態では、ＪＯＩＮコマンド、ＰＵＴコマンド、ＧＥＴコマンド、ＰＩＮＧコマンド、ＮＯＴＩＦＹコマンド（以下、ＪＯＩＮ、ＰＵＴ、ＧＥＴ、ＰＩＮＧ、ＮＯＴＩＦＹと略す場合もある）を用いている。
応答パケットは、要求パケットに対応する応答（ＯＫ又はＮＧ）を含んだものであり、要求コマンドがＪＯＩＮコマンド又はＧＥＴコマンドの場合には、それぞれに対応した固有データを含んだものである。
ここで、図２、図３を参照して、まず、パケットの構造と、要求パケット及び応答パケットの固有データとについて説明する。
図２に示すように、パケットは、「コマンド種別／応答種別」、「送信先アドレス」、「送信元アドレス」、「固有データ」を含む構造となっている。「コマンド種別／応答種別」は、要求パケットの場合にはコマンド種別を、応答パケットの場合には応答種別を示すものであり、コマンド種別がＪＯＩＮ、ＰＵＴ、ＧＥＴ、ＰＩＮＧ、ＮＯＴＩＦＹのいずれかであり、応答種別がＯＫ、ＮＧのいずれかである。
図２に示すように、パケットは、「コマンド種別／応答種別」、「送信先アドレス」、「送信元アドレス」、「固有データ」を含む構造となっている。「コマンド種別／応答種別」は、要求パケットの場合にはコマンド種別を、応答パケットの場合には応答種別を示すものであり、コマンド種別がＪＯＩＮ、ＰＵＴ、ＧＥＴ、ＰＩＮＧ、ＮＯＴＩＦＹのいずれかであり、応答種別がＯＫ、ＮＧのいずれかである。
「送信先アドレス」はパケットの送信先のアドレスを示すものであり、「送信元アドレス」はパケットの送信元のアドレスを示すものである。
「固有データ」は、コマンド種別によって異なるデータであり、図３に示すように、ＪＯＩＮの要求パケットの固有データは、ホストＩＤ、位置識別ＩＤ、サーバアドレスからなり、ＪＯＩＮの応答パケットの固有データは、ホストリストである。
「固有データ」は、コマンド種別によって異なるデータであり、図３に示すように、ＪＯＩＮの要求パケットの固有データは、ホストＩＤ、位置識別ＩＤ、サーバアドレスからなり、ＪＯＩＮの応答パケットの固有データは、ホストリストである。
また、ＰＵＴの要求パケットの固有データは、コンテンツＩＤ、サーバアドレスからなる。ＰＵＴの応答パケットの固有データは無い。
ＧＥＴの要求パケットの固有データは、コンテンツＩＤからなり、ＧＥＴの応答パケットの固有データはサーバアドレスからなる。
ＧＥＴの要求パケットの固有データは、コンテンツＩＤからなり、ＧＥＴの応答パケットの固有データはサーバアドレスからなる。
ＰＩＮＧの要求パケットの固有データ及び応答パケットの固有データは無い。
ＮＯＴＩＦＹの要求パケットの固有データは、ホストＩＤ、位置識別ＩＤ、サーバアドレス、動作種別、通知モードからなり、ＮＯＴＩＦＹの応答パケットの固有データは無い。
ＮＯＴＩＦＹの要求パケットの固有データは、ホストＩＤ、位置識別ＩＤ、サーバアドレス、動作種別、通知モードからなり、ＮＯＴＩＦＹの応答パケットの固有データは無い。
次に、各種コマンド（ＪＯＩＮコマンド、ＰＵＴコマンド、ＧＥＴコマンド、ＰＩＮＧコマンド、ＮＯＴＩＦＹコマンド）の内容について説明する。
ＪＯＩＮコマンドは、コンテンツ管理サーバ１がオーバーレイネットワークに接続（参加）する場合に用いるものである。ＪＯＩＮコマンドの要求パケット（以下、要求パケット（ＪＯＩＮ）とする）には、前記したように、参加するコンテンツ管理サーバ１（以下、新規のコンテンツ管理サーバ１という）のホストＩＤ、位置識別ＩＤ、サーバアドレスが固有データとして含まれている。以下、ＪＯＩＮコマンドの応答パケットを応答パケット（ＪＯＩＮ）とする。
ＪＯＩＮコマンドは、コンテンツ管理サーバ１がオーバーレイネットワークに接続（参加）する場合に用いるものである。ＪＯＩＮコマンドの要求パケット（以下、要求パケット（ＪＯＩＮ）とする）には、前記したように、参加するコンテンツ管理サーバ１（以下、新規のコンテンツ管理サーバ１という）のホストＩＤ、位置識別ＩＤ、サーバアドレスが固有データとして含まれている。以下、ＪＯＩＮコマンドの応答パケットを応答パケット（ＪＯＩＮ）とする。
ホストＩＤは、予め決められたハッシュ関数により生成されたものである。この実施形態では、ホストＩＤのビット長を１６０ビットとしている。
位置識別ＩＤは、物理ネットワーク上のコンテンツ管理サーバ１間の距離を、オーバーレイネットワーク上のコンテンツ管理サーバ１間の距離に反映させたものであり、物理ネットワーク上のコンテンツ管理サーバ１間の距離が近ければ（例えば、同じ建物内、同じ都道府県内等）、同一のＩＤを使用するとしたものである。そして、この位置識別ＩＤは、コンテンツ管理サーバ１のＩＰアドレスの上位アドレスを、ハッシュ関数を使って自動生成したり、予め地域ごとに固有のＩＤを用いたりするなどして決定する。この実施形態では、位置識別ＩＤのビット長を１６ビットとしている。
そして、ＪＯＩＮコマンドがオーバーレイネットワークに既に接続（参加）しているコンテンツ管理サーバ１（以下、既存のコンテンツ管理サーバ１という）に送信される。そして、ＪＯＩＮコマンドが成功すると、新規のコンテンツ管理サーバ１は、既存のコンテンツ管理サーバ１から応答パケットとして、既存のコンテンツ管理サーバ１の管理用ホストリスト記憶手段１７及び検索用ホストリスト記憶手段１９に記憶されているホストリストを受信する。各ホストリストの詳細については後記する。
ＰＵＴコマンドは、コンテンツをオーバーレイネットワーク上に登録する際に用いるものである。ＰＵＴコマンドの要求パケット（以下、要求パケット（ＰＵＴ）とする）には、登録するコンテンツＩＤとこのコンテンツを蓄積しているコンテンツ管理サーバ１のサーバアドレスが含まれている。そして、コンテンツＩＤは、ホストＩＤと同じハッシュ関数によって生成されたものである。以下、ＰＵＴコマンドの応答パケットを応答パケット（ＰＵＴ）とする。
ＧＥＴコマンドは、コンテンツのコンテンツＩＤから当該コンテンツを蓄積しているコンテンツ管理サーバ１のサーバアドレスを取得する際に用いるものである。ＧＥＴコマンドの要求パケット（以下、要求パケット（ＧＥＴ）とする）には、コンテンツＩＤが含まれている。そして、ＧＥＴコマンドの応答パケット（以下、応答パケット（ＧＥＴ）とする）という）には、要求パケット（ＧＥＴ）に含まれたコンテンツＩＤと一致するコンテンツＩＤのコンテンツを蓄積しているコンテンツ管理サーバ１のサーバアドレスが含まれている。
ＰＩＮＧコマンドは、コンテンツ管理サーバ１の生存確認（オーバーレイネットワークに接続（参加）しているのか、離脱してしまったのかの確認）を行う際に用いるものである。コンテンツ管理サーバ１は、ＰＩＮＧコマンドの要求パケット（以下、要求パケット（ＰＩＮＧ）とする）を送信し、ＰＩＮＧコマンドの応答パケット（以下、応答パケット（ＰＩＮＧ）とする）を受信することで、他のコンテンツ管理サーバ１の存在を随時確認している。
ＮＯＴＩＦＹコマンドは、コンテンツ管理サーバ１の接続（参加）、離脱をオーバーレイネットワーク上のすべてのコンテンツ管理サーバ１に通知する際に用いるものである。ＮＯＴＩＦＹコマンドの要求パケット（以下、要求パケット（ＮＯＴＩＦＹ）とする）には、前記したように接続（参加）又は離脱したコンテンツ管理サーバ１のホストＩＤ、位置識別ＩＤ、サーバアドレス、動作種別、通知モードが含まれている。以下、ＮＯＴＩＦＹコマンドの応答パケットを応答パケット（ＮＯＴＩＦＹ）とする。
動作種別は、コンテンツ管理サーバ１の接続（参加（ＪＯＩＮ））又は離脱（ＬＥＡＶＥ）を示すものである。
通知モードは、ＯｎｅＨｏｐにおける通知の段階を示すものであり、前記した図１１における通報元からＳｌｉｃｅ Ｌｅａｄｅｒへの第１段階（図１１の“１”）の通知と、Ｓｌｉｃｅ Ｌｅａｄｅｒから他のＳｌｉｃｅ Ｌｅａｄｅｒへの第２段階（図１１の“２”）の通知と、Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒへの第３段階（図１１“３”）の通知と、Ｕｎｉｔ Ｌｅａｄｅｒから領域内のコンテンツ管理サーバ１への第４段階の通知とがある。
なお、各コマンドによるコンテンツ管理サーバ１の動作については、後記する。図１に戻る。
通知モードは、ＯｎｅＨｏｐにおける通知の段階を示すものであり、前記した図１１における通報元からＳｌｉｃｅ Ｌｅａｄｅｒへの第１段階（図１１の“１”）の通知と、Ｓｌｉｃｅ Ｌｅａｄｅｒから他のＳｌｉｃｅ Ｌｅａｄｅｒへの第２段階（図１１の“２”）の通知と、Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒへの第３段階（図１１“３”）の通知と、Ｕｎｉｔ Ｌｅａｄｅｒから領域内のコンテンツ管理サーバ１への第４段階の通知とがある。
なお、各コマンドによるコンテンツ管理サーバ１の動作については、後記する。図１に戻る。
スタビライゼーション処理手段５は、パケット送受信手段３を介して、要求パケット（ＰＩＮＧ）を隣接するコンテンツ管理サーバ１に送信し、応答パケット（ＰＩＮＧ）を受信することで、当該コンテンツ管理サーバ１の生存確認を行って、オーバーレイネットワークの構造を維持するものである。
ネットワーク管理用パケット処理手段７は、パケット送受信手段３を介して、受信した要求パケットが要求パケット（ＪＯＩＮ）又は要求パケット（ＮＯＴＩＦＹ）であるかを判別し、他のコンテンツ管理サーバ１のオーバーレイネットワークへの接続（参加）及び離脱の管理を行うものである。
そして、このネットワーク管理用パケット処理手段７は、受信した要求パケットが、要求パケット（ＪＯＩＮ）の場合、要求パケット（ＪＯＩＮ）の固有データであるホストＩＤ、位置識別ＩＤ、サーバアドレスに従って、管理用ホストリスト記憶手段１７の管理用ホストリスト及び検索用ホストリスト記憶手段１９の検索用ホストリストを更新するものである。なお、管理用ホストリスト及び検索用ホストリストは、ＯｎｅＨｏｐにおける２次元の円周上に並べられたオーバーレイネットワークにおけるそれぞれのサーバの位置やアドレスを示すものである。
管理用ホストリストは、当初のホストＩＤの上位ビットを位置識別ＩＤに置き換えたものをホストＩＤとして登録したものである。この実施形態では、位置識別ＩＤを１６ビット長としており、ホストＩＤを１６０ビットとしているので、このホストＩＤの１６０ビットの上位１６ビットを位置識別ＩＤに置き換えたものが、管理用ホストリストに登録されることになる。なお、この管理用ホストリストは、ホストＩＤの値により、当該ホストＩＤの値が大きい順又は小さい順にソートされているものとする。これにより、この管理用ホストリストを、各コンテンツ管理サーバ１の管理に用いたオーバーレイネットワークは、物理的なネットワーク上での各コンテンツ管理サーバ１の距離を反映させた構造となる。また、ネットワーク管理用パケット処理手段７では、登録しようとするホストＩＤ（上位ビットを位置識別ＩＤに置き換えたホストＩＤ）がすでに登録されている場合には、当該ホストＩＤを追加登録しない。
検索用ホストリストは、要求パケット（ＪＯＩＮ）の固有データであるホストＩＤ、位置識別ＩＤ、サーバアドレスに従って、当該ホストＩＤをそのまま登録したものである。この検索用ホストリストも、ホストＩＤの値により、当該ホストＩＤの値が大きい順又は小さい順にソートされているものとする。
また、このネットワーク管理用パケット処理手段７は、受信した要求パケットが、要求パケット（ＮＯＴＩＦＹ）の場合、要求パケット（ＮＯＴＩＦＹ）の固有データである動作種別が参加（ＪＯＩＮ）又は離脱（ＬＥＡＶＥ）に従って、要求パケット（ＮＯＴＩＦＹ）の固有データであるホストＩＤ、位置識別ＩＤ、サーバアドレスを、管理用ホストリスト記憶手段１７の管理用ホストリスト及び検索用ホストリスト記憶手段１９の検索用ホストリストに書き込む（記憶させる）ものである。なお、管理用ホストリストには、当初のホストＩＤの上位ビットを位置識別ＩＤに置き換えたものが書き込まれ、検索用ホストリストには、当初のホストＩＤがそのまま書き込まれる。
さらに、このネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の場合、要求パケット（ＮＯＴＩＦＹ）の固有データである通信モード（ｍｏｄｅ＝１、ｍｏｄｅ＝２、ｍｏｄｅ＝３、ｍｏｄｅ＝４のいずれか）に従って、パケット送受信手段３を介して、要求パケット（ＮＯＴＩＦＹ）を他のコンテンツ管理サーバ１に送信するものである。
通信モード１（ｍｏｄｅ＝１：通知元からＳｌｉｃｅ Ｌｅａｄｅｒに向けた通信）は、通信モードを２に変更（通信モード２を発行）し、オーバーレイネットワーク上の自体を除く、すべてのＳｌｉｃｅ Ｌｅａｄｅｒに要求パケット（ＮＯＴＩＦＹ）を送信するものである。
通信モード２（ｍｏｄｅ＝２：Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒに向けた通信）は、通信モード３に変更（通信モード３を発行）し、自体（Ｓｌｉｃｅ Ｌｅａｄｅｒ）が所属するすべてのＵｎｉｔ Ｌｅａｄｅｒに要求パケット（ＮＯＴＩＦＹ）を送信するものである。
通信モード２（ｍｏｄｅ＝２：Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒに向けた通信）は、通信モード３に変更（通信モード３を発行）し、自体（Ｓｌｉｃｅ Ｌｅａｄｅｒ）が所属するすべてのＵｎｉｔ Ｌｅａｄｅｒに要求パケット（ＮＯＴＩＦＹ）を送信するものである。
通信モード３（ｍｏｄｅ＝３：Ｕｎｉｔ Ｌｅａｄｅｒから所属しているコンテンツ管理サーバ１に向けた通信）は、通信モード４に変更（通信モード４を発行）し、自体（Ｕｎｉｔ Ｌｅａｄｅｒ）が所属するすべてのコンテンツ管理サーバ１に要求パケット（ＮＯＴＩＦＹ）を送信するものである。
通信モード４（ｍｏｄｅ＝４）は、要求パケット（ＮＯＴＩＦＹ）の送信が完了したことを示すものである。
通信モード４（ｍｏｄｅ＝４）は、要求パケット（ＮＯＴＩＦＹ）の送信が完了したことを示すものである。
検索用パケット処理手段９は、パケット送受信手段３を介して、他のコンテンツ管理サーバ１から送信された要求パケット（ＰＵＴ）を受信することで、当該要求パケット（ＰＵＴ）の固有データであるコンテンツＩＤ、サーバアドレスをコンテンツ管理情報として、コンテンツ管理情報記憶手段２１に書き込む（記憶させる）ものである。
また、検索用パケット処理手段９は、パケット送受信手段３を介して、ユーザ端末２から送信された要求パケット（ＧＥＴ）を受信することで、当該要求パケットの固有データであるコンテンツＩＤと一致するコンテンツ管理情報を、まず、コンテンツ管理情報記憶手段２１に書き込まれたコンテンツ管理情報の中から検索し、該当するものがあった場合には通知し、該当するものが無かった場合には検索用ホストリスト記憶手段１９に記憶されている検索用ホストリストのホストＩＤ、サーバアドレスを通知する。
ホスト参加処理手段１１は、コンテンツ管理サーバ１がオーバーレイネットワークに接続（参加）する際に、ホストＩＤ生成手段１５からホストＩＤを取得し、このホストＩＤを固有データとする要求パケット（ＪＯＩＮ）を生成するものである。そして、このホスト参加処理手段１１は、生成した要求パケット（ＪＯＩＮ）を、パケット送受信手段３を介して、既にオーバーレイネットワークに接続している他のコンテンツ管理サーバ１に送信するものである。
なお、このホスト参加処理手段１１で生成した要求パケット（ＪＯＩＮ）の送信先は、既に参加している他のコンテンツ管理サーバ１のアドレスを、外部から予め指定しているものである。
そして、ホスト参加処理手段１１は、応答パケット（ＪＯＩＮ）が、送信先の他のコンテンツ管理サーバ１から送信されると、この応答パケット（ＪＯＩＮ）の固有データであるホストリストを、管理用ホストリスト記憶手段１７及び検索用ホストリスト記憶手段１９にそれぞれ新規に作成するものである。なお、その後のホストリストの更新は、ネットワーク管理用パケット処理手段７によって行われる。
また、ホスト参加処理手段１１は、自体がオーバーレイネットワークに接続したことを他のコンテンツ管理サーバ１に通知するために、動作種別を参加、通知モードを１（通知元からＳｌｉｃｅ Ｌｅａｄｅｒ）とした要求パケット（ＮＯＴＩＦＹ）を生成し、パケット送受信手段３を介して、既にオーバーレイネットワークに接続している他のコンテンツ管理サーバ１に送信するものである。
なお、ホスト参加処理手段１１で生成した要求パケット（ＮＯＴＩＦＹ）の送信先は、自コンテンツ管理サーバ１が所属しているＳｌｉｃｅ Ｌｅａｄｅｒである。Ｓｌｉｃｅ Ｌｅａｄｅｒの決定方法については後記する。また、ホスト参加処理手段１１は、後記するコンテンツ登録処理手段１３からの「仮想ホストＩＤのＪＯＩＮ処理の要求」に従って、仮想ホストＩＤを設定する（詳細は、コンテンツ登録処理手段１３にて行う）。
コンテンツ登録処理手段１３は、パケット送受信手段３を介して、要求パケット（ＰＵＴ）を送信することで、コンテンツ蓄積手段２３に蓄積されているコンテンツを、オーバーレイネットワーク上に登録するものである。
このコンテンツ登録処理手段１３は、まず、コンテンツのオーバーレイネットワーク上への登録数をカウントするための変数ｎ（コンテンツ登録カウンタ）を０とし、コンテンツ蓄積手段２３に蓄積されているコンテンツを読み出して、コンテンツＩＤが生成されているか否かに基づいて、未登録か否かを判定し、未登録の場合（コンテンツＩＤが生成されていない）、コンテンツＩＤを生成する。このコンテンツＩＤの生成は、コンテンツのファイル名と、当該コンテンツが蓄積されているコンテンツ管理サーバ１のホストＩＤを生成した際に用いたハッシュ関数とによって行われる。
そして、コンテンツ登録処理手段１３は、要求パケット（ＰＵＴ）を生成し、パケット送受信手段３を介して、他のコンテンツ管理サーバ１に送信する。この要求パケット（ＰＵＴ）の送信先は、検索用ホストリスト記憶手段１９に記憶されている検索用ホストリストからコンテンツＩＤに近いコンテンツ管理サーバ１となる。
そして、コンテンツ登録処理手段１３は、コンテンツ登録カウンタｎに１を加算し、ｎが予め設定する数Ｎ（このＮがコンテンツの公開数であり、各コンテンツ管理サーバ１が管理する管理数）よりも小さい場合、コンテンツ蓄積手段２３に蓄積されている他のコンテンツを読み出して、登録処理を継続して行う。
ここで、コンテンツ登録処理手段１３は、コンテンツ登録カウンタｎがＮより大きい場合、仮想ホストＩＤのＪＯＩＮ処理の要求を、ホスト参加処理手段１１に行う。そして、コンテンツ登録処理手段１３は、仮想ホストＩＤのＪＯＩＮ処理後、コンテンツ登録カウンタｎをリセットし、他のコンテンツを読み出して登録処理を継続して行う。
この仮想ホストＩＤのＪＯＩＮ処理は、コンテンツ管理サーバ１がオーバーレイネットワーク上に公開したコンテンツの数と、各コンテンツ管理サーバ１が管理する管理数とが同じになるように公開したコンテンツ数Ｎごとに、ホストＩＤが異なるＩＤを生成し、この生成したＩＤを新たにオーバーレイネットワークに参加させる。これによって、公開したコンテンツ数が多いコンテンツ管理サーバ１ほど、管理するコンテンツ数が多くなる。ここで、新たに生成したホストＩＤを仮想ホストＩＤと呼称する。
ホストＩＤ生成手段１５は、ホストＩＤ参加処理手段１１にホストＩＤを提供すると共に、コンテンツ登録処理手段１３から仮想ホストＩＤのＪＯＩＮ処理の要求を受けた場合、仮想ホストＩＤを生成するものである。なお、前記したように、ホストＩＤは、予め決められたハッシュ関数により生成されたもので、この実施形態では、ホストＩＤのビット長を１６０ビットとしている。
ホストＩＤ生成手段１５による仮想ホストＩＤの生成は、ｉ番目の仮想ホストＩＤとして、元のホストＩＤの上位ｍビットを以下の数式（１）により計算することで生成する。
仮想ホストＩＤの上位ｍビット＝（ａ・ｆ〜＋ａ〜・ｆ） ・・・数式（１）
ａ＝ホストＩＤの上位ｍビット
ｆ＝ｄｉｎ＜ｉ＞
なお、ｄｉｎ＜ｉ＞はビットリバース、ｆ〜はｆのビット反転、ａ〜はａのビット反転を表している。
仮想ホストＩＤの上位ｍビット＝（ａ・ｆ〜＋ａ〜・ｆ） ・・・数式（１）
ａ＝ホストＩＤの上位ｍビット
ｆ＝ｄｉｎ＜ｉ＞
なお、ｄｉｎ＜ｉ＞はビットリバース、ｆ〜はｆのビット反転、ａ〜はａのビット反転を表している。
ここで、図８を参照して、仮想ホストＩＤの割り当ての順について説明する。この図８では、ｍ＝３の場合において、仮想ホストＩＤのオーバーレイネットワーク上の位置を示している。この図８に示したように、実線の「元のホストＩＤ」から、最も離れているコンテンツ管理サーバ１（点線の「１」）、このコンテンツ管理サーバ１（点線の「１」）と実線の「元のホストＩＤ」との中間のコンテンツ管理サーバ１（点線「２」、点線「３」）といったように、均等に仮想ホストＩＤが割り当てられている。
ａは３ビットであるので、ａ＝「０００」、「００１」、「０１０」、「０１１」、「１００」、「１０１」、「１１０」、「１１１」のいずれかであり、例えば、「０００」とすると、ｉ＝１の場合（１番目の仮想ホストＩＤ）は、数式（１）より、（０００・０１１＋１１１・１００）＝１００となり、ｉ＝２の場合（２番目の仮想ホストＩＤ）は、数式（１）により、（０００・１０１＋１１１・０１０）＝０１０となる。
なお、この実施形態では、ビット長ｍを位置識別ＩＤのビット長と同じ長さとしている。これにより、ホストＩＤ生成手段１５では、コンテンツ登録処理手段１３から仮想ホストＩＤのＪＯＩＮ処理の要求を受けた場合、仮想ホストＩＤが管理用ホストリスト記憶手段１７に記憶されている管理ホストリストにおけるホストＩＤとなるため、当該仮想ホストＩＤは管理用ホストリストには登録されず、検索用ホストリスト記憶手段１９のみに記憶されることになる。このため、仮想ホストＩＤを、検索用ホストリスト記憶手段１９に記憶しても、ネットワーク管理用のパケット（要求パケット（ＮＯＴＩＦＹ））は、仮想ホストＩＤに対しては送信されてないため、オーバーレイネットワークにおいて、送受信されるパケットの増加が起きない。
なお、仮想ホストＩＤの生成の仕方は、前記した方法に限定されるものではなく、他の生成の仕方を用いてもよい。例えば、単純に元のホストＩＤの上位ビットａをカウントアップするという生成の仕方がある。
また、この実施形態では、コンテンツの登録数がＮ個ごとに線形に仮想ホストＩＤの登録を行っているが、この方法に限定されるものではなく、例えば、コンテンツの登録数が２ｉ個ごとなど、非線形な関数を用いる等して、仮想ホストＩＤの登録を行ってもよい。
また、この実施形態では、コンテンツの登録数がＮ個ごとに線形に仮想ホストＩＤの登録を行っているが、この方法に限定されるものではなく、例えば、コンテンツの登録数が２ｉ個ごとなど、非線形な関数を用いる等して、仮想ホストＩＤの登録を行ってもよい。
管理用ホストリスト記憶手段１７は、管理用ホストリストを記憶しているもので、一般的なハードディスクやメモリ等によって構成されている。
検索用ホストリスト記憶手段１９は、検索用ホストリストを記憶しているもので、一般的なハードディスクやメモリ等によって構成されている。
検索用ホストリスト記憶手段１９は、検索用ホストリストを記憶しているもので、一般的なハードディスクやメモリ等によって構成されている。
コンテンツ管理情報記憶手段２１は、コンテンツ管理情報を記憶しているもので、一般的なハードディスクやメモリ等によって構成されている。
コンテンツ蓄積手段２３は、コンテンツを蓄積しているもので、一般的なハードディスクやメモリ等によって構成されている。
コンテンツ蓄積手段２３は、コンテンツを蓄積しているもので、一般的なハードディスクやメモリ等によって構成されている。
（Ｓｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの決定方法）
ここで、Ｓｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの決定方法について説明する。
Ｓｌｉｃｅ Ｌｅａｄｅｒは、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリストによって関連付けられているオーバーレイネットワークをｋ個に分割して、それぞれの分割領域内のコンテンツ管理サーバ１の１台を予め選択することで、決定される。
ここで、Ｓｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの決定方法について説明する。
Ｓｌｉｃｅ Ｌｅａｄｅｒは、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリストによって関連付けられているオーバーレイネットワークをｋ個に分割して、それぞれの分割領域内のコンテンツ管理サーバ１の１台を予め選択することで、決定される。
Ｕｎｉｔ Ｌｅａｄｅｒは、ｋ個に分割された領域をさらにｓ個に分割して、それぞれの分割領域内のコンテンツ管理サーバの１台を予め選択することで、決定される。この実施形態では、位置識別ＩＤの上位８ビットを、Ｓｌｉｃｅ Ｌｅａｄｅｒ用の分割に、下位８ビットを、Ｕｎｉｔ Ｌｅａｄｅｒ用の分割に使用している。すなわち、ｋ＝２５６、ｓ＝２５６である。そして、各領域内でのＳｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの選択方法は任意であるが、この実施形態では、各領域内でホストＩＤが最小なものを、Ｓｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒとしている。
そして、コンテンツ管理サーバ１では、このようなＳｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの決定方法により、位置識別ＩＤを用いて構築された管理用ホストリストを、ネットワーク管理用パケット処理手段７によって、要求パケット（ＮＯＴＩＦＹ）を受信した際に利用することで、Ｓｌｉｃｅ ＬｅａｄｅｒからＵｎｉｔ Ｌｅａｄｅｒへ、Ｕｎｉｔ Ｌｅａｄｅｒから各コンテンツ管理サーバ１に要求パケット（ＮＯＴＩＦＹ）が送信される。
そして、コンテンツ管理サーバ１において、要求パケット（ＮＯＴＩＦＹ）の送信は、物理ネットワーク上の距離が近いコンテンツ管理サーバ１間で行われることになり、遠距離間でのパケットの通信量を少なくすることができる。なお、各領域内でのＳｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒの選択方法として、どのようなものを選択しても、本願の効果には影響を及ぼさない。また、この実施形態では、Ｓｌｉｃｅ Ｌｅａｄｅｒ、Ｕｎｉｔ Ｌｅａｄｅｒという２段階における要求パケット（ＮＯＴＩＦＹ）の送信について説明しているが、さらに多段階層の送信であってもよい。
次に、コンテンツ管理サーバ１における動作を、各手段、コマンド別に説明する。
（コンテンツ管理サーバにおける動作、ホスト参加処理手段 ＪＯＩＮコマンド）
図４に示すフローチャートを参照して、ホスト参加処理手段１１の動作について説明する（適宜、図１参照）。
ホスト参加処理手段１１は、自体がオーバーレイネットワークに接続する際に、パケット送受信手段３を介して、要求パケット（ＪＯＩＮ）を送信する際に、まず、ホストＩＤ生成手段１５で生成されたホストＩＤを取得する（ステップＳ１）。
（コンテンツ管理サーバにおける動作、ホスト参加処理手段 ＪＯＩＮコマンド）
図４に示すフローチャートを参照して、ホスト参加処理手段１１の動作について説明する（適宜、図１参照）。
ホスト参加処理手段１１は、自体がオーバーレイネットワークに接続する際に、パケット送受信手段３を介して、要求パケット（ＪＯＩＮ）を送信する際に、まず、ホストＩＤ生成手段１５で生成されたホストＩＤを取得する（ステップＳ１）。
続いて、ホスト参加処理手段１１は、ホストＩＤ、位置識別ＩＤ、サーバアドレスを固有データとしたＪＯＩＮコマンドを生成し、パケット送受信手段３を介して、要求パケット（ＪＯＩＮ）として送信する（ステップＳ２）。
そして、ホスト参加処理手段１１は、既にオーバーレイネットワークに接続している他のコンテンツ管理サーバ１から応答パケット（ＪＯＩＮ）を、パケット送受信手段３を介して受信し、管理用ホストリスト記憶手段１７及び検索用ホストリスト記憶手段１９に新規にホストリストを作成して、応答パケットの固有データであるホストリストをコピーする（ステップＳ３、ステップＳ４）。
そして、ホスト参加処理手段１１は、自体コンテンツ管理サーバ１がオーバーレイネットワークに接続したことを他のコンテンツ管理サーバ１に通知するため、動作種別を参加（ＪＯＩＮ）、通知モードを１（通知元からＳｌｉｃｅ Ｌｅａｄｅｒ）とした要求パケット（ＮＯＴＩＦＹ）（ＮＯＴＩＦＹ（ＪＯＩＮ））を、パケット送受信手段３を介して送信する（ステップＳ５）。
（コンテンツ管理サーバにおける動作、ネットワーク管理用パケット処理手段）
図５に示すフローチャートを参照して、ネットワーク管理用パケット処理手段７の動作について説明する（適宜、図１参照）。
ネットワーク管理用パケット処理手段７は、まず、パケット送受信手段３を介して受信した要求パケットの種別が要求パケット（ＪＯＩＮ）であるか否かを判別する（ステップＳ１１）。
図５に示すフローチャートを参照して、ネットワーク管理用パケット処理手段７の動作について説明する（適宜、図１参照）。
ネットワーク管理用パケット処理手段７は、まず、パケット送受信手段３を介して受信した要求パケットの種別が要求パケット（ＪＯＩＮ）であるか否かを判別する（ステップＳ１１）。
ネットワーク管理用パケット処理手段７は、要求パケット（ＪＯＩＮ）でないと判別した場合（ステップＳ１１、Ｎｏ）、要求パケット（ＮＯＴＩＦＹ）であるか否かを判別する（ステップＳ１２）。ネットワーク管理用パケット処理手段７は、ステップＳ１２にて要求パケット（ＮＯＴＩＦＹ）であると判別された場合（ステップＳ１２、Ｙｅｓ）、当該要求パケット（ＮＯＴＩＦＹ）を処理する（ステップＳ１５）、要求パケット（ＮＯＴＩＦＹ）でないと判別された場合（ステップＳ１２、Ｎｏ）、処理を終了する。
また、ネットワーク管理用パケット処理手段７は、ステップＳ１１にて、要求パケット（ＪＯＩＮ）であると判定した場合（ステップＳ１１、Ｙｅｓ）、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリストの更新を行う（ステップＳ１３）。同様に、ネットワーク管理用パケット処理手段７は、検索用ホストリスト記憶手段１９に記憶されている検索用ホストリストの更新を行う（ステップＳ１４）。
（コンテンツ管理サーバにおける動作、ＮＯＴＩＦＹコマンド）
図６に示すフローチャートを参照して、ネットワーク管理用パケット処理手段７がパケット送受信手段３を介して、要求パケット（ＮＯＴＩＦＹ）を受信した場合の処理について説明する（適宜、図１参照）。
まず、ネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の固有データである動作種別（参加（ＪＯＩＮ）又は離脱（Ｌｅａｖｅ））に従って、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリスト及び検索用ホストリスト記憶手段１９に記憶されている検索用ホストリストに対し、参加の場合、指定されたホストリスト（要求パケット（ＮＯＴＩＦＹ）の固有データであるホストＩＤ、位置識別ＩＤ、サーバアドレス）の追加を、離脱の場合、ホストリストの削除を行う（ステップＳ２１、ステップＳ２２）。
図６に示すフローチャートを参照して、ネットワーク管理用パケット処理手段７がパケット送受信手段３を介して、要求パケット（ＮＯＴＩＦＹ）を受信した場合の処理について説明する（適宜、図１参照）。
まず、ネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の固有データである動作種別（参加（ＪＯＩＮ）又は離脱（Ｌｅａｖｅ））に従って、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリスト及び検索用ホストリスト記憶手段１９に記憶されている検索用ホストリストに対し、参加の場合、指定されたホストリスト（要求パケット（ＮＯＴＩＦＹ）の固有データであるホストＩＤ、位置識別ＩＤ、サーバアドレス）の追加を、離脱の場合、ホストリストの削除を行う（ステップＳ２１、ステップＳ２２）。
続いて、ネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の固有データである通知モードが１（ｍｏｄｅ＝１）であるか否かを判定し（ステップＳ２３）、１であると判定した場合（ステップＳ２３、Ｙｅｓ）、すべてのＳｌｉｃｅ Ｌｅａｄｅｒに要求パケット（ＮＯＴＩＦＹ、通知モード２（ｍｏｄｅ＝２））を発行し、パケット送受信手段３を介して送信する（ステップＳ２４）。
そして、ネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の固有データである通知モードが１（ｍｏｄｅ＝１）であると判定しなかった場合（ステップＳ２３、Ｎｏ）、通知モードが２（ｍｏｄｅ＝２）であるか否かを判定し（ステップＳ２５）、２であると判定した場合（ステップＳ２５、Ｙｅｓ）、所属するＵｎｉｔ Ｌｅａｄｅｒに要求パケット（ＮＯＴＩＦＹ、通知モード３（ｍｏｄｅ＝３））を発行し、パケット送受信手段３を介して送信する（ステップＳ２６）。
そしてまた、ネットワーク管理用パケット処理手段７は、要求パケット（ＮＯＴＩＦＹ）の固有データである通知モードが２（ｍｏｄｅ＝２）であると判定しなかった場合（ステップＳ２５、Ｎｏ）、通知モードが３（ｍｏｄｅ＝３）であるか否かを判定し（ステップＳ２７）、３であると判定した場合（ステップＳ２７、Ｙｅｓ）、所属する各コンテンツ管理サーバ１に要求パケット（ＮＯＴＩＦＹ、通知モード４（ｍｏｄｅ＝４））を発行し、パケット送受信手段３を介して送信する（ステップＳ２８）。
（コンテンツ管理サーバにおける動作、コンテンツ登録処理手段）
図７に示すフローチャートを参照して、コンテンツ登録処理手段１３の動作について説明する（適宜、図１参照）。
まず、コンテンツ登録処理手段１３は、コンテンツ登録カウンタを０とし（ステップＳ３１）、コンテンツ蓄積手段２３から読み出したコンテンツが未登録のコンテンツであるか否かを判定し（ステップＳ３２）、未登録のコンテンツでないと判定した場合（ステップＳ３２、Ｎｏ）、動作を終了する。
図７に示すフローチャートを参照して、コンテンツ登録処理手段１３の動作について説明する（適宜、図１参照）。
まず、コンテンツ登録処理手段１３は、コンテンツ登録カウンタを０とし（ステップＳ３１）、コンテンツ蓄積手段２３から読み出したコンテンツが未登録のコンテンツであるか否かを判定し（ステップＳ３２）、未登録のコンテンツでないと判定した場合（ステップＳ３２、Ｎｏ）、動作を終了する。
続いて、コンテンツ登録処理手段１３は、未登録のコンテンツであると判定した場合（ステップＳ３２、Ｙｅｓ）、コンテンツＩＤを生成する（ステップＳ３３）。そして、コンテンツ登録処理手段１３は、パケット送受信手段３を介して、要求パケット（ＰＵＴ）を送信する（ステップＳ３４）（ＰＵＴコマンド送信）。また、コンテンツ登録処理手段１３は、コンテンツ登録カウンタの数に１を加算する（ステップＳ３５）（ｎ＝ｎ＋１）。
そして、コンテンツ登録処理手段１３は、コンテンツ登録カウンタの数ｎが予め設定した数Ｎよりも大きくなった否かを判定し（ステップＳ３６）、コンテンツ登録カウンタの数ｎがＮよりも大きくなっていない場合（ステップＳ３６、Ｎｏ）、ステップＳ３２に戻り、コンテンツ登録カウンタの数ｎがＮよりも大きくなった場合（ステップＳ３６、Ｙｅｓ）、仮想ホストＩＤのＪＯＩＮ処理をホストＩＤ生成手段１５に要求し（ステップＳ３７）、コンテンツ登録カウンタを０とする（ステップＳ３８）。
（コンテンツ管理サーバにおける動作、スタビライゼーション処理手段）
図９に示すフローチャートを参照して、スタビライゼーション処理手段５の動作について説明する（適宜、図１参照）。
まず、スタビライゼーション処理手段５は、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリストから自体（コンテンツ管理サーバ１）に隣接するコンテンツ管理サーバ１のサーバアドレスを取得する（ステップＳ４１）。
図９に示すフローチャートを参照して、スタビライゼーション処理手段５の動作について説明する（適宜、図１参照）。
まず、スタビライゼーション処理手段５は、管理用ホストリスト記憶手段１７に記憶されている管理用ホストリストから自体（コンテンツ管理サーバ１）に隣接するコンテンツ管理サーバ１のサーバアドレスを取得する（ステップＳ４１）。
続いて、スタビライゼーション処理手段５は、パケット送受信手段３を介して、要求パケット（ＰＩＮＧ）（ＰＩＮＧコマンド送信）を隣接するコンテンツ管理サーバ１に送信する（ステップＳ４２）。そして、スタビライゼーション処理手段５は、パケット送受信手段３を介して、応答パケット（ＰＩＮＧ）を受信したか否かを判定し（ステップＳ４３）（応答あり？）、あった場合（ステップＳ４３、Ｙｅｓ）にはステップＳ４１に戻り、無かった場合（ステップＳ４３、Ｎｏ）には、要求パケット（ＮＯＴＩＦＹ）を送信する（ステップＳ４４）（ＮＯＴＩＦＹコマンド送信）。このスタビライゼーション処理手段５の動作において、仮想ホストＩＤが登録されていない管理用ホストリストのみを参照しているので、要求パケット（ＰＩＮＧ）は、物理的に近距離の他のコンテンツ管理サーバ１にだけ送信していることになる。
以上、本発明の実施形態について説明したが、本発明は前記実施形態には限定されない。例えば、本実施形態では、ＯｎｅＨｏｐに対応して説明したが、従来のＰ２Ｐ型のコンテンツ管理システムにも適応することが可能である。また、実際の物理ネットワーク上での距離を考慮する必要が無い場合には、オーバーレイネットワークにおいて、仮想ホストＩＤによるコンテンツ管理の公平性を図ることのみを実現すればよい。
また、この実施形態では、コンテンツ管理サーバ１を１つのサーバとして構成しているが、各手段がそれぞれの装置として、独立させて構成してもよい。
１ コンテンツ管理サーバ
３ パケット送受信手段
５ スタビライゼーション処理手段
７ ネットワーク管理用パケット処理手段
９ 検索用パケット処理手段
１１ ホスト参加処理手段
１３ コンテンツ登録処理手段
１５ ホストＩＤ生成手段
１７ 管理用ホストリスト記憶手段
１９ 検索用ホストリスト記憶手段
２１ コンテンツ管理情報記憶手段
２３ コンテンツ蓄積手段
３ パケット送受信手段
５ スタビライゼーション処理手段
７ ネットワーク管理用パケット処理手段
９ 検索用パケット処理手段
１１ ホスト参加処理手段
１３ コンテンツ登録処理手段
１５ ホストＩＤ生成手段
１７ 管理用ホストリスト記憶手段
１９ 検索用ホストリスト記憶手段
２１ コンテンツ管理情報記憶手段
２３ コンテンツ蓄積手段
Claims (3)
- ホストＩＤによってコンテンツ管理サーバ同士を識別するオーバーレイネットワークであって、
少なくとも１以上の他のコンテンツ管理サーバと協同して、複数のコンテンツを管理するコンテンツ管理サーバにおいて、
各コンテンツ管理サーバのオーバーレイネットワークにおけるサーバアドレスと予め設定したハッシュ関数とに基づいて、前記ホストＩＤを生成するホストＩＤ生成手段と、
前記ホストＩＤ生成手段で生成されたホストＩＤと前記サーバアドレスとを、他のコンテンツ管理サーバに通知することで、前記オーバーレイネットワークに、当該コンテンツ管理サーバの登録を行うホスト参加処理手段と、
前記ホストＩＤ生成手段で生成されたホストＩＤと前記サーバアドレスとを対応付けた検索用ホストリストを記憶する検索用ホストリスト記憶手段と、を備え、
前記ホストＩＤ生成手段は、前記オーバーレイネットワークにおいて当該コンテンツ管理サーバが公開するコンテンツのうちの所定数のコンテンツごとに、前記ホストＩＤとは特定のビットが異なるビット列を有する仮想ホストＩＤを生成し、前記検索用ホストリスト記憶手段は、前記仮想ホストＩＤと前記サーバアドレスとを対応付けた検索用ホストリストをさらに記憶することを特徴とするコンテンツ管理サーバ。 - 前記ホストＩＤ生成手段は、物理ネットワーク上で所定距離内にあるコンテンツ管理サーバ同士に同一のＩＤを割り当てた位置識別ＩＤを、前記ホストＩＤの特定のビットに割り当てることで、物理ネットワーク上におけるコンテンツ管理サーバ間の距離を前記オーバーレイネットワーク上におけるコンテンツ管理サーバ間の距離に反映させ、
前記ホストＩＤ生成手段で生成されたホストＩＤに前記位置識別ＩＤを特定のビットに割り当てたホストＩＤと前記サーバアドレスとを対応付けた管理用ホストリストを記憶する管理用ホストリスト記憶手段と、
前記オーバーレイネットワークにおいて、前記管理用ホストリスト記憶手段に記憶されている管理用ホストリストに存在するホストＩＤのコンテンツ管理サーバ宛に送信したパケットの返信の有無によって、各コンテンツ管理サーバが現在接続されているかどうかの確認を行うスタビライゼーション処理手段と、
を備えることを特徴とする請求項１に記載のコンテンツ管理サーバ。 - ホストＩＤによってコンテンツ管理サーバ同士を識別するオーバーレイネットワークにおいて、少なくとも１以上の他のコンテンツ管理サーバと協同して、複数のコンテンツを管理するために、記憶手段を備えたコンピュータを、
各コンテンツ管理サーバのオーバーレイネットワークにおけるサーバアドレスと予め設定したハッシュ関数とに基づいて、前記ホストＩＤを生成するホストＩＤ生成手段、
前記ホストＩＤ生成手段で生成されたホストＩＤと前記サーバアドレスとを、他のコンテンツ管理サーバに通知することで、前記オーバーレイネットワークに、当該コンテンツ管理サーバの登録を行うホスト参加処理手段、として機能させ、
前記ホストＩＤ生成手段は、前記オーバーレイネットワークにおいて公開するコンテンツのうちの所定数のコンテンツごとに、前記ホストＩＤとは特定のビットが異なるビット列を有する仮想ホストＩＤを生成し、前記記憶手段は、前記ホストＩＤと前記サーバアドレスと対応付けたと共に前記仮想ホストＩＤと前記サーバアドレスとを対応付けた前記検索用ホストリストを記憶することを特徴とするコンテンツ管理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008078345A JP2009230686A (ja) | 2008-03-25 | 2008-03-25 | コンテンツ管理サーバ及びコンテンツ管理プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008078345A JP2009230686A (ja) | 2008-03-25 | 2008-03-25 | コンテンツ管理サーバ及びコンテンツ管理プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2009230686A true JP2009230686A (ja) | 2009-10-08 |
Family
ID=41245949
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008078345A Pending JP2009230686A (ja) | 2008-03-25 | 2008-03-25 | コンテンツ管理サーバ及びコンテンツ管理プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2009230686A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011227712A (ja) * | 2010-04-20 | 2011-11-10 | Nippon Hoso Kyokai <Nhk> | ノード装置及びコンピュータプログラム |
| JP2012014494A (ja) * | 2010-07-01 | 2012-01-19 | Kddi Corp | ピア・ツー・ピア・ネットワークにおける負荷分散方法及び該方法で使用するノード装置 |
| JP2012123544A (ja) * | 2010-12-07 | 2012-06-28 | Nippon Hoso Kyokai <Nhk> | 負荷分散装置及びプログラム |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007272467A (ja) * | 2006-03-30 | 2007-10-18 | Brother Ind Ltd | 配信システム、制御装置及び制御装置用プログラム、管理装置及び管理装置用プログラム、補助装置及び補助装置用プログラム並びに配信システム制御方法 |
-
2008
- 2008-03-25 JP JP2008078345A patent/JP2009230686A/ja active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007272467A (ja) * | 2006-03-30 | 2007-10-18 | Brother Ind Ltd | 配信システム、制御装置及び制御装置用プログラム、管理装置及び管理装置用プログラム、補助装置及び補助装置用プログラム並びに配信システム制御方法 |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011227712A (ja) * | 2010-04-20 | 2011-11-10 | Nippon Hoso Kyokai <Nhk> | ノード装置及びコンピュータプログラム |
| JP2012014494A (ja) * | 2010-07-01 | 2012-01-19 | Kddi Corp | ピア・ツー・ピア・ネットワークにおける負荷分散方法及び該方法で使用するノード装置 |
| JP2012123544A (ja) * | 2010-12-07 | 2012-06-28 | Nippon Hoso Kyokai <Nhk> | 負荷分散装置及びプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4806203B2 (ja) | ピアツーピアネットワークにおけるルーティング | |
| US7782866B1 (en) | Virtual peer in a peer-to-peer network | |
| EP2171607B1 (en) | Load balancing distribution of data to multiple recipients on a peer-to-peer network | |
| US11102290B2 (en) | Peer-to-peer network prioritizing propagation of objects through the network | |
| US8554827B2 (en) | Virtual peer for a content sharing system | |
| JP3944168B2 (ja) | ネットワーク環境におけるピアツーピア通信のための方法およびシステム | |
| KR101211923B1 (ko) | 서비스 제공 엔티티를 선택하기 위한 방법, 시스템, 서비스 선택 엔티티, 및 서비스 관리 엔티티 | |
| US20150215405A1 (en) | Methods of managing and storing distributed files based on information-centric network | |
| US20080270421A1 (en) | Information distribution system, information processing device and memory medium | |
| US20090177772A1 (en) | Method, system and device for establishing a peer to peer connection in a p2p network | |
| WO2010127618A1 (zh) | 一种实现流媒体内容服务的系统和方法 | |
| JP2009534939A (ja) | アクティブなデバイスのリストなど動的データの発見および取出しのためのアドホックプロキシ | |
| JP2007148545A (ja) | 情報配信システム、情報配信方法、ノード装置、及びノード処理プログラム | |
| JP2013514591A (ja) | ピアツーピアネットワークを分解して、分解されたピアツーピアネットワークを使用するための方法および装置 | |
| US8249638B2 (en) | Device and method for participating in a peer-to-peer network | |
| CN111046065B (zh) | 可扩展的高性能分布式查询处理方法及装置 | |
| JP4459999B2 (ja) | 投票を活用した無停止サービスシステム及びそのシステムにおける情報更新及び提供方法 | |
| JP2009230686A (ja) | コンテンツ管理サーバ及びコンテンツ管理プログラム | |
| JP5212292B2 (ja) | 情報通信システム、ノード装置、ノード装置確認方法及びプログラム | |
| US9942311B2 (en) | Method and apparatus for transferring content among large clusters of storage devices to achieve a target replication distribution | |
| JP2009070172A (ja) | コンテンツ分散保存システム、提供元サーバ装置登録方法、ノード装置、及びノード処理プログラム | |
| JP2008005449A (ja) | 分散データの管理方法および管理システム | |
| JP5434268B2 (ja) | 分散保存システム、データファイル分散保存方法及びプログラム | |
| Deltouzos et al. | SeekStream: adapting to dynamic user behavior in P2P video‐on‐demand | |
| JP2012078903A (ja) | ノード装置、ノード装置用プログラムおよび情報処理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100310 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120405 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120424 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120904 |