(57)【要約】【課題】ＤＮＳをＣＤＮに適用したシステムにおいて、コンテンツの配信負荷を分散させる。【解決手段】ドメイン名を構成するドメインのレベルごとのラベルであり、所定のドメインを示すラベルとサブドメインまたはホストを示すラベルのうち、取得対象としてドメイン名に対するコンテンツを識別するラベルであるコンテンツラベルと、を含む複数のラベルにより構成されるドメイン名を、解決を問い合わせる問い合わせ装置から受信し、コンテンツラベルを示すラベル情報と、ノード装置の所在を示す所在情報と、を対応付けて記憶し、コンテンツ配信システムの利用状況を示す利用情報を取得し、取得された利用情報に基づいて、コンテンツ配信システムの利用状況に応じて、ラベル情報と所在情報との対応付けを更新し、受信されたドメイン名に含まれるコンテンツラベルを示すラベル情報に対応付けられた所在情報を、問い合わせ装置に送信する。【選択図】図４
2012118708.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続される複数のノード装置にコンテンツが分散保存され、前記複数のノード装置により構成されるオーバーレイネットワークからコンテンツが配信されるコンテンツ配信システムにおいて、
コンテンツの取得先のドメイン名を解決する情報処理装置であって、
前記ドメイン名を構成するドメインのレベルごとのラベルであり、所定のドメインを示すラベルと、前記所定のドメインに含まれるサブドメインまたはホストを示すラベルのうち、取得対象として前記ドメイン名に対応するコンテンツを識別するラベルであるコンテンツラベルと、を含む複数のラベルにより構成されるドメイン名を、解決を問い合わせる問い合わせ装置から受信する受信手段と、
前記コンテンツラベルを示すラベル情報と、前記ノード装置の所在を示す所在情報と、を対応付けて記憶する記憶手段と、
前記コンテンツ配信システムの利用状況を示す利用情報を取得する取得手段と、
前記取得手段により取得された前記利用情報に基づいて、前記コンテンツ配信システムの利用状況に応じて、前記記憶手段に記憶された前記ラベル情報と前記所在情報との対応付けを更新する更新手段と、
前記受信手段により受信されたドメイン名に含まれる前記コンテンツラベルを示す前記ラベル情報に対応付けられた前記所在情報を、前記問い合わせ装置に送信する送信手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
前記記憶手段は、前記所在情報と対応付ける前記コンテンツラベルの範囲を示す範囲情報としての前記ラベル情報と、少なくとも１つの前記所在情報と、を対応付けて記憶し、
前記取得手段は、前記オーバーレイネットワークに参加してきた前記ノード装置の所在を示す前記所在情報を、前記利用情報として取得し、
前記更新手段は、
前記取得手段により取得された前記所在情報を対応付ける前記範囲情報を決定する決定手段と、
前記決定手段により決定された前記範囲情報に対応付けられている前記所在情報の数が予め設定された数以上であるかを判定する第１判定手段と、
前記第１判定手段により予め設定された数以上であると判定された場合には、前記決定手段により決定された前記範囲情報が示す範囲を複数の範囲に分割し、前記決定手段により決定された前記範囲情報に対応付けられていた各前記所在情報を、それぞれ前記複数の範囲のうち何れかの範囲を示す前記範囲情報に対応付ける分割手段と、
前記分割手段により分割された前記複数の範囲のうち何れかの範囲を示す前記範囲情報に対応付けて、前記取得手段により取得された前記所在情報を前記記憶手段に記憶させる追加手段と、
を備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記記憶手段は、前記所在情報と対応付ける前記コンテンツラベルの範囲を示す範囲情報としての前記ラベル情報と、少なくとも１つの前記所在情報と、を対応付けて記憶し、
前記取得手段は、前記オーバーレイネットワークから離脱した前記ノード装置の所在を示す前記所在情報を、前記利用情報として取得し、
前記更新手段は、
前記取得手段により取得された前記所在情報の、前記範囲情報との対応付けを削除する削除手段と、
前記削除手段により前記所在情報との対応付けが削除された前記範囲情報に対応付けられている前記所在情報の数が予め設定された数以下であるかを判定する第２判定手段と、
前記第２判定手段により予め設定された数以下であると判定された場合には、前記削除手段により前記所在情報との対応付けが削除された前記範囲情報と、他の何れかの前記範囲情報と、を統合する統合手段と、
を備えることを特徴とする請求項１または請求項２に記載の情報処理装置。
【請求項４】
前記取得手段は、前記受信手段により前記ドメイン名を受信した受信数を示す数情報を前記利用情報として、前記ラベル情報ごとに取得し、
前記取得手段により取得された前記数情報に基づいて、前記更新手段は、前記受信数が多い前記ラベル情報に、何れかの前記ノード装置の所在を示す前記所在情報を対応付けることを特徴とする請求項１乃至３の何れか１項に情報処理装置。
【請求項５】
前記取得手段は、前記ノード装置のコンテンツの保存状況を示す保存情報を、前記利用情報として取得し、
前記取得手段により取得された前記保存情報に基づいて、前記更新手段は、前記ノード装置が多く保存するコンテンツに対応する前記コンテンツラベルを示す前記ラベル情報に、前記保存情報が保存状況を示す前記ノード装置の所在を示す前記所在情報を対応付けることを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
【請求項６】
ネットワークに接続される複数のノード装置にコンテンツが分散保存され、前記複数のノード装置により構成されるオーバーレイネットワークからコンテンツが配信されるコンテンツ配信システムにおいて、
コンテンツの取得先のドメイン名を解決する情報処理装置における情報処理方法であって、
前記ドメイン名を構成するドメインのレベルごとのラベルであり、所定のドメインを示すラベルと、前記所定のドメインに含まれるサブドメインまたはホストを示すラベルのうち、取得対象として前記ドメイン名に対応するコンテンツを識別するラベルであるコンテンツラベルと、を含む複数のラベルにより構成されるドメイン名を、解決を問い合わせる問い合わせ装置から受信する受信ステップと、
前記コンテンツ配信システムの利用状況を示す利用情報を取得する取得ステップと、
前記取得ステップにおいて取得された前記利用情報に基づいて、前記コンテンツ配信システムの利用状況に応じて、前記コンテンツラベルを示すラベル情報と、前記ノード装置の所在を示す所在情報と、を対応付けて記憶する記憶手段に記憶された前記ラベル情報と前記所在情報との対応付けを更新する更新ステップと、
前記受信ステップにおいて受信されたドメイン名に含まれる前記コンテンツラベルを示す前記ラベル情報に対応付けられた前記所在情報を、前記問い合わせ装置に送信する送信ステップと、
を有することを特徴とする情報処理方法。
【請求項７】
ネットワークに接続される複数のノード装置にコンテンツが分散保存され、前記複数のノード装置により構成されるオーバーレイネットワークからコンテンツが配信されるコンテンツ配信システムにおいて、
コンテンツの取得先のドメイン名を解決する情報処理装置に含まれるコンピュータを、
前記ドメイン名を構成するドメインのレベルごとのラベルであり、所定のドメインを示すラベルと、前記所定のドメインに含まれるサブドメインまたはホストを示すラベルのうち、取得対象として前記ドメイン名に対応するコンテンツを識別するラベルであるコンテンツラベルと、を含む複数のラベルにより構成されるドメイン名を、解決を問い合わせる問い合わせ装置から受信する受信ステップと、
前記コンテンツ配信システムの利用状況を示す利用情報を取得する取得ステップと、
前記取得ステップにおいて取得された前記利用情報に基づいて、前記コンテンツ配信システムの利用状況に応じて、前記コンテンツラベルを示すラベル情報と、前記ノード装置の所在を示す所在情報と、を対応付けて記憶する記憶手段に記憶された前記ラベル情報と前記所在情報との対応付けを更新する更新ステップと、
前記受信ステップにおいて受信されたドメイン名に含まれる前記コンテンツラベルを示す前記ラベル情報に対応付けられた前記所在情報を、前記問い合わせ装置に送信する送信ステップと、
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（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）ルーティングテーブルに基づいて他のノードとの間で各種メッセージを送受信できる状態にすることをいう。Ｐ２ＰネットワークＰＷへの参加は、参加していないノードが、参加している任意のノードに参加要求を示す参加メッセージを送信することによって行われる。参加メッセージを受信する側のノードを、「コンタクトノード」という。
【００３１】
Ｐ２ＰネットワークＰＷは、特定のアルゴリズム、例えば、ＤＨＴを利用したアルゴリズムにより実現される。そして、Ｐ２ＰネットワークＰＷに接続する各ノードには、所定桁数からなる固有の識別情報であるノードＩＤが割り当てられている。図１に示すＰ２ＰネットワークＰＷは、ノードＩＤのＩＤ空間をリング状のものとして示されている。そして、図１のリング状のＩＤ空間において示されている各ノードの位置は、それぞれのノードＩＤに対応している。
【００３２】
各ノードは、それぞれ、ＤＨＴを用いたルーティングテーブルを保持している。ルーティングテーブルは、Ｐ２ＰネットワークＰＷ上における各種メッセージの転送先を規定している。具体的に、ルーティングテーブルには、ＩＤ空間内で適度に離れたノードのノードＩＤ、ＩＰアドレス及びポート番号を含むノード情報が複数登録されている。なお、ルーティングテーブルを用いたＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００３３】
Ｐ２ＰネットワークＰＷにおいては、内容の異なる様々なコンテンツが複数のノードに分散して保存される。コンテンツとしては、例えば、画像データ、動画データ、音声データ、テキストデータ、電子文書、ＨＴＭＬ（HyperText Markup Language）文書等が挙げられる。これらのコンテンツのうち、ＨＴＭＬ文書は、ＷｅｂサーバＳＷが保存している。ＨＴＭＬ文書以外のコンテンツは、各ノードに分散して保存される。以下、コンテンツを保存するノードを、「コンテンツ保持ノード」という。各コンテンツには、それぞれコンテンツごとに固有の識別情報であるコンテンツＩＤが割り当てられている。コンテンツＩＤは、例えば、コンテンツのＵＲＬ（Uniform Resource Locator）が共通のハッシュ関数によりハッシュ化されて生成される。
【００３４】
複数のノードに分散保存されているコンテンツの所在は、インデックス情報として、コンテンツの所在を管理または記憶しているノードにより記憶される。コンテンツの所在を管理しているノードを、「ルートノード」という。インデックス情報は、コンテンツを保存したノードのノード情報と、コンテンツのコンテンツＩＤと等の組を含む。このようなルートノードは、例えば、コンテンツＩＤと最も近いノードＩＤを有するノードであるように定められる。コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。
【００３５】
そして、あるノードが、あるコンテンツを取得しようとする場合、そのノードは、検索メッセージを送信する。以下、コンテンツを取得しようとするノードを、「ユーザノード」という。検索メッセージは、取得対象のコンテンツのコンテンツＩＤ及びユーザノードのＩＰアドレス等を含む。検索メッセージは、コンテンツ保持ノードを検索するためのメッセージである。ユーザノードは、ユーザノードが記憶するルーティングテーブルに従って、他のノードに送信する。これにより、検索メッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによって最終的にルートノードに到着することになる。
【００３６】
検索メッセージを受信したルートノードは、これに含まれるコンテンツＩＤに対応するインデックス情報を、ユーザノードに送信する。ユーザノードは、受信したインデックス情報に含まれるＩＰアドレス及びポート番号に基づいて、何れかのコンテンツ保持ノードに、コンテンツＩＤを含むコンテンツ要求メッセージを送信する。コンテンツ保持ノードは、受信したコンテンツ要求メッセージに含まれるコンテンツＩＤに対応するコンテンツを、ユーザノードにアップロードまたは送信する。こうして、ユーザノードは、コンテンツをダウンロードまたは取得することができる。コンテンツを取得して保存したユーザノードは、そのコンテンツの新たなコンテンツ保持ノードとなる。
【００３７】
［２．ユーザ端末へのコンテンツの配信］
次に、コンテンツ配信システムＳにおけるユーザ端末Ｔｎ−ｌへのコンテンツの配信について説明する。先ず、本実施形態においてＤＮＳに関して用いられる用語について説明する。ドメインは、ネットワーク上のホストをグループ化したものを示す。ドメイン名は、このホストのグループを識別するための名前である。本実施形態において、「ドメイン名」は、ＦＱＤＮ（Fully Qualified Domain Name）を意味する。例えば、コンテンツのＵＲＬが「http://0123.xxxxx.yy.zz/image/image01.jpeg」であったとする。この場合、「//」の直後の文字から最初に「/」が出現する直前の文字までの文字列である「0123.xxxxx.yy.zz」の部分がドメイン名である。ドメイン名を構成する各レベルのドメインの名前、すなわち、ピリオドで区切られた各名前を、「ラベル」という。例えば、ドメイン名が「xxxxx.yy.zz」であるとする。この場合、「zz」は、トップレベルドメインを示すラベルである。また、「yy」は、セカンドレベルドメインを示すラベルである。また、「xxxxx」は、サードレベルドメインを示すラベルである。あるドメインに含まれるホストを更にグループ化したものを、そのドメインに対して、「サブドメイン」という。例えば、「yy.zz」が示すドメインは、「zz」が示すドメインのサブドメインである。また、「xxxxx.yy.zz」が示すドメインは、「yy.zz」が示すドメインのサブドメインであるとともに、「zz」が示すドメインのサブドメインでもある。つまり、「zz」が示すドメインに含まれるドメインは、全て「zz」が示すドメインのサブドメインである。特定のホストを示すドメイン名を、特に「ホスト名」という。あるドメインに含まれるホストのホスト名は、そのドメインのドメイン名に、１つ以上のラベルが付加されたもので示される。例えば、「xxxxx.yy.zz」が示すドメインにおいて、「0123」というラベルで識別されるホストのホスト名は、「0123.xxxxx.yy.zz」となる。よって、ホスト名は、ホストが属するドメインのドメイン名を含んでいる。
【００３８】
コンテンツ配信システムＳには、コンテンツを配信するためのドメイン名が割り当てられている。例えば、コンテンツ配信システムＳには、「xxxxx.yy.zz」というドメイン名が割り当てられている。なお、コンテンツ配信システムＳに対応するドメインを、「コンテンツ配信ドメイン」という。コンテンツ配信ドメインを示すドメイン名が「xxxxx.yy.zz」である。ここで、「xxxxx」は、「yy.zz」が示すドメインに含まれるサブドメインのうち、コンテンツ配信ドメインを示すラベルである。なお、コンテンツ配信ドメインを示すラベルは、本発明における所定のドメインを示すラベルの一例である。
【００３９】
ＷｅｂサーバＳＷ、Ｐ２Ｐ用ＤＮＳサーバＳＰ及び各ノードは、コンテンツ配信ドメインに含まれるホストである。従って、ＷｅｂサーバＳＷ、Ｐ２Ｐ用ＤＮＳサーバＳＰ及び各ノードには、「xxxxx.yy.zz」というドメイン名に、１つ以上のラベルが付加されたものがホスト名として割り当てられる。例えば、ＷｅｂサーバＳＷには、「www.xxxxx.yy.zz」というホスト名が割り当てられている。また、Ｐ２Ｐ用ＤＮＳサーバＳＰには、「dns.xxxxx.yy.zz」というホスト名が割り当てられている。
【００４０】
各ノードには、「****.xxxxx.yy.zz」というホスト名が割り当てられる。ここで、最下位のレベルのドメインを示すラベル「****」は、コンテンツＩＤの上位４桁の値を示す数字である。以下、ノードに割り当てられるホスト名において、最下位のレベルのドメインを示すラベルを、「ホスト名ラベル」という。本実施形態においては、コンテンツＩＤを１６進数で示すものとする。従って、ホスト名ラベルは、0000からFFFFまでの値のうち何れかの値を示す数字である。なお、ホスト名ラベルは、本発明におけるコンテンツラベルの一例である。
【００４１】
なお、コンテンツＩＤに対応させるラベルは、最下位のレベルのドメインを示すラベルのみに限られるものではない。例えば、コンテンツ配信システムに含まれるサブドメインを示すラベルを、コンテンツＩＤに対応させても良い。例えば、「aaa.****.xxxxx.yy.zz」というホスト名において、「****」がサブドメインを示すラベルである。
【００４２】
コンテンツ配信ドメインに含まれるホストのホスト名とＩＰアドレスとの対応付けは、Ｐ２Ｐ用ＤＮＳサーバＳＰにより管理されている。つまり、Ｐ２Ｐ用ＤＮＳサーバＳＰは、コンテンツ配信ドメインのオーソリティである。各ノードに対するホスト名の割り当ては、ゾーン情報により定義されている。ゾーン情報は、Ｐ２Ｐ用ＤＮＳサーバＳＰにより記憶されている。そして、各ノードに対するホスト名の割り当ては、Ｐ２Ｐ用ＤＮＳサーバＳＰより動的に行われる。なお、ゾーン情報の詳細については後述する。
【００４３】
コンテンツ配信システムＳからユーザ端末Ｔｎ−ｌへ配信されるコンテンツのうち、ＨＴＭＬ文書には、「www.xxxxx.yy.zz」を含むＵＲＬが付与されている。また、ＨＴＭＬ文書以外のコンテンツには、「****.xxxxx.yy.zz」を含むＵＲＬが付与されている。
【００４４】
例えば、ユーザ端末Ｔ１−１を利用するユーザは、Ｗｅｂページを閲覧する場合、Ｗｅｂページを構成するＨＴＭＬ文書のＵＲＬ等を指定する。すると、ユーザ端末Ｔ１−１は、ＷｅｂサーバＳＷに対して、ＨＴＭＬ文書を要求するためのＨＴＴＰ（HyperText Transfer Protocol）リクエストを送信する。ＷｅｂサーバＳＷは、受信したＨＴＴＰリクエストに含まれるＵＲＬに対応するＨＴＭＬ文書をユーザ端末Ｔ１−１に送信する。なお、ＵＲＬに含まれるドメイン名「www.xxxxx.yy.zz」を解決するためのユーザ端末Ｔ１−１、ローカルＤＮＳサーバＳＬ、ＤＮＳサーバＳＤ及びＰ２Ｐ用ＤＮＳサーバＳＰの動作は、ＤＮＳにおける公知の動作と同様である。
【００４５】
ユーザ端末Ｔ１−１は、受信したＨＴＭＬ文書から、Ｗｅｂページを構成するコンテンツのＵＲＬを取得する。例えば、ユーザ端末Ｔ１−１は、「http://0123.xxxxx.yy.zz/image/image01.jpeg」という、画像データのＵＲＬを取得したとする。すると、ユーザ端末Ｔ１−１は、取得したＵＲＬに含まれるドメイン名として、「0123.xxxxx.yy.zz」を設定したＤＮＳ問い合わせメッセージを、ローカルＤＮＳサーバＳＬへ送信する。ＤＮＳ問い合わせメッセージは、ドメイン名の解決を問い合わせるためのメッセージである。
【００４６】
ローカルＤＮＳサーバＳＬは、受信したＤＮＳ問い合わせメッセージに含まれるドメイン名「0123.xxxxx.yy.zz」に対応するＩＰアドレスをキャッシュしていない場合、Ｐ２Ｐ用ＤＮＳサーバＳＰから「0123.xxxxx.yy.zz」に対応するＩＰアドレスを取得する。例えば、ＤＮＳにおける再帰モードでＩＰアドレスを取得する場合、ローカルＤＮＳサーバＳＬは、複数のＤＮＳサーバＳＤのうちルートネームサーバに、ＤＮＳ問い合わせメッセージを転送する。ルートネームサーバは、「zz」のオーソリティであるＤＮＳサーバＳＤに、ＤＮＳ問い合わせメッセージを転送する。「zz」のオーソリティであるＤＮＳサーバは、「yy.zz」のオーソリティであるＤＮＳサーバＳＤに、ＤＮＳ問い合わせメッセージを転送する。「yy.zz」のオーソリティであるＤＮＳサーバは、「xxxxx.yy.zz」のオーソリティであるＤＮＳサーバ、すなわち、Ｐ２Ｐ用ＤＮＳサーバＳＰに、ＤＮＳ問い合わせメッセージを転送する。
【００４７】
Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に基づいて、受信したＤＮＳ問い合わせメッセージに含まれる「0123.xxxxx.yy.zz」が割り当てられたノード、例えばノードＮ１のＩＰアドレスを、ＤＮＳサーバＳＤに返信する。ＤＮＳサーバＳＤに返信されたＩＰアドレスは、ＤＮＳ問い合わせメッセージの転送経路とは逆の経路で、ローカルＤＮＳサーバＳＬに転送される。なお、ＤＮＳにおける反復モードでＩＰアドレスを取得する場合、ローカルＤＮＳサーバＳＬは、「yy.zz」のオーソリティであるＤＮＳサーバから取得したＰ２Ｐ用ＤＮＳサーバＳＰのＩＰアドレスに基づいて、Ｐ２Ｐ用ＤＮＳサーバＳＰにＤＮＳ問い合わせメッセージを送信する。そして、ローカルＤＮＳサーバＳＬは、Ｐ２Ｐ用ＤＮＳサーバＳＰからノードのＩＰアドレスを受信する。ＩＰアドレスを取得したローカルＤＮＳサーバＳＬは、取得したＩＰアドレスを、ユーザ端末Ｔ１−１に送信する。
【００４８】
ユーザ端末Ｔ１−１は、受信したＩＰアドレスに基づいて、ＨＴＴＰリクエストをノードＮ１に送信する。このＨＴＴＰリクエストには、要求されるコンテンツのＵＲＬとして、「http://0123.xxxxx.yy.zz/image/image01.jpeg」が含まれる。このＵＲＬは、ＤＮＳにより解決されたドメイン名である「0123.xxxxx.yy.zz」を含む。つまり、「0123.xxxxx.yy.zz」は、要求されるコンテンツと対応する。ノードＮ１は、例えば、受信したＨＴＴＰリクエストに含まれるＵＲＬから、「http://0123.」を除いた「xxxxx.yy.zz/image/image01.jpeg」の部分を取得する。そして、ノードＮ１は、「xxxxx.yy.zz/image/image01.jpeg」のハッシュ値を計算することにより、要求されたコンテンツのコンテンツＩＤを計算する。次いで、ノードＮ１は、コンテンツＩＤに対応するコンテンツを保存している場合には、そのコンテンツをユーザ端末Ｔ１−１へ送信する。一方、ノードＮ１は、コンテンツＩＤに対応するコンテンツを保存していない場合には、Ｐ２ＰネットワークＰＷからコンテンツを取得する。つまり、ノードＮ１は、コンテンツＩＤに対応するコンテンツを保存しているコンテンツ保持ノードからコンテンツを取得する。そして、ノードＮ１は、取得したコンテンツをユーザ端末Ｔ１−１へ送信する。
【００４９】
［３．ゾーン情報の詳細］
次に、図２を参照して、ゾーン情報の詳細について説明する。図２（ａ）は、ゾーン情報に設定される内容の一例を示す図である。ゾーン情報は、Ｐ２Ｐ用ＤＮＳサーバＳＰが、受信したドメイン名に対応してどのＩＰアドレスを返信するかを示す情報である。
【００５０】
図２（ａ）に示すように、ゾーン情報は、クラス化ホスト名と、ノードのＩＰアドレスと、が対応付けて格納されるレコードを複数含む。クラス化ホスト名は、ノードのＩＰアドレスに対応付けられるホスト名ラベルの範囲を示す情報である。例えば、図２（ａ）においては、ホスト名ラベルの先頭一文字、すなわちコンテンツＩＤの上位一桁の数字が設定されている。例えば、クラス化ホスト名としての「0」は、ホスト名ラベルの範囲が「0000」から「0FFF」までの範囲であることを示す。ノードのＩＰアドレスは、１つのレコードに１または複数格納される。例えば、図２（ａ）においては、クラス化ホスト名「0」に対応付けて、ＩＰアドレス１及びＩＰアドレス２が格納されている。従って、Ｐ２Ｐ用ＤＮＳサーバＳＰは、「0000」から「0FFF」までの何れかのホスト名ラベルを含むドメイン名を受信した場合、ＩＰアドレス１及びＩＰアドレス２を返信する。図２（ａ）においては、クラス化ホスト名として、「0」、「1」、「2」・・・「F」が、それぞれレコードに格納されている。なお、クラス化ホスト名は、本発明における範囲情報の一例である。また、ノードのＩＰアドレスは、本発明における所在情報の一例である。
【００５１】
なお、ゾーン情報において、ノードのＩＰアドレスと対応付ける情報を、ホスト名ラベルの範囲を示す情報としなくても良い。例えば、ノードと対応付ける情報を、ホスト名ラベルそのものとしても良い。この場合、各ホスト名ラベルにノードのＩＰアドレスを対応付けるため、１台のノードのＩＰアドレスが、複数のホスト名ラベルに対応付けられても良い。また、複数のノードのＩＰアドレスが、１つのホスト名ラベルに対応付けられても良い。この場合のホスト名ラベルは、本発明におけるラベル情報の一例である。
【００５２】
Ｐ２Ｐ用ＤＮＳサーバＳＰは、ノードまたはユーザ端末Ｔｎ−ｌによるコンテンツ配信システムＳの利用状況に応じて、ゾーン情報に含まれるクラス化ホスト名とノードのＩＰアドレスとの対応付けを更新する。
【００５３】
このとき、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名とノードのＩＰアドレスとの対応付けが適切となるように、この対応付けを更新する。例えば、ＤＮＳ問い合わせメッセージに対して、特定のノードのＩＰアドレスの返信回数が、他のノードのＩＰアドレスの返信回数に比して極端に多かったとする。すると、特定のノードにユーザ端末Ｔｎ−ｌからのＨＴＴＰリクエストが集中する。従って、コンテンツの配信の負荷が特定のノードに集中する。これは、クラス化ホスト名とノードのＩＰアドレスとの対応付けが適切になされていないことを意味する。適切な対応付けとは、コンテンツの配信の負荷が特定のノードに集中しないような対応付けである。
【００５４】
ノードによるコンテンツ配信システムＳの利用状況の一例としては、ノードによるＰ２ＰネットワークＰＷの参加状況が挙げられる。ノードは、Ｐ２ＰネットワークＰＷに参加することにより、コンテンツ配信システムＳを利用することになるからである。また、ノードによるコンテンツ配信システムＳの利用状況の他の一例としては、ノードが保存したコンテンツの保存状況が挙げられる。ノードは、Ｐ２ＰネットワークＰＷに参加することにより、他のノードからコンテンツを取得して保存したり、保存したコンテンツを削除したりするからである。
【００５５】
ユーザ端末Ｔｎ−ｌによるコンテンツ配信システムＳの利用状況の一例としては、ユーザ端末Ｔｎ−ｌによるＰ２ＰネットワークＰＷからのコンテンツの取得頻度が挙げられる。コンテンツの取得頻度の一例として、Ｐ２Ｐ用ＤＮＳサーバＳＰにおけるＤＮＳ問い合わせメッセージの受信頻度が挙げられる。ユーザ端末Ｔｎ−ｌは、Ｐ２ＰネットワークＰＷからコンテンツを取得するために、コンテンツの取得先であるノードのＩＰアドレスを、ローカルＰ２ＰサーバＳＬを介してＰ２Ｐ用ＤＮＳサーバＳＰから取得する。そのため、ユーザ端末Ｔｎ−ｌによるコンテンツの取得頻度が高くなると、Ｐ２Ｐ用ＤＮＳサーバＳＰによるＤＮＳ問い合わせメッセージの受信頻度も高くなる。
【００５６】
先ず、ノードがＰ２ＰネットワークＰＷに参加してきたときのゾーン情報の更新について説明する。図２（ｂ）及び図２（ｃ）は、それぞれＰ２ＰネットワークＰＷにノードが参加してきたことに応じて更新されたゾーン情報の内容の一例を示す図である。コンタクトノードは、Ｐ２ＰネットワークＰＷに参加するノードから参加メッセージを受信すると、参加するノードのＩＰアドレスを含む新規ノード追加メッセージをＰ２Ｐ用ＤＮＳサーバＳＰに送信する。新規ノード追加メッセージに含まれるノードのＩＰアドレスは、本発明における利用情報の一例である。Ｐ２Ｐ用ＤＮＳサーバＳＰは、受信した新規ノード追加メッセージに含まれるＩＰアドレスをゾーン情報に追加する。ここで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に追加するＩＰアドレスを対応付けるクラス化ホスト名を決定する。なお、ＩＰアドレスを対応付けるクラス化ホスト名の決定方法については後述する。
【００５７】
例えば、参加してきたノードのＩＰアドレスがＩＰアドレス８であるとする。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、対応付けるクラス化ホスト名を「2」と決定したとする。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、図２（ｂ）に示すように、ＩＰアドレス８をクラス化ホスト名「2」に対応付けて追加設定する。
【００５８】
また、ＩＰアドレスを対応付けると決定されたクラス化ホスト名に既に対応付けられているＩＰアドレスの個数が、予め設定された閾値Ａ以上である場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、そのクラス化ホスト名を分割する。クラス化ホスト名の分割とは、そのクラス化ホスト名が示すホスト名ラベルの範囲を複数の範囲に分割することにより、１つクラス化ホスト名を複数のクラス化ホスト名に分けることである。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名の分割に伴い、ゾーン情報に含まれるレコードを分割する。閾値Ａの値は任意であるが、例えば、ＤＮＳのプロトコルにおいて、ＤＮＳ問い合わせメッセージの応答として一度に返信することができるＩＰアドレスの個数の上限値を閾値Ａとしても良い。
【００５９】
例えば、閾値Ａ＝２であるとする。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、参加するノードのＩＰアドレスと対応付けるクラス化ホスト名を「3」と決定したとする。図２（ａ）に示すように、クラス化ホスト名「3」には、既にＩＰアドレス５及びＩＰアドレス６という２個のＩＰアドレスが対応付けられている。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名「3」が示す「3000」から「3FFF」までのホスト名ラベルの範囲を、例えば、「3000」から「37FF」までの範囲と、「3800」から「3FFF」までの範囲と、に分割する。
【００６０】
具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、図２（ｃ）に示すように、ゾーン情報に設定されているクラス化ホスト名「3」を、「30-37」に書き換える。クラス化ホスト名「30-37」は、ホスト名ラベルの先頭二文字が「30」から「37」までの何れかであることを示す。つまり、クラス化ホスト名「30-37」は、ホスト名ラベルの範囲が「3000」から「37FF」までの範囲であることを示す。これにより、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名「3」に対応付けられていたＩＰアドレス５及びＩＰアドレス６を、クラス化ホスト名「30-37」に対応付ける。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に新たなレコードを追加する。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、追加したレコードに、クラス化ホスト名「38-3F」を設定する。クラス化ホスト名「38-3F」は、ホスト名ラベルの先頭二文字が「38」から「3F」までの何れかであることを示す。つまり、クラス化ホスト名「38-3F」は、ホスト名ラベルの範囲が「3800」から「3FFF」までの範囲であることを示す。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、追加したレコードに、参加してきたノードのＩＰアドレス８を追加する。これにより、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＩＰアドレス８をクラス化ホスト名「38-3F」に対応付ける。
【００６１】
なお、ホスト名ラベルの範囲を分割するときの分割数は３つ以上であっても良い。また、ホスト名ラベルの範囲の分割割合は等分ではなくても良い。また、ホスト名ラベルの範囲の分割対象とされたクラス化ホスト名に既に対応付けられているＩＰアドレス及び参加するノードのＩＰアドレスを、それぞれ分割された複数のクラス化ホスト名のうちどのクラス化ホスト名に対応付けるかは任意である。
【００６２】
ここで、ＩＰアドレスを対応付けるクラス化ホスト名の決定方法について説明する。Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に含まれるクラス化ホスト名のうち、対応付けられたＩＰアドレスを単位時間あたりに返信した回数が最も多いクラス化ホスト名に、参加してきたノードのＩＰアドレスを対応付けると決定する。つまり、Ｐ２Ｐ用ＤＮＳサーバＳＰは、単位時間あたりにおけるＤＮＳ問い合わせメッセージの受信回数が最も多いクラス化ホスト名に、ＩＰアドレスを対応付ける。この単位時間あたりにおけるＤＮＳ問い合わせメッセージの受信回数を、「単位時間あたり問い合わせ回数」という。Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＤＮＳ問い合わせメッセージを受信する都度、対応する単位時間あたり問い合わせ回数を更新する。
【００６３】
ユーザ端末Ｔｎ−ｌによるコンテンツの取得頻度が高いコンテンツを保存するノードは、そのコンテンツを配信するための処理負荷も高くなる。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、単位時間あたり問い合わせ回数が最も多いクラス化ホスト名に、参加してきたノードのＩＰアドレスを対応付けると決定する。これにより、コンテンツ配信の負荷が適切に分散される。
【００６４】
なお、Ｐ２Ｐ用ＤＮＳサーバＳＰは、各単位時間あたり問い合わせ回数を、それぞれ対応するクラス化ホスト名に対応付けられているノードのＩＰアドレスの個数で除算しても良い。これにより、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ノード１台あたりの単位時間あたり問い合わせ回数を計算しても良い。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ノード１台あたりの単位時間あたり問い合わせ回数が最も多いクラス化ホスト名に、ＩＰアドレスを対応付けると決定しても良い。
【００６５】
また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に含まれるクラス化ホスト名のうち、参加してきたノードが最も多く保存しているコンテンツに対応するクラス化ホスト名を特定する。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、特定したクラス化ホスト名に、参加してきたノードのＩＰアドレスを対応付けると決定する。ユーザ端末Ｔｎ−ｌから要求されたコンテンツをノードが保存している場合、ノードは、要求元のユーザ端末Ｔｎ−ｌにコンテンツを送信するためにオーバーレイネットワークを介して他のノードからコンテンツを取得する必要がない。過去にＰ２Ｐ用ＤＮＳサーバＳＰに参加したことがあるノードは、何らかのコンテンツを保存している可能性がある。そして、ノードが多く保存しているコンテンツに対応するクラス化ホスト名と、そのノードのＩＰアドレスが対応付けられる。これにより、ユーザ端末Ｔｎ−ｌが取得するコンテンツを保存している可能性が高いノードのＩＰアドレスを、Ｐ２Ｐ用ＤＮＳサーバＳＰが返信する。従って、ユーザ端末Ｔｎ−ｌは、取得しようとするコンテンツを保存している可能性が高いノードにＨＴＴＰリクエストを送信する。そのため、ノード間のコンテンツの送受信が減るので、ノードの処理負荷を軽減させることができる。
【００６６】
このような決定を行うため、Ｐ２Ｐ用ＤＮＳサーバＳＰは、参加してきたノードのコンテンツの保存状況を取得する。Ｐ２ＰネットワークＰＷに参加するノードは、そのノードが保存しているコンテンツの個数を計算する。この計算は、コンテンツＩＤの上位１桁の値が同一であるコンテンツごとに行われる。具体的に、ノードは、例えば、コンテンツＩＤの上位１桁の値が「1」であるコンテンツの個数を計算する。次に、ノードは、コンテンツＩＤの上位１桁の値が「2」であるコンテンツの個数を計算する。このように、ノードは、コンテンツＩＤの上位１桁の値が小さい順に、コンテンツの個数を計算する。そして、ノードは、コンテンツＩＤの上位１桁の値が「F」であるコンテンツの個数を計算する。ノードは、保存しているコンテンツの個数が最も多いコンテンツＩＤの上位１桁の値を示す数字を、コンテンツの保存状況を示すコンテンツ保存情報とする。コンテンツ保存情報の形式は、クラス化ホスト名の形式と一致する。ノードは、コンテンツ保存情報を含む参加メッセージを、コンタクトノードに送信する。コンタクトノードは、受信した参加メッセージからコンテンツ保存情報を取得する。そして、コンタクトノードは、取得したコンテンツ保存情報を含む新規ノード追加メッセージを、Ｐ２Ｐ用ＤＮＳサーバＳＰに送信する。Ｐ２Ｐ用ＤＮＳサーバＳＰは、受信した新規ノード追加メッセージに含まれるコンテンツ保存情報と一致するクラス化ホスト名を特定する。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、特定したクラス化ホスト名に、参加してきたノードのＩＰアドレスを対応付けると決定する。なお、コンテンツ保存情報は、本発明における保存情報の一例である。
【００６７】
なお、ノードはＰ２ＰネットワークＰＷに新規参加する場合、コンテンツを１つも保存していない場合がある。その場合、ノードは、参加メッセージにコンテンツ保存情報を含めない。この場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、上述した単位時間あたり問い合わせ回数に基づいて決定を行う。
【００６８】
次に、ノードがＰ２ＰネットワークＰＷから離脱したときのゾーン情報の更新について説明する。図２（ｄ）及び図２（ｅ）は、ノードがＰ２ＰネットワークＰＷから離脱したことに応じて更新されたゾーン情報の内容の一例を示す図である。Ｐ２ＰネットワークＰＷからの離脱とは、Ｐ２ＰネットワークＰＷに参加していたノードが他のノードと通信することができない状態になったことをいう。ノードが他のノードと通信することができない状態になる場合としては、例えば、ノードの電源がＯＦＦになった場合がある。また、ノードは、ルーティングテーブルを用いて他のノードと通信を行うためのＰ２Ｐプログラムを実行することにより、Ｐ２ＰネットワークＰＷに参加する。管理者の操作によって、ノードがＰ２Ｐプログラムの実行を終了させた場合も、ノードが他のノードと通信することができない状態になる場合の一例である。
【００６９】
Ｐ２Ｐ用ＤＮＳサーバＳＰは、定期的に、ゾーン情報にＩＰアドレスが設定されている各ノードの生存確認を行う。ノードが生存しているとは、Ｐ２ＰネットワークＰＷに参加しているノードがＰ２ＰネットワークＰＷから離脱していないことをいう。そして、生存確認とは、ノードがＰ２ＰネットワークＰＷから離脱していないことを確認することをいう。具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報に設定されているＩＰアドレスに基づいて、生存確認の要求を示す生存確認メッセージをノードに送信する。生存確認要求メッセージを受信したノードは、Ｐ２ＰネットワークＰＷから離脱していないことを示す生存確認応答メッセージをＰ２Ｐ用ＤＮＳサーバＳＰに送信する。ここで、Ｐ２ＰネットワークＰＷから離脱しているノードは生存確認応答メッセージを送信することができない。そこで、生存確認要求メッセージを送信してから所定時間が経過しても送信先のノードから生存確認応答メッセージが受信されなかった場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、そのノードはＰ２ＰネットワークＰＷから離脱したと判定する。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、離脱したノードのＩＰアドレスのクラス化ホスト名との対応付けを、ゾーン情報から削除する。なお、離脱したノードのＩＰアドレスとして、Ｐ２Ｐ用ＤＮＳサーバＳＰがゾーン情報から取得したＩＰアドレスは、本発明における利用情報の一例である。
【００７０】
例えば、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ＩＰアドレス６に対応するノードが離脱したと判定したとする。すると、Ｐ２Ｐ用ＤＮＳサーバＳＰは、図２（ｄ）に示すように、クラス化ホスト名「3」に対応付けられているＩＰアドレス６をゾーン情報から削除する。これにより、ＩＰアドレス６とクラス化ホスト名「3」との対応付けが削除される。そして、クラス化ホスト名「3」には、ＩＰアドレス５のみが対応付けられる。
【００７１】
また、ＩＰアドレスが削除されたクラス化ホスト名「3」にまだ対応付けられているＩＰアドレスの個数が、予め設定された閾値Ｂ以下である場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、そのクラス化ホスト名を、他のクラス化ホスト名と統合する。クラス化ホスト名の統合とは、複数のクラス化ホスト名がそれぞれ示すホスト名ラベルの範囲を統合することにより、複数のクラス化ホスト名を１つのクラス化ホスト名にすることをいう。そして、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名の統合に伴い、ゾーン情報に含まれるレコードを統合する。なお閾値Ｂの値は任意である。
【００７２】
例えば、閾値Ｂ＝０であるとする。また、削除されるＩＰアドレスがＩＰアドレス４であるとする。この場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名「2」に対応付けられているＩＰアドレス４をゾーン情報から削除する。すると、クラス化ホスト名「2」に対応付けられているＩＰアドレスは存在しない。そこで、Ｐ２Ｐ用ＤＮＳサーバＳＰは、例えば、クラス化ホスト名「2」と「1」とを統合する。
【００７３】
具体的に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、図２（ｃ）に示すように、ゾーン情報に設定されているクラス化ホスト名「1」を「1-2」に書き換える。クラス化ホスト名「1-2」は、ホスト名ラベルの先頭一文字が「1」または「2」の何れかであることを示す。つまり、クラス化ホスト名「1-2」は、ホスト名ラベルの範囲が「1000」から「2FFF」までの範囲であることを示す。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、クラス化ホスト名「2」が格納されていたレコードをゾーン情報から削除する。これにより、クラス化ホスト名「1」に対応付けられていたＩＰアドレス３は、クラス化ホスト名「1-2」に対応付けられる。
【００７４】
なお、閾値Ｂが１以上に設定されている場合、削除されるレコードには、まだＩＰアドレスが格納されていることになる。その場合、Ｐ２Ｐ用ＤＮＳサーバＳＰは、削除されるレコードに格納されているＩＰアドレスを、統合先のレコードに格納する。また、ＩＰアドレスが削除されたクラス化ホスト名を、どのクラス化ホスト名と統合するかは任意である。また、統合後のクラス化ホスト名が示すホスト名ラベルの範囲が連続していなくても良い。
【００７５】
また、ゾーン情報の更新のタイミングは、ノードがＰ２ＰネットワークＰＷに参加したときや離脱したときのみに限られるものではない。例えば、Ｐ２Ｐ用ＤＮＳサーバＳＰは、ゾーン情報におけるクラス化ホスト名とＩＰアドレスとの対応付けを、定期的に更新しても良い。
【００７６】
［４．Ｐ２Ｐ用ＤＮＳサーバの構成］
次に、図３を参照して、Ｐ２Ｐ用ＤＮＳサーバＳＰの構成及び機能について説明する。図３は、Ｐ２Ｐ用ＤＮＳサーバＳＰの概要構成例を示す図である。
【００７７】
Ｐ２Ｐ用ＤＮＳサーバＳＰは、図３に示すように、制御部１１を備えている。制御部１１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成される。また、Ｐ２Ｐ用ＤＮＳサーバＳＰは、記憶部１２を備えている。記憶部１２は、各種データ及び各種プログラム等を記憶保存するためのＨＤ等から構成される。更に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、通信部１３を備えている。通信部１３は、Ｐ２Ｐ用ＤＮＳサーバＳＰは、配信センターネットワークＮＳ等を通じてＤＮＳサーバＳＤやローカルＤＮＳサーバＳＬ等との間の情報の通信制御を行う。また更に、Ｐ２Ｐ用ＤＮＳサーバＳＰは、表示部１４を備えている。表示部１４は、各種情報を表示するＣＲＴ，液晶ディスプレイ等である。更にまた、Ｐ２Ｐ用ＤＮＳサーバＳＰは、入力部１５を備えている。入力部１５は、管理者等からの指示を受け付けこの指示に応じた指示信号を制御部１１に対して与える。入力部１５は、例えば、キーボード、マウス等である。そして、制御部１１、記憶部１２、通信部１３、表示部１４、及び入力部１５はバス１６を介して相互に接続されている。ここで、記憶部１２は、本発明における記憶手段の一例である。
【００７８】
記憶部１２には、ゾーン情報が記憶されている。また、記憶部１２には、ホスト名と、そのホストのＩＰアドレスと、が対応付けて記憶されている。記憶されるホスト名は、ＷｅｂサーバＳＷ等のコンテンツ配信ドメインに含まれるホストである。また、記憶部１２には、閾値Ａ、閾値Ｂ等の設定値が記憶されている。また、記憶部１２には、回数情報が、クラス化ホスト名ごとに記憶されている。回数情報は、単位時間あたり問い合わせ回数を示す問い合わせ回数である。問い合わせ回数情報は、例えば、ＤＮＳ問い合わせメッセージの受信回数を、予め設定されたリフレッシュ時間ごとに示す配列変数である。例えば、単位時間あたり問い合わせ回数を計算する単位時間を２４時間とする。また、リフレッシュ時間を１０分とする。この場合、問い合わせ回数情報の要素数は１４４となる。リフレッシュ時間は、単位時間あたり問い合わせ回数をリフレッシュする時間間隔である。単位時間あたり問い合わせ回数のリフレッシュとは、問い合わせ回数情報に含まれるＤＮＳ問い合わせメッセージの受信回数のうち、古い時間帯に取得された受信回数をクリアすることをいう。ＤＮＳサーバＳＰは、問い合わせ回数情報に含まれる全要素の値を合算することにより、単位時間あたり問い合わせ回数を取得する。なお、問い合わせ回数情報は、本発明における数情報の一例である。
【００７９】
更に、記憶部１２には、ＤＮＳサーバプログラムが記憶されている。ＤＮＳサーバプログラムは、ＤＮＳサーバとしての処理を実行するためのプログラムである。なお、ＤＮＳサーバプログラムは、例えば、ネットワークＮＷ上の所定のサーバからダウンロードされるようにしても良い。また、ＤＮＳサーバプログラム及びＰ２Ｐプログラムは、例えば、ＤＶＤ（Digital Versatile Disc）等の記録媒体に記録されてこの記録媒体のドライブを介して読み込まれるようにしても良い。ＤＮＳサーバプログラムは、本発明におけるプログラムの一例である。
【００８０】
制御部１１は、ＣＰＵが記憶部１２等に記憶されたＤＮＳサーバプログラムを読み出して実行することにより、本発明における受信手段、取得手段、更新手段、送信手段、決定手段、第１判定手段、分割手段、追加手段、削除手段、第２判定手段及び統合手段として機能する。
【００８１】
［５．コンテンツ配信システムの動作］
次に、図４及び図５を参照して、本実施形態におけるコンテンツ配信システムＳの動作について説明する。図４は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部１１の処理例を示すフローチャートである。
【００８２】
図４に示す処理は、例えば、Ｐ２Ｐ用ＤＮＳサーバＳＰの電源がＯＮとされたときに開始される。先ず、制御部１１は、ＤＮＳサーバＳＤまたはローカルＤＮＳサーバＳＬからＤＮＳ問い合わせメッセージを受信したか否かを判定する（ステップＳ１）。このとき、制御部１１は、ＤＮＳ問い合わせメッセージを受信していないと判定した場合には（ステップＳ１：ＮＯ）、ステップＳ４に移行する。
【００８３】
一方、制御部１１は、ＤＮＳ問い合わせメッセージを受信したと判定した場合には（ステップＳ１：ＹＥＳ）、受信したＤＮＳ問い合わせメッセージに含まれるドメイン名に対応するＩＰアドレスを返信する（ステップＳ２）。具体的に、制御部１１は、ＤＮＳ問い合わせメッセージに含まれるドメイン名から、ホスト名ラベルを取得する。次いで、制御部１１は、取得したホスト名ラベルと、ゾーン情報に含まれる各クラス化ホスト名と、を比較する。これにより、制御部１１は、ＩＰアドレスを返信するホスト名ラベルを決定する。例えば、制御部１１は、ホスト名ラベルの先頭の文字から、比較対象となるクラス化ホスト名の文字数分の文字列を取得する。そして、制御部１１は、取得した文字列とクラス化ホスト名とが一致する場合、そのクラス化ホスト名を、ＩＰアドレスを返信するクラス化ホスト名として決定する。ただし、クラス化ホスト名が、例えば「20-27」となっている場合がある。このような場合、制御部１１は、クラス化ホスト名において、ハイフンの前に設定されている文字列が示す値からハイフンの後に設定されている文字列が示す値までの範囲を特定する。そして、制御部１１は、特定した範囲に、ホスト名ラベルの先頭二文字が示す値が含まれている場合に、そのクラス化ホスト名を、ＩＰアドレスを返信するクラス化ホスト名として決定する。制御部１１は、決定したクラス化ホスト名に対応付けられている全部のＩＰアドレスを、ＤＮＳ問い合わせメッセージの送信元に返信する。なお、制御部１１は、決定したクラス化ホスト名に対応付けられているＩＰアドレスのうち、一部のＩＰアドレスを返信しても良い。
【００８４】
次いで、制御部１１は、単位時間あたり問い合わせ回数を更新する（ステップＳ３）。具体的に、制御部１１は、ステップＳ２において決定したクラス化ホスト名に対応する問い合わせ回数情報を選択する。次いで、制御部１１は、選択した問い合わせ回数情報に含まれる配列要素のうち、現在の時刻が属する時間帯に対応する配列要素を選択する。次いで、制御部１１は、選択した配列要素が示す回数に１を加算して、選択した配列要素の値を更新する。制御部１１は、ステップＳ３の処理を終えると、ステップＳ４に移行する。
【００８５】
ステップＳ４において、制御部１１は、単位時間あたり問い合わせ回数をリフレッシュする時間であるか否かを判定する。このとき、制御部１１は、前回問い合わせ回数のリフレッシュを行ってからリフレッシュ時間が経過していない場合には、単位時間あたり問い合わせ回数をリフレッシュする時間ではないと判定する（ステップＳ４：ＮＯ）。この場合、制御部１１は、ステップＳ６に移行する。
【００８６】
一方、制御部１１は、前回問い合わせ回数のリフレッシュを行ってからリフレッシュ時間が経過した場合には、単位時間あたり問い合わせ回数をリフレッシュする時間であると判定する（ステップＳ４：ＹＥＳ）。この場合、制御部１１は、単位時間あたり問い合わせ回数をリフレッシュする（ステップＳ５）。具体的に、制御部１１は、問い合わせ回数情報に含まれる配列要素のうち、最も古い時間帯に取得されたＤＮＳ問い合わせメッセージの受信回数が設定されている配列要素の値を、０にクリアする。制御部１１は、この処理を各問い合わせ回数情報について行う。０にクリアされた配列要素には、次に問い合わせ回数をリフレッシュする時間になるまでにおけるＤＮＳ問い合わせメッセージの受信回数が設定されることになる。つまり、０にクリアされた配列要素には、最新の時間帯におけるＤＮＳ問い合わせメッセージの受信回数が設定される。制御部１１は、ステップＳ４の処理を終えると、ステップＳ６に移行する。
【００８７】
ステップＳ６において、制御部１１は、コンタクトノードから新規ノード追加メッセージを受信したか否かを判定する。このとき、制御部１１は、新規ノード追加メッセージを受信していないと判定した場合には（ステップＳ６：ＮＯ）、ステップＳ８に移行する。一方、システム制御部１１は、新規ノード追加メッセージを受信したと判定した場合には（ステップＳ６：ＹＥＳ）、後述する参加ノード追加処理を実行して（ステップＳ７）、ステップＳ８に移行する。
【００８８】
ステップＳ８において、制御部１１は、ノードの生存確認を行う時間になったか否かを判定する。例えば、制御部１１は、ノードの生存確認を行うと、次にノードの生存確認を行う時間を作業用ＲＡＭに設定する。そこで、制御部１１は、作業用ＲＡＭに設定されている時間に基づいて判定を行う。このとき、制御部１１は、ノードの生存確認を行う時間になっていないと判定した場合には（ステップＳ８：ＮＯ）、ステップＳ１１に移行する。
【００８９】
一方、制御部１１は、ノードの生存確認を行う時間になったと判定した場合には（ステップＳ８：ＹＥＳ）、後述する生存確認・離脱ノード削除処理を実行する（ステップＳ９）。次いで、制御部１１は、ノードの生存確認を行う時間をリセットする（ステップＳ１０）。つまり、制御部１１は、作業用ＲＡＭに設定されている時間を、次にノードの生存確認を行う時間に書き換える。制御部１１は、ステップＳ１０の処理を終えると、ステップＳ１１に移行する。
【００９０】
ステップＳ１１において、制御部１１は、管理者から電源ＯＦＦの要求がされたか否かを判定する。このとき、制御部１１は、電源ＯＦＦの要求がされなかったと判定した場合には（ステップＳ１１：ＮＯ）、ステップＳ１に移行する。一方、制御部１１は、電源ＯＦＦの要求がされたと判定した場合には（ステップＳ１１：ＹＥＳ）、図４に示す処理を終了させる。
【００９１】
図５（ａ）は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部１１の参加ノード追加処理における処理例を示すフローチャートである。先ず、制御部１１は、受信した新規ノード追加メッセージから、Ｐ２ＰネットワークＰＷに参加してきたノードのＩＰアドレスを取得する（ステップＳ２１）。次いで、制御部１１は、後述する追加クラス化ホスト名決定処理を実行する（ステップＳ２２）。次いで、制御部１１は、追加クラス化ホスト名決定処理において、参加してきたノードのＩＰアドレスの追加対象として決定されたクラス化ホスト名に対応付けて、取得したＩＰアドレスをゾーン情報に設定する（ステップＳ２３）。制御部１１は、ステップＳ２３の処理を終えると、参加ノード追加処理を終了させる。
【００９２】
図５（ｂ）は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部１１の追加クラス化ホスト名決定処理における処理例を示すフローチャートである。先ず、制御部１１は、受信した新規ノード追加メッセージに、コンテンツ保存情報が含まれているか否かを判定する（ステップＳ３１）。このとき、制御部１１は、新規ノード追加メッセージにコンテンツ保存情報が含まれていると判定した場合には（ステップＳ３１：ＹＥＳ）、参加してきたノードが最も多く保存しているコンテンツに対応するクラス化ホスト名を、そのノードのＩＰアドレスの追加対象として決定する（ステップＳ３２）。具体的に、制御部１１は、コンテンツ保存情報と一致するクラス化ホスト名を、追加対象として決定する。制御部１１は、ステップＳ３２の処理を終えると、ステップＳ３４に移行する。
【００９３】
ステップＳ３１において、制御部１１は、新規ノード追加メッセージにコンテンツ保存情報が含まれていないと判定した場合には（ステップＳ３１：ＮＯ）、単位時間あたり問い合わせ回数が最も多いクラス化ホスト名を、追加対象として決定する（ステップＳ３３）。具体的に、制御部１１は、各問い合わせ回数情報について、問い合わせ回数情報に含まれる全要素の値を合算して、単位時間あたり問い合わせ回数を求める。そして、制御部１１は、計算された単位時間あたり問い合わせ回数が最も多い問い合わせ回数情報に対応するクラス化ホスト名を、追加対象として決定する。制御部１１は、ステップＳ３３の処理を終えると、ステップＳ３４に移行する。
【００９４】
ステップＳ３４において、制御部１１は、追加対象として決定されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ａ以上であるか否かを判定する。このとき、制御部１１は、追加対象として決定されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ａ以上ではないと判定した場合には（ステップＳ３４：ＮＯ）、追加クラス化ホスト名決定処理を終了させる。
【００９５】
一方、制御部１１は、追加対象として決定されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ａ以上であると判定した場合には（ステップＳ３４：ＹＥＳ）、追加対象として決定されたクラス化ホスト名を分割し、そのクラス化ホスト名が格納されたレコードを分割する（ステップＳ３５）。なお、分割の詳細な処理内容は、ゾーン情報の詳細の項において既に説明されている。次いで、制御部１１は、分割された複数のクラス化ホスト名のうち何れか１つのクラス化ホスト名を、追加対象として決定する（ステップＳ３６）。制御部１１は、ステップＳ３６の処理を終えると、追加クラス化ホスト名決定処理を終了させる。
【００９６】
図５（ｃ）は、本実施形態におけるＰ２Ｐ用ＤＮＳサーバＳＰの制御部１１の生存確認・離脱ノード削除処理における処理例を示すフローチャートである。先ず、制御部１１は、ゾーン情報に設定されているＩＰアドレスのうち１つのＩＰアドレスを取得する（ステップＳ４１）。次いで、制御部１１は、取得したＩＰアドレスに対応するノードの生存確認を行う（ステップＳ４２）。具体的に、制御部１１は、取得したＩＰアドレスに対応するノードに生存確認要求メッセージを送信する。そして、制御部１１は、ノードからの生存確認応答メッセージの受信待ちを行う。
【００９７】
次いで、制御部１１は、取得したＩＰアドレスに対応するノードが生存しているか否かを判定する（ステップＳ４３）。このとき、制御部１１は、生存確認要求メッセージを送信してから所定時間が経過する前に生存確認応答メッセージを受信した場合には、ノードが生存していると判定する（ステップＳ４３：ＹＥＳ）。この場合、制御部１１は、ステップＳ４７に移行する。
【００９８】
一方、制御部１１は、生存確認要求メッセージを送信してから所定時間が経過しても生存確認応答メッセージを受信しなかった場合には、ノードは生存していないと判定する（ステップＳ４３：ＮＯ）。この場合、制御部１１は、取得したＩＰアドレスをゾーン情報から削除することにより、ＩＰアドレスとクラス化ホスト名との対応付けを削除する（ステップＳ４４）。次いで、制御部１１は、ＩＰアドレスが削除されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ｂ以下であるか否かを判定する（ステップＳ４５）。このとき、制御部１１は、ＩＰアドレスが削除されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ｂ以下ではないと判定した場合には（ステップＳ４５：ＮＯ）、ステップＳ４７に移行する。
【００９９】
一方、制御部１１は、ＩＰアドレスが削除されたクラス化ホスト名に現在対応付けられているＩＰアドレスの個数が閾値Ｂ以下であると判定した場合には（ステップＳ４５：ＹＥＳ）、ＩＰアドレスが削除されたクラス化ホスト名と他のクラス化ホスト名とを統合し、これらのクラス化ホスト名が格納されていたレコードを統合する（ステップＳ４６）。なお、統合の詳細な処理内容は、ゾーン情報の詳細の項において既に説明されている。次いで、制御部１１は、ステップＳ４７に移行する。
【０１００】
ステップＳ４７において、制御部１１は、ゾーン情報に設定されているＩＰアドレスのうちまだ取得していないＩＰアドレスが存在するか否かを判定する。このとき、制御部１１は、まだ取得していないＩＰアドレスが存在すると判定した場合には（ステップＳ４７：ＹＥＳ）、まだ取得していないＩＰアドレスのうち１つのＩＰアドレスを取得する（ステップＳ４８）。次いで、制御部１１は、ステップＳ４２に移行する。一方、制御部１１は、まだ取得していないＩＰアドレスが存在しないと判定した場合には（ステップＳ４７：ＮＯ）、生存確認・離脱ノード削除処理を終了させる。
【０１０１】
なお、上記実施形態においては、本発明のノード装置をルータに適用していた。しかしながら、本発明のノード装置を、例えば、プロキシサーバ、ロードバランサ、Ｗｅｂアクセラレータ等の、情報を中継する機能を有するネットワーク機器に適用しても良い。また、本発明のノード装置を、例えば、キャッシュサーバ、エッジサーバ等のサーバ装置に適用しても良い。
【０１０２】
また、本発明の情報処理装置を、上記実施形態のＰ２Ｐ用ＤＮＳサーバＳＰとローカルＤＮＳサーバＳＬとの両方の機能を兼ね備えたＤＮＳサーバに適用しても良い。この場合、本発明の問い合わせ装置は、ユーザ端末Ｔｎ−ｌとなる。
【０１０３】
また、上記実施形態においては、オーバーレイネットワークに、ＤＨＴを利用したピアツーピアネットワークが適用されていたが、これに限られるものではない。例えば、他のピアツーピアシステム、または、オーバーレイネットワークを用いたシステムが適用されても良い。ＤＨＴを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。
【符号の説明】
【０１０４】
１１  制御部
１２  記憶部
１３  通信部
ＳＰ  Ｐ２Ｐ用ＤＮＳサーバ
ＳＬ  ローカルＤＮＳサーバ
ＳＤ  ＤＮＳサーバ
ＳＳ  コンテンツ投入サーバ
Ｎｎ  ノード
ＮＬｎ  拠点ネットワーク
ＮＳ  配信センターネットワーク
ＮＷ  ネットワーク
ＰＷ  Ｐ２Ｐネットワーク
Ｓ  コンテンツ配信システム
【図１】
2012118708.tif 000003
【図２】
2012118708.tif 000004
【図３】
2012118708.tif 000005
【図４】
2012118708.tif 000006
【図５】
2012118708.tif 000007