(57)【要約】      （修正有）【課題】ストレージの少ないノードであってもオーバレイネットワークに参加してコンテンツを共有可能とする。【解決手段】ノードは、コンテンツ「Content Name」そのものを、分散ハッシュテーブル（ＤＨＴ）を用いたオーバレイネットワークに参加していない外部のサーバ等に格納する。ノードＮ１は、コンテンツの格納位置情報を格納する前に、既に同様の情報が格納されていないか、ＬＯＯＫＵＰリクエストをＤＨＴへ送信する。ＤＨＴは、hash(“Content Name”)をｋｅｙとして、当該分散ハッシュテーブルＤＨＴに同様の情報が格納されているか検索する。ＤＨＴは、ｋｅｙが存在しないとき、ノードＮ１へ404 NOT FOUNDのレスポンスを送信する。ノードＮ１は、コンテンツの格納位置情報であるcontentinfoをＤＨＴへ格納するために、ＰＵＴリクエストをＤＨＴへ送信する。【選択図】図３
2009259008.tif 000002
【特許請求の範囲】
【請求項１】
所定コンテンツを所定の格納位置に格納するコンテンツ処理部と、
分散ハッシュテーブルにアクセスし、該分散ハッシュテーブルに、上記コンテンツ処理部で上記所定コンテンツが格納された上記所定の格納位置を示す格納位置情報を格納する分散ハッシュテーブル部と
を備えるノード。
【請求項２】
上記所定の格納位置は、上記分散ハッシュテーブルを用いたオーバレイネットワーク上でない位置である
請求項１に記載のノード。
【請求項３】
上記所定の格納位置は、上記分散ハッシュテーブルを用いたオーバレイネットワーク上の位置である
請求項１に記載のノード。
【請求項４】
上記コンテンツ処理部は、上記所定コンテンツを複数個の断片に分割し、各断片を格納位置に格納し、
上記分散ハッシュテーブル部は、上記所定コンテンツの各断片の格納位置のリストを、上記分散ハッシュテーブルに格納する
請求項１に記載のノード。
【請求項５】
上記コンテンツ処理部は、上記所定コンテンツを構成する複数個の断片のうち、少なくとも、１個の断片を特定の格納位置に格納する
請求項４に記載のノード。
【請求項６】
所定コンテンツを所定の格納位置に格納するコンテンツ格納ステップと、
分散ハッシュテーブルにアクセスし、該分散ハッシュテーブルに、上記コンテンツ格納ステップで上記所定コンテンツが格納された上記所定の格納位置を示す格納位置情報を格納する格納位置情報格納ステップと
を備えるコンテンツ格納方法。
【請求項７】
分散ハッシュテーブルにアクセスして所定コンテンツの格納位置情報を取得する分散ハッシュテーブル部と、
上記分散ハッシュテーブル部で取得された上記格納位置情報に基づいて、上記所定コンテンツを格納位置から取得するコンテンツ処理部と
を備えるノード。
【請求項８】
上記格納位置情報で示される格納位置は、上記分散ハッシュテーブルを用いたオーバレイネットワーク上の位置でない
請求項７に記載のノード。
【請求項９】
上記格納位置情報で示される格納位置は、上記分散ハッシュテーブルを用いたオーバレイネットワーク上の位置である
請求項７に記載のノード。
【請求項１０】
上記分散ハッシュテーブル部で取得される上記格納位置情報は、上記所定コンテンツを分割して得られた各断片の格納位置のリストであり、
上記コンテンツ処理部は、上記分算ハッシュテーブルで取得された上記リストに基づいて上記所定コンテンツの各断片を取得し、該各断片を合成して上記所定コンテンツを生成する
請求項７に記載のノード。
【請求項１１】
上記コンテンツ処理部は、上記所定コンテンツを構成する複数個の断片のうち、少なくとも、１個の断片を特定の格納位置から取得する
請求項１０に記載のノード。
【請求項１２】
分散ハッシュテーブルにアクセスして所定コンテンツの格納位置情報を取得する格納位置情報取得ステップと、
上記格納位置情報取得ステップで取得された上記格納位置情報に基づいて、上記所定コンテンツを格納位置から取得するコンテンツ取得ステップと
を備えるコンテンツ取得方法。
【請求項１３】
所定コンテンツを複数個の断片に分割する分割部と、
上記分割部で分割されて得られた各断片を、該各断片に対応して求められたハッシュ値に基づいて、オーバレイネットワーク上の分散ハッシュテーブルに格納する格納部と
を備えるノード。
【請求項１４】
所定コンテンツを構成する複数個の断片に対応したハッシュ値を求めるハッシュ値算出部と、
上記ハッシュ値算出部で求められた上記所定コンテンツの各断片に対応したハッシュ値に基づいて、オーバレイネットワーク上の分散ハッシュテーブルから上記所定コンテンツの各断片を取得するコンテンツ取得部と、
上記コンテンツ取得部で取得された上記所定コンテンツの各断片を合成して、該所定コンテンツを生成する合成部と
を備えるノード。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ノード、コンテンツ格納方法およびコンテンツ取得方法に関する。詳しくは、この発明は、分散ハッシュテーブルに、コンテンツそのものではなく、このコンテンツの格納位置を示す格納位置情報を格納することにより、ストレージの少ないノードであってもオーバレイネットワークに参加してコンテンツを共有できるようにしたノード等に係るものである。
【背景技術】
【０００２】
通信制御プロトコルとして、例えば、特許文献１等に記載されているＳＩＰ(Session Initiation Protocol)が知られている。ＳＩＰは、ＩＰ(InitiationProtocol)ネットワーク上でマルチメディアセッションを開始／変更／終了するための、アプリケーション層のシグナリングプロトコルである。ＳＩＰは、ＲＦＣ３２６１で標準化されている。ＳＩＰを用いたＩＰ電話やビデオ会議システム等のコミュニケーション端末は、ＳＩＰＵＲＩ(Uniform Resource Identifier)の名前解決を行うために、ＳＩＰプロキシサーバやレジストラサーバ等を導入する必要がある。
【０００３】
しかし、端末数が小中規模のコミュニケーションシステムでは、端末以外にＳＩＰサーバを導入することなく、より簡単にコミュニケーション環境を実現することが望まれている。これを実現するために、オーバレイネットワークを応用することが考えられる。オーバレイネットワークは、ＩＰネットワークなどのネットワーク層における接続性を前提として、その上位に仮想的なネットワークを構成する手法である。オーバレイネットワークの実現には様々な方法があるが、そのひとつにChord等の分散ハッシュテーブルの技術を用いた実現方法がある。
【０００４】
分散ハッシュテーブルは、例えば、特許文献２、特許文献３に記載されているように、端末（ノード）が管理するストレージの集まりをひとつの巨大なハッシュテーブルとしてみせる技術である。ハッシュテーブルに格納したいコンテンツは、コンテンツを識別する名前などからSHA-1などのハッシュ関数を用いて、キー（ハッシュ値）を計算する。そして、そのキーをもとに分散ハッシュテーブルを構成するノードのうち、そのキーのコンテンツを格納することになったノードに格納する。
【０００５】
また、ノードに格納されたコンテンツにアクセスしたい場合には、同様にコンテンツを識別する名前などから計算されたキーをもとに、そのキーに対応するコンテンツを格納しているノードからコンテンツを取得する。なお、実際にどのノードに格納されるかは使用しているアルゴリズムによって異なる。分散ハッシュテーブルを用いたオーバレイネットワークは、この分散ハッシュテーブルを構成するノードの集まりによって構成される。
【０００６】
図１０は、分散ハッシュテーブルを用いたオーバレイネットワーク２００の構成例を示している。オーバレイネットワーク２００において、Ｎ個のノード（端末）２０１-1〜２０１-Nは、ＩＰネットワークに接続されている。この場合、ノード２０１-1〜２０１-Nにより分散ハッシュテーブルが構成されている。
【０００７】
例えば、分散ハッシュテーブルのアルゴリズムのひとつであるChordは、オーバレイネットワークに参加するノードによって単一のリングを構成する。各ノードには、例えば、端末のIPアドレスとポート番号の組にハッシュ関数を適用した値などによるユニークなノードIDが与えられる。Chordでは、図１１に示すように、このノードＩＤの値の小さいものから順番にリングを構成する。
【０００８】
コンテンツを格納する場合には、コンテンツのキーを計算し、このキーの値に近いノードＩＤを持つ端末のストレージに格納する。同様に、コンテンツを取得する場合には、キーに近いノードＩＤを持つ端末のストレージからコンテンツを取得する。Chordでは、このキーに対応するノードを探す処理において、オーバレイネットワークを構成するリング上の順序関係をうまく利用することで効率よく実現している。
【特許文献１】特開２００５−１８４４５０号公報
【特許文献２】特開２００５−２３４７６２号公報
【特許文献３】特開２００６−２４４２２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
分散ハッシュテーブルを用いたオーバレイネットワークでは、オーバレイネットワークに参加しているノードのストレージにコンテンツを格納する。このとき、オーバレイネットワークに参加するノードのストレージなどのリソースをあまり考慮することなく配置される。オーバレイネットワークに参加するノードは、必ずしも同じ性能であるとは限らないため、コンテンツサイズが大きなものがストレージサイズの小さなノードに格納されることもある。
【００１０】
しかしながら、ＨＤ(High Definition)コンテンツなど、数十ギガバイトサイズの大きなコンテンツもある。このようなコンテンツを分散ハッシュテーブルで扱おうとすると、オーバレイネットワークに参加する各ノードにコンテンツを配置する方式ではコンテンツを扱いきれなくなってしまう。
【００１１】
また、純粋な分散ハッシュテーブルにそのままコンテンツを分散する方式では、中央サーバ的な役割を持ったノードが存在しないために、どのようなコンテンツがアクセスされたかなどの管理が困難であり、コンテンツの課金などの処理を実現することが困難である。
【００１２】
この発明の目的は、ストレージの少ないノードであってもオーバレイネットワークに参加してコンテンツを共有可能とすることにある。また、この発明の他の目的は、コンテンツの集中管理を容易に実現することにある。
【課題を解決するための手段】
【００１３】
この発明の概念は、
所定コンテンツを所定の格納位置に格納するコンテンツ処理部と、
分散ハッシュテーブルにアクセスし、該分散ハッシュテーブルに、上記コンテンツ処理部で上記所定コンテンツが格納された上記所定の格納位置を示す格納位置情報を格納する分散ハッシュテーブル部と
を備えるノードにある。
【００１４】
この発明において、コンテンツ処理部により、所定コンテンツは所定の格納位置に格納される。例えば、この所定の格納位置は、分散ハッシュテーブルを用いたオーバレイネットワーク上でない位置、つまり、オーバレイネットワークに参加していないコンテンツサーバ等である。また、例えば、この所定の格納位置は、分散ハッシュテーブルを用いたオーバレイネットワーク上の位置、つまり、オーバレイネットワークに参加している特定のノード等である。また、分散ハッシュテーブル部により、分散ハッシュテーブルにアクセスされ、この分散ハッシュテーブルに、上述したように所定コンテンツが格納された所定の格納位置を示す格納位置情報が格納される。
【００１５】
このようにこの発明においては、分散ハッシュテーブルにコンテンツそのものではなく、このコンテンツの格納位置を示す情報を格納する。そのため、ストレージが少なく大きなコンテンツを格納できないノードであっても、オーバレイネットワークに参加してコンテンツを共有することが可能となる。この場合、サイズの大きなコンテンツ自体は、ストレージの大きなノード、あるいは外部のサーバ等に格納されるからである。
【００１６】
また、この発明において、例えば、コンテンツ処理部は、所定コンテンツを複数個の断片に分割し、各断片を格納位置に格納し、分散ハッシュテーブル部は、所定コンテンツの各断片の格納位置のリストを、分散ハッシュテーブルに格納する、ようにされてもよい。このように、所定コンテンツが複数個の断片に分割されることで、ストレージが少なく、コンテンツの全体を格納できないノードにも、格納することが可能となる。
【００１７】
上述のように、所定コンテンツを複数個の断片に分割し、各断片を格納位置に格納するものにあって、所定コンテンツを構成する複数個の断片のうち、少なくとも、１個の断片を特定の格納位置に格納する、ようにされてもよい。このように所定のコンテンツを構成する断片の一部が特定の格納位置に格納される場合、例えば、この特定の格納位置を管理サーバ（中央サーバ）等とすることで、コンテンツの集中管理を実現できる。
【発明の効果】
【００１８】
この発明によれば、分散ハッシュテーブルに、コンテンツそのものではなく、このコンテンツの格納位置を示す情報を格納するものであり、ストレージの少ないノードであってもオーバレイネットワークに参加してコンテンツを共有可能となる。
【発明を実施するための最良の形態】
【００１９】
以下、この発明の実施の形態について説明する。
【００２０】
「分散ハッシュテーブルＡＰＩの定義」
分散ハッシュテーブルのアルゴリズムには、ChordやKademliaなど様々なものある。この発明は、特定のアルゴリズムに依存していない。ここでは、説明の便宜上、分散ハッシュテーブルのＡＰＩを以下のように定義する。
【００２１】
value：値（コンテンツ）
name：  コンテンツの識別子（コンテンツ名など）
hash(x)：ｘのキーを計算するハッシュ関数
key：ハッシュ関数によって計算されたハッシュ値（キー）
PUT(key,value)：keyに対応するvalueを分散ハッシュテーブルに追加する。
DELETE(key)：keyに対応するvalueを分散ハッシュテーブルから削除する。なお、このとき、削除したvalueを取得できる。
LOOKUP(key)：keyに対応するvalueを分散ハッシュテーブルから取得する。
【００２２】
例えば、名前n1のコンテンツv1を分散ハッシュテーブルへ格納する場合には、以下のように記述する。これによって、コンテンツvlがhash(nl)によって計算されたkeyに対応するノードのストレージへと格納される。
PUT(hash(n1),v1)
【００２３】
また、例えば、分散ハッシュテーブルから名前nlに対応するコンテンツvlを削除する場合には以下のように記述する。
DELETE(hash(n1))
【００２４】
また、例えば、分散ハッシュテーブルから名前nlに対応するコンテンツvlを取得する場合には以下のように記述する。
LOOKUP(hash(n1))
【００２５】
「ノード（端末）の基本構成」
図１は、分散ハッシュテーブルを用いてコンテンツを共有するノード（端末）１００の基本構成を示している。ノード１００は、ノード管理部１０１、分散ハッシュテーブル部１０２、コンテンツ管理部１０３、およびアプリケーション部１０４を有している。
【００２６】
ノード管理部１０１は、オーバレイネットワークに参加している、つまり分散ハッシュテーブルを構成する各ノードの管理を行う部分である。分散ハッシュテーブル部１０２は、分散ハッシュテーブル内にコンテンツを追加したり、削除したり、検索したりする処理を行う部分である。コンテンツ処理部１０３は、分散ハッシュテーブルから取得したコンテンツの位置情報をもとに、実際のコンテンツを取得する処理を行う部分である。
【００２７】
「コンテンツの間接参照」
ＨＤ(HighDefinition)コンテンツなど、数十ギガバイトサイズの大きなコンテンツもあり、このようなコンテンツを分散ハッシュテーブルで扱おうとすると、オーバレイネットワークに参加する各ノードにコンテンツを配置する方式ではコンテンツを扱いきれなくなる。
【００２８】
そのため、この実施の形態において、ノードは、コンテンツそのものを、分散ハッシュテーブルを用いたオーバレイネットワークに参加していない外部のサーバ、あるいは、オーバレイネットワークに参加している、例えば大きなストレージを持ったノードに格納する。そして、分散ハッシュテーブルには、実際にコンテンツが格納された格納位置を示す格納位置情報を格納する（間接参照）。
【００２９】
下記は、ContentNameのコンテンツの格納位置情報を、ＸＭＬで記述した例である。
<?xmlversion=”1.0” encoding=”utf-8”?>
<contentinfoxmlns=”http://xmlns.sony.net/dht/contentinfo”>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<title>ContentName</title>
<author>AAA</author>
<rights>Copyright(c)2007, XXX Corporation</rights>
<published>2007-07-03T09:43:32+09:00</published>
<link href=”http://www.example.com/movie/content_name.mp4”/>
</contentinfo>
【００３０】
この例では、コンテンツ「Content Name」の格納位置は、
「http://www.example.com/movie/content_name.mp4」
であることを示している。ここで、www.example.comは、図２に示すように、例えば、オーバレイネットワークに参加していない、外部のサーバである。なお、図２において、Ｎ１〜Ｎ４は、分散ハッシュテーブルを用いたオーバレイネットワークに参加しているノードを示している。なお、コンテンツに格納する位置は、オーバレイネットワークに参加している特定のノードであってもよい。
【００３１】
図３は、ノードＮ１が、コンテンツの格納位置情報（コンテンツが格納された場所の情報）を、分散ハッシュテーブルに格納する際のシーケンスを示している。なお、図３において、「sip:alice@sony.net」は、ノードＮ１のノードアドレスである。
【００３２】
（ａ）ノードＮ１は、コンテンツ「Content Name」の格納位置情報を格納する前に、既に同様の情報が格納されていないか、LOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。（ｂ）分散ハッシュテーブルＤＨＴは、hash(“Content Name”)をｋｅｙとして、当該分散ハッシュテーブルＤＨＴに同様の情報が格納されているか検索する。分散ハッシュテーブルＤＨＴは、ｋｅｙが存在しないとき、つまりコンテンツ「Content Name」の格納位置情報が格納されていないとき、ノードＮ１へ404 NOT FOUNDのレスポンスを送信する。
【００３３】
（ｃ）ノードＮ１は、コンテンツ「Content Name」の格納位置情報であるcontentinfoを分散ハッシュテーブルＤＨＴへ格納するために、ＰＵＴリクエストを分散ハッシュテーブルＤＨＴへ送信する。（ｄ）分散ハッシュテーブルＤＨＴは、コンテンツ「Content Name」の格納位置情報の格納が完了したとき、２００  ＯＫレスポンスをノードＮ１へ送信する。
【００３４】
なお、上述の（ｂ）において、ｋｅｙが存在したとき、分散ハッシュテーブルＤＨＴは、ノードＮ１に２００  ＯＫのレスポンスを送信する。
【００３５】
上述したように、分散ハッシュテーブルにコンテンツの格納位置情報が格納される場合、分散ハッシュテーブルを用いたオーバレイネットワークに参加している各ノードは、以下のようにしてコンテンツを取得する。まず、分散ハッシュテーブルからコンテンツの格納位置情報を取得する。そして、この格納位置情報に基づいて、格納位置からコンテンツを取得する。
【００３６】
図４は、ノードＮ１がコンテンツ「Content Name」を取得する際のシーケンスを示している。
【００３７】
（ａ）ノードＮ１は、コンテンツ「Content Name」の格納位置情報を得るために、ＬＯＯＫＵＰリクエストを、分散ハッシュテーブルＤＨＴへ送信する。分散ハッシュテーブルＤＨＴはhash(“Content Name”)をｋｅｙとしてＤＨＴを検索する。（ｂ）分散ハッシュテーブルＤＨＴは、ｋｅｙが存在したとき、つまり、コンテンツ「Content Name」の格納位置情報が格納されているとき、ノードＮ１へ、コンテンツ「Content Name」の格納位置情報を持った、２００  ＯＫのレスポンスを送信する。
【００３８】
（ｃ）ノードＮ１は、受信したコンテンツ「Content Name」の格納位置情報（ＸＭＬで記述）により、コンテンツの格納位置が
http://www.example.com/movie/content_name.mp4
であることを知り、HTTPのGETリクエストを、http://www.example.com/へ送信する。（ｄ）これにより、ノードＮ１は、http://www.example.com/より、２００  ＯＫレスポンスと共にcontent_name.mp4を取得する。
【００３９】
以上説明したように、この実施の形態においては、分散ハッシュテーブルにコンテンツそのものではなく、このコンテンツの格納位置を示す格納位置情報を格納する。そのため、ストレージが少なく大きなコンテンツを格納できないノードであっても、オーバレイネットワークに参加してコンテンツを共有することが可能となる。
【００４０】
「コンテンツの分割」
上述の実施の形態において、ノードは、コンテンツを一つのままで、例えば、オーバレイネットワークに参加していない外部のサーバ、あるいは、オーバレイネットワークに参加している特定のノードに格納するものである。しかし、コンテンツを複数個の断片に分割し格納することも考えられる。
【００４１】
図５は、コンテンツの分割、合成（復元）の概略を示している。コンテンツＡは、断片Ａ1〜Ａnに分割される。コンテンツが分割されることによって、それぞれの断片Ａ1〜Ａnのサイズは、元のコンテンツＡよりも小さくなる。
【００４２】
ここで、コンテンツＡの断片Ａ1〜Ａnを、分散ハッシュテーブルへ格納する方法が考えられる。例えば、コンテンツ「Content Name」を１０分割して得られる各断片に対して、ContentName_1_10, Content Name_2_10, ・・・Content Name_10_10のような識別子のルールを設けることで、各断片の識別子からキーを計算して、当該各断片を分散ハッシュテーブルに分散配置できる。
【００４３】
また、コンテンツ「Content Name」のコンテンツを取得する場合には、ContentName_1_10からContent Name_10_10のキーを計算し、各断片をＬＯＯＫＵＰリクエストによって取得して合成すればよい。ただし、この方法には、コンテンツが何個に分割されているかを予め知らなければいけない問題点があるが、コンテンツが何個に分割されているかが予め分かるコンテンツには適用することができる。
【００４４】
また、上述実施の形態と同様に、分散ハッシュテーブルに各断片の格納位置情報を格納するコンテンツの間接参照を導入した場合には、コンテンツが何個に分割されているかを予め知らなくてもよい。
【００４５】
コンテンツを分割して得られた各断片は、図６に示すように、例えば、オーバレイネットワークに参加していない、外部のサーバに格納される。図６において、Ｎ１〜Ｎ４は、分散ハッシュテーブルを用いたオーバレイネットワークに参加しているノードを示している。なお、コンテンツを分割して得られた各断片の一部または全部はオーバレイネットワークに参加しているノードに格納されてもよい。
【００４６】
下記は、コンテンツ「Content Name」が５個の断片に分割されて格納された場合における、コンテンツ「ContentName」の格納位置情報、つまり、各断片の格納位置のリストを、ＸＭＬで記述した例である。
<?xmlversion=”1.0” encoding=”utf-8”?>
<contentinfoxmlns=”http://xmlns.sony.net/dht/contentinfo”>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
<title>ContentName</title>
<author>AAA</author>
<rights>Copyright(c)2007, XXX Corporation</rights>
<published>2007-07-03T09:43:32+09:00</published>
<link href=”http://www.example.com/movie/content_name.mp4”/>
<piece>
<id>・・・</id>
<title>ContentName_1_5</title>
<link href=”http://www2.example.com/movie/content_name/pieces/01.mp4”/>
</piece>
<piece>
<id>・・・</id>
<title>ContentName_2_5</title>
<link href=”http://www1.example.com/movie/content_name/pieces/02.mp4”/>
</piece>
<piece>
<id>・・・</id>
<title>ContentName_3_5</title>
<link/>
</piece>
<piece>
<id>・・・</id>
<title>ContentName_4_5</title>
<link href=”http://www6.example.com/movie/content_name/pieces/04.mp4”/>
</piece>
<piece>
<id>・・・</id>
<title>ContentName_5_5</title>
<linkhref=”http://www3.example.com/movie/content_name/pieces/05.mp4”/>
</piece>
</contentinfo>
【００４７】
このＸＭＬにおいて、各pieceタグの内部にコンテンツのそれぞれの断片が格納されている格納位置情報が入っている。ここで、Content Name_3_5には格納位置情報が入っているlinkタグに値が入っていないが、このような場合には、titleタグの値からハッシュの値を計算し、再度、分散ハッシュテーブルからコンテンツ（断片）を取得する。
【００４８】
例えば、ノードＮ１が、コンテンツの各断片の格納位置のリストを、分散ハッシュテーブルに格納する際のシーケンスは、詳細説明は省略するが、上述のコンテンツの格納位置情報を格納する際のシーケンスと同様である（図３参照）。
【００４９】
また、例えば、ノードＮ１がコンテンツ「Content Name」を取得する際のシーケンスは、以下の通りである。
【００５０】
（ａ）ノードＮ１は、コンテンツ「Content Name」の格納位置情報（各断片の格納位置のリスト）を得るために、ＬＯＯＫＵＰリクエストを、分散ハッシュテーブルＤＨＴへ送信する。分散ハッシュテーブルＤＨＴはhash(“Content Name”)をｋｅｙとしてＤＨＴを検索する。（ｂ）分散ハッシュテーブルＤＨＴは、ｋｅｙが存在したとき、つまり、コンテンツ「Content Name」の格納位置情報が格納されているとき、ノードＮ１へ、当該リストを持った、２００  ＯＫのレスポンスを送信する。
【００５１】
（ｃ）ノードＮ１は、受信した格納位置情報（ＸＭＬで記述）により、コンテンツ「Content Name」が複数個の断片に分割されていることを知り、各断片をその格納位置から取得し、合成してコンテンツ「Content Name」を得る。
【００５２】
図７は、コンテンツ「Content Name」が複数個の断片に分割されて格納されている場合において、ノードＮ１（図１参照）が各断片を取得する際の処理手順を示している。
【００５３】
ノードＮ１は、ステップＳＴ１において、取得処理を開始し、その後に、ステップＳＴ２の処理に移る。このステップＳＴ２において、ノードＮ１は、分散ハッシュテーブル部１０２により、コンテンツ「Content Name」の格納位置情報であるcontentinfoを分散ハッシュテーブルＤＨＴから取得する。
【００５４】
次に、ノードＮ１は、ステップＳＴ３において、格納位置情報contentinfoに、pieceタグがあるか否かを判断する。そして、ノードＮ１は、ステップＳＴ４において、pieceタグ内のlinkタグに値があるか否かを判断する。
【００５５】
linkタグに値があるとき、ノードＮ１は、ステップＳＴ５において、コンテンツ処理部１０３により、linkタグの値（断片の格納位置）に従ってコンテンツの断片を取得する。その後、ノードＮ１は、ステップＳＴ７において、次のpieceタグの処理に移って、ステップＳＴ３の処理に戻る。
【００５６】
一方、linkタグの値がないとき、ノードＮ１は、ステップＳＴ６において、titleタグの名前からハッシュ値を計算し、分散ハッシュテーブルから、コンテンツの断片を、その格納位置から取得する。その後、ノードＮ１は、ステップＳＴ７において、次のpieceタグの処理に移って、ステップＳＴ３の処理に戻る。
【００５７】
ノードＮ１は、以上のステップＳＴ４〜ステップＳＴ７の動作を、格納位置情報contentinfo に含まれるpieceタグの数だけ繰り返す。すなわち、ノードＮ１は、ステップＳＴ３において、次のpieceタグがないとき、ステップＳＴ８の処理に移って、取得処理を終了する。
【００５８】
「コンテンツの断片の一部を必ず特定サーバから取得する」
上述したように、分散ハッシュテーブルに格納されているコンテンツの格納位置情報（各断片の格納位置のリスト）に基づいて、コンテンツの各断片を取得する、間接分割参照の場合には、図８に示すように、コンテンツの一部の断片を、必ず特定の格納位置、例えば特定サのーバ（中央サーバ）から取得するように構成できる。
【００５９】
図８の例では、コンテンツ「Content Name 1」は、４個の断片に分割されて格納されるが、一つの断片は中央サーバ（http:/www.example.com/）に格納されている。また、図８の例では、コンテンツ「Content Name 2」は、４個の断片に分割されて格納されるが、一つの断片は中央サーバ（http:/www.example.com/）に格納されている。
【００６０】
コンテンツの一部の断片を特定の格納位置に格納しておくものにあっては、コンテンツを取得する際に完全なコンテンツを構成するためには、必ず特定の格納位置へのアクセスが必要となる。そのため、純粋な分散ハッシュテーブルだけでは実現が困難であったコンテンツアクセスの管理が可能となる。例えば、特定のサーバ（中央サーバ）からコンテンツの断片を取得する際に課金をするようにすれば、コンテンツの課金などの処理も可能となる。
【００６１】
「コンテンツの分割の変形例」
上述したようにコンテンツを複数個の断片に分割して格納するものにあっては、各断片を定期的にexpireして、コンテンツのｋｅｙや断片の切り方を定期的に変更してもよい。図９は、Chordによる有効期限チェックリストの例を示している。上述したように、Chordでは、ノードＩＤの値の小さいものから順番にリングを構成している。
【００６２】
また、上述では、コンテンツを複数個の断片に分割して格納するものにあっては、各断片を全て取得することで、元のコンテンツを復元できる。しかし、コンテンツを複数個の断片に分割する際に、例えば、一部が重複するように断片化しておくことで、各断片を全て取得しなくても元のコンテンツを復元可能とすることも考えられる。
【産業上の利用可能性】
【００６３】
この発明は、分散ハッシュテーブルを用いたオーバレイネットワークを構成するノードに適用できる。
【図面の簡単な説明】
【００６４】
【図１】分散ハッシュテーブルを用いてコンテンツを共有するノード（端末）の基本構成を示すブロック図である。
【図２】コンテンツをオーバレイネットワークに参加していない外部のサーバに格納し、分散ハッシュテーブルにはその外部サーバを示す格納位置情報を格納する例を示す図である。
【図３】ノードＮ１がコンテンツの格納位置情報を分散ハッシュテーブルＤＨＴに格納する際のシーケンスを示す図である。
【図４】ノードＮ１がコンテンツ「Content Name」を取得する際のシーケンスを示す図である。
【図５】コンテンツＡの分割、合成（復元）の概略を示す図である。
【図６】コンテンツを構成する各断片をオーバレイネットワークに参加していない外部のサーバに格納し、分散ハッシュテーブルにはその外部サーバを示す格納位置情報を格納する例を示す図である。
【図７】コンテンツ「Content Name」が複数個の断片に分割されて格納されている場合において、ノードが各断片を取得する際の処理手順を示すフローチャートである。
【図８】コンテンツの一部の断片を必ず特定サのーバ（中央サーバ）から取得する構成を示す図である。
【図９】Chordによる有効期限チェックリストの例を示す図である。
【図１０】分散ハッシュテーブルを用いたオーバレイネットワークの構成例を示す図である。
【図１１】分散ハッシュテーブルのアルゴリズムのひとつであるChordは、オーバレイネットワークに参加するノードによって単一のリングを構成する、ことを示す図である。
【符号の説明】
【００６５】
１００・・・ノード、１０１・・・ノード管理部、１０２・・・分散ハッシュテーブル部、１０３・・・コンテンツ処理部、１０４・・・アプリケーション部
【図１】
2009259008.tif 000003
【図２】
2009259008.tif 000004
【図３】
2009259008.tif 000005
【図４】
2009259008.tif 000006
【図５】
2009259008.tif 000007
【図６】
2009259008.tif 000008
【図７】
2009259008.tif 000009
【図８】
2009259008.tif 000010
【図９】
2009259008.tif 000011
【図１０】
2009259008.tif 000012
【図１１】
2009259008.tif 000013