以下、本発明の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ配信システムに本発明を適用した場合の実施形態である。
[1.コンテンツ配信システムの概要構成]
始めに、図1を参照して、本実施形態のコンテンツ配信システムの概要構成について説明する。図1は、本実施形態のコンテンツ配信システムSの概要構成例を示す図である。コンテンツ配信システムSは、DNSを適用したCDNである。図1に示すように、コンテンツ配信システムSは、ネットワークNWに、配信センターネットワークNSと複数の拠点ネットワークNLn(n=1,2,3・・・の何れか)とが接続されている。このネットワークNW、配信センターネットワークNS、及び各拠点ネットワークNLnは、現実世界の通信ネットワークである。
ネットワークNWは、配信センターネットワークNS及び各拠点ネットワークNLnを相互接続するためのネットワークである。このネットワークNWは、例えば、WAN(Wide Area Network)等である。そして、ネットワークNWは、例えば、IX(Internet eXchange)、ISP(Internet Service Provider)、DSL(Digital Subscriber Line)回線事業者の装置、FTTH(Fiber To The Home)回線事業者の装置、及び通信回線等によって構築されている。なお、ネットワークNWは、コンテンツ配信システムS専用のネットワークであっても良い。
配信センターネットワークNSは、例えば、配信センターの敷地内に構築されたネットワークである。この配信センターネットワークNSは、例えば、LAN(Local Area Network)等により構築されている。配信センターネットワークNSには、コンテンツ投入サーバSS、WebサーバSW及びP2P用DNSサーバSPが接続されている。コンテンツ投入サーバSSは、コンテンツをP2PネットワークPWに投入する。コンテンツの投入とは、コンテンツを何れかのノード装置Nnに保存させ、保存されたコンテンツを、各ノード装置Nnが取得可能にすることである。
配信センターネットワークNS及び各拠点ネットワークNLnには、それぞれノード装置Nnが定常的に接続されている。このノード装置Nnは、例えば、配信センターネットワークNSまたは拠点ネットワークNLnと、ネットワークNWとを相互接続するルータである。例えば、ノード装置Nnは、ルータ機能を有するファイアーウォール、ブロードバンドルータ等である。なお、ノード装置を、以下、「ノード」という。
WebサーバSWは、Webページをユーザ端末Tn−lに配信するためのサーバ装置である。P2P用DNSサーバSPは、ドメイン名を解決するDNSサーバである。P2P用DNSサーバSPは、後述するDNSサーバSDまたはローカルDNSサーバSLからドメイン名の解決の問い合わせを受け付ける。なお、P2P用DNSサーバSPは、本発明における情報処理装置の一例である。
各拠点ネットワークNLnは、それぞれ拠点nの敷地内に構築されたネットワークである。拠点nは、例えば、企業、学校、病院、カラオケボックス、公共団体等の組織が活動とする拠点である。この拠点ネットワークNLnは、例えば、LAN等により構築されている。各拠点ネットワークNLnには、複数のユーザ端末Tn−l(l=1,2,3・・・の何れか)が接続されている。ユーザ端末Tn−lは、例えば、パーソナルコンピュータ等である。図1においては、一部の拠点ネットワークNLnの図示、及び、その拠点ネットワークNLnに接続されているユーザ端末Tn−lの図示を省略している。
ネットワークNWには、また、複数のDNSサーバSD及びローカルDNSサーバSLが接続されている。各DNSサーバSDは、それぞれ所定のドメインのオーソリティであるDNSサーバである。オーソリティとは、DNSにおいて、所定のドメインに含まれるサブドメインに関する情報を管理するDNSサーバである。ローカルDNSサーバSLは、ドメイン名を解決するDNSサーバである。ローカルDNSサーバSLは、ユーザ端末Tn−lからドメイン名の解決の問い合わせを受け付ける。なお、DNSサーバSDまたはローカルDNSサーバSLは、本発明における問い合わせ装置の一例である。
コンテンツ配信システムSにおいては、コンテンツを配信するためのピアツーピアネットワークであるP2PネットワークPWが構築されている。図1に示すように、P2PネットワークPWは、ネットワークNW上に構築された論理的なオーバーレイネットワークである。このP2PネットワークPWは、コンテンツ配信システムSを構成する複数のノードの参加により形成されるネットワークである。なお、P2PネットワークPWへの参加とは、後述するDHT(Distributed Hash Table)ルーティングテーブルに基づいて他のノードとの間で各種メッセージを送受信できる状態にすることをいう。P2PネットワークPWへの参加は、参加していないノードが、参加している任意のノードに参加要求を示す参加メッセージを送信することによって行われる。参加メッセージを受信する側のノードを、「コンタクトノード」という。
P2PネットワークPWは、特定のアルゴリズム、例えば、DHTを利用したアルゴリズムにより実現される。そして、P2PネットワークPWに接続する各ノードには、所定桁数からなる固有の識別情報であるノードIDが割り当てられている。図1に示すP2PネットワークPWは、ノードIDのID空間をリング状のものとして示されている。そして、図1のリング状のID空間において示されている各ノードの位置は、それぞれのノードIDに対応している。
各ノードは、それぞれ、DHTを用いたルーティングテーブルを保持している。ルーティングテーブルは、P2PネットワークPW上における各種メッセージの転送先を規定している。具体的に、ルーティングテーブルには、ID空間内で適度に離れたノードのノードID、IPアドレス及びポート番号を含むノード情報が複数登録されている。なお、ルーティングテーブルを用いたDHTルーティングについては、特開2006−197400号公報等で公知であるので、詳しい説明を省略する。
P2PネットワークPWにおいては、内容の異なる様々なコンテンツが複数のノードに分散して保存される。コンテンツとしては、例えば、画像データ、動画データ、音声データ、テキストデータ、電子文書、HTML(HyperText Markup Language)文書等が挙げられる。これらのコンテンツのうち、HTML文書は、WebサーバSWが保存している。HTML文書以外のコンテンツは、各ノードに分散して保存される。以下、コンテンツを保存するノードを、「コンテンツ保持ノード」という。各コンテンツには、それぞれコンテンツごとに固有の識別情報であるコンテンツIDが割り当てられている。コンテンツIDは、例えば、コンテンツのURL(Uniform Resource Locator)が共通のハッシュ関数によりハッシュ化されて生成される。
複数のノードに分散保存されているコンテンツの所在は、インデックス情報として、コンテンツの所在を管理または記憶しているノードにより記憶される。コンテンツの所在を管理しているノードを、「ルートノード」という。インデックス情報は、コンテンツを保存したノードのノード情報と、コンテンツのコンテンツIDと等の組を含む。このようなルートノードは、例えば、コンテンツIDと最も近いノードIDを有するノードであるように定められる。コンテンツIDと最も近いノードIDとは、例えば、IDの上位桁が最も多く一致するノードIDである。
そして、あるノードが、あるコンテンツを取得しようとする場合、そのノードは、検索メッセージを送信する。以下、コンテンツを取得しようとするノードを、「ユーザノード」という。検索メッセージは、取得対象のコンテンツのコンテンツID及びユーザノードのIPアドレス等を含む。検索メッセージは、コンテンツ保持ノードを検索するためのメッセージである。ユーザノードは、ユーザノードが記憶するルーティングテーブルに従って、他のノードに送信する。これにより、検索メッセージは、コンテンツIDをキーとするDHTルーティングによって最終的にルートノードに到着することになる。
検索メッセージを受信したルートノードは、これに含まれるコンテンツIDに対応するインデックス情報を、ユーザノードに送信する。ユーザノードは、受信したインデックス情報に含まれるIPアドレス及びポート番号に基づいて、何れかのコンテンツ保持ノードに、コンテンツIDを含むコンテンツ要求メッセージを送信する。コンテンツ保持ノードは、受信したコンテンツ要求メッセージに含まれるコンテンツIDに対応するコンテンツを、ユーザノードにアップロードまたは送信する。こうして、ユーザノードは、コンテンツをダウンロードまたは取得することができる。コンテンツを取得して保存したユーザノードは、そのコンテンツの新たなコンテンツ保持ノードとなる。
[2.ユーザ端末へのコンテンツの配信]
次に、コンテンツ配信システムSにおけるユーザ端末Tn−lへのコンテンツの配信について説明する。先ず、本実施形態においてDNSに関して用いられる用語について説明する。ドメインは、ネットワーク上のホストをグループ化したものを示す。ドメイン名は、このホストのグループを識別するための名前である。本実施形態において、「ドメイン名」は、FQDN(Fully Qualified Domain Name)を意味する。例えば、コンテンツのURLが「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」が示すドメインのサブドメインである。特定のホストを示すドメイン名を、特に「ホスト名」という。あるドメインに含まれるホストのホスト名は、そのドメインのドメイン名に、1つ以上のラベルが付加されたもので示される。例えば、「xxxxx.yy.zz」が示すドメインにおいて、「0123」というラベルで識別されるホストのホスト名は、「0123.xxxxx.yy.zz」となる。よって、ホスト名は、ホストが属するドメインのドメイン名を含んでいる。
コンテンツ配信システムSには、コンテンツを配信するためのドメイン名が割り当てられている。例えば、コンテンツ配信システムSには、「xxxxx.yy.zz」というドメイン名が割り当てられている。なお、コンテンツ配信システムSに対応するドメインを、「コンテンツ配信ドメイン」という。コンテンツ配信ドメインを示すドメイン名が「xxxxx.yy.zz」である。ここで、「xxxxx」は、「yy.zz」が示すドメインに含まれるサブドメインのうち、コンテンツ配信ドメインを示すラベルである。なお、コンテンツ配信ドメインを示すラベルは、本発明における所定のドメインを示すラベルの一例である。
WebサーバSW、P2P用DNSサーバSP及び各ノードは、コンテンツ配信ドメインに含まれるホストである。従って、WebサーバSW、P2P用DNSサーバSP及び各ノードには、「xxxxx.yy.zz」というドメイン名に、1つ以上のラベルが付加されたものがホスト名として割り当てられる。例えば、WebサーバSWには、「www.xxxxx.yy.zz」というホスト名が割り当てられている。また、P2P用DNSサーバSPには、「dns.xxxxx.yy.zz」というホスト名が割り当てられている。
各ノードには、「****.xxxxx.yy.zz」というホスト名が割り当てられる。ここで、最下位のレベルのドメインを示すラベル「****」は、コンテンツIDの上位4桁の値を示す数字である。以下、ノードに割り当てられるホスト名において、最下位のレベルのドメインを示すラベルを、「ホスト名ラベル」という。本実施形態においては、コンテンツIDを16進数で示すものとする。従って、ホスト名ラベルは、0000からFFFFまでの値のうち何れかの値を示す数字である。なお、ホスト名ラベルは、本発明におけるコンテンツラベルの一例である。
なお、コンテンツIDに対応させるラベルは、最下位のレベルのドメインを示すラベルのみに限られるものではない。例えば、コンテンツ配信システムに含まれるサブドメインを示すラベルを、コンテンツIDに対応させても良い。例えば、「aaa.****.xxxxx.yy.zz」というホスト名において、「****」がサブドメインを示すラベルである。
コンテンツ配信ドメインに含まれるホストのホスト名とIPアドレスとの対応付けは、P2P用DNSサーバSPにより管理されている。つまり、P2P用DNSサーバSPは、コンテンツ配信ドメインのオーソリティである。各ノードに対するホスト名の割り当ては、ゾーン情報により定義されている。ゾーン情報は、P2P用DNSサーバSPにより記憶されている。そして、各ノードに対するホスト名の割り当ては、P2P用DNSサーバSPより動的に行われる。なお、ゾーン情報の詳細については後述する。
コンテンツ配信システムSからユーザ端末Tn−lへ配信されるコンテンツのうち、HTML文書には、「www.xxxxx.yy.zz」を含むURLが付与されている。また、HTML文書以外のコンテンツには、「****.xxxxx.yy.zz」を含むURLが付与されている。
例えば、ユーザ端末T1−1を利用するユーザは、Webページを閲覧する場合、Webページを構成するHTML文書のURL等を指定する。すると、ユーザ端末T1−1は、WebサーバSWに対して、HTML文書を要求するためのHTTP(HyperText Transfer Protocol)リクエストを送信する。WebサーバSWは、受信したHTTPリクエストに含まれるURLに対応するHTML文書をユーザ端末T1−1に送信する。なお、URLに含まれるドメイン名「www.xxxxx.yy.zz」を解決するためのユーザ端末T1−1、ローカルDNSサーバSL、DNSサーバSD及びP2P用DNSサーバSPの動作は、DNSにおける公知の動作と同様である。
ユーザ端末T1−1は、受信したHTML文書から、Webページを構成するコンテンツのURLを取得する。例えば、ユーザ端末T1−1は、「http://0123.xxxxx.yy.zz/image/image01.jpeg」という、画像データのURLを取得したとする。すると、ユーザ端末T1−1は、取得したURLに含まれるドメイン名として、「0123.xxxxx.yy.zz」を設定したDNS問い合わせメッセージを、ローカルDNSサーバSLへ送信する。DNS問い合わせメッセージは、ドメイン名の解決を問い合わせるためのメッセージである。
ローカルDNSサーバSLは、受信したDNS問い合わせメッセージに含まれるドメイン名「0123.xxxxx.yy.zz」に対応するIPアドレスをキャッシュしていない場合、P2P用DNSサーバSPから「0123.xxxxx.yy.zz」に対応するIPアドレスを取得する。例えば、DNSにおける再帰モードでIPアドレスを取得する場合、ローカルDNSサーバSLは、複数のDNSサーバSDのうちルートネームサーバに、DNS問い合わせメッセージを転送する。ルートネームサーバは、「zz」のオーソリティであるDNSサーバSDに、DNS問い合わせメッセージを転送する。「zz」のオーソリティであるDNSサーバは、「yy.zz」のオーソリティであるDNSサーバSDに、DNS問い合わせメッセージを転送する。「yy.zz」のオーソリティであるDNSサーバは、「xxxxx.yy.zz」のオーソリティであるDNSサーバ、すなわち、P2P用DNSサーバSPに、DNS問い合わせメッセージを転送する。
P2P用DNSサーバSPは、ゾーン情報に基づいて、受信したDNS問い合わせメッセージに含まれる「0123.xxxxx.yy.zz」が割り当てられたノード、例えばノードN1のIPアドレスを、DNSサーバSDに返信する。DNSサーバSDに返信されたIPアドレスは、DNS問い合わせメッセージの転送経路とは逆の経路で、ローカルDNSサーバSLに転送される。なお、DNSにおける反復モードでIPアドレスを取得する場合、ローカルDNSサーバSLは、「yy.zz」のオーソリティであるDNSサーバから取得したP2P用DNSサーバSPのIPアドレスに基づいて、P2P用DNSサーバSPにDNS問い合わせメッセージを送信する。そして、ローカルDNSサーバSLは、P2P用DNSサーバSPからノードのIPアドレスを受信する。IPアドレスを取得したローカルDNSサーバSLは、取得したIPアドレスを、ユーザ端末T1−1に送信する。
ユーザ端末T1−1は、受信したIPアドレスに基づいて、HTTPリクエストをノードN1に送信する。このHTTPリクエストには、要求されるコンテンツのURLとして、「http://0123.xxxxx.yy.zz/image/image01.jpeg」が含まれる。このURLは、DNSにより解決されたドメイン名である「0123.xxxxx.yy.zz」を含む。つまり、「0123.xxxxx.yy.zz」は、要求されるコンテンツと対応する。ノードN1は、例えば、受信したHTTPリクエストに含まれるURLから、「http://0123.」を除いた「xxxxx.yy.zz/image/image01.jpeg」の部分を取得する。そして、ノードN1は、「xxxxx.yy.zz/image/image01.jpeg」のハッシュ値を計算することにより、要求されたコンテンツのコンテンツIDを計算する。次いで、ノードN1は、コンテンツIDに対応するコンテンツを保存している場合には、そのコンテンツをユーザ端末T1−1へ送信する。一方、ノードN1は、コンテンツIDに対応するコンテンツを保存していない場合には、P2PネットワークPWからコンテンツを取得する。つまり、ノードN1は、コンテンツIDに対応するコンテンツを保存しているコンテンツ保持ノードからコンテンツを取得する。そして、ノードN1は、取得したコンテンツをユーザ端末T1−1へ送信する。
[3.ゾーン情報の詳細]
次に、図2を参照して、ゾーン情報の詳細について説明する。図2(a)は、ゾーン情報に設定される内容の一例を示す図である。ゾーン情報は、P2P用DNSサーバSPが、受信したドメイン名に対応してどのIPアドレスを返信するかを示す情報である。
図2(a)に示すように、ゾーン情報は、クラス化ホスト名と、ノードのIPアドレスと、が対応付けて格納されるレコードを複数含む。クラス化ホスト名は、ノードのIPアドレスに対応付けられるホスト名ラベルの範囲を示す情報である。例えば、図2(a)においては、ホスト名ラベルの先頭一文字、すなわちコンテンツIDの上位一桁の数字が設定されている。例えば、クラス化ホスト名としての「0」は、ホスト名ラベルの範囲が「0000」から「0FFF」までの範囲であることを示す。ノードのIPアドレスは、1つのレコードに1または複数格納される。例えば、図2(a)においては、クラス化ホスト名「0」に対応付けて、IPアドレス1及びIPアドレス2が格納されている。従って、P2P用DNSサーバSPは、「0000」から「0FFF」までの何れかのホスト名ラベルを含むドメイン名を受信した場合、IPアドレス1及びIPアドレス2を返信する。図2(a)においては、クラス化ホスト名として、「0」、「1」、「2」・・・「F」が、それぞれレコードに格納されている。なお、クラス化ホスト名は、本発明における範囲情報の一例である。また、ノードのIPアドレスは、本発明における所在情報の一例である。
なお、ゾーン情報において、ノードのIPアドレスと対応付ける情報を、ホスト名ラベルの範囲を示す情報としなくても良い。例えば、ノードと対応付ける情報を、ホスト名ラベルそのものとしても良い。この場合、各ホスト名ラベルにノードのIPアドレスを対応付けるため、1台のノードのIPアドレスが、複数のホスト名ラベルに対応付けられても良い。また、複数のノードのIPアドレスが、1つのホスト名ラベルに対応付けられても良い。この場合のホスト名ラベルは、本発明におけるラベル情報の一例である。
P2P用DNSサーバSPは、ノードまたはユーザ端末Tn−lによるコンテンツ配信システムSの利用状況に応じて、ゾーン情報に含まれるクラス化ホスト名とノードのIPアドレスとの対応付けを更新する。
このとき、P2P用DNSサーバSPは、クラス化ホスト名とノードのIPアドレスとの対応付けが適切となるように、この対応付けを更新する。例えば、DNS問い合わせメッセージに対して、特定のノードのIPアドレスの返信回数が、他のノードのIPアドレスの返信回数に比して極端に多かったとする。すると、特定のノードにユーザ端末Tn−lからのHTTPリクエストが集中する。従って、コンテンツの配信の負荷が特定のノードに集中する。これは、クラス化ホスト名とノードのIPアドレスとの対応付けが適切になされていないことを意味する。適切な対応付けとは、コンテンツの配信の負荷が特定のノードに集中しないような対応付けである。
ノードによるコンテンツ配信システムSの利用状況の一例としては、ノードによるP2PネットワークPWの参加状況が挙げられる。ノードは、P2PネットワークPWに参加することにより、コンテンツ配信システムSを利用することになるからである。また、ノードによるコンテンツ配信システムSの利用状況の他の一例としては、ノードが保存したコンテンツの保存状況が挙げられる。ノードは、P2PネットワークPWに参加することにより、他のノードからコンテンツを取得して保存したり、保存したコンテンツを削除したりするからである。
ユーザ端末Tn−lによるコンテンツ配信システムSの利用状況の一例としては、ユーザ端末Tn−lによるP2PネットワークPWからのコンテンツの取得頻度が挙げられる。コンテンツの取得頻度の一例として、P2P用DNSサーバSPにおけるDNS問い合わせメッセージの受信頻度が挙げられる。ユーザ端末Tn−lは、P2PネットワークPWからコンテンツを取得するために、コンテンツの取得先であるノードのIPアドレスを、ローカルP2PサーバSLを介してP2P用DNSサーバSPから取得する。そのため、ユーザ端末Tn−lによるコンテンツの取得頻度が高くなると、P2P用DNSサーバSPによるDNS問い合わせメッセージの受信頻度も高くなる。
先ず、ノードがP2PネットワークPWに参加してきたときのゾーン情報の更新について説明する。図2(b)及び図2(c)は、それぞれP2PネットワークPWにノードが参加してきたことに応じて更新されたゾーン情報の内容の一例を示す図である。コンタクトノードは、P2PネットワークPWに参加するノードから参加メッセージを受信すると、参加するノードのIPアドレスを含む新規ノード追加メッセージをP2P用DNSサーバSPに送信する。新規ノード追加メッセージに含まれるノードのIPアドレスは、本発明における利用情報の一例である。P2P用DNSサーバSPは、受信した新規ノード追加メッセージに含まれるIPアドレスをゾーン情報に追加する。ここで、P2P用DNSサーバSPは、ゾーン情報に追加するIPアドレスを対応付けるクラス化ホスト名を決定する。なお、IPアドレスを対応付けるクラス化ホスト名の決定方法については後述する。
例えば、参加してきたノードのIPアドレスがIPアドレス8であるとする。また、P2P用DNSサーバSPは、対応付けるクラス化ホスト名を「2」と決定したとする。そこで、P2P用DNSサーバSPは、図2(b)に示すように、IPアドレス8をクラス化ホスト名「2」に対応付けて追加設定する。
また、IPアドレスを対応付けると決定されたクラス化ホスト名に既に対応付けられているIPアドレスの個数が、予め設定された閾値A以上である場合、P2P用DNSサーバSPは、そのクラス化ホスト名を分割する。クラス化ホスト名の分割とは、そのクラス化ホスト名が示すホスト名ラベルの範囲を複数の範囲に分割することにより、1つクラス化ホスト名を複数のクラス化ホスト名に分けることである。そして、P2P用DNSサーバSPは、クラス化ホスト名の分割に伴い、ゾーン情報に含まれるレコードを分割する。閾値Aの値は任意であるが、例えば、DNSのプロトコルにおいて、DNS問い合わせメッセージの応答として一度に返信することができるIPアドレスの個数の上限値を閾値Aとしても良い。
例えば、閾値A=2であるとする。また、P2P用DNSサーバSPは、参加するノードのIPアドレスと対応付けるクラス化ホスト名を「3」と決定したとする。図2(a)に示すように、クラス化ホスト名「3」には、既にIPアドレス5及びIPアドレス6という2個のIPアドレスが対応付けられている。そこで、P2P用DNSサーバSPは、クラス化ホスト名「3」が示す「3000」から「3FFF」までのホスト名ラベルの範囲を、例えば、「3000」から「37FF」までの範囲と、「3800」から「3FFF」までの範囲と、に分割する。
具体的に、P2P用DNSサーバSPは、図2(c)に示すように、ゾーン情報に設定されているクラス化ホスト名「3」を、「30-37」に書き換える。クラス化ホスト名「30-37」は、ホスト名ラベルの先頭二文字が「30」から「37」までの何れかであることを示す。つまり、クラス化ホスト名「30-37」は、ホスト名ラベルの範囲が「3000」から「37FF」までの範囲であることを示す。これにより、P2P用DNSサーバSPは、クラス化ホスト名「3」に対応付けられていたIPアドレス5及びIPアドレス6を、クラス化ホスト名「30-37」に対応付ける。また、P2P用DNSサーバSPは、ゾーン情報に新たなレコードを追加する。そして、P2P用DNSサーバSPは、追加したレコードに、クラス化ホスト名「38-3F」を設定する。クラス化ホスト名「38-3F」は、ホスト名ラベルの先頭二文字が「38」から「3F」までの何れかであることを示す。つまり、クラス化ホスト名「38-3F」は、ホスト名ラベルの範囲が「3800」から「3FFF」までの範囲であることを示す。そして、P2P用DNSサーバSPは、追加したレコードに、参加してきたノードのIPアドレス8を追加する。これにより、P2P用DNSサーバSPは、IPアドレス8をクラス化ホスト名「38-3F」に対応付ける。
なお、ホスト名ラベルの範囲を分割するときの分割数は3つ以上であっても良い。また、ホスト名ラベルの範囲の分割割合は等分ではなくても良い。また、ホスト名ラベルの範囲の分割対象とされたクラス化ホスト名に既に対応付けられているIPアドレス及び参加するノードのIPアドレスを、それぞれ分割された複数のクラス化ホスト名のうちどのクラス化ホスト名に対応付けるかは任意である。
ここで、IPアドレスを対応付けるクラス化ホスト名の決定方法について説明する。P2P用DNSサーバSPは、ゾーン情報に含まれるクラス化ホスト名のうち、対応付けられたIPアドレスを単位時間あたりに返信した回数が最も多いクラス化ホスト名に、参加してきたノードのIPアドレスを対応付けると決定する。つまり、P2P用DNSサーバSPは、単位時間あたりにおけるDNS問い合わせメッセージの受信回数が最も多いクラス化ホスト名に、IPアドレスを対応付ける。この単位時間あたりにおけるDNS問い合わせメッセージの受信回数を、「単位時間あたり問い合わせ回数」という。P2P用DNSサーバSPは、DNS問い合わせメッセージを受信する都度、対応する単位時間あたり問い合わせ回数を更新する。
ユーザ端末Tn−lによるコンテンツの取得頻度が高いコンテンツを保存するノードは、そのコンテンツを配信するための処理負荷も高くなる。そこで、P2P用DNSサーバSPは、単位時間あたり問い合わせ回数が最も多いクラス化ホスト名に、参加してきたノードのIPアドレスを対応付けると決定する。これにより、コンテンツ配信の負荷が適切に分散される。
なお、P2P用DNSサーバSPは、各単位時間あたり問い合わせ回数を、それぞれ対応するクラス化ホスト名に対応付けられているノードのIPアドレスの個数で除算しても良い。これにより、P2P用DNSサーバSPは、ノード1台あたりの単位時間あたり問い合わせ回数を計算しても良い。そして、P2P用DNSサーバSPは、ノード1台あたりの単位時間あたり問い合わせ回数が最も多いクラス化ホスト名に、IPアドレスを対応付けると決定しても良い。
また、P2P用DNSサーバSPは、ゾーン情報に含まれるクラス化ホスト名のうち、参加してきたノードが最も多く保存しているコンテンツに対応するクラス化ホスト名を特定する。そして、P2P用DNSサーバSPは、特定したクラス化ホスト名に、参加してきたノードのIPアドレスを対応付けると決定する。ユーザ端末Tn−lから要求されたコンテンツをノードが保存している場合、ノードは、要求元のユーザ端末Tn−lにコンテンツを送信するためにオーバーレイネットワークを介して他のノードからコンテンツを取得する必要がない。過去にP2P用DNSサーバSPに参加したことがあるノードは、何らかのコンテンツを保存している可能性がある。そして、ノードが多く保存しているコンテンツに対応するクラス化ホスト名と、そのノードのIPアドレスが対応付けられる。これにより、ユーザ端末Tn−lが取得するコンテンツを保存している可能性が高いノードのIPアドレスを、P2P用DNSサーバSPが返信する。従って、ユーザ端末Tn−lは、取得しようとするコンテンツを保存している可能性が高いノードにHTTPリクエストを送信する。そのため、ノード間のコンテンツの送受信が減るので、ノードの処理負荷を軽減させることができる。
このような決定を行うため、P2P用DNSサーバSPは、参加してきたノードのコンテンツの保存状況を取得する。P2PネットワークPWに参加するノードは、そのノードが保存しているコンテンツの個数を計算する。この計算は、コンテンツIDの上位1桁の値が同一であるコンテンツごとに行われる。具体的に、ノードは、例えば、コンテンツIDの上位1桁の値が「1」であるコンテンツの個数を計算する。次に、ノードは、コンテンツIDの上位1桁の値が「2」であるコンテンツの個数を計算する。このように、ノードは、コンテンツIDの上位1桁の値が小さい順に、コンテンツの個数を計算する。そして、ノードは、コンテンツIDの上位1桁の値が「F」であるコンテンツの個数を計算する。ノードは、保存しているコンテンツの個数が最も多いコンテンツIDの上位1桁の値を示す数字を、コンテンツの保存状況を示すコンテンツ保存情報とする。コンテンツ保存情報の形式は、クラス化ホスト名の形式と一致する。ノードは、コンテンツ保存情報を含む参加メッセージを、コンタクトノードに送信する。コンタクトノードは、受信した参加メッセージからコンテンツ保存情報を取得する。そして、コンタクトノードは、取得したコンテンツ保存情報を含む新規ノード追加メッセージを、P2P用DNSサーバSPに送信する。P2P用DNSサーバSPは、受信した新規ノード追加メッセージに含まれるコンテンツ保存情報と一致するクラス化ホスト名を特定する。そして、P2P用DNSサーバSPは、特定したクラス化ホスト名に、参加してきたノードのIPアドレスを対応付けると決定する。なお、コンテンツ保存情報は、本発明における保存情報の一例である。
なお、ノードはP2PネットワークPWに新規参加する場合、コンテンツを1つも保存していない場合がある。その場合、ノードは、参加メッセージにコンテンツ保存情報を含めない。この場合、P2P用DNSサーバSPは、上述した単位時間あたり問い合わせ回数に基づいて決定を行う。
次に、ノードがP2PネットワークPWから離脱したときのゾーン情報の更新について説明する。図2(d)及び図2(e)は、ノードがP2PネットワークPWから離脱したことに応じて更新されたゾーン情報の内容の一例を示す図である。P2PネットワークPWからの離脱とは、P2PネットワークPWに参加していたノードが他のノードと通信することができない状態になったことをいう。ノードが他のノードと通信することができない状態になる場合としては、例えば、ノードの電源がOFFになった場合がある。また、ノードは、ルーティングテーブルを用いて他のノードと通信を行うためのP2Pプログラムを実行することにより、P2PネットワークPWに参加する。管理者の操作によって、ノードがP2Pプログラムの実行を終了させた場合も、ノードが他のノードと通信することができない状態になる場合の一例である。
P2P用DNSサーバSPは、定期的に、ゾーン情報にIPアドレスが設定されている各ノードの生存確認を行う。ノードが生存しているとは、P2PネットワークPWに参加しているノードがP2PネットワークPWから離脱していないことをいう。そして、生存確認とは、ノードがP2PネットワークPWから離脱していないことを確認することをいう。具体的に、P2P用DNSサーバSPは、ゾーン情報に設定されているIPアドレスに基づいて、生存確認の要求を示す生存確認メッセージをノードに送信する。生存確認要求メッセージを受信したノードは、P2PネットワークPWから離脱していないことを示す生存確認応答メッセージをP2P用DNSサーバSPに送信する。ここで、P2PネットワークPWから離脱しているノードは生存確認応答メッセージを送信することができない。そこで、生存確認要求メッセージを送信してから所定時間が経過しても送信先のノードから生存確認応答メッセージが受信されなかった場合、P2P用DNSサーバSPは、そのノードはP2PネットワークPWから離脱したと判定する。そして、P2P用DNSサーバSPは、離脱したノードのIPアドレスのクラス化ホスト名との対応付けを、ゾーン情報から削除する。なお、離脱したノードのIPアドレスとして、P2P用DNSサーバSPがゾーン情報から取得したIPアドレスは、本発明における利用情報の一例である。
例えば、P2P用DNSサーバSPは、IPアドレス6に対応するノードが離脱したと判定したとする。すると、P2P用DNSサーバSPは、図2(d)に示すように、クラス化ホスト名「3」に対応付けられているIPアドレス6をゾーン情報から削除する。これにより、IPアドレス6とクラス化ホスト名「3」との対応付けが削除される。そして、クラス化ホスト名「3」には、IPアドレス5のみが対応付けられる。
また、IPアドレスが削除されたクラス化ホスト名「3」にまだ対応付けられているIPアドレスの個数が、予め設定された閾値B以下である場合、P2P用DNSサーバSPは、そのクラス化ホスト名を、他のクラス化ホスト名と統合する。クラス化ホスト名の統合とは、複数のクラス化ホスト名がそれぞれ示すホスト名ラベルの範囲を統合することにより、複数のクラス化ホスト名を1つのクラス化ホスト名にすることをいう。そして、P2P用DNSサーバSPは、クラス化ホスト名の統合に伴い、ゾーン情報に含まれるレコードを統合する。なお閾値Bの値は任意である。
例えば、閾値B=0であるとする。また、削除されるIPアドレスがIPアドレス4であるとする。この場合、P2P用DNSサーバSPは、クラス化ホスト名「2」に対応付けられているIPアドレス4をゾーン情報から削除する。すると、クラス化ホスト名「2」に対応付けられているIPアドレスは存在しない。そこで、P2P用DNSサーバSPは、例えば、クラス化ホスト名「2」と「1」とを統合する。
具体的に、P2P用DNSサーバSPは、図2(c)に示すように、ゾーン情報に設定されているクラス化ホスト名「1」を「1-2」に書き換える。クラス化ホスト名「1-2」は、ホスト名ラベルの先頭一文字が「1」または「2」の何れかであることを示す。つまり、クラス化ホスト名「1-2」は、ホスト名ラベルの範囲が「1000」から「2FFF」までの範囲であることを示す。また、P2P用DNSサーバSPは、クラス化ホスト名「2」が格納されていたレコードをゾーン情報から削除する。これにより、クラス化ホスト名「1」に対応付けられていたIPアドレス3は、クラス化ホスト名「1-2」に対応付けられる。
なお、閾値Bが1以上に設定されている場合、削除されるレコードには、まだIPアドレスが格納されていることになる。その場合、P2P用DNSサーバSPは、削除されるレコードに格納されているIPアドレスを、統合先のレコードに格納する。また、IPアドレスが削除されたクラス化ホスト名を、どのクラス化ホスト名と統合するかは任意である。また、統合後のクラス化ホスト名が示すホスト名ラベルの範囲が連続していなくても良い。
また、ゾーン情報の更新のタイミングは、ノードがP2PネットワークPWに参加したときや離脱したときのみに限られるものではない。例えば、P2P用DNSサーバSPは、ゾーン情報におけるクラス化ホスト名とIPアドレスとの対応付けを、定期的に更新しても良い。
[4.P2P用DNSサーバの構成]
次に、図3を参照して、P2P用DNSサーバSPの構成及び機能について説明する。図3は、P2P用DNSサーバSPの概要構成例を示す図である。
P2P用DNSサーバSPは、図3に示すように、制御部11を備えている。制御部11は、演算機能を有するCPU,作業用RAM,各種データ及びプログラムを記憶するROM等から構成される。また、P2P用DNSサーバSPは、記憶部12を備えている。記憶部12は、各種データ及び各種プログラム等を記憶保存するためのHD等から構成される。更に、P2P用DNSサーバSPは、通信部13を備えている。通信部13は、P2P用DNSサーバSPは、配信センターネットワークNS等を通じてDNSサーバSDやローカルDNSサーバSL等との間の情報の通信制御を行う。また更に、P2P用DNSサーバSPは、表示部14を備えている。表示部14は、各種情報を表示するCRT,液晶ディスプレイ等である。更にまた、P2P用DNSサーバSPは、入力部15を備えている。入力部15は、管理者等からの指示を受け付けこの指示に応じた指示信号を制御部11に対して与える。入力部15は、例えば、キーボード、マウス等である。そして、制御部11、記憶部12、通信部13、表示部14、及び入力部15はバス16を介して相互に接続されている。ここで、記憶部12は、本発明における記憶手段の一例である。
記憶部12には、ゾーン情報が記憶されている。また、記憶部12には、ホスト名と、そのホストのIPアドレスと、が対応付けて記憶されている。記憶されるホスト名は、WebサーバSW等のコンテンツ配信ドメインに含まれるホストである。また、記憶部12には、閾値A、閾値B等の設定値が記憶されている。また、記憶部12には、回数情報が、クラス化ホスト名ごとに記憶されている。回数情報は、単位時間あたり問い合わせ回数を示す問い合わせ回数である。問い合わせ回数情報は、例えば、DNS問い合わせメッセージの受信回数を、予め設定されたリフレッシュ時間ごとに示す配列変数である。例えば、単位時間あたり問い合わせ回数を計算する単位時間を24時間とする。また、リフレッシュ時間を10分とする。この場合、問い合わせ回数情報の要素数は144となる。リフレッシュ時間は、単位時間あたり問い合わせ回数をリフレッシュする時間間隔である。単位時間あたり問い合わせ回数のリフレッシュとは、問い合わせ回数情報に含まれるDNS問い合わせメッセージの受信回数のうち、古い時間帯に取得された受信回数をクリアすることをいう。DNSサーバSPは、問い合わせ回数情報に含まれる全要素の値を合算することにより、単位時間あたり問い合わせ回数を取得する。なお、問い合わせ回数情報は、本発明における数情報の一例である。
更に、記憶部12には、DNSサーバプログラムが記憶されている。DNSサーバプログラムは、DNSサーバとしての処理を実行するためのプログラムである。なお、DNSサーバプログラムは、例えば、ネットワークNW上の所定のサーバからダウンロードされるようにしても良い。また、DNSサーバプログラム及びP2Pプログラムは、例えば、DVD(Digital Versatile Disc)等の記録媒体に記録されてこの記録媒体のドライブを介して読み込まれるようにしても良い。DNSサーバプログラムは、本発明におけるプログラムの一例である。
制御部11は、CPUが記憶部12等に記憶されたDNSサーバプログラムを読み出して実行することにより、本発明における受信手段、取得手段、更新手段、送信手段、決定手段、第1判定手段、分割手段、追加手段、削除手段、第2判定手段及び統合手段として機能する。
[5.コンテンツ配信システムの動作]
次に、図4及び図5を参照して、本実施形態におけるコンテンツ配信システムSの動作について説明する。図4は、本実施形態におけるP2P用DNSサーバSPの制御部11の処理例を示すフローチャートである。
図4に示す処理は、例えば、P2P用DNSサーバSPの電源がONとされたときに開始される。先ず、制御部11は、DNSサーバSDまたはローカルDNSサーバSLからDNS問い合わせメッセージを受信したか否かを判定する(ステップS1)。このとき、制御部11は、DNS問い合わせメッセージを受信していないと判定した場合には(ステップS1:NO)、ステップS4に移行する。
一方、制御部11は、DNS問い合わせメッセージを受信したと判定した場合には(ステップS1:YES)、受信したDNS問い合わせメッセージに含まれるドメイン名に対応するIPアドレスを返信する(ステップS2)。具体的に、制御部11は、DNS問い合わせメッセージに含まれるドメイン名から、ホスト名ラベルを取得する。次いで、制御部11は、取得したホスト名ラベルと、ゾーン情報に含まれる各クラス化ホスト名と、を比較する。これにより、制御部11は、IPアドレスを返信するホスト名ラベルを決定する。例えば、制御部11は、ホスト名ラベルの先頭の文字から、比較対象となるクラス化ホスト名の文字数分の文字列を取得する。そして、制御部11は、取得した文字列とクラス化ホスト名とが一致する場合、そのクラス化ホスト名を、IPアドレスを返信するクラス化ホスト名として決定する。ただし、クラス化ホスト名が、例えば「20-27」となっている場合がある。このような場合、制御部11は、クラス化ホスト名において、ハイフンの前に設定されている文字列が示す値からハイフンの後に設定されている文字列が示す値までの範囲を特定する。そして、制御部11は、特定した範囲に、ホスト名ラベルの先頭二文字が示す値が含まれている場合に、そのクラス化ホスト名を、IPアドレスを返信するクラス化ホスト名として決定する。制御部11は、決定したクラス化ホスト名に対応付けられている全部のIPアドレスを、DNS問い合わせメッセージの送信元に返信する。なお、制御部11は、決定したクラス化ホスト名に対応付けられているIPアドレスのうち、一部のIPアドレスを返信しても良い。
次いで、制御部11は、単位時間あたり問い合わせ回数を更新する(ステップS3)。具体的に、制御部11は、ステップS2において決定したクラス化ホスト名に対応する問い合わせ回数情報を選択する。次いで、制御部11は、選択した問い合わせ回数情報に含まれる配列要素のうち、現在の時刻が属する時間帯に対応する配列要素を選択する。次いで、制御部11は、選択した配列要素が示す回数に1を加算して、選択した配列要素の値を更新する。制御部11は、ステップS3の処理を終えると、ステップS4に移行する。
ステップS4において、制御部11は、単位時間あたり問い合わせ回数をリフレッシュする時間であるか否かを判定する。このとき、制御部11は、前回問い合わせ回数のリフレッシュを行ってからリフレッシュ時間が経過していない場合には、単位時間あたり問い合わせ回数をリフレッシュする時間ではないと判定する(ステップS4:NO)。この場合、制御部11は、ステップS6に移行する。
一方、制御部11は、前回問い合わせ回数のリフレッシュを行ってからリフレッシュ時間が経過した場合には、単位時間あたり問い合わせ回数をリフレッシュする時間であると判定する(ステップS4:YES)。この場合、制御部11は、単位時間あたり問い合わせ回数をリフレッシュする(ステップS5)。具体的に、制御部11は、問い合わせ回数情報に含まれる配列要素のうち、最も古い時間帯に取得されたDNS問い合わせメッセージの受信回数が設定されている配列要素の値を、0にクリアする。制御部11は、この処理を各問い合わせ回数情報について行う。0にクリアされた配列要素には、次に問い合わせ回数をリフレッシュする時間になるまでにおけるDNS問い合わせメッセージの受信回数が設定されることになる。つまり、0にクリアされた配列要素には、最新の時間帯におけるDNS問い合わせメッセージの受信回数が設定される。制御部11は、ステップS4の処理を終えると、ステップS6に移行する。
ステップS6において、制御部11は、コンタクトノードから新規ノード追加メッセージを受信したか否かを判定する。このとき、制御部11は、新規ノード追加メッセージを受信していないと判定した場合には(ステップS6:NO)、ステップS8に移行する。一方、システム制御部11は、新規ノード追加メッセージを受信したと判定した場合には(ステップS6:YES)、後述する参加ノード追加処理を実行して(ステップS7)、ステップS8に移行する。
ステップS8において、制御部11は、ノードの生存確認を行う時間になったか否かを判定する。例えば、制御部11は、ノードの生存確認を行うと、次にノードの生存確認を行う時間を作業用RAMに設定する。そこで、制御部11は、作業用RAMに設定されている時間に基づいて判定を行う。このとき、制御部11は、ノードの生存確認を行う時間になっていないと判定した場合には(ステップS8:NO)、ステップS11に移行する。
一方、制御部11は、ノードの生存確認を行う時間になったと判定した場合には(ステップS8:YES)、後述する生存確認・離脱ノード削除処理を実行する(ステップS9)。次いで、制御部11は、ノードの生存確認を行う時間をリセットする(ステップS10)。つまり、制御部11は、作業用RAMに設定されている時間を、次にノードの生存確認を行う時間に書き換える。制御部11は、ステップS10の処理を終えると、ステップS11に移行する。
ステップS11において、制御部11は、管理者から電源OFFの要求がされたか否かを判定する。このとき、制御部11は、電源OFFの要求がされなかったと判定した場合には(ステップS11:NO)、ステップS1に移行する。一方、制御部11は、電源OFFの要求がされたと判定した場合には(ステップS11:YES)、図4に示す処理を終了させる。
図5(a)は、本実施形態におけるP2P用DNSサーバSPの制御部11の参加ノード追加処理における処理例を示すフローチャートである。先ず、制御部11は、受信した新規ノード追加メッセージから、P2PネットワークPWに参加してきたノードのIPアドレスを取得する(ステップS21)。次いで、制御部11は、後述する追加クラス化ホスト名決定処理を実行する(ステップS22)。次いで、制御部11は、追加クラス化ホスト名決定処理において、参加してきたノードのIPアドレスの追加対象として決定されたクラス化ホスト名に対応付けて、取得したIPアドレスをゾーン情報に設定する(ステップS23)。制御部11は、ステップS23の処理を終えると、参加ノード追加処理を終了させる。
図5(b)は、本実施形態におけるP2P用DNSサーバSPの制御部11の追加クラス化ホスト名決定処理における処理例を示すフローチャートである。先ず、制御部11は、受信した新規ノード追加メッセージに、コンテンツ保存情報が含まれているか否かを判定する(ステップS31)。このとき、制御部11は、新規ノード追加メッセージにコンテンツ保存情報が含まれていると判定した場合には(ステップS31:YES)、参加してきたノードが最も多く保存しているコンテンツに対応するクラス化ホスト名を、そのノードのIPアドレスの追加対象として決定する(ステップS32)。具体的に、制御部11は、コンテンツ保存情報と一致するクラス化ホスト名を、追加対象として決定する。制御部11は、ステップS32の処理を終えると、ステップS34に移行する。
ステップS31において、制御部11は、新規ノード追加メッセージにコンテンツ保存情報が含まれていないと判定した場合には(ステップS31:NO)、単位時間あたり問い合わせ回数が最も多いクラス化ホスト名を、追加対象として決定する(ステップS33)。具体的に、制御部11は、各問い合わせ回数情報について、問い合わせ回数情報に含まれる全要素の値を合算して、単位時間あたり問い合わせ回数を求める。そして、制御部11は、計算された単位時間あたり問い合わせ回数が最も多い問い合わせ回数情報に対応するクラス化ホスト名を、追加対象として決定する。制御部11は、ステップS33の処理を終えると、ステップS34に移行する。
ステップS34において、制御部11は、追加対象として決定されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値A以上であるか否かを判定する。このとき、制御部11は、追加対象として決定されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値A以上ではないと判定した場合には(ステップS34:NO)、追加クラス化ホスト名決定処理を終了させる。
一方、制御部11は、追加対象として決定されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値A以上であると判定した場合には(ステップS34:YES)、追加対象として決定されたクラス化ホスト名を分割し、そのクラス化ホスト名が格納されたレコードを分割する(ステップS35)。なお、分割の詳細な処理内容は、ゾーン情報の詳細の項において既に説明されている。次いで、制御部11は、分割された複数のクラス化ホスト名のうち何れか1つのクラス化ホスト名を、追加対象として決定する(ステップS36)。制御部11は、ステップS36の処理を終えると、追加クラス化ホスト名決定処理を終了させる。
図5(c)は、本実施形態におけるP2P用DNSサーバSPの制御部11の生存確認・離脱ノード削除処理における処理例を示すフローチャートである。先ず、制御部11は、ゾーン情報に設定されているIPアドレスのうち1つのIPアドレスを取得する(ステップS41)。次いで、制御部11は、取得したIPアドレスに対応するノードの生存確認を行う(ステップS42)。具体的に、制御部11は、取得したIPアドレスに対応するノードに生存確認要求メッセージを送信する。そして、制御部11は、ノードからの生存確認応答メッセージの受信待ちを行う。
次いで、制御部11は、取得したIPアドレスに対応するノードが生存しているか否かを判定する(ステップS43)。このとき、制御部11は、生存確認要求メッセージを送信してから所定時間が経過する前に生存確認応答メッセージを受信した場合には、ノードが生存していると判定する(ステップS43:YES)。この場合、制御部11は、ステップS47に移行する。
一方、制御部11は、生存確認要求メッセージを送信してから所定時間が経過しても生存確認応答メッセージを受信しなかった場合には、ノードは生存していないと判定する(ステップS43:NO)。この場合、制御部11は、取得したIPアドレスをゾーン情報から削除することにより、IPアドレスとクラス化ホスト名との対応付けを削除する(ステップS44)。次いで、制御部11は、IPアドレスが削除されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値B以下であるか否かを判定する(ステップS45)。このとき、制御部11は、IPアドレスが削除されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値B以下ではないと判定した場合には(ステップS45:NO)、ステップS47に移行する。
一方、制御部11は、IPアドレスが削除されたクラス化ホスト名に現在対応付けられているIPアドレスの個数が閾値B以下であると判定した場合には(ステップS45:YES)、IPアドレスが削除されたクラス化ホスト名と他のクラス化ホスト名とを統合し、これらのクラス化ホスト名が格納されていたレコードを統合する(ステップS46)。なお、統合の詳細な処理内容は、ゾーン情報の詳細の項において既に説明されている。次いで、制御部11は、ステップS47に移行する。
ステップS47において、制御部11は、ゾーン情報に設定されているIPアドレスのうちまだ取得していないIPアドレスが存在するか否かを判定する。このとき、制御部11は、まだ取得していないIPアドレスが存在すると判定した場合には(ステップS47:YES)、まだ取得していないIPアドレスのうち1つのIPアドレスを取得する(ステップS48)。次いで、制御部11は、ステップS42に移行する。一方、制御部11は、まだ取得していないIPアドレスが存在しないと判定した場合には(ステップS47:NO)、生存確認・離脱ノード削除処理を終了させる。
なお、上記実施形態においては、本発明のノード装置をルータに適用していた。しかしながら、本発明のノード装置を、例えば、プロキシサーバ、ロードバランサ、Webアクセラレータ等の、情報を中継する機能を有するネットワーク機器に適用しても良い。また、本発明のノード装置を、例えば、キャッシュサーバ、エッジサーバ等のサーバ装置に適用しても良い。
また、本発明の情報処理装置を、上記実施形態のP2P用DNSサーバSPとローカルDNSサーバSLとの両方の機能を兼ね備えたDNSサーバに適用しても良い。この場合、本発明の問い合わせ装置は、ユーザ端末Tn−lとなる。
また、上記実施形態においては、オーバーレイネットワークに、DHTを利用したピアツーピアネットワークが適用されていたが、これに限られるものではない。例えば、他のピアツーピアシステム、または、オーバーレイネットワークを用いたシステムが適用されても良い。DHTを利用しないピアツーピアシステムとしては、例えば、ハイブリッド型のピアツーピアシステムがある。