JP2012078902A - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】ＤＮＳをＣＤＮに適用したシステムにおいて、コンテンツの配信負荷を分散させる。
【解決手段】問い合わせ元の問い合わせ装置から取得された名前を示す名前情報を取得する取得手段と、取得手段により取得された名前情報が取得先の名前を示すコンテンツを、オーバーレイネットワークにより検索する検索手段と、検索手段による検索結果として、コンテンツを保存するノード装置の所在を示す所在情報を含む結果情報を、問い合わせ装置に送信する送信手段と、結果情報を記憶する記憶手段と、取得手段により名前情報が取得されたときに当該名前情報が示す名前に対応するコンテンツの結果情報が、記憶手段により記憶されているか否かを判定する判定手段と、を備え、送信手段は、判定手段により記憶されていると判定されたとき、結果情報を問い合わせ装置に送信し、検索手段は、判定手段により記憶されていないと判定されたとき、検索を行う。
【選択図】図２

Description

本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））方式の通信システムの技術分野に関する。

近年、端末装置に対して配信されるコンテンツを複数のサーバ装置に分散保存させ、コンテンツの配信負荷を複数のサーバ装置に分散させるコンテンツ分散保存システムが知られている。例えば、特許文献１には、分散キャッシュシステムに関する技術が記載されている。この分散キャッシュシステムにおいて、キャッシュサーバＡは、クライアント端末から要求されたコンテンツを保存していない場合、オリジンサーバに向けてコンテンツの要求を送信する。キャッシュ制御サーバは、キャッシュサーバＡからオリジンサーバへのコンテンツの要求を受信すると、要求されたコンテンツを保存しているキャッシュサーバＢからキャッシュサーバＡへコンテンツを転送させる制御を行う。

特開２００７−６６１６１号公報

ここで、ＤＮＳ（Domain Name System）をＣＤＮ（Contents Delivery Network）に適用する場合を想定する。この場合、ＤＮＳサーバは、クライアントとなる装置からドメイン名の解決の要求を受けると、受信したドメイン名に対応して、例えば、コンテンツを保存するサーバ装置のＩＰ（Internet Protocol）アドレスを返信する。

しかしながら、ドメイン名に対応するコンテンツを保存するサーバ装置の数が少ない場合、特定のドメインに対するコンテンツの要求が多いと、特定のサーバ装置に付加が集中する。そのため、コンテンツの配信負荷を分散させるというＣＤＮの利点を十分に生かすことができない。

そこで、本発明は、以上の点に鑑みてなされたものである。本発明は、ＤＮＳをＣＤＮに適用したシステムにおいて、コンテンツの配信負荷を分散させることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置であって、問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得手段と、前記取得手段により取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索手段と、前記検索手段による検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信手段と、前記検索手段により検索された前記所在情報を、前記ドメイン情報と対応付けて記憶する記憶手段と、前記取得手段により前記ドメイン情報が取得されたときに、前記取得手段により取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定手段と、を備え、前記送信手段は、前記判定手段により記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、前記検索手段は、前記判定手段により記憶されていないと判定されたとき、検索を行うことを特徴とする。

この発明によれば、情報処理装置が、問い合わせ装置から取得したドメイン情報が示すドメイン名に対応するコンテンツを、オーバーレイネットワークにより検索する。そして、情報処理装置が、検索結果として、ドメイン情報が示すドメイン名に対応するコンテンツを保存するノード装置の所在を示す所在情報を問い合わせ装置に送信する。そのため、コンテンツを取得する装置は、所在情報が所在を示すノード装置からコンテンツを取得する。従って、コンテンツが分散保存される複数のノード装置からコンテンツが取得されるので、コンテンツの配信負荷を分散させることができる。

請求項２に記載の発明は、前記ドメイン情報が示すドメイン名に対応するコンテンツを前記オーバーレイネットワークから検索する検索キーを示すキー情報であって、前記取得手段により取得された前記ドメイン情報に基づいて、前記検索キーを生成する生成手段を更に備え、前記生成手段により生成された前記キー情報に基づいて、前記検索手段は、前記キー情報に対応するコンテンツを前記オーバーレイネットワークから検索することを特徴とする。

この発明によれば、問い合わせ装置から取得されたドメイン情報から、コンテンツを検索することができる。

請求項３に記載の発明は、前記記憶手段に前記所在情報が記憶されてから所定の時間が経過したかを判定する第２判定手段を更に備え、前記送信手段は、前記第２判定手段により前記所定の時間が経過したと判定された前記所在情報を送信しないことを特徴とする。

この発明によれば、情報処理装置は、ドメイン情報を問い合わせ装置から取得すると、取得したドメイン情報に対応する所在情報のうち、記憶されてから所定の期間が経過した所在情報とは異なる所在情報を問い合わせ装置に送信する。そのため、新しい所在情報を問い合わせ装置に送信することができる。

請求項４に記載の発明は、前記取得手段により前記ドメイン情報が取得された回数を示す回数情報を、前記ドメイン情報と対応付けて記憶する第２記憶手段と、前記第２記憶手段により記憶された前記回数情報が示す回数が、予め定められた所定値を超えたかを判定する第３判定手段と、前記第３判定手段により、前記第２記憶手段により記憶された前記回数情報が示す回数が前記所定値を超えたと判定された場合には、前記回数情報に対応する前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記複数のノード装置の何れかの前記ノード装置に保存させる指示を示す指示情報を、何れかの前記ノード装置に送信する第２送信手段と、を更に備えることを特徴とする。

この発明によれば、問い合わせの回数が所定値を超えたドメイン名に対応するコンテンツを保存するノード装置が増加する。そのため、コンテンツの要求に対する負荷を分散することができる。

請求項５に記載の発明は、コンテンツを保存する前記ノード装置の数を示す数情報を前記ドメイン情報ごとに取得する第２取得手段と、前記所定値を決定する決定手段であって、前記第２取得手段により取得された前記数情報が示す数が多い前記ドメイン情報であるほど、大きい前記所定値を決定する決定手段と、を更に備え、前記第３判定手段は、前記第２記憶手段により記憶された前記回数情報が示す回数が、前記決定手段により決定された前記所定値を超えたかを判定することを特徴とする。

この発明によれば、コンテンツを保存するノード装置を増加させる条件としての所定値が、ドメイン名に対応するコンテンツを現在保存しているノード装置の数が多いほど大きい値となる。そのため、コンテンツの要求に対する負荷分散を適切に行うことができる。

請求項６に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置による情報処理方法であって、問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得ステップと、前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、を含み、前記送信ステップにおいては、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、前記検索ステップにおいては、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うことを特徴とする。

請求項７に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置に含まれるコンピュータに、問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得ステップと、前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、を実行させ、前記送信ステップを、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信するように実行させ、前記検索ステップを、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うように実行させることを特徴とする。

本発明によれば、情報処理装置が、問い合わせ装置から取得したドメイン情報が示すドメイン名に対応するコンテンツを、オーバーレイネットワークにより検索する。そして、情報処理装置が、検索結果として、ドメイン情報が示すドメイン名に対応するコンテンツを問い合わせ装置に送信する。そのため、コンテンツを取得する装置は、所在情報が所在を示すノード装置からコンテンツを取得する。従って、コンテンツが分散保存される複数のノード装置からコンテンツが取得されるので、コンテンツの配信負荷を分散させることができる。

一実施形態に係るコンテンツ配信システムＳの概要構成例を示す図である。 一実施形態に係るコンテンツ配信システムＳにおける動作概要の一例を示す図である。 一実施形態に係るコンテンツ配信システムＳにおける動作概要の一例を示す図である。 ルータＲｍの概要構成例を示す図である。 Ｐ２Ｐ用ＤＮＳサーバＳＰの概要構成例を示す図である。 一実施形態におけるルータＲｍの制御部１１の処理例を示すフローチャートである。 一実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１の処理例を示すフローチャートである。 （ａ）は、一実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１のコンテンツキャッシュ追加指示処理における処理例を示すフローチャートであり、（ｂ）は、一実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１のコンテンツ保持ノード検索処理における処理例を示すフローチャートである。

以下、本発明の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ配信システムに本発明を適用した場合の実施形態である。

［１．コンテンツ配信システムの概要構成］
始めに、図１を参照して、本実施形態に係るコンテンツ配信システムの概要構成について説明する。図１は、本実施形態に係るコンテンツ配信システムＳの概要構成例を示す図である。コンテンツ配信システムＳは、ＤＮＳを適用したＣＤＮである。図１に示すように、コンテンツ配信システムＳは、ネットワークＮＷに、配信センターネットワークＮＳと複数の拠点ネットワークＮＬｍ（ｍ＝１，２，３・・・の何れか）とが接続されている。このネットワークＮＷ、配信センターネットワークＮＳ、及び各拠点ネットワークＮＬｍは、現実世界の通信ネットワークである。

ネットワークＮＷは、配信センターネットワークＮＳ及び各拠点ネットワークＮＬｍを相互接続するためのネットワークである。このネットワークＮＷは、例えば、ＷＡＮ（Wide Area Network）等である。そして、ネットワークＮＷは、例えば、ＩＸ（Internet eＸchange）、ＩＳＰ（Internet Service Provider）、ＤＳＬ（Digital Subscriber Line）回線事業者の装置、ＦＴＴＨ（Fiber To The Home）回線事業者の装置、及び通信回線等によって構築されている。なお、ネットワークＮＷは、コンテンツ配信システムＳ専用のネットワークであっても良い。

配信センターネットワークＮＳは、例えば、配信センターの敷地内に構築されたネットワークである。この配信センターネットワークＮＳは、例えば、ＬＡＮ（Local Area Network）等により構築されている。配信センターネットワークＮＳには、センターサーバＳＳが接続されている。センターサーバＳＳは、コンテンツをＰ２ＰネットワークＰＷに投入する。コンテンツの投入とは、コンテンツを何れかのルータＲｍに保存させ、保存されたコンテンツを、各ルータＲｍが取得可能にすることである。

各拠点ネットワークＮＬｍは、それぞれ拠点ｍの敷地内に構築されたネットワークである。拠点ｍは、例えば、企業、学校、病院、カラオケボックス、公共団体等の組織が活動とする拠点である。この拠点ネットワークＮＬｍは、例えば、ＬＡＮ等により構築されている。各拠点ネットワークＮＬｍには、複数のユーザ端末Ｔｍ−ｎ（ｎ＝１，２，３・・・の何れか）が接続されている。ユーザ端末Ｔｍ−ｎは、例えば、パーソナルコンピュータ等である。図１においては、一部の拠点ネットワークＮＬｍの図示、及び、その拠点ネットワークＮＬｍに接続されているユーザ端末Ｔｍ−ｎの図示を省略している。

ネットワークＮＷには、また、ＷｅｂサーバＳＷ、組織用ＤＮＳサーバＳＯ及びＰ２Ｐ用ＤＮＳサーバＳＰが接続されている。ＷｅｂサーバＳＷは、例えば、上述した拠点ｍを有する組織が運営するＷｅｂサイトの各種のコンテンツを、ユーザ端末Ｔｍ−ｎに配信するためのサーバ装置である。図１においては、ＷｅｂサーバＳＷは１台のみ示されているが、ＷｅｂサーバＳＷは、例えば、組織ごとに設置されている。そして、各ＷｅｂサーバＳＷには、それぞれ個別にドメイン名が付与されている。

組織用ＤＮＳサーバＳＯは、ドメイン名を解決するＤＮＳサーバである。組織用ＤＮＳサーバＳＯは、ユーザ端末Ｔｍ−ｎからＩＰアドレスの問い合わせを受け付ける。図１においては、組織用ＤＮＳサーバＳＯは１台のみ示されているが、組織用ＤＮＳサーバＳＯは、例えば、組織ごとに設置されても良い。なお、組織用ＤＮＳサーバＳＯは、本発明における問い合わせ装置の一例である。

Ｐ２Ｐ用ＤＮＳサーバＳＰも、ドメイン名を解決するＤＮＳサーバである。Ｐ２Ｐ用ＤＮＳサーバＳＰは、組織用ＤＮＳサーバＳＯからＩＰアドレスの問い合わせを受け付ける。また、Ｐ２Ｐ用ＤＮＳサーバＳＰには、固有のドメイン名が割り当てられている。なお、Ｐ２Ｐ用ＤＮＳサーバＳＰは、本発明における情報処理装置の一例である。

配信センターネットワークＮＳ及び拠点ネットワークＮＬｍには、それぞれルータＲｍが定常的に接続されている。このルータＲｍは、配信センターネットワークＮＳまたは拠点ネットワークＮＬｍと、ネットワークＮＷとを相互接続する。ルータＲｍは、例えば、ルータ機能を有するファイアーウォール、ブロードバンドルータ等である。なお、ルータＲｍは、本発明におけるノード装置の一例である。

コンテンツ配信システムＳにおいては、コンテンツを配信するためのピアツーピアネットワークであるＰ２ＰネットワークＰＷが構築されている。図１に示すように、Ｐ２ＰネットワークＰＷは、ネットワークＮＷ上に構築された論理的なオーバーレイネットワークである。このＰ２ＰネットワークＰＷは、コンテンツ配信システムＳを構成する複数のルータＲｍとＰ２Ｐ用ＤＮＳサーバＳＰとの参加により形成されるネットワークである。以下の説明においては、Ｐ２ＰネットワークＰＷに接続するルータＲｍ及びＰ２Ｐ用ＤＮＳサーバＳＰを、「ノード」と称する。なお、Ｐ２ＰネットワークＰＷへの参加とは、後述するＤＨＴ（Distributed Hash Table）ルーティングテーブルに基づいて他のノードとの間で各種メッセージを送受信できる状態にすることをいう。

Ｐ２ＰネットワークＰＷは、特定のアルゴリズム、例えば、ＤＨＴを利用したアルゴリズムにより実現される。そして、Ｐ２ＰネットワークＰＷに接続する各ノードには、所定桁数からなる固有の識別情報であるノードＩＤが割り当てられている。図１に示すＰ２ＰネットワークＰＷは、ノードＩＤのＩＤ空間をリング状のものとして示されている。そして、図１のリング状のＩＤ空間において示されている各ノードの位置は、それぞれのノードＩＤに対応している。

各ノードは、それぞれ、ＤＨＴを用いたルーティングテーブルを保持している。このルーティングテーブルを、「ＤＨＴルーティングテーブル」という。ＤＨＴルーティングテーブルは、Ｐ２ＰネットワークＰＷ上における各種メッセージの転送先を規定している。具体的に、ＤＨＴルーティングテーブルには、ＩＤ空間内で適度に離れたノードのノードＩＤ、ＩＰアドレス及びポート番号を含むノード情報が複数登録されている。なお、ＤＨＴルーティングテーブルを用いたＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

Ｐ２ＰネットワークＰＷにおいては、内容の異なる様々なコンテンツが複数のノードに分散して保存される。以下、コンテンツを保存するノードを、「コンテンツ保持ノード」という。各コンテンツには、それぞれコンテンツごとに固有の識別情報であるコンテンツＩＤが割り当てられている。なお、Ｐ２Ｐ用ＤＮＳサーバＳＰは、コンテンツを保存しなくても良い。

コンテンツには、Ｐ２ＰネットワークＰＷを介してコンテンツ配信システムＳで主として配信される主コンテンツと、主コンテンツとは異なる副コンテンツと、がある。ここで、Ｐ２ＰネットワークＰＷを介して配信されるコンテンツとは、Ｐ２ＰネットワークＰＷに参加しているノード間で送受信されるコンテンツを意味する。例えば拠点Ｐｎがカラオケ店舗である場合、主コンテンツとしては、カラオケデータが挙げられる。一方、副コンテンツとしては、例えば、ＷｅｂサーバＳＷから配信されるコンテンツと同一のコンテンツが挙げられる。例えば、ＷｅｂサーバＳＷの管理者が、ＷｅｂサーバＳＷに配信対象のコンテンツを登録するとともに、Ｐ２ＰネットワークＰＷの管理者に、コンテンツの投入を依頼する。Ｐ２ＰネットワークＰＷの管理者は、センターサーバＳＳを操作することにより、依頼されたコンテンツをセンターサーバＳＳからＰ２ＰネットワークＰＷに投入させる。ユーザ端末Ｔｍ−ｎは、標準で利用するＤＮＳサーバを組織用ＤＮＳサーバＳＯとすることにより、ＷｅｂサーバＳＷからではなく、Ｐ２ＰネットワークＰＷからコンテンツを取得する。主コンテンツとして、カラオケデータが配信されている場合、本実施形態のコンテンツが副コンテンツとして扱われても良い。

また、副コンテンツとして、複数のコンテンツから構成される複合コンテンツが投入される場合がある。複合コンテンツとしては、例えば、ＷｅｂページやＲＩＡ（Rich Internet Application）等がある。複合コンテンツを構成するコンテンツを、「通常コンテンツ」という。例えば、Ｗｅｂページは、ＨＴＭＬ（HyperText Markup Language）文書、画像データ、動画データ、音声データ、テキストデータ等の通常コンテンツから構成される。通常コンテンツのコンテンツＩＤは、例えば、その通常コンテンツのＵＲＬ（Uniform Resource Locator）を共通のハッシュ関数によりハッシュ化することにより生成される。複合コンテンツを構成する各ファイルのコンテンツＩＤは、例えば、複合コンテンツのメタファイルに記述されている。複合コンテンツのメタファイルとは、複合コンテンツを構成する各通常コンテンツをＰ２Ｐネットワークにより検索し取得するためのファイルである。また、複合コンテンツのメタファイルには、この複合コンテンツのコンテンツＩＤが付与される。コンテンツＩＤが付与された複合コンテンツのメタファイルは、１つのコンテンツとしてＰ２ＰネットワークＰＷに投入される。

各複合コンテンツや通常コンテンツは、その通常コンテンツの本来の配信元であるＷｅｂサーバＳＷのドメインと対応付けられている。ユーザ端末Ｔｍ−ｎは、コンテンツの本来の取得先であるＷｅｂサーバＳＷのドメイン名に基づいて、Ｐ２ＰネットワークＰＷからコンテンツを取得するルータＲｍのＩＰアドレスを取得する。ＷｅｂサーバＳＷから配信されるコンテンツと同一のコンテンツのうち、どのコンテンツが実際にユーザ端末Ｔｍ−ｎから要求されるかは、ルータＲｍ側からは分からない。そこで、各ルータＲｍは、どのコンテンツの要求にも対応することができるように、通常コンテンツを、ドメイン単位で保存する。

ドメイン単位のコンテンツの保存のため、各ＷｅｂサーバＳＷのドメインには、それぞれドメインＩＤが割り当てられている。ドメインＩＤは、例えば、コンテンツＩＤを生成するときと同じハッシュ関数によりドメイン名をハッシュ化することにより生成される。ドメインＩＤに対応するドメインのＷｅｂサーバＳＷから配信される全てのコンテンツを１つのコンテンツとみなしたとき、ドメインＩＤは、その１つのコンテンツのコンテンツＩＤとみなすことができる。各ノードは、ドメインＩＤをコンテンツＩＤとして用いることにより、そのドメインＩＤに対応するドメインのＷｅｂサーバＳＷから配信されるコンテンツと同一のコンテンツを保存するコンテンツ保持ノードを検索することができる。なお、あるドメインのＷｅｂサーバＳＷから配信されるコンテンツと同一のコンテンツを、その「ドメインに対応するコンテンツ」という。ドメインＩＤは、本発明におけるキー情報の一例である。

複数のノードに分散保存されているコンテンツの所在は、インデックス情報として、コンテンツの所在を管理（記憶）しているノードにより記憶される。コンテンツの所在を管理しているノードを、「ルートノード」という。インデックス情報は、コンテンツを保存したノードのノード情報と、コンテンツのコンテンツＩＤと等の組を含む。このようなルートノードは、例えば、コンテンツＩＤと最も近いノードＩＤを有するノードであるように定められる。コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。なお、インデックス情報は、本発明における結果情報の一例である。また、インデックス情報に含まれるルータＲｍのＩＰアドレスは、本発明における所在情報の一例である。

そして、あるノードが、あるコンテンツを取得しようとする場合、そのノードは、検索メッセージを送信する。以下、コンテンツを取得しようとするノードを、「ユーザノード」という。検索メッセージは、取得対象のコンテンツのコンテンツＩＤ及びユーザノードのＩＰアドレス等を含む。検索メッセージは、コンテンツ保持ノードを検索するためのメッセージである。ユーザノードは、ユーザノードが記憶するＤＨＴルーティングテーブルに従って、他のノードに送信する。これにより、検索メッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによって最終的にルートノードに到着することになる。

検索メッセージを受信したルートノードは、これに含まれるコンテンツＩＤに対応するインデックス情報を、ユーザノードに送信する。ユーザノードは、受信したインデックス情報に含まれるＩＰアドレス及びポート番号に基づいて、何れかのコンテンツ保持ノードに、コンテンツＩＤを含むコンテンツ要求メッセージを送信する。コンテンツ保持ノードは、受信したコンテンツ要求メッセージに含まれるコンテンツＩＤに対応するコンテンツを、ユーザノードにアップロード（送信）する。こうして、ユーザノードは、コンテンツをダウンロード（取得）することができる。

ユーザノードは、コンテンツ保持ノードからコンテンツを取得して保存したとき、パブリッシュメッセージを送信する。パブリッシュメッセージは、コンテンツを保存したことをルートノードへ知らせるためのメッセージである。パブリッシュメッセージは、コンテンツのコンテンツＩＤ及びコンテンツを保存したノード装置のノード情報を含む。パブリッシュメッセージは、検索メッセージと同じように、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになる。ルートノードは、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報をインデックスキャッシュ領域に記憶する。こうして、上記ユーザノードは、新たに、上記コンテンツを保持するコンテンツ保持ノードとなる。

［２．ユーザ端末へのコンテンツの配信］
次に、図２を参照して、コンテンツ配信システムＳにおけるユーザ端末Ｔｍ−ｎへのコンテンツの配信について説明する。図２は、本実施形態に係るコンテンツ配信システムＳにおける動作概要の一例を示す図である。コンテンツ配信システムＳにおいては、Ｐ２ＰネットワークＰＷを用いることにより、ユーザ端末Ｔｍ−ｎに対するコンテンツの配信負荷を分散させる。

ユーザ端末Ｔｍ−ｎは、ユーザによる操作等に基づいて、ダウンロードしようとするコンテンツのＵＲＬを取得する。ＵＲＬを取得したユーザ端末Ｔｍ−ｎは、先ず、ＩＰアドレスの問い合わせを行う。例えば、図２に示すように、ユーザ端末Ｔ１−１が、ＵＲＬから、ＷｅｂサーバＳＷのドメイン名を取得したとする。ユーザ端末Ｔ１−１は、取得したドメイン名を含む名前解決リクエストを、組織用ＤＮＳサーバＳＯに送信する（図２（１））。なお、名前解決リクエストに含まれるドメイン名を、「要求ドメイン名」という。要求ドメイン名は、本発明におけるドメイン情報の一例である。

組織用ＤＮＳサーバＳＯは、ドメイン名とＩＰアドレスとが対応付けて登録されているデータベースを保持している。通常、組織用ＤＮＳサーバＳＯは、受信した名前解決リクエストに含まれる要求ドメイン名に対応するＩＰアドレスを、ユーザ端末Ｔｍ−ｎに送信する。しかしながら、組織用ＤＮＳサーバＳＯのデータベースには、ＷｅｂサーバＳＷのドメイン名がエイリアス名として登録されている。具体的に、ＷｅｂサーバＳＷのドメイン名に対応付けて、Ｐ２Ｐ用ＤＮＳサーバのドメイン名が登録されている。これは、ユーザ端末Ｔｍ−ｎにＰ２ＰネットワークＰＷからコンテンツを取得させるための登録である。従って、組織用ＤＮＳサーバＳＯは、データベースからＰ２Ｐ用ＤＮＳサーバのドメイン名を取得する。更に、組織用ＤＮＳサーバＳＯは、データベースから、Ｐ２Ｐ用ＤＮＳサーバのドメイン名に対応するＩＰアドレスを取得する。そして、組織用ＤＮＳサーバＳＯは、取得したＩＰアドレスに基づいて、受信した名前解決リクエストをＰ２Ｐ用ＤＮＳサーバＳＰに転送する（図２（２））。

Ｐ２Ｐ用ＤＮＳサーバＳＰは、名前解決リクエストを受信すると、名前解決リクエストに含まれる要求ドメイン名に対応するコンテンツ保持ノードを検索する。ただし、Ｐ２Ｐ用ＤＮＳサーバＳＰが以前に同じドメイン名で検索を行ったのであれば、そのときの検索結果を利用することができる。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、要求ドメイン名のドメインＩＤに対応するインデックス情報が検索結果としてインデックスキャッシュ領域に記憶されているか否かを判定する（図２（３））。Ｐ２Ｐ用ＤＮＳサーバＳＰが有するインデックスキャッシュ領域を、特に「検索結果キャッシュ領域」という。ここで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、要求ドメイン名に基づいて、ドメインＩＤを生成する。例えば、ドメイン名とドメインＩＤとを対応付けて示す情報として、ドメインリストがＰ２Ｐ用ＤＮＳサーバＳＰに記憶されている。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ドメインリストに基づいて、ドメインＩＤを生成する。あるいは、Ｐ２Ｐ用ＤＮＳサーバＳＰは、要求ドメイン名のハッシュ値を計算してドメインＩＤを生成しても良い。

Ｐ２Ｐ用ＤＮＳサーバＳＰは、要求ドメイン名に対応するインデックス情報が検索結果キャッシュ領域に記憶されていないと判定した場合には、Ｐ２ＰネットワークＰＷにより要求ドメイン名に対応するコンテンツ保持ノードを検索する。具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、生成したドメインＩＤを含む検索メッセージを送信することにより、ルートノードとしてのルータＲｍからインデックス情報を取得する（図２（４））。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、インデックス情報を検索結果キャッシュ領域に記憶させる（図２（５））。

Ｐ２Ｐ用ＤＮＳサーバＳＰは、検索結果キャッシュ領域に記憶されたインデックス情報に基づいて、何れかのコンテンツ保持ノードを選択する。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、選択したコンテンツ保持ノードのＩＰアドレスを、組織用ＤＮＳサーバＳＯに返信する（図２（６））。ここで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、各ルータＲｍごとに、今まで組織用ＤＮＳサーバＳＯにＩＰアドレスを返信した回数に基づいて、コンテンツ保持ノードを選択する。この回数を「返答回数」という。具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、返答回数が最も少ないコンテンツ保持ノード、例えば、ルータＲ２を選択する。これは、特定のルータＲｍに、ユーザ端末Ｔｍ−ｎからのコンテンツの要求の負荷を集中させないためである。

以降、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＷｅｂサーバＳＷのドメイン名を含む名前解決リクエストを受信した場合には、検索結果キャッシュ領域に既に記憶されているインデックス情報に基づいて、ＩＰアドレスを返信する。これにより、名前解決リクエストに対する応答時間を短くすることができる。ただし、インデックス情報が検索結果キャッシュ領域に記憶されてから長期間経過すると、インデックス情報が古くなり、インデックス情報が示すコンテンツ保持ノードと実際のコンテンツ保持ノードとの間に食い違いが生じる。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、インデックス情報が検索結果キャッシュ領域に記憶されてから所定期間が経過した後は、そのインデックス情報を用いない。具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、記憶されてから所定期間が経過したインデックス情報に対応する要求ドメイン名を含む名前解決リクエストを受信したときには、要求ドメイン名に対応するコンテンツ保持ノードを再度検索する。そのため、Ｐ２Ｐ用ＤＮＳサーバＳＰは、検索結果キャッシュ領域に記憶されてから所定期間が経過したインデックス情報を、検索結果キャッシュ領域から削除する。

なお、Ｐ２Ｐ用ＤＮＳサーバＳＰは、検索結果キャッシュ領域に記憶されてから所定期間が経過したインデックス情報を、検索結果キャッシュ領域から削除しなくても良い。例えば、Ｐ２Ｐ用ＤＮＳサーバＳＰは、記憶されてから所定期間が経過したインデックス情報を、一定期間、用いないようにしても良い。つまり、Ｐ２Ｐ用ＤＮＳサーバＳＰは、記憶されてから所定期間が経過したインデックス情報に含まれるＩＰアドレスを、一定期間、組織用ＤＮＳサーバＳＯに送信しないようにしても良い。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、一定期間経過した後は、用いないと決定したインデックス情報を再度用いるようにしても良い。これにより、常に同じルータＲｍのＩＰアドレスが送信されることが防止される。この場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、例えば、インデックス情報に対応付けて、用いないことを示す情報と、用いない期間を示す情報と、を設定する。Ｐ２Ｐ用ＤＮＳサーバＳＰは、受信した名前解決リクエストに含まれる要求ドメイン名に対応するインデックス情報のうち、用いないと設定されたインデックス情報以外のインデックス情報に含まれるＩＰアドレスを、組織用ＤＮＳサーバに送信しても良い。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、要求ドメイン名に対応する全てのインデックス情報が、用いないと設定されたインデックス情報である場合、要求ドメイン名に対応するコンテンツ保持ノードを再度検索しても良い。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、検索によって取得したインデックス情報を検索結果キャッシュ領域に記憶させ、このインデックス情報に含まれるＩＰアドレスを、組織用ＤＮＳサーバに送信しても良い。

ルータＲ２のＩＰアドレスを受信した組織用ＤＮＳサーバＳＯは、このＩＰアドレスをユーザ端末Ｔ１−１に転送する（図２（７））。そして、ユーザ端末Ｔ１−１は、受信したＩＰアドレスに基づいて、ＨＴＴＰ（HyperText Transfer Protocol）リクエストであるコンテンツ要求メッセージをルータＲ２にコンテンツに送信する（図２（８））。ルータＲ２は、受信したコンテンツ要求メッセージに対応するコンテンツを、ユーザ端末Ｔ１−１に送信する（図２（９））。

［３．コンテンツ保持ノードの追加］
次に、図３を参照して、コンテンツ配信システムＳにおけるコンテンツ保持ノードの追加について説明する。図３は、本実施形態に係るコンテンツ配信システムＳにおける動作概要の一例を示す図である。

上述したように、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ユーザ端末Ｔｍ−ｎが取得しようとするコンテンツを保存するルータＲｍのＩＰアドレスを返信する。そのため、ルータＲｍは、ユーザ端末Ｔｍ−ｎからコンテンツの要求を受けたとき、要求されたコンテンツを保存するルータＲｍを検索して他のルータＲｍからコンテンツを取得する必要がない。しかしながら、特定のドメインに対応するコンテンツを保存するルータＲｍの台数が少ないと、ユーザ端末Ｔｍ−ｎからの要求が特定のルータＲｍに集中する。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、各ルータＲｍと連携して、コンテンツ保持ノードを追加する処理を行う。これにより、コンテンツ保持ノードが増加するので、ルータＲｍの負荷を分散される。

具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ドメインごとに、名前解決リクエストを受信した回数をカウントしている。この回数を「リクエスト受信回数」という。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、例えば、図３に示すように、ＷｅｂサーバＳＷのドメインに対応するリクエスト受信回数が、上限値を超えたと判定したとする（図３（１Ａ））。すると、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＷｅｂサーバＳＷのドメインに対応するコンテンツのコンテンツ保持ノードを追加させる。リクエスト受信回数が上限値を超える場合には、特定のドメインに対応するコンテンツの要求が集中し、あるいは、集中しつつあるからである。ここで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、例えば、ＷｅｂサーバＳＷのドメインに対応するコンテンツの現在のコンテンツ保持ノードの台数に基づいて、上限値を決定しても良い。このコンテンツ保持ノードの台数を、「ホルダ数」という。具体的には、ホルダ数が多いほど、コンテンツの要求に対する負荷が分散される。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ホルダ数が多いほど、上限値を大きい値にする。これにより、例えば、リクエスト受信回数の増加に従って、ホルダ数を徐々に増やしていくことができる。このように、コンテンツ保持ノードを追加する条件を適切な条件とすることができる。なお、リクエスト受信回数は、本発明における回数情報の一例である。また、このときの上限値は、本発明における所定値の一例である。また、ホルダ数は、本発明における数情報の一例である。

Ｐ２Ｐ用ＤＮＳサーバＳＰは、リクエスト受信回数が上限値を超えたと判定した場合、新たなコンテンツ保持ノードを決定する。具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＷｅｂサーバＳＷのドメインに対応するコンテンツを保存していないルータＲｍのうち、返答回数が最も少ないルータＲｍ、例えば、ルータＲ５を、新たなコンテンツ保持ノードと決定する（図３（２Ａ））。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＷｅｂサーバＳＷのドメインのドメインＩＤを含むダウンロード指示メッセージを、ルータＲ５に送信する（図３（３Ａ））。ダウンロード指示メッセージは、コンテンツ保持ノードを増加させる指示を示すメッセージである。具体的に、ダウンロード指示メッセージは、メッセージの送信先のルータＲｍに、指示したドメインに対応するコンテンツをダウンロードさせるメッセージである。なお、ダウンロード指示メッセージは、本発明における指示情報の一例である。

ルータＲ５は、受信したダウンロード指示メッセージに含まれるドメインＩＤに基づいて、ＷｅｂサーバＳＷのドメインに対応するコンテンツのコンテンツ保持ノード、例えば、ルータＲ４から、そのドメインに対応するコンテンツを全部ダウンロードして保存する（図３（４Ａ））。なお、ルータＲ５は、複数のコンテンツ保持ノードから、コンテンツを分散してダウンロードしても良い。ルータＲ５は、コンテンツを全部ダウンロードすると、ダウンロード指示メッセージに含まれるドメインＩＤを設定したパブリッシュメッセージを送信する。これにより、ルータＲ５は、ＷｅｂサーバＳＷのドメインに対応するコンテンツの新たなコンテンツ保持ノードとなる。

一方、ルータＲｍも、ルータＲｍ自身に対するコンテンツの要求の集中を判定して、コンテンツ保持ノードを追加させる。例えば、ルータＲ２は、ルータＲ２からコンテンツを取得するためにルータＲ２と現在接続中のユーザ端末Ｔｍ−ｎの台数が、予め設定された上限値を超えた場合に、コンテンツ保持ノードを追加させる。この台数を、「接続端末数」という。接続端末数は、あるルータＲｍにコンテンツ要求メッセージを送信してきたユーザ端末Ｔｍ−ｎのうち、このコンテンツ要求メッセージに対してそのルータＲｍがコンテンツのアップロードを完了していないユーザ端末Ｔｍ−ｎの台数を示す。

ルータＲ２は、接続端末数が上限値を超えたと判定した場合（図３（１Ｂ））、Ｐ２Ｐ用ＤＮＳサーバＳＰの場合と同様の方法で、例えば、ルータＲ３を、新たなコンテンツ保持ノードとして決定する（図３（２Ｂ））。そして、ルータＲ２は、ダウンロード指示メッセージをルータＲ３に送信する（図３（３Ｂ））。ルータＲ３も、ルータＲ５の場合と同様に、ＷｅｂサーバＳＷのドメインに対応するコンテンツを全部取得する（図３（４Ｂ））。

ルータＲ２は、現在のコンテンツの要求の集中を解消するため、Ｐ２Ｐ用ＤＮＳサーバＳＰに、紹介拒否通知メッセージを送信する（図３（５Ｂ））。すると、Ｐ２Ｐ用ＤＮＳサーバＳＰは、組織用ＤＮＳサーバＳＯにＩＰアドレスを返信するルータＲｍの候補から、ルータＲ２を除外する。その後、ルータＲ２は、コンテンツの要求の集中が解消されたと判定すると、Ｐ２Ｐ用ＤＮＳサーバＳＰに、紹介拒否解除通知メッセージを送信する。すると、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＩＰアドレスを返信するルータＲｍの候補から、ルータＲ２を除外しない。

［４．各装置の構成及び機能］
次に、図４及び図５を参照して、各装置の構成及び機能について説明する。図４は、ルータＲｍの概要構成例を示す図である。また、図５は、Ｐ２Ｐ用ＤＮＳサーバＳＰの概要構成例を示す図である。

［４．１ ルータの構成］
ルータＲｍは、図４に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部１１を備えている。また、ルータＲｍは、各種データ及び各種プログラム等を記憶保存するためのＨＤ（ハードディスク）等から構成された記憶部１２を備えている。更に、ルータＲｍは、ネットワークＮＷ、配信センターネットワークＮＳ、拠点ネットワークＮＬｍ等を通じて、他のルータＲｍ、センターサーバＳＳ、Ｐ２Ｐ用ＤＮＳサーバＳＰ、ユーザ端末Ｔｍ−ｎ等との間の情報の通信制御を行うための通信部１３を備えている。制御部１１、記憶部１２及び通信部１３はバス１４を介して相互に接続されている。

記憶部１２には、センターサーバＳＳやＰ２Ｐ用ドメインサーバＳＰのＩＰアドレス及びポート番号が記憶されている。また、記憶部１２には、ＤＨＴルーティングテーブル、ネットワーク層レベルでのルーティングに用いられるルーティングテーブル、カタログ情報、インデックス情報、ドメインリスト、現在の接続端末数、接続端末数の上限値、現在の紹介状態が記憶されている。紹介状態は、ルータＲｍが、そのルータＲｍ自身のＩＰアドレスをユーザ端末Ｔｍ−ｎに紹介することを拒否しているか否かを示す。Ｐ２Ｐ用ＤＮＳサーバＳＰから見ると、紹介状態は、そのルータＲｍのＩＰアドレスを組織用ＤＮＳサーバＳＯに返信することを拒否しているか否かを示す。この紹介状態には、紹介許可状態または紹介拒否状態が設定される。

カタログ情報には、Ｐ２ＰネットワークＰＷに投入されている各コンテンツの属性情報が記述されている。属性情報には、例えば、コンテンツＩＤ、コンテンツ名、ファイルサイズ、複合コンテンツフラグ等が含まれる。複合コンテンツフラグは、コンテンツが複合コンテンツであるか否かを示す情報である。複合コンテンツの属性情報には、その複合コンテンツに対応するドメインのドメインＩＤが含まれている。なお、通常コンテンツの属性情報にドメインＩＤが含まれていても良い。

また、記憶部１２には、ダウンロードされたコンテンツが、コンテンツＩＤに対応付けて記憶されている。記憶部１２には、コンテンツが記憶されるコンテンツキャッシュ領域として、固定キャッシュ領域と動的キャッシュ領域とが割り当てられている。各コンテンツキャッシュ領域には、コンテンツの最大記憶容量が設定されている。制御部１１がコンテンツをコンテンツキャッシュ領域に新しく記憶しようとする場合に、コンテンツキャッシュ領域の容量が足りない場合がある。その場合、制御部１１は、コンテンツキャッシュ領域に記憶されているコンテンツのうち、例えば、記憶された時期が最も古いコンテンツをコンテンツキャッシュ領域から削除する。こうして、制御部１１は、新しいコンテンツを記憶するための容量を確保する。固定キャッシュ領域は、例えば、主コンテンツが記憶される領域であり、動的キャッシュ領域は、例えば、副コンテンツが記憶される領域である。主コンテンツは、例えば、各ルータＲｍが、コンテンツ配信システムＳ等に関する処理を実行するために必要なコンテンツである。コンテンツキャッシュ領域を１つの領域としたとする。その場合、ルータＲｍが、Ｐ２Ｐ用ＤＮＳサーバＳＰや他のルータＲｍからダウンロード指示メッセージを受信すると、副コンテンツを記憶するため、コンテンツキャッシュ領域から主コンテンツを削除しなければならない可能性がある。そこで、コンテンツキャッシュ領域を分けることにより、副コンテンツの記憶によって必要なコンテンツが削除されないようになっている。

センターサーバＳＳは、主コンテンツをルータＲｍにダウンロードさせるために、ルータＲｍにダウンロード指示メッセージを送信する場合がある。この場合、ダウンロード指示メッセージには、ダウンロードすべきコンテンツのコンテンツＩＤが含まれている。なお、固定キャッシュ領域には、ルータＲｍがセンターサーバＳＳからダウンロード指示メッセージを受信することによりダウンロードされた副コンテンツが記憶されても良い。このような副コンテンツは、例えば、全てのルータＲｍが保存すべき副コンテンツである。全てのルータＲｍが保存すべき副コンテンツは、例えば、新着のコンテンツ等、ユーザ端末Ｔｍ−ｎからの要求が集中すると予想されるコンテンツである。

更に、記憶部１２には、ＤＨＴルーティングテーブルに基づいて他のノードとの間で各種メッセージを送受信するためのＰ２Ｐプログラムが記憶されている。なお、Ｐ２Ｐプログラムは、例えば、所定のサーバ装置等からダウンロードされるようにしても良い。また、Ｐ２Ｐプログラムは、例えば、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されて当該記録媒体からドライブを介して読み込まれるようにしても良い。

制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラムを読み出して実行することにより、ルータＲｍの各部を統括制御する。

［４．２ Ｐ２Ｐ用ＤＮＳサーバの構成］
Ｐ２Ｐ用ＤＮＳサーバＳＰは、図５に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部２１を備えている。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、各種データ及び各種プログラム等を記憶保存するためのＨＤ等から構成された記憶部２２を備えている。更に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ネットワークＮＷ等を通じてルータＲｍや組織用ＤＮＳサーバＳＯ等との間の情報の通信制御を行うための通信部２３を備えている。また更に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、各種情報を表示するＣＲＴ，液晶ディスプレイ等の表示部２４を備えている。更にまた、Ｐ２Ｐ用ＤＮＳサーバＳＰは、オペレータからの指示を受け付けこの指示に応じた指示信号を制御部２１に対して与える入力部（例えば、キーボード、マウス等）２５を備えている。そして、制御部２１、記憶部２２、通信部２３、表示部２４、及び入力部２５はバス２６を介して相互に接続されている。ここで、記憶部２２は、本発明における記憶手段及び第２記憶手段の一例である。

記憶部２２には、ＤＨＴルーティングテーブル、カタログ情報、ドメインリスト、リクエスト受信リスト、リクエスト返答リストが記憶されている。ドメインリストは、ドメイン名と、ドメインＩＤとを対応付けて示す情報である。リクエスト受信リストは、ドメイン名と、リクエスト受信回数と、ホルダ数とを対応付けて示す情報である。リクエスト返答リストは、ルータＲｍのＩＰアドレスと、返答回数と、紹介状態とを対応付けて示す情報である。また、記憶部２２には、検索結果キャッシュ領域が割り当てられている。また、記憶部２２には、検索結果記憶時間が記憶されている。検索結果記憶時間は、検索結果キャッシュ領域にインデックス情報を記憶させておくことができる最長の時間を示す。

更に、記憶部２２には、ＤＮＳサーバとしての処理を実行するためのＤＮＳサーバプログラムやＰ２Ｐプログラムが記憶されている。なお、ＤＮＳサーバプログラム及びＰ２Ｐプログラムは、例えば、ネットワークＮＷ上の所定のサーバからダウンロードされるようにしても良い。また、ＤＮＳサーバプログラム及びＰ２Ｐプログラムは、例えば、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてこの記録媒体のドライブを介して読み込まれるようにしても良い。ＤＮＳサーバプログラム及びＰ２Ｐプログラムは、本発明における情報処理プログラムの一例である。

制御部２１は、ＣＰＵが記憶部２２等に記憶されたＤＮＳサーバプログラムやＰ２Ｐプログラム等のプログラムを読み出して実行することにより、検索手段、送信手段、判定手段、生成手段、第２判定手段、削除手段、第３判定手段、第２送信手段、第２取得手段及び決定手段として機能する。

［５．コンテンツ配信システムの動作］
次に、図６乃至図８を参照して、本実施形態におけるコンテンツ配信システムＳの動作について説明する。図６は、本実施形態におけるルータＲｍの制御部１１の処理例を示すフローチャートである。

図６に示す処理は、例えば、ルータＲｍのＰ２Ｐプログラムが起動したときに開始される。先ず、制御部１１は、初期化処理の一環として、接続端末数を０に設定し、紹介状態を紹介許可状態に設定する。次いで、制御部１１は、コンテンツ要求メッセージを受信したか否かを判定する（ステップＳ１）。このとき、制御部１１は、コンテンツ要求メッセージを受信しなかったと判定した場合には（ステップＳ１：ＮＯ）、ステップＳ１４に移行する。

一方、制御部１１は、コンテンツ要求メッセージを受信したと判定した場合には（ステップＳ１：ＹＥＳ）、Ｐ２Ｐネットワーク外からのコンテンツ要求メッセージを受信したか否かを判定する（ステップＳ２）。Ｐ２Ｐネットワーク外からのコンテンツ要求メッセージは、ユーザ端末Ｔｍ−ｎから送信されるＨＴＴＰリクエストである。一方、Ｐ２Ｐネットワーク内からのコンテンツ要求メッセージは、他のルータＲｍから送信されるピアツーピア専用のプロトコルのメッセージである。従って、両者はプロトコルが互いに異なるため、制御部１１は、コンテンツ要求メッセージを受信したときのポート番号から、どこからのコンテンツ要求メッセージであるかを判断することができる。制御部１１は、Ｐ２Ｐネットワーク内からのコンテンツ要求メッセージであると判定した場合には（ステップＳ２：ＮＯ）、コンテンツ要求メッセージの送信元のルータＲｍへのコンテンツのアップロードを開始する（ステップＳ３）。次いで、制御部１１は、ステップＳ１４に移行する。

一方、制御部１１は、Ｐ２Ｐネットワーク外からのコンテンツ要求メッセージであると判定した場合には（ステップＳ２：ＹＥＳ）、要求されたコンテンツをコンテンツキャッシュ領域から検索する。Ｐ２Ｐネットワーク外からのコンテンツ要求メッセージには、要求されたコンテンツのＵＲＬが含まれている。そこで、制御部１１は、このＵＲＬをハッシュ化して、コンテンツＩＤを生成する。そして、制御部１１は、生成したコンテンツＩＤに対応するコンテンツを、固定キャッシュ領域及び動的キャッシュ領域から検索する。

次いで、制御部１１は、検索の結果、要求されたコンテンツがコンテンツキャッシュ領域に記憶されているか否かを判定する（ステップＳ５）。このとき、制御部１１は、要求されたコンテンツが記憶されていないと判定した場合には（ステップＳ５：ＮＯ）、コンテンツ要求メッセージの送信元のユーザ端末Ｔｍ−ｎにエラーメッセージを送信して、ステップＳ１４に移行する。

一方、制御部１１は、要求されたコンテンツが記憶されていると判定した場合には（ステップＳ５：ＹＥＳ）、接続端末数に１を加算する（ステップＳ６）。次いで、制御部１１は、接続端末数が上限値を超えているか否かを判定する（ステップＳ７）。このとき、制御部１１は、接続端末数が上限値を超えていないと判定した場合には（ステップＳ７：ＮＯ）、コンテンツのアップロードを開始する（ステップＳ１３）。具体的に、制御部１１は、生成したコンテンツＩＤに対応するコンテンツをコンテンツキャッシュ領域から取得する。そして、制御部１１は、コンテンツ要求メッセージの送信元のユーザ端末Ｔｍ−ｎへのコンテンツのアップロードを開始する。次いで、制御部１１は、ステップＳ１４に移行する。

一方、制御部１１は、接続端末数が上限値を超えていると判定した場合には（ステップＳ７：ＹＥＳ）、Ｐ２Ｐ用ＤＮＳサーバＳＰからリクエスト返答リストを取得する（ステップＳ８）。具体的に、制御部１１は、リクエスト返答リスト要求メッセージをＰ２Ｐ用ＤＮＳサーバＳＰに送信する。そして制御部１１は、Ｐ２Ｐ用ＤＮＳサーバＳＰから送信されてきたリクエスト返答リストを受信する。

次いで、制御部１１は、ルータＲｍ自身に現在接続している各ユーザ端末Ｔｍ−ｎからのコンテンツの要求が最も多いドメインを選択する（ステップＳ９）。具体的に、制御部１１は、現在接続している各ユーザ端末Ｔｍ−ｎから受信しているコンテンツ要求メッセージからドメイン名を取得する。次いで、制御部１１は、コンテンツ要求メッセージから取得されたドメイン名の個数を、ドメイン名ごとに集計する。そして、個数が最も多いドメイン名を選択する。次いで、制御部１１は、後述するコンテンツキャッシュ追加指示処理を実行する（ステップＳ１０）。このとき、制御部１１は、引数として、選択したドメイン名を引き渡す。

次いで、制御部１１は、Ｐ２Ｐ用ＤＮＳサーバＳＰに、紹介拒否通知メッセージを送信する（ステップＳ１１）。次いで、制御部１１は、紹介状態を紹介拒否状態に設定する（ステップＳ１２）。次いで、制御部１１は、ユーザ端末Ｔｍ−ｎへのコンテンツのアップロードを開始して（ステップＳ１３）、ステップＳ１４に移行する。

ステップＳ１４において、制御部１１は、コンテンツのアップロードを開始したもののうち、アップロードが完了したものがあるか否かを判定する。このとき、制御部１１は、アップロードが完了したものがないと判定した場合には（ステップＳ１４：ＮＯ）、ステップＳ２１に移行する。一方、制御部１１は、アップロードが完了したものがあると判定した場合には（ステップＳ１４：ＹＥＳ）、完了したアップロードが、Ｐ２ＰネットワークＰＷ外へのアップロードであるか否かを判定する（ステップＳ１５）。このとき、制御部１１は、完了したアップロードが、Ｐ２ＰネットワークＰＷ内へのアップロードであると判定した場合には（ステップＳ１５：ＮＯ）、ステップＳ２１に移行する。

一方、制御部１１は、完了したアップロードがＰ２ＰネットワークＰＷ外へのアップロードであると判定した場合には（ステップＳ１５：ＹＥＳ）、接続端末数から１を減算する（ステップＳ１６）。次いで、制御部１１は、接続端末数が０であるか否かを判定する（ステップＳ１７）。このとき、制御部１１は、接続端末数が０ではないと判定した場合には（ステップＳ１７：ＮＯ）、ステップＳ２１に移行する。一方、制御部１１は、接続端末数が０であると判定した場合には（ステップＳ１７：ＹＥＳ）、紹介状態が紹介拒否状態であるか否かを判定する（ステップＳ１８）。このとき、制御部１１は、紹介状態が紹介許可状態であると判定した場合には（ステップＳ１８：ＮＯ）、ステップＳ２１に移行する。

一方、制御部１１は、紹介状態が紹介拒否状態であると判定した場合には（ステップＳ１８：ＹＥＳ）、Ｐ２Ｐ用ＤＮＳサーバＳＰに、紹介拒否解除通知メッセージを送信する（ステップＳ１９）。次いで、制御部１１は、紹介状態を紹介許可状態に設定して（ステップＳ２０）、ステップＳ２１に移行する。

ステップＳ２１において、制御部１１は、ダウンロード指示メッセージを受信したか否かを判定する。このとき、制御部１１は、ダウンロード指示メッセージを受信したと判定した場合には（ステップＳ２１：ＹＥＳ）、指示されたコンテンツをダウンロードする（ステップＳ２２）。具体的に、制御部１１は、センターサーバＳＳからダウンロード指示メッセージを受信した場合には、ダウンロード指示メッセージからコンテンツＩＤを取得する。そして、制御部１１は、コンテンツＩＤを含む検索メッセージを送信することにより、コンテンツ保持ノードを検索する。そして、制御部１１は、コンテンツ保持ノードにコンテンツ要求メッセージを送信して、コンテンツをダウンロードする。

一方、制御部１１は、Ｐ２Ｐ用ＤＮＳサーバＳＰまたは他のルータＲｍからダウンロード指示メッセージを受信した場合には、ダウンロード指示メッセージからドメインＩＤを取得する。次いで、制御部１１は、ドメインＩＤに対応する複合コンテンツをカタログ情報から検索する。次いで、制御部１１は、検索された複合コンテンツのコンテンツＩＤに基づいて、複合コンテンツのメタファイルを他のルータＲｍから取得する。メタファイルの取得方法は、コンテンツの場合と同様である。次いで、制御部１１は、取得したメタファイルから、複合コンテンツを構成する各通常コンテンツのコンテンツＩＤを取得する。次いで、制御部１１は、取得したコンテンツＩＤに基づいて、通常コンテンツを他のルータＲｍから取得する。制御部１１は、このような処理を、ドメインＩＤに対応する全ての複合コンテンツについて実行する。そして、制御部１１は、ドメインＩＤに対応するコンテンツを全部取得すると、ドメインＩＤを含むパブリッシュメッセージを送信する。

制御部１１は、コンテンツのダウンロードが完了すると、受信したダウンロード指示メッセージが、センターサーバＳＳからのメッセージであるか否かを判定する（ステップＳ２３）。このとき、制御部１１は、センターサーバＳＳからのメッセージであると判定した場合には（ステップＳ２３：ＹＥＳ）、ダウンロードしたコンテンツを固定キャッシュ領域に記憶させる（ステップＳ２４）。一方、制御部１１は、センターサーバＳＳからのメッセージではないと判定した場合には（ステップＳ２３：ＮＯ）、ダウンロードしたコンテンツを動的キャッシュ領域に記憶させる（ステップＳ２５）。

制御部１１は、ステップＳ２４またはＳ２５の処理を終えると、管理者から、Ｐ２ＰネットワークＮＷから離脱指示があったか否かを判定する（ステップＳ２６）。このとき、制御部１１は、離脱指示がなかったと判定した場合には（ステップＳ２６：ＮＯ）、ステップＳ１に移行する。一方、制御部１１は、離脱指示があったと判定した場合には（ステップＳ２６：ＹＥＳ）、図６に示す処理を終了させる。

図７は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１の処理例を示すフローチャートである。

図７に示す処理は、例えば、Ｐ２Ｐ用ＤＮＳサーバＳＰの電源がＯＮとされたときに開始される。先ず、制御部２１は、初期化処理の一貫として、リクエスト受信リストにおける全てのリクエスト受信回数及びホルダ数を０に設定する。また、制御部２１は、リクエスト返答リストにおける全ての返答回数を０に設定し、全ての紹介状態を紹介許可状態に設定する。次いで、制御部２１は、組織用ＤＮＳサーバＳＯから名前解決リクエストを受信したか否かを判定する（ステップＳ５１）。このとき、制御部２１は、名前解決リクエストを受信しなかったと判定した場合には（ステップＳ５１：ＮＯ）、ステップＳ６６に移行する。

一方、制御部２１は、名前解決リクエストを受信したと判定した場合には（ステップＳ５１：ＹＥＳ）、リクエスト受信リストにおいて、名前解決リクエストに含まれる要求ドメイン名に対応するリクエスト受信回数に１を加算する（ステップＳ５２）。次いで、制御部２１は、リクエスト受信回数の上限値を決定する（ステップＳ５３）。具体的に、制御部２１は、リクエスト受信リストから、要求ドメイン名に対応するホルダ数を取得する。そして、制御部２１は、取得したホルダ数の値が大きいほど、上限値の値を大きくする。このとき、制御部２１は、例えば、所定の計算式にホルダ数を当てはめて、上限値を計算しても良い。また例えば、制御部２１は、ホルダ数と上限値とを対応付けて示すテーブル情報に基づいて、上限値を決定しても良い。

次いで、制御部２１は、要求ドメイン名に対応するリクエスト受信回数が、決定した上限値を超えているか否かを判定する（ステップＳ５４）。このとき、制御部２１は、上限値を超えていると判定した場合には（ステップＳ５４：ＹＥＳ）、後述するコンテンツキャッシュ追加指示処理を実行する（ステップＳ５５）。このとき、制御部２１は、引数として、要求ドメイン名を引き渡す。

制御部２１は、上限値を超えていないと判定した場合（ステップＳ５４：ＮＯ）、または、ステップＳ５５の処理を終えた場合には、要求ドメイン名に対応するインデックス情報が、検索結果キャッシュ領域に記憶されているか否かを判定する（ステップＳ５６）。具体的に、制御部２１は、ドメインリストから要求ドメイン名に対応するドメインＩＤを取得する。そして、制御部２１は、ドメインＩＤに対応するインデックス情報を検索結果キャッシュ領域から検索する。このとき、制御部２１は、要求ドメイン名に対応するインデックス情報が検索結果キャッシュ領域に記憶されていると判定した場合には（ステップＳ５６：ＹＥＳ）、ステップＳ６１に移行する。

一方、制御部２１は、要求ドメイン名に対応するインデックス情報が検索結果キャッシュ領域に記憶されていないと判定した場合には、後述するコンテンツ保持ノード検索処理を実行する（ステップＳ５７）。このとき、制御部２１は、引数として、要求ドメイン名を引き渡す。コンテンツ保持ノード検索処理において、制御部２１は、渡されたドメイン名のドメインに対応するコンテンツのコンテンツ保持ノードを検索する。

次いで、制御部２１は、コンテンツ保持ノード検索処理による検索が成功したか否かを判定する（ステップＳ５８）。つまり、制御部２１は、要求ドメイン名が示すドメインに対応するコンテンツのコンテンツ保持ノードを検索することができたか否かを判定する。このとき、制御部２１は、検索が成功しなかったと判定した場合には（ステップＳ５８：ＮＯ）、組織用ＤＮＳサーバＳＯにエラーメッセージを返信する（ステップＳ５９）。次いで、制御部２１は、ステップＳ６６に移行する。

一方、制御部２１は、検索が成功したと判定した場合には（ステップＳ５８：ＹＥＳ）、コンテンツ保持ノード検索処理において取得されたインデックス情報を、検索結果キャッシュ領域に記憶させる（ステップＳ６０）。このとき、制御部２１は、制御部２１のタイマー機能から、現在日時を取得する。次いで、制御部２１は、取得した現在日時に検索結果記憶時間を加算して、インデックス情報の有効期限日時を計算する。そして、制御部２１は、計算した有効期限日時を、要求ドメイン名のドメインＩＤに対応付けて記憶部２２に記憶させる。また、制御部２１は、取得されたインデックス情報から、検索されたコンテンツ保持ノードの台数を計算する。そして、制御部２１は、計算した台数を、要求ドメイン名に対応するホルダ数として、リクエスト受信リストに設定する。

次いで、制御部２１は、検索されたコンテンツ保持ノードのうち、リクエスト返答リストに設定されている返答回数の値が最も小さいコンテンツ保持ノードのＩＰアドレスを、検索結果キャッシュ領域に記憶されたインデックス情報から取得する（ステップＳ６１）。次いで、制御部２１は、リクエスト返答リストにおいて、ＩＰアドレスを取得したコンテンツ保持ノードの紹介状態が紹介拒否状態であるか否かを判定する（ステップＳ６２）。このとき、制御部２１は、紹介状態が紹介拒否状態であると判定した場合には（ステップＳ６２：ＹＥＳ）、ＩＰアドレスを取得したコンテンツ保持ノードのインデックス情報を、検索結果キャッシュ領域から削除する（ステップＳ６３）。次いで、制御部２１は、ステップＳ５６に移行する。

一方、制御部２１は、紹介状態が紹介許可状態であると判定した場合には（ステップＳ６２：ＮＯ）、取得したＩＰアドレスを組織用ＤＮＳサーバＳＯに返信する（ステップＳ６４）。制御部２１は、ステップＳ５６〜Ｓ６４の処理により、紹介状態が紹介許可状態であるコンテンツ保持ノードのうち、返答回数が最も少ないコンテンツ保持ノードのＩＰアドレスを返信する。次いで、制御部２１は、リクエスト返答リストにおいて、ＩＰアドレスを取得したコンテンツ保持ノードの返答回数に１を加算する（ステップＳ６５）。次いで、制御部２１は、ステップＳ６６に移行する。

ステップＳ６６において、制御部２１は、リクエスト受信回数をリセットするタイミングであるか否かを判定する。このとき、制御部２１は、リクエスト受信回数をリセットするタイミングであると判定した場合には（ステップＳ６６：ＹＥＳ）、リクエスト受信リストに設定されている全てのリクエスト受信回数を０に設定する（ステップＳ６７）。リクエスト受信回数を長期間カウントし続けていると、リクエスト受信回数の内容が古い内容を反映するようになる。そこで、制御部２１は、リクエスト受信回数を定期的にリセットする。

制御部２１は、リクエスト受信回数をリセットするタイミングではないと判定した場合（ステップＳ６６：ＮＯ）、または、ステップＳ６７の処理を終えた場合には、ルータＲｍから紹介拒否通知メッセージを受信したか否かを判定する（ステップＳ６８）。このとき、制御部２１は、紹介拒否通知メッセージを受信したと判定した場合には（ステップＳ６７：ＹＥＳ）、リクエスト返答リストにおいて、紹介拒否通知メッセージの送信元のルータＲｍの紹介状態を、紹介拒否状態に設定する（ステップＳ６９）。

制御部２１は、紹介拒否通知メッセージを受信しなかったと判定した場合（ステップＳ６８：ＮＯ）、または、ステップＳ６９の処理を終えた場合には、ルータＲｍから紹介拒否解除通知メッセージを受信したか否かを判定する（ステップＳ７０）。このとき、制御部２１は、紹介拒否解除通知メッセージを受信したと判定した場合には（ステップＳ７０：ＹＥＳ）、リクエスト返答リストにおいて、紹介拒否解除通知メッセージの送信元のルータＲｍの紹介状態を、紹介許可状態に設定する（ステップＳ７１）。

制御部２１は、紹介拒否解除通知メッセージを受信しなかったと判定した場合（ステップＳ７０：ＮＯ）、または、ステップＳ７１の処理を終えた場合には、ルータＲｍからリクエスト返答リスト要求メッセージを受信したか否かを判定する（ステップＳ７２）。このとき、制御部２１は、リクエスト返答リスト要求メッセージを受信したと判定した場合には（ステップＳ７２：ＹＥＳ）、リクエスト返答リストを、リクエスト返答リスト要求メッセージの送信元のルータＲｍにアップロードする（ステップＳ７３）。

制御部２１は、リクエスト返答リスト要求メッセージを受信しなかったと判定した場合（ステップＳ７２：ＮＯ）、または、ステップＳ７３の処理を終えた場合には、検索結果キャッシュ領域に記憶されたインデックス情報を削除するタイミングであるか否かを判定する（ステップＳ７４）。具体的に、制御部２１は、制御部２１のタイマー機能から現在日時を取得する。次いで、制御部２１は、記憶部２２に記憶されているインデックス情報の有効期限日時のうち、現在日時よりも古い日時を示すものが存在するか否かを判定する。このとき、制御部２１は、現在日時よりも古い日時を示す有効期限日時が存在する場合には、インデックス情報を削除するタイミングであると判定する（ステップＳ７４：ＹＥＳ）。この場合、制御部２１は、現在日時よりも古い日時を示す有効期限日時に対応するドメインＩＤを取得する。そして、制御部２１は、検索結果キャッシュ領域から、取得したドメインＩＤに対応するインデックス情報を全て削除する（ステップＳ７５）。

制御部２１は、インデックス情報を削除するタイミングではないと判定した場合（ステップＳ７４）、または、ステップＳ７５の処理を終えた場合には、管理者からの終了指示があったか否かを判定する（ステップＳ７６）。このとき、制御部２１は、終了指示がなかったと判定した場合には（ステップＳ７６：ＮＯ）、ステップＳ５１に移行する。一方、制御部２１は、終了指示があったと判定した場合には（ステップＳ７６：ＹＥＳ）、図７に示す処理を終了させる。

図８（ａ）は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１のコンテンツキャッシュ追加指示処理における処理例を示すフローチャートである。なお、ルータＲｍにおけるコンテンツキャッシュ追加指示処理も、Ｐ２Ｐ用ＤＮＳサーバＳＰの場合と同様である。

先ず、制御部２１は、後述するコンテンツ保持ノード検索処理を実行する（ステップＳ１０１）。このとき、制御部２１は、引数として渡されたドメイン名を、コンテンツ保持ノード検索処理の引数として引き渡す。次いで、制御部２１は、リクエスト返答リストにおいて、返答回数の値が最も小さいルータＲｍを選択する（ステップＳ１０２）。次いで、制御部２１は、選択したルータＲｍが、コンテンツキャッシュ領域への追加対象となるドメインのコンテンツを保存しているか否かを判定する（ステップＳ１０３）。具体的に、制御部２１は、コンテンツ保持ノード検索処理において検索されたコンテンツ保持ノードの中に、選択したルータＲｍが存在するか否かを判定する。このとき、制御部２１は、検索されたコンテンツ保持ノードの中に、選択したルータＲｍが存在する場合には、追加対象となるドメインのコンテンツを保存していると判定する（ステップＳ１０３：ＹＥＳ）。この場合、制御部２１は、今選択したルータＲｍを、以降の選択の対象から除外して（ステップＳ１０４）、再度選択を行う（ステップＳ１０２）。

一方、制御部２１は、検索されたコンテンツ保持ノードの中に、選択したルータＲｍが存在しない場合には、追加対象となるドメインのコンテンツを保存していないと判定する（ステップＳ１０３：ＮＯ）。この場合、制御部２１は、リクエスト返答リストにおいて、選択したルータＲｍの紹介状態が紹介拒否状態であるか否かを判定する（ステップＳ１０５）。このとき、制御部２１は、紹介状態が紹介拒否状態であると判定した場合には（ステップＳ１０５：ＹＥＳ）、ステップＳ１０４に移行する。

一方、制御部２１は、紹介状態が紹介許可状態であると判定した場合には（ステップＳ１０５：ＮＯ）、追加対象のドメインのドメイン名を含むダウンロード指示メッセージを、選択したルータＲｍに送信する（ステップＳ１０６）。制御部２１は、ステップＳ１０６の処理を終えると、コンテンツキャッシュ追加指示処理を終了させる。

図８（ｂ）は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部２１のコンテンツ保持ノード検索処理における処理例を示すフローチャートである。なお、ルータＲｍにおけるコンテンツ保持ノード検索処理も、Ｐ２Ｐ用ＤＮＳサーバＳＰの場合と同様である。

先ず、制御部２１は、ドメインリストから、引数として渡されたドメイン名に対応するドメインＩＤを検索する（ステップＳ１５１）。次いで、制御部２１は、ドメインＩＤを検索することができたか否かを判定する（ステップＳ１５２）。このとき、制御部２１は、ドメインＩＤをすることができなかったと判定した場合には（ステップＳ１５２：ＮＯ）、コンテンツ保持ノード検索処理を終了させて、処理結果として検索失敗を返却する。

一方、制御部２１は、ドメインＩＤを検索することができたと判定した場合には（ステップＳ１５２：ＹＥＳ）、検索されたドメインＩＤを含む検索メッセージを送信することにより、コンテンツ保持ノードを検索する（ステップＳ１５３）。次いで、制御部２１は、コンテンツ保持ノードを検索することができたか否かを判定する（ステップＳ１５４）。このとき、制御部２１は、送信した検索メッセージに応じてルートノードからコンテンツ保持ノードのインデックス情報を受信した場合には、コンテンツ保持ノードを検索することができたと判定する（ステップＳ１５４：ＹＥＳ）。この場合、制御部２１は、コンテンツ保持ノード検索処理を終了させて、処理結果として検索成功を返却する。一方、制御部２１は、ルートノードからコンテンツ保持ノードのインデックス情報を受信することができなかった場合には、コンテンツ保持ノードを検索することができなかったと判定する（ステップＳ１５４：ＮＯ）。この場合、制御部２１は、コンテンツ保持ノード検索処理を終了させて、処理結果として検索失敗を返却する。

なお、上記実施形態において、Ｐ２Ｐ用ＤＮＳサーバＳＰは、リクエスト受信回数の上限値をホルダ数に基づいて決定していたが、上限値は固定値であっても良い。

また、上記実施形態において、ルータＲｍは、コンテンツキャッシュ追加処理を実行する接続端末数と同じ接続端末数で、紹介拒否通知メッセージを送信していた。しかしながら、ルータＲｍは、例えば、コンテンツキャッシュ追加処理を実行して、コンテンツ保持ノードを増やした後、更に接続端末数が増加した場合に、紹介拒否通知メッセージを送信しても良い。また、ルータＲｍは、例えば、接続端末数が０より大きい所定数以下になったときに、紹介拒否解除通知メッセージを送信しても良い。また、ルータＲｍは、紹介拒否通知メッセージ及び紹介拒否解除通知メッセージを送信しなくても良い。

また、各ルータＲｍは、コンテンツキャッシュ領域にコンテンツを記憶させたり削除させたりした都度、コンテンツの保存状況を示すメッセージを、Ｐ２Ｐ用ＤＮＳサーバＳＰに送信しても良い。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ルータＲｍから受信したメッセージに基づいて、検索結果キャッシュ領域に対してインデックス情報の追加や削除を行ったり、リクエスト受信リストのホルダ数を更新したりしても良い。また、この場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、Ｐ２ＰネットワークＰＷに参加しなくても良い。この場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ドメインに対応するコンテンツ保持ノードを自ら検索する必要がないからである。

また、上記実施形態においては、本発明のノード装置をルータに適用していた。しかしながら、本発明のノード装置を、例えば、プロキシサーバ、ロードバランサ、Ｗｅｂアクセラレータ等の、情報を中継する機能を有するネットワーク機器に適用しても良い。また、本発明のノード装置を、例えば、キャッシュサーバ、エッジサーバ等のサーバ装置に適用しても良い。

また、本発明の情報処理装置を、上記実施形態のＰ２Ｐ用ＤＮＳサーバＳＰと組織用ＤＮＳサーバＳＯとの両方の機能を兼ね備えたＤＮＳサーバに適用しても良い。この場合、本発明の問い合わせ装置は、ユーザ端末Ｔｍ−ｎとなる。

また、上記実施形態においては、オーバーレイネットワークに、ＤＨＴを利用したピアツーピアネットワークが適用されていたが、これに限られるものではない。例えば、他のピアツーピアシステム、または、オーバーレイネットワークを用いたシステムが適用されても良い。ＤＨＴを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。

１１ 制御部
１２ 記憶部
１３ 通信部
Ｒｍ ルータ
２１ 制御部
２２ 記憶部
２３ 通信部
ＳＰ Ｐ２Ｐ用ＤＮＳサーバ
ＳＯ 組織用ＤＮＳサーバ
ＳＳ センターサーバ
ＮＬｍ 拠点ネットワーク
ＮＳ 配信センターネットワーク
ＮＷ ネットワーク
ＰＷ Ｐ２Ｐネットワーク
Ｓ コンテンツ配信システム

上記課題を解決するために、請求項１に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置であって、問い合わせ元の問い合わせ装置から問い合わせされたドメイン名を示すドメイン情報を取得する取得手段と、前記取得手段により取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索手段と、前記検索手段による検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信手段と、前記検索手段により検索された前記所在情報を、前記ドメイン情報と対応付けて記憶する記憶手段と、前記取得手段により前記ドメイン情報が取得されたときに、前記取得手段により取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定手段と、を備え、前記送信手段は、前記判定手段により記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、前記検索手段は、前記判定手段により記憶されていないと判定されたとき、検索を行うことを特徴とする。

請求項６に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置による情報処理方法であって、問い合わせ元の問い合わせ装置から問い合わせされたドメイン名を示すドメイン情報を取得する取得ステップと、前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、を含み、前記送信ステップにおいては、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、前記検索ステップにおいては、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うことを特徴とする。

請求項７に記載の発明は、ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、コンテンツの取得先のドメイン名を解決する情報処理装置に含まれるコンピュータに、問い合わせ元の問い合わせ装置から問い合わせされたドメイン名を示すドメイン情報を取得する取得ステップと、前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、を実行させ、前記送信ステップを、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信するように実行させ、前記検索ステップを、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うように実行させることを特徴とする。

Claims (7)

1. ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、
   コンテンツの取得先のドメイン名を解決する情報処理装置であって、
   問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得手段と、
   前記取得手段により取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索手段と、
   前記検索手段による検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信手段と、
   前記検索手段により検索された前記所在情報を、前記ドメイン情報と対応付けて記憶する記憶手段と、
   前記取得手段により前記ドメイン情報が取得されたときに、前記取得手段により取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定手段と、
   を備え、
   前記送信手段は、前記判定手段により記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、
   前記検索手段は、前記判定手段により記憶されていないと判定されたとき、検索を行うことを特徴とする情報処理装置。
2. 前記ドメイン情報が示すドメイン名に対応するコンテンツを前記オーバーレイネットワークから検索する検索キーを示すキー情報であって、前記取得手段により取得された前記ドメイン情報に基づいて、前記検索キーを生成する生成手段を更に備え、
   前記生成手段により生成された前記キー情報に基づいて、前記検索手段は、前記キー情報に対応するコンテンツを前記オーバーレイネットワークから検索することを特徴とする請求項１に記載の情報処理装置。
3. 前記記憶手段に前記所在情報が記憶されてから所定の時間が経過したかを判定する第２判定手段を更に備え、
   前記送信手段は、前記第２判定手段により前記所定の時間が経過したと判定された前記所在情報を送信しないことを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記取得手段により前記ドメイン情報が取得された回数を示す回数情報を、前記ドメイン情報と対応付けて記憶する第２記憶手段と、
   前記第２記憶手段により記憶された前記回数情報が示す回数が、予め定められた所定値を超えたかを判定する第３判定手段と、
   前記第３判定手段により、前記第２記憶手段により記憶された前記回数情報が示す回数が前記所定値を超えたと判定された場合には、前記回数情報に対応する前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記複数のノード装置の何れかの前記ノード装置に保存させる指示を示す指示情報を、何れかの前記ノード装置に送信する第２送信手段と、
   を更に備えることを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. コンテンツを保存する前記ノード装置の数を示す数情報を前記ドメイン情報ごとに取得する第２取得手段と、
   前記所定値を決定する決定手段であって、前記第２取得手段により取得された前記数情報が示す数が多い前記ドメイン情報であるほど、大きい前記所定値を決定する決定手段と、
   を更に備え、
   前記第３判定手段は、前記第２記憶手段により記憶された前記回数情報が示す回数が、前記決定手段により決定された前記所定値を超えたかを判定することを特徴とする請求項４に記載の情報処理装置。
6. ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、
   コンテンツの取得先のドメイン名を解決する情報処理装置による情報処理方法であって、
   問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得ステップと、
   前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、
   前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、
   前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、
   前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、
   を含み、
   前記送信ステップにおいては、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信し、
   前記検索ステップにおいては、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うことを特徴とする情情報処理方法。
7. ネットワークに接続される複数のノード装置によりオーバーレイネットワークが構成され、前記複数のノード装置にコンテンツが分散保存される情報通信システムにおいて、
   コンテンツの取得先のドメイン名を解決する情報処理装置に含まれるコンピュータに、
   問い合わせ元の問い合わせ装置から問い合わせされたドンメイン名を示すドメイン情報を取得する取得ステップと、
   前記取得ステップにおいて取得された前記ドメイン情報が示すドメイン名に対応するコンテンツを、前記オーバーレイネットワークにより検索する検索ステップと、
   前記検索ステップによる検索結果として、前記ドメイン情報が示すドメイン名に対応するコンテンツを保存する前記ノード装置の所在を示す所在情報を、前記問い合わせ装置に送信する送信ステップと、
   前記検索ステップにおいて検索された前記所在情報を、前記ドメイン情報と対応付けて記憶手段に記憶させる記憶ステップと、
   前記取得ステップにおいて前記ドメイン情報が取得されたときに、前記取得ステップにおいて取得された前記ドメイン情報に対応する前記所在情報が、前記記憶手段により記憶されているか否かを判定する判定ステップと、
   を実行させ、
   前記送信ステップを、前記判定ステップにおいて記憶されていると判定されたとき、前記取得された前記ドメイン情報に対応する前記所在情報を前記問い合わせ装置に送信するように実行させ、
   前記検索ステップを、前記判定ステップにおいて記憶されていないと判定されたとき、検索を行うように実行させることを特徴とする情報処理プログラム。

Images