(57)【要約】      （修正有）【課題】サーバへの負荷を軽減させ、ノード装置における省エネをも向上させ得る通信システム、稼動制御方法、ノード装置及びノード処理プログラムを提供する。【解決手段】ネットワークを介して通信可能であり、コンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを稼動状態にある他のノード装置、且つ当該コンテンツデータを提供するサーバ装置から取得可能とした通信システムの前記ノード装置であって、前記コンテンツデータを提供するために前記サーバ装置に課されるサーバ負荷量を取得するサーバ負荷量取得手段と、稼動停止指令の有無を判断する稼動停止判断手段と、前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が予め設定の基準量以上であるか否かを判断する基準量判断手段と、前記サーバ負荷量が前記基準量以上でないと判断された場合には自己の稼動を停止する稼動停止手段と、を備える。【選択図】図７
2008181408.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置であって、
前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得するサーバ負荷量取得手段と、
稼動停止指令があったか否かを判断する稼動停止判断手段と、
前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する基準量判断手段と、
前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する稼動停止手段と、
を備えることを特徴とするノード装置。
【請求項２】
請求項１に記載のノード装置において、
前記サーバ負荷量が、前記基準量以上であると判断された場合には、稼動状態から、稼動の停止を待機する稼動停止待機状態に切り換える状態切換手段を更に備えることを特徴とするノード装置。
【請求項３】
請求項１又は２に記載のノード装置において、
前記サーバ負荷量取得手段は、前記複数のノード装置により前記コンテンツデータの要求が見込まれる推定需要量と、前記コンテンツデータの要求に対して前記サーバ装置によらず各前記ノード装置により応じることが可能な供給可能量との差に基づいて前記サーバ負荷量を算出して取得することを特徴とするノード装置。
【請求項４】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置であって、
前記通信システムにおいて稼動状態にあるノード装置の数を取得するノード数取得手段と、
稼動停止指令があったか否かを判断する稼動停止判断手段と、
前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断するノード数判断手段と、
前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する稼動停止手段と、
を備えることを特徴とするノード装置。
【請求項５】
請求項４に記載のノード装置において、
前記ノード装置の数が、前記所定範囲内にあると判断された場合には、稼動状態から、稼動の停止を待機する稼動停止待機状態に切り換える状態切換手段を更に備えることを特徴とするノード装置。
【請求項６】
請求項４又は５に記載のノード装置において、
前記Ｎ１は、前記稼動状態にあるノード装置の数が増加することにより、前記コンテンツデータの提供のため前記サーバ装置に課されるサーバ負荷量が増加し予め設定された基準量となる前記ノード装置の数に相当し、
前記Ｎ２は、前記稼動状態にあるノード装置の数が更に増加することにより、前記サーバ負荷量が減少し前記基準量となる前記ノード装置の数に相当することを特徴とするノード装置。
【請求項７】
コンピュータを、請求項１乃至６の何れかに記載のノード装置として機能させることを特徴とするノード処理プログラム。
【請求項８】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムであって、
前記ノード装置は、
前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得するサーバ負荷量取得手段と、
稼動停止指令があったか否かを判断する稼動停止判断手段と、
前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する基準量判断手段と、
前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する稼動停止手段と、
を備えることを特徴とする通信システム。
【請求項９】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置の稼動制御方法であって、
前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得する工程と、
稼動停止指令があったか否かを判断する工程と、
前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する工程と、
前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する工程と、
を備えることを特徴とする稼動制御方法。
【請求項１０】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムであって、
前記ノード装置は、
前記通信システムにおいて稼動状態にあるノード装置の数を取得するノード数取得手段と、
稼動停止指令があったか否かを判断する稼動停止判断手段と、
前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断するノード数判断手段と、
前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する稼動停止手段と、
を備えることを特徴とする通信システム。
【請求項１１】
ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置の稼動制御方法であって、
前記ノード装置は、
前記通信システムにおいて稼動状態にあるノード装置の数を取得する工程と、
稼動停止指令があったか否かを判断する工程と、
前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断する工程と、
前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する工程と、
を備えることを特徴とする稼動制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型のコンテンツ配信システムに関する。
【背景技術】
【０００２】
この種のコンテンツ配信システムにおいては、複数のコンテンツデータ（ファイル）を複数のノード装置に分散配置（分散保存）させておくシステムが知られており、これにより、対故障性やアクセスの分散性を高められている。このように分散保存されたコンテンツデータの所在は、例えば特許文献１に開示されるような分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用して効率良く検索可能になっており、これにより、オーバーレイネットワークに参加している各ノード装置は、所望のコンテンツデータを他のノード装置から取得することができる。
【０００３】
ところで、オーバーレイネットワークに参加しているノード装置の数が少ないほど、コンテンツデータを取得するまでの時間が非常に長かったり、コンテンツデータの取得が失敗する確率が高くなる。また、コンテンツデータがコンテンツ配信システムに投入され（例えば、コンテンツ投入サーバによりあるノード装置に初めて保存され）て間もないうちは、当該コンテンツデータを保存しているノード装置の数が少ないため、コンテンツデータを取得するまでの時間が非常に長かったり、コンテンツデータの取得が失敗する確率が高くなる。
【０００４】
これを解消するため、別に、コンテンツ提供サーバを設置して、各ノード装置が、当該コンテンツ提供サーバからも所望のコンテンツデータを取得することが考えられる。
【特許文献１】特開２００６−１９７４００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記オーバーレイネットワークに参加しているノード装置の数は、例えばノード装置の電源ＯＮ／ＯＦＦにより変動し不安定であるため、場合によっては、コンテンツ提供サーバへの負荷集中が生じ、当該サーバへの負荷がサーバ能力限界を超えるという問題が生じる可能性がある。
【０００６】
このような問題を回避するためには、ノード装置の電源を切らせずに常時オーバーレイネットワークに参加していることが望ましいが、ノード装置の電源を絶対に切らせないようにすることは、電力を無駄に消費し、省エネの観点から望ましくない。
【０００７】
本発明は、以上の点に鑑みてなされたものであり、コンテンツ提供サーバへの負荷を軽減させつつ、各ノード装置における省エネをも向上させることが可能な通信システム、稼動制御方法、ノード装置及びノード処理プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置であって、前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得するサーバ負荷量取得手段と、稼動停止指令があったか否かを判断する稼動停止判断手段と、前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する基準量判断手段と、前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する稼動停止手段と、を備えることを特徴とする。
【０００９】
この発明によれば、稼動停止指令があったと判断された場合には、前記サーバ装置に課される負荷を示すサーバ負荷量が、予め設定された基準量以上であるか否かを判断し、前記サーバ負荷量が、前記基準量以上でないと判断された場合に自己の稼動を停止するように構成したので、各ノード装置において自律的に最適な稼動制御を行い、前記サーバ装置への負荷を軽減させつつ、当該ノード装置における省エネをも向上させることができる。
【００１０】
請求項２に記載の発明は、請求項１に記載のノード装置において、前記サーバ負荷量が、前記基準量以上であると判断された場合には、稼動状態から、稼動の停止を待機する稼動停止待機状態に切り換える状態切換手段を更に備えることを特徴とする。
【００１１】
この発明によれば、前記サーバ装置への負荷を軽減させつつ、当該ノード装置における省エネをも向上させることができる。
【００１２】
請求項３に記載の発明は、請求項１又は２に記載のノード装置において、前記サーバ負荷量取得手段は、前記複数のノード装置により前記コンテンツデータの要求が見込まれる推定需要量と、前記コンテンツデータの要求に対して前記サーバ装置によらず各前記ノード装置により応じることが可能な供給可能量との差に基づいて前記サーバ負荷量を算出して取得することを特徴とする。
【００１３】
この発明によれば、ノード装置が前記サーバ負荷量を算出するので、ネットワークに負荷をかけず、より迅速にサーバ負荷量を取得することができる。
【００１４】
請求項４に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置であって、前記通信システムにおいて稼動状態にあるノード装置の数を取得するノード数取得手段と、稼動停止指令があったか否かを判断する稼動停止判断手段と、前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断するノード数判断手段と、前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する稼動停止手段と、を備えることを特徴とする。
【００１５】
この発明によれば、稼動停止指令があったと判断された場合には、前記通信システムにおいて稼動状態にあるノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断し、前記ノード装置の数が、前記所定範囲内にないと判断された場合に自己の稼動を停止するように構成したので、各ノード装置において自律的に最適な稼動制御を行い、前記サーバ装置への負荷を軽減させつつ、当該ノード装置における省エネをも向上させることができる。
【００１６】
請求項５に記載の発明は、請求項４に記載のノード装置において、前記ノード装置の数が、前記所定範囲内にあると判断された場合には、稼動状態から、稼動の停止を待機する稼動停止待機状態に切り換える状態切換手段を更に備えることを特徴とする。
【００１７】
この発明によれば、前記サーバ装置への負荷を軽減させつつ、当該ノード装置における省エネをも向上させることができる。
【００１８】
請求項６に記載の発明は、請求項４又は５に記載のノード装置において、前記Ｎ１は、前記稼動状態にあるノード装置の数が増加することにより、前記コンテンツデータの提供のため前記サーバ装置に課されるサーバ負荷量が増加し予め設定された基準量となる前記ノード装置の数に相当し、前記Ｎ２は、前記稼動状態にあるノード装置の数が更に増加することにより、前記サーバ負荷量が減少し前記基準量となる前記ノード装置の数に相当することを特徴とする。
【００１９】
請求項７に記載のノード処理プログラムの発明は、コンピュータを、請求項１乃至６の何れかに記載のノード装置として機能させることを特徴とする。
【００２０】
請求項８に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムであって、前記ノード装置は、前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得するサーバ負荷量取得手段と、稼動停止指令があったか否かを判断する稼動停止判断手段と、前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する基準量判断手段と、前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する稼動停止手段と、を備えることを特徴とする。
【００２１】
請求項９に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置の稼動制御方法であって、前記複数のノード装置に対して前記コンテンツデータを提供するために前記サーバ装置に課される負荷を示すサーバ負荷量を取得する工程と、稼動停止指令があったか否かを判断する工程と、前記稼動停止指令があったと判断された場合には、前記サーバ負荷量が、予め設定された基準量以上であるか否かを判断する工程と、前記サーバ負荷量が、前記基準量以上でないと判断された場合には、自己の稼動を停止する工程と、を備えることを特徴とする。
【００２２】
請求項１０に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムであって、前記ノード装置は、前記通信システムにおいて稼動状態にあるノード装置の数を取得するノード数取得手段と、稼動停止指令があったか否かを判断する稼動停止判断手段と、前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断するノード数判断手段と、前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する稼動停止手段と、を備えることを特徴とする。
【００２３】
請求項１１に記載の発明は、ネットワークを介して互いに通信可能であり、取得したコンテンツデータを保存可能な複数のノード装置の夫々が、自己が保存していないコンテンツデータを前記ネットワークを介して稼動状態にある他のノード装置から取得可能とし、且つ、夫々の前記ノード装置が、自己が保存していないコンテンツデータを前記ネットワークを介して当該コンテンツデータを提供するサーバ装置からも取得可能とした通信システムにおける前記ノード装置の稼動制御方法であって、前記ノード装置は、前記通信システムにおいて稼動状態にあるノード装置の数を取得する工程と、稼動停止指令があったか否かを判断する工程と、前記稼動停止指令があったと判断された場合には、前記ノード装置の数が、Ｎ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの所定範囲内にあるか否かを判断する工程と、前記ノード装置の数が、前記所定範囲内にないと判断された場合には、自己の稼動を停止する工程と、を備えることを特徴とする。
【発明の効果】
【００２４】
本発明によれば、各ノードにおいて自律的に最適な稼動制御を行い、サーバ装置への負荷を軽減させつつ、ノード装置における省エネをも向上させることができる。
【発明を実施するための最良の形態】
【００２５】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、ＤＨＴ（Distributed Hash Table）を利用したコンテンツ配信システムに本発明を適用した場合の実施形態である。
【００２６】
［１．コンテンツ配信システムの構成等］
始めに、図１を参照して、通信システムの一例としてのコンテンツ配信システムの概要構成等について説明する。
【００２７】
図１は、本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【００２８】
図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、および通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界のネットワーク）８が構築されている。なお、図１の例におけるネットワーク（通信ネットワーク）８には、メッセージ（パケット）を転送するためのルータが、適宜挿入されているが図示を省略している。
【００２９】
コンテンツ配信システムＳは、このようなネットワーク８を介して互いに通信可能な複数のノード装置（以下、「ノード」という）Ａ，Ｂ，Ｃ・・・Ｘ，Ｙ，Ｚ・・・を備えて構成されることになり、ピアツーピア方式のネットワークシステムとなっている。各ノードＡ，Ｂ，Ｃ・・・Ｘ，Ｙ，Ｚ・・・には、固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。かかる製造番号およびＩＰアドレスは、複数のノード間で重複しないものである。
【００３０】
このようなコンテンツ配信システムＳにおいて、当該ノード同士が、互いに情報をやり取りする際には、お互いのＩＰアドレス等を知っていなければならない。
【００３１】
例えば、コンテンツを互いに共有するシステムにおいては、ネットワーク８に参加している各ノードが互いにネットワーク８に参加している全てのノードのＩＰアドレスを知っておくのが単純な手法であるが、端末数が何万何十万と多数になると、その全てのノードのＩＰアドレスを覚えておくのは現実的ではない。また、任意のノードの電源がＯＮ或いはＯＦＦとすると、各ノードにて記憶している当該任意のノードのＩＰアドレスの更新が頻繁になり、運用上困難となる。
【００３２】
そこで、１台のノードでは、ネットワーク８に参加している全てのノードのうち、必要最低限のノードのＩＰアドレスだけを覚えて（記憶して）おいて、ＩＰアドレスを知らない（記憶していない）ノードについては、各ノード間で互いに情報を転送し合って届けてもらうというシステムが考案されている。
【００３３】
このようなシステムの一例として、ＤＨＴを利用したアルゴリズムによって、図１の上部枠１００内に示すような、オーバーレイネットワーク９が構築されることになる。つまり、このオーバーレイネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するネットワークを意味する。
【００３４】
本実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバーレイネットワーク９を前提としており、このオーバーレイネットワーク９上に配置されたノードを、オーバーレイネットワーク９に参加しているノードという。
【００３５】
なお、オーバーレイネットワーク９への参加は、例えば、未参加のノードにおいて稼動指令があった（例えば、電源ＯＮ（入）指示がなされることによる）場合に、当該未参加のノードが既参加の任意のノード（例えば、常時電源が入っているコンタクトノード）に接続して参加要求を送ることによってなされる。このようにオーバーレイネットワーク９に参加したノードは、稼動状態となり、ＤＨＴを用いた後述するルーティングテーブル（コンテンツ配信システムＳ上における各種メッセージの転送先を規定した転送先テーブル）を利用して他のノードと互いに情報をやり取りすることが可能となる。一方、既参加（参加中）のノードにおいて稼動停止指令があった（例えば、電源ＯＦＦ（切）指示がなされることによる）場合には、当該既参加のノードはオーバーレイネットワーク９から脱退し、稼動停止状態となり、他のノードと互いに情報をやり取りすることが不能となる。
【００３６】
また、各ノードは、固有のノード識別情報としてのノードＩＤを有しており、当該ノードＩＤは、例えば、ＩＰアドレスあるいは製造番号を共通のハッシュ関数（例えば、ＳＨＡ−１等）によりハッシュ化して得た一定桁数からなるハッシュ値であり、一つのＩＤ空間に偏りなく分散して配置されることになる。このノードＩＤは、ノードの最大運用台数を収容できるだけのｂｉｔ数を持たせる必要がある。例えば、１２８ｂｉｔの番号とすれば、2128＝340×1036台のノードを運用できる。
【００３７】
このように共通のハッシュ関数により求められたノードＩＤは、当該ＩＰアドレスあるいは製造番号が異なれば、同じ値になる確率が極めて低いものである。なお、ハッシュ関数については公知であるので詳しい説明を省略する。
【００３８】
［１．１  ＤＨＴを用いたルーティングテーブルの作成手法］
次に、図２及び図３を参照して、ＤＨＴの内容であるルーティングテーブルの作成手法の一例について説明する。
【００３９】
図２は、ルーティングテーブルが作成される様子の一例を示す図であり、図３は、ルーティングテーブルの一例を示す図である。
【００４０】
各ノードに付与されたノードＩＤは、共通のハッシュ関数によって生成したため、図２（Ａ）乃至図２（Ｃ）に示す如く、同一のリング状のＩＤ空間上にさほど偏ることなく、散らばって存在するものとして考えることができる。同図は８ｂｉｔでノードＩＤを付与し、図示したものである。図中黒点はノードＩＤを示し、反時計回りでＩＤが増加するものとする。
【００４１】
先ず、図２（Ａ）に示す如く、ＩＤ空間が、所定の規則に従って幾つかのエリアに分割される（分けられる）。実際には、１６分割程度が良く用いられるが、説明を簡単にするためここでは４分割とし、ＩＤをビット長８Ｂｉｔの４進数で表すこととした。そして、ノードＮのノードＩＤを「1023」とし、このノードＮのルーティングテーブルを作る例について説明する。
【００４２】
（レベル１のルーティング）
ＩＤ空間を４分割とすると、それぞれのエリアは４進数で表すと最大桁が異なる４つのエリア「0XXX」、「1XXX」、「2XXX」、「3XXX」（Ｘは０から３の整数、以下同様。）で分けられる。ノードＮは、当該ノードＮ自身のノードＩＤが「1023」であるため、図中左下「1XXX」のエリアに存在することになる。
【００４３】
そして、ノードＮは、自己の存在するエリア（すなわち、「1XXX」のエリア）以外のエリアに存在する任意の各ノード（オーバーレイネットワーク９に参加中のノード）のノードＩＤ及びＩＰアドレス等（実際には、ポート番号も含まれる、以下同様）をレベル１のテーブルにおける各欄（テーブルエントリー）に登録（記憶）する。
【００４４】
図３（Ａ）がレベル１のテーブルの一例である。なお、レベル１のテーブルにおける２列目の欄は、ノードＮ自身を示しているため、ＩＰアドレス等を登録する必要は無い。また、各欄に登録される各ノードのノードＩＤ及びＩＰアドレス等は、例えば、オーバーレイネットワーク９への参加の際に、他のノードから取得されるようになっている（以下同様）。
【００４５】
（レベル２のルーティング）
次に、図２（Ｂ）に示す如く、上記４分割されたエリアのうち、ノードＮ自身の存在するエリアが更に４分割され、４つのエリア「10XX」、「11XX」、「12XX」、「13XX」に分けられる。
【００４６】
そして、ノードＮは、上記と同様に自己の存在するエリア以外のエリアに存在する任意の各ノード（オーバーレイネットワーク９に参加中のノード）のノードＩＤ及びＩＰアドレス等をレベル２のテーブルにおける各欄（テーブルエントリー）に登録する。
【００４７】
図３（Ｂ）がレベル２のテーブルの一例である。なお、レベル２のテーブルにおける１列目の欄は、ノードＮ自身を示しているため、ＩＰアドレス等を登録する必要は無い。
【００４８】
（レベル３のルーティング）
更に、図２（Ｃ）に示す如く、上記４分割されたエリアのうち、ノードＮ自身の存在するエリアが更に４分割され、４つのエリア「100X」、「101X」、「102X」、「103X」に分けられる。
【００４９】
そして、ノードＮは、上記と同様に自己の存在するエリア以外のエリアに存在する任意の各ノード（オーバーレイネットワーク９に参加中のノード）のノードＩＤ及びＩＰアドレス等をレベル３のテーブルにおける各欄（テーブルエントリー）に登録する。
【００５０】
図３（Ｃ）がレベル３のテーブルの一例である。なお、レベル３のテーブルにおける３列目の欄は、ノードＮ自身を示しているため、ＩＰアドレス等を登録する必要は無く、２列目及び４列目の欄はそのエリアにノードが存在しないため空白となる。
【００５１】
このようにして、レベル４まで同様にルーティングテーブルが図３（Ｄ）に示す如く作成されることにより、８ｂｉｔのＩＤ全てを網羅することができる。また、レベルが上がる（高くなる）毎にテーブルの中に空白が目立つようになる。
【００５２】
以上説明した手法（規則）に従って作成したルーティングテーブルを、全てのノードが夫々作成して所有することになる（かかるルーティングテーブルの作成は、例えば、未参加のノードがオーバーレイネットワーク９に参加する際に行われるが、本発明とは直接の関係がないので詳しい説明を省略する）。
【００５３】
つまり、各ノードは、複数に分けられた各エリアに属する一のノードのノードＩＤ及びＩＰアドレス等を、夫々のエリアに対応付けて一の段階（レベル）として規定し、さらに自己が属するエリアが複数のエリアに分けられ、当該分けられた各エリアに属する一のノードのＩＰアドレス等を、夫々のエリアに対応付けて次の段階（レベル）として規定するルーティングテーブルを記憶している。
【００５４】
なお、ノードＩＤの桁数に応じてレベルの数が決まり、進数の数に応じて図３（Ｄ）における各レベルの注目桁の数が決まる。例えば、１６桁１６進数である場合には、６４ｂｉｔのＩＤとなり、レベル１６で注目桁の（英）数字は０〜Ｆとなる。
【００５５】
また、各ノードにおけるルーティングテーブルは、例えば、他のノードにメッセージを転送する際等に更新されるようになっており、かかる更新において、オーバーレイネットワーク９から脱退したノードのノードＩＤ及びＩＰアドレス等は、当該ルーティングテーブルにおける欄から削除されるようになっている。
【００５６】
［１．２  コンテンツデータの保存及び発見方法］
次に、コンテンツ配信システムＳにおいて取得可能なコンテンツデータの保存及び発見方法について説明する。
【００５７】
オーバーレイネットワーク９においては、様々な種類のコンテンツ（例えば、映画や音楽等）データが複数のノードに分散して保存（格納）されている（言い換えれば、コンテンツデータが複製されその複製情報であるレプリカのファイルが分散保存されている）。
【００５８】
例えば、ノードＡ及びノードＤには、タイトルがＸＸＸの映画のコンテンツデータが保存されており、一方、ノードＢ及びノードＣには、タイトルがＹＹＹの映画のコンテンツデータが保存されるというように、複数のノード（以下、コンテンツデータを保存するノドを「コンテンツ保持ノード」という）に分散されて保存される。
【００５９】
また、これらのコンテンツデータには、夫々、コンテンツ名（タイトル）及びコンテンツＩＤ（コンテンツ毎に固有のコンテンツ識別情報）等の情報が付加されている。
【００６０】
このコンテンツＩＤは、例えば、コンテンツ名＋任意の数値（或いは、当該コンテンツデータの先頭数バイトでも良い）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて生成される（ノードＩＤと同一のＩＤ空間に配置）。或いは、システム運営者が、コンテンツ毎に一意のＩＤ値（ノードＩＤと同一ビット長）を付与しても良い。この場合は、コンテンツカタログ情報に、コンテンツ名とそのコンテンツＩＤの対応が書かれた状態で、各ノードに配布される。
【００６１】
また、このように分散保存されているコンテンツデータの所在、つまり、当該コンテンツデータを保存したノードのＩＰアドレス等と、当該コンテンツデータに対応するコンテンツＩＤ等の組が含まれるインデックス情報が、当該コンテンツデータの所在の管理元のノード（以下、「ルートノード」、又は「コンテンツ（コンテンツＩＤ）のルートノード」という）等により記憶（インデックスキャッシュに記憶）、管理されるようになっている。
【００６２】
例えば、タイトルがＸＸＸの映画のコンテンツデータのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＭにより管理され、タイトルがＹＹＹの映画のコンテンツデータのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＯにより管理される。
【００６３】
つまり、コンテンツ毎にルートノードが分けられるので負荷分散が図らており、しかも、同一のコンテンツデータ（コンテンツＩＤが同一）が、夫々、複数のコンテンツ保持ノードに保存されている場合であっても、かかるコンテンツデータのインデックス情報は、１つのルートノードで管理することができる。また、このようなルートノードは、例えば、コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノードであるように定められる。
【００６４】
このようにしてコンテンツデータを保存したノード（コンテンツ保持ノード）は、当該コンテンツデータを保存したことをそのルートノードに知らせる（つまり、オーバーレイネットワーク９上で公開する）ために、そのコンテンツデータのコンテンツＩＤ及び自己のＩＰアドレス等が含まれるパブリッシュ（登録通知）メッセージ（コンテンツデータを保存したので、ＩＰアドレス等の登録の要求を示す登録メッセージ）を生成し、該パブリッシュメッセージを、そのルートノードに向けて送出する。これにより、パブリッシュメッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになる。
【００６５】
図４は、コンテンツ保持ノードから送出されたパブリッシュメッセージの流れの一例をＤＨＴのノードＩＤ空間にて示した概念図である。
【００６６】
図４の例において、例えば、コンテンツ保持ノードであるノードＡは、自己のルーティングテーブルにおけるレベル１のテーブルを参照して、パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードＨのＩＰアドレス等を取得し、そのＩＰアドレス等宛てに、上記パブリッシュメッセージを送信する。
【００６７】
これに対して、ノードＨは、当該パブリッシュメッセージを受信し、自己のルーティングテーブルにおけるレベル２のテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードＩのＩＰアドレス等を取得し、そのＩＰアドレス等宛てに、上記パブリッシュメッセージを転送する。
【００６８】
これに対して、ノードＩは、当該パブリッシュメッセージを受信し、自己のルーティングテーブルにおけるレベル３のテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードＭのＩＰアドレス等を取得し、そのＩＰアドレス等宛てに、上記パブリッシュメッセージを転送する。
【００６９】
これに対して、ノードＭは、パブリッシュメッセージを受信し、自己のルーティングテーブルにおけるレベル４のテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤが自己のものである、つまり、自分がそのコンテンツＩＤのルートノードであることを認識し、当該パブリッシュメッセージに含まれるＩＰアドレス等及びコンテンツＩＤの組を含むインデックス情報を登録（インデックスキャッシュ領域に記憶）することになる。
【００７０】
なお、パブリッシュメッセージに含まれるＩＰアドレス等及びコンテンツＩＤの組を含むインデックス情報は、コンテンツ保持ノードからルートノードに至るまでの転送経路におけるノード（以下、「中継ノード」という。図４の例では、ノードＨ、及びノードＩ）においても登録（キャッシュ）される（このように、インデックス情報をキャッシュする中継ノードをキャッシュノードという）。
【００７１】
そして、あるノードのユーザが、所望するコンテンツデータを取得したい場合、当該コンテンツデータ（自己のノードに保存されていないコンテンツデータ）の取得を望むノード（以下、「ユーザノード」という）は、当該ユーザによりコンテンツカタログ情報（コンテンツリストともいう）から選択されたコンテンツデータのコンテンツＩＤを含むコンテンツ所在問合せメッセージを、自己のルーティングテーブルにしたがって他のノードに対して送出する。これにより、当該コンテンツ所在問合せメッセージは、上述したパブリッシュメッセージと同様に、コンテンツＩＤをキーとするＤＨＴルーティングによって、いくつかの中継ノードを経由（転送）されて、そのコンテンツＩＤのルートノードに辿り着く。そして、上記ユーザノードは、当該ルートノードから、上述したそのコンテンツデータのインデックス情報を取得（受信）し、これに含まれＩＰアドレス等に基づいて上記コンテンツデータを保存しているコンテンツ保持ノードに接続し、そこから当該コンテンツデータを取得（ダウンロード）することが可能になる。或いは、当該ルートノードが当該インデックス情報に示されたコンテンツ保持ノードに対してコンテンツ送信要求メッセージ（ユーザノードのＩＰアドレス等を含み、当該ユーザノードに対してコンテンツデータの送信要求を示す要求情報）を送信することにより、ユーザノードは、上記コンテンツ保持ノードから当該コンテンツデータの提供を受けることが可能になる。
【００７２】
なお、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該ルートノードと同じインデックス情報をキャッシュしている中継ノード（キャッシュノード）から当該ＩＰアドレス等を取得（受信）することもできる。
【００７３】
こうしてコンテンツデータを取得したユーザノードは、上述したパブリッシュメッセージを、そのルートノードに向けて送出することで、新たに、当該取得したコンテンツデータを保存するコンテンツ保持ノードとなる。
【００７４】
なお、上記コンテンツカタログ情報には、コンテンツ配信システムＳにおいて取得可能なコンテンツデータの属性情報（例えば、コンテンツＩＤ、コンテンツ名、ジャンル、アーティスト名、出演者（コンテンツが映画や放送番組の場合のキャスト）、監督名等）が記述されており、例えば、コンテンツカタログ情報を管理するカタログ管理サーバから全ノードに対して配信されるようになっている。
【００７５】
［１．３  コンテンツ提供サーバＳＡによるコンテンツデータの提供］
上述したように、各ノードは、ＤＨＴルーティングにより、所望のコンテンツデータを、稼動状態にある他のノードから取得可能であるが、オーバーレイネットワーク９に参加しているノードの数が少ないほど、コンテンツデータを取得するまでの時間が非常に長かったり、コンテンツデータの取得が失敗する確率が高くなる。また、コンテンツデータがコンテンツ配信システムＳに投入され（例えば、コンテンツ投入サーバによりあるノード装置に初めて保存され）て間もないうちは、当該コンテンツデータを保存しているノードの数が少ないため、コンテンツデータを取得するまでの時間が非常に長かったり、コンテンツデータの取得が失敗する確率が高くなる。
【００７６】
これを解消するため、本実施形態におけるコンテンツ配信システムＳでは、コンテンツデータを提供する一又は複数のコンテンツ提供サーバ（サーバ装置の一例）ＳＡを備えており、各ノードは、当該コンテンツ提供サーバＳＡに接続し、所望のコンテンツデータを要求することにより、当該コンテンツ提供サーバＳＡからも所望のコンテンツデータを取得可能になっている。
【００７７】
図５は、コンテンツ提供サーバＳＡのサーバ負荷量と、参加ノード数との関係を示す図である。
【００７８】
図５の曲線５１に示すように、複数のノードに対してコンテンツデータを提供するためにコンテンツ提供サーバＳＡに課される負荷を示すサーバ負荷量は、オーバーレイネットワーク９に参加し稼動状態にあるノードの数が増加する（ノードの数が０からＮ１まで）にしたがって増加していくことになるが、更に当該稼動状態にあるノードの数が増加していく（ノードの数がＮ１以上）と、コンテンツデータの要求に対してコンテンツ提供サーバＳＡによらず各ノードにより応じる割合も増加してくるので、次第にサーバ負荷量が減少してくることになる。
【００７９】
また、図５の曲線５２に示すように、コンテンツデータの種類が多いと、コンテンツデータの種類が少ないとき（曲線５１）よりも、上記サーバ負荷量が増加し、ノードの数がＮ１（Ｎ１は自然数）からＮ２（Ｎ２はＮ１より大きい自然数）までの範囲内にある場合、コンテンツ提供サーバＳＡの能力（性能）限界値（サーバ能力限界値）を超えることとなる。ここで、Ｎ１は、稼動状態にあるノードの数が増加することにより、コンテンツデータの提供のためコンテンツ提供サーバＳＡに課されるサーバ負荷量が増加しコンテンツ提供サーバＳＡの能力限界値となるノードの数に相当し、Ｎ２は、稼動状態にあるノードの数が更に増加することにより、上記サーバ負荷量が減少し上記能力限界値となるノードの数に相当する。
【００８０】
このため、本実施形態においては、後述するように、各ノードは、当該サーバ負荷量が当該能力限界値を超えないように自律的に制御するようになっている。
【００８１】
なお、コンテンツ提供サーバＳＡの能力限界値は、当該コンテンツ提供サーバＳＡのコンテンツデータの提供能力を示すパラメータ、例えば、ＣＰＵの演算能力（クロック周波数）、及びネットワーク８の有効帯域（データ伝送速度）等に基づいて決定され（このとき、ある程度のマージンも考慮される）、予め各ノードにおいて設定されるようになっている。
【００８２】
［２．ノードの構成等］
次に、図６を参照して、ノードの構成及び機能について説明する。
【００８３】
図６は、ノードの概要構成例を示す図である。
【００８４】
各ノードは、図６に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、コンテンツデータ、コンテンツカタログ情報、ルーティングテーブル及び各種プログラム等を記憶保存（格納）するためのＨＤ等から構成された記憶部１２と、受信されたコンテンツデータ等を一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）およびオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノード又はサーバとの間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４および通信部２０はバス２２を介して相互に接続されている。また、ノードにおける各構成部分には、電源ＯＮにより電源供給がなされる。なお、ノードとしては、パーソナルコンピュータ、ＳＴＢ（Set Top Box）、或いは、ＴＶ受信機等を適用可能である。また、記憶部１２には、上述したコンタクトノードのＩＰアドレス等及びコンテンツ提供サーバＳＡのＩＰアドレス等が予め記憶されている。
【００８５】
このような構成において、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラム（本発明のノード処理プログラムを含む）を読み出して実行することにより、全体を統括制御すると共に、オーバーレイネットワーク９への参加により上述したユーザノード、中継ノード、ルートノード、キャッシュノード、及びコンテンツ保持ノードの少なくとも何れか一つのノードとしての処理を行うようになっており、更に、本発明におけるサーバ負荷量取得手段、稼動停止判断手段、基準量判断手段、稼動停止手段、及び状態切換手段等として機能するようになっている。
【００８６】
より具体的には、制御部１１は、上述したコンテンツ提供サーバＳＡに課される負荷を示すサーバ負荷量を取得するようになっている。例えば、制御部１１は、複数のノードによりコンテンツデータの要求が見込まれる推定需要量Ｒと、当該コンテンツデータの要求に対してコンテンツ提供サーバＳＡによらず各ノードにより応じることが可能な（つまり、ノード間で賄うことが可能な）供給可能量Ｓとの差に基づいて上記サーバ負荷量（例えば、推定需要量Ｒ−供給可能量Ｓ＝サーバ負荷量）を算出して取得する。なお、当該サーバ負荷量の算出は、所定のサーバにより行われ、各ノードに通知されるものであっても構わないが、各ノードにより算出される構成の方が、ネットワーク８に負荷をかけることなく、なおかつ、より迅速にサーバ負荷量を取得できるので望ましい。
【００８７】
ここで、推定需要量Ｒは、例えば、コンテンツ配信システムＳにおいて稼動状態（後述する稼動停止待機状態も含む）にあるノード（つまり、オーバーレイネットワーク９に参加中のノード）の数と、コンテンツデータの推定視聴率（％）との積に基づいて決定される。
【００８８】
稼動状態にあるノードの数（おおよその数）は、各ノードにおいて記憶されるルーティングテーブルに基づいて（当該ルーティングテーブルの埋まり具合から）、制御部１１により算出（推定）することができる。例えば、一つのＩＤ空間にノードＩＤが偏りなく分散している場合において、上述した図３に示すレベル１のテーブルの各欄の全てにノードＩＤ及びＩＰアドレス等が登録されている（自己に対応する欄も登録されているとして数える）ならば、オーバーレイネットワーク９には少なくとも４4/4＝４1＝４台のノードが参加し稼動状態にあるという計算となり、また、例えば、上述した図３に示すレベル１及びレベル２のテーブルの各欄の全てにノードＩＤ及びＩＰアドレス等が登録されているならば、オーバーレイネットワーク９には少なくとも４8/4＝４2＝１６台のノードが参加し稼動状態にあるという計算となる。また、例えば、レベル１及びレベル２のテーブルの各欄の全てにノードＩＤ及びＩＰアドレス等が登録されており、且つ、レベル３のテーブルに空白の欄が２つあるならば（通常、低いレベルの欄から埋まっていく）、４10/4＝３２台のノードが参加し稼動状態にあるという計算となる。そして、例えば、ノードＩＤが１６桁１６進数である場合において、このルーティングテーブルのＫ個の欄にノードＩＤ及びＩＰアドレス等が登録されている（自己に対応する欄も登録されているとして数える）ものとすると、オーバーレイネットワーク９には、「１６Ｋ/16」台のノードが参加し稼動状態にあるという計算となる。
【００８９】
一方、コンテンツデータの推定視聴率（％）は、例えばサービスとして保障しなければならない視聴率であり、これは、例えば各ノードにおいて予め設定されているか、或いは、オーバーレイネットワーク９への参加後に取得される（例えば、コンテンツカタログ情報に記述される）ようになっている。なお、タイトルが異なるコンテンツデータ（ファイル）毎に人気度が変るため、その推定視聴率も変ってくるが、例えば、各コンテンツデータ（ファイル）の推定視聴率を平均したものが上記推定視聴率となる。
【００９０】
また、上記供給可能量Ｓは、１ノード当たりのＣＰＵの演算能力（クロック周波数）やネットワーク８の有効帯域（データ伝送速度）等の配信能力の他、全ノードにおけるコンテンツデータの総記憶容量、提供されるコンテンツデータの総データ量、検索（上述したＤＨＴルーティング）によるコンテンツデータの発見・取得確率等によって決定される。
【００９１】
一例として、稼動状態にあるノードの数が５００台、推定視聴率が８０％、提供されるコンテンツデータの総データ量が１００ＧＢ、１ノード当たりのコンテンツデータの記憶容量が１００ＭＢ、及び検索によるコンテンツデータの発見・取得確率を９０％、と仮定すると、
推定需要量Ｒ＝５００台×８０％＝４００リクエスト、となる。
【００９２】
また、全ノードにおけるコンテンツデータの総記憶容量は、１００ＭＢ×５００台＝５０ＧＢとなるので、提供されるコンテンツデータの総データ量「１００ＧＢ」のうちの、１／２（５０ＧＢ／１００ＧＢ）のコンテンツデータが複数のノードに記憶保存されることになる。したがって、検索（上述したＤＨＴルーティング）によるコンテンツデータの発見・取得確率は、（５０ＧＢ／１００ＧＢ）×９０％＝４５％となり、
供給可能量Ｓ＝５００台×４５％＝２２５リクエスト、となる。
【００９３】
よって、サーバ負荷量は、４００−２２５＝１７５リクエスト、という計算となる。
【００９４】
そして、制御部１１は、稼動停止指令を認識（例えば、ユーザにより電源ＯＦＦ（切）指示がなされることによる）すると、上述したように取得したサーバ負荷量が、コンテンツ提供サーバＳＡの能力限界値（予め設定された基準量の一例）以上であるか（又は超えたか）否かを自ら判断して、サーバ負荷量が能力限界値以上でない（又は超えない）場合には自己の稼動を停止（例えば、ノードの電源を切る）し、能力限界値以上である（又は超えた）場合には自己の稼動の停止を待機する稼動停止待機状態に切り換えるようになっている。制御部１１は、他のノードからの要求に応じてコンテンツデータを提供するのに必要な電源（例えば、制御部１１、記憶部１２、及び通信部２０に供給される電源）以外の電源（例えば、表示部１６におけるディスプレイ等に供給される電源）を切ることにより、ノードが稼動停止待機状態となる。これにより、コンテンツ提供サーバＳＡのサーバ負荷量が能力限界値を超えることを防ぐことができる。
【００９５】
また、別の例として、制御部１１は、上述したように、稼動停止指令があった場合に、自己のルーティングテーブルに基づいて稼動状態（稼動停止待機状態も含む）にあるノードの数を算出し、当該算出したノードの数が、上述した図５に示すＮ１からＮ２までの範囲内にあるか否かを判断し（この場合、ノードは、例えば図５に示すような曲線５２を表す関数又はテーブルを予め記憶、又は算出することになる）、算出したノードの数が、Ｎ１からＮ２までの範囲内にない場合には自己の稼動を停止し、Ｎ１からＮ２までの範囲内にある場合には自己の稼動の停止を待機する稼動停止待機状態に切り換えるように構成しても良い。ここで、稼動状態にあるノードの数の算出は、所定のサーバにより行われ、各ノードに通知されるものであっても構わないが、各ノードにより算出される構成の方が、ネットワーク８に負荷をかけることなく、なおかつ、より迅速にノードの数を取得できるので望ましい。
【００９６】
なお、上記ノード処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしてもよい。
【００９７】
［３．コンテンツ配信システムの動作］
次に、図７及び図８等を参照して、コンテンツ配信システムＳの動作について説明する。
【００９８】
図７は、各ノードの制御部１１における処理を示すフローチャートであり、図８は、図７におけるファイル要求・取得処理の詳細を示すフローチャートである。
【００９９】
図７に示す処理は、例えばノードＮのユーザが入力部２１を操作して（例えば、電源ボタンを押す）電源ＯＮ（入）指示を行うことにより、当該ノードＮに対する稼動指令があった（稼動指令を制御部１１が認識した）場合に開始され、ノードＮの全ての電源がＯＮにされる（ステップＳ１）。
【０１００】
次いで、制御部１１は、オーバーレイネットワーク９への参加処理を実行する（ステップＳ２）。当該参加処理においては、上述したように、ノードＮがコンタクトノードに接続（記憶部１２に記憶されたコンタクトノードのＩＰアドレス等に基づき接続）して参加要求を行い、例えばコンタクトノード等から返信されたルーティングテーブルに基づき、自己のルーティングテーブルを作成する。こうして、当該ノードＮは、オーバーレイネットワーク９に参加することになる。
【０１０１】
次いで、制御部１１は、ユーザからファイル（コンテンツデータファイル）ＦＸの要求指示があったか否かを判別し（ステップＳ３）、当該要求指示がない場合には（ステップＳ３：ＮＯ）、ステップＳ５に進み、当該要求指示があった場合には（ステップＳ３：ＹＥＳ）、図８に示すファイル要求・取得処理を実行する（ステップＳ４）。当該ファイルＦＸの要求指示は、例えば表示部１６にコンテンツカタログ情報が表示された状態で、ユーザが入力部２１を操作して当該ファイルＦＸに対応するコンテンツ名を選択実行することにより行われる。
【０１０２】
図８に示すファイル要求・取得処理では、制御部１１は、図８に示すように、要求指示されたファイルＦＸを既に記憶部１２に記憶保存しているか否かを判別し（ステップＳ４１）、保存されていない場合には（ステップＳ４１：ＮＯ）、ステップＳ４２に進み、保存されている場合には（ステップＳ４１：ＹＥＳ）、これを記憶部１２から取得し（読み出し）ステップＳ４９に進む。
【０１０３】
ステップＳ４２では、制御部１１は、上記要求指示されたファイルＦＸに係るコンテンツデータのコンテンツＩＤを含むコンテンツ所在問合せメッセージを、上述したように、自己のルーティングテーブルにしたがって他のノード（つまり、当該コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノード）に対して送出する。これにより、当該コンテンツ所在問合せメッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによって、そのコンテンツＩＤのルートノードに向かって転送されていくことになる。また、このとき、タイマがセットされカウントが開始される。
【０１０４】
次いで、制御部１１は、一定時間（例えば、タイマによりセットされた３分）以内に上記要求指示されたファイルＦＸに係るコンテンツデータを保存しているコンテンツ保持ノードからアクセスがあり当該ファイルＦＸを送信可能である旨のメッセージを受信したか否かを判別し（ステップＳ４３）、当該メッセージを一定時間内に受信した場合には（ステップＳ４３：ＹＥＳ）、当該コンテンツ保持ノードからファイルＦＸを受信（取得）し（ステップＳ４４）、これを記憶部１２に記憶保存し（ステップＳ４７）、ステップＳ４８に進む。
【０１０５】
一方、上記コンテンツ保持ノードから当該ファイルＦＸを送信可能である旨のメッセージを受信することなく上記一定時間に達した（タイマがカウントアップした）場合（例えば、ネットワーク８における何らかの要因でコンテンツ所在問合せメッセージがルートノードに辿り着かなかったことによる）、又はコンテンツ保持ノードからファイルＦＸを送信可能でない旨のメッセージを受信した場合（例えば、当該コンテンツ保持ノードへのアクセス集中等による）には（ステップＳ４３：ＮＯ）、当該制御部１１は、コンテンツ提供サーバＳＡに接続（記憶部１２に記憶されたコンテンツ提供サーバＳＡのＩＰアドレス等に基づき接続）し、上記要求指示されたファイルＦＸに係るコンテンツデータをコンテンツ提供サーバＳＡに要求し（ステップＳ４５）、これに応じてコンテンツ提供サーバＳＡから送信された当該ファイルＦＸを受信（取得）し（ステップＳ４６）、これを記憶部１２に記憶保存し（ステップＳ４７）、ステップＳ４８に進む。
【０１０６】
ステップＳ４８では、制御部１１は、上述したように、当該コンテンツデータを保存したことをオーバーレイネットワーク９上で公開するために、当該コンテンツデータのコンテンツＩＤ及び自己のＩＰアドレス等が含まれるパブリッシュメッセージを生成し、該パブリッシュメッセージを、そのルートノードに向けて送出する。これにより、パブリッシュメッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着し、当該パブリッシュメッセージに含まれるＩＰアドレス等及びコンテンツＩＤの組を含むインデックス情報が登録されることになる。
【０１０７】
そして、ステップＳ４９では、例えばユーザからの再生指示に応じて、取得したファイルＦＸに係るコンテンツデータを再生する再生処理が実行される。
【０１０８】
図７の処理に戻り、ステップＳ５では、制御部１１は、他のノードからコンテンツ所在問合せメッセージを受信したか否かを判別しており、当該コンテンツ所在問合せメッセージを受信していない場合には（ステップＳ５：ＮＯ）、ステップＳ７に進み、当該コンテンツ所在問合せメッセージを受信した場合には（ステップＳ５：ＹＥＳ）、問い合わせメッセージ受信処理を実行する（ステップＳ６）。当該問い合わせメッセージ受信処理においては、制御部１１は、自己のルーティングテーブルを参照して、当該コンテンツ所在問合せメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを特定し、当該特定したノードＩＤが自己のノードＩＤである場合には、自己が当該コンテンツＩＤのルートノードであるので、当該コンテンツＩＤに対応するコンテンツデータを保存しているコンテンツ保持ノードに対して、コンテンツ送信要求メッセージ（ユーザノードのＩＰアドレス等を含み、ユーザノードに対してコンテンツデータの送信要求を示す要求情報）を送信する。一方、上記特定したノードＩＤが自己のノードＩＤでない場合には、制御部１１は、当該ノードＩＤに対応するノード（ルーティングテーブルに登録されているノード）に対して、上記コンテンツ所在問合せメッセージを転送する。
【０１０９】
ステップＳ７では、制御部１１は、コンテンツ送信要求メッセージを受信したか否かを判別しており、当該コンテンツ所在問合せメッセージを受信していない場合には（ステップＳ７：ＮＯ）、ステップＳ１１に進み、コンテンツ送信要求メッセージを受信した（つまり、自己がコンテンツ保持ノードである）場合には（ステップＳ７：ＹＥＳ）、当該要求に係るコンテンツデータファイルを送信可能であるか否かを判断する（ステップＳ８）。当該送信可能であるか否かは、そのときのネットワーク８の負荷や、制御部１１におけるＣＰＵ負荷等に応じて判断される。例えば、多数のノードから同時期に当該ファイルの要求があり、制御部１１におけるＣＰＵ負荷が閾値以上（例えばＣＰＵの稼働率が８０％以上）である場合には、当該送信可能でないと判断される。
【０１１０】
そして、当該制御部１１は、コンテンツデータファイルを送信可能であると判断した場合には（ステップＳ８：ＹＥＳ）、コンテンツ送信要求メッセージに含まれるユーザノードのＩＰアドレスに従い、当該ユーザノードに対して当該ファイルを送信可能である旨のメッセージを送信し（ステップＳ９）、送信可能でないと判断した場合には（ステップＳ８：ＮＯ）、当該ユーザノードに対して当該ファイルを送信可能でない旨のメッセージを送信し（ステップＳ１０）、ステップＳ１１に進む。
【０１１１】
ステップＳ１１では、制御部１１は、例えばノードＮのユーザが入力部２１を操作して電源ＯＦＦ（切）指示を行うことにより、当該ノードＮに対する稼動停止指令があったか否かを判断しており、稼動指令がないと判断した場合には（ステップＳ１１：ＮＯ）、ステップＳ３に戻り、稼動停止指令があったと判断した場合（稼動停止指令を認識した）場合には（ステップＳ１１：ＹＥＳ）、コンテンツ配信システムＳにおいて稼動状態（稼動停止待機状態も含む）にあるノードの数を自己のルーティングテーブルから算出し、コンテンツ提供サーバＳＡにおける現在のサーバ負荷量を、上述したように、推定需要量Ｒと供給可能量Ｓとの差より算出する（ステップＳ１２）。なお、推定需要量Ｒと供給可能量Ｓを求めるに当たって、ノードの数以外のパラメータ（例えば、コンテンツデータの推定視聴率及びコンテンツデータの総データ量等）は、予めノードに記憶されているか或いは他のノード又はサーバから取得される。
【０１１２】
次いで、制御部１１は、算出したサーバ負荷量が、予め設定された、コンテンツ提供サーバＳＡの能力限界値を超えているか否かを判断し（ステップＳ１３）、超えていないと判断した場合には（ステップＳ１３：ＮＯ）、自己の稼動を停止（例えば、ノードの全ての電源を切る（ＯＦＦ））し（ステップＳ１４）、当該処理を終了する。
【０１１３】
一方、制御部１１は、算出したサーバ負荷量が上記能力限界値を超えていると判断した場合には（ステップＳ１３：ＹＥＳ）、例えば、制御部１１、記憶部１２及び通信部２０に供給される電源は切らず、表示部１６におけるディスプレイに供給される電源のみを切り、稼動停止待機状態（待機モード）に切り換え（ステップＳ１５）、ステップＳ１６に進む。
【０１１４】
そして、ステップＳ１６では、ステップＳ５と同様、制御部１１は、他のノードからコンテンツ所在問合せメッセージを受信したか否かを判別し、当該コンテンツ所在問合せメッセージを受信していない場合には（ステップＳ１６：ＮＯ）、ステップＳ１８に進み、当該コンテンツ所在問合せメッセージを受信した場合には（ステップＳ１６：ＹＥＳ）、上記ステップＳ６と同様の問い合わせメッセージ受信処理を実行する（ステップＳ１７）。
【０１１５】
ステップＳ１８では、ステップＳ７と同様、制御部１１は、コンテンツ送信要求メッセージを受信したか否かを判別しており、当該コンテンツ所在問合せメッセージを受信していない場合には（ステップＳ１８：ＮＯ）、ステップＳ２２に進み、コンテンツ送信要求メッセージを受信した場合には（ステップＳ１８：ＹＥＳ）、ステップＳ８と同様、当該要求に係るコンテンツデータファイルを送信可能であるか否かを判断する（ステップＳ１９）。なお、ステップＳ２０の処理は、ステップＳ９の処理と同様であり、ステップＳ２１の処理は、ステップＳ１０の処理と同様である。
【０１１６】
ステップＳ２２では、制御部１１は、ユーザから入力部２１を介した電源ＯＮ（入）指示があったか否かを判別しており、電源ＯＮ指示がない場合には（ステップＳ２２：ＮＯ）、ステップＳ１２に戻り、上記と同様の処理を行い（このときのステップＳ１５の処理では、稼動停止待機状態（待機モード）を維持する）、電源ＯＮ指示があった場合には（ステップＳ２２：ＹＥＳ）、ノードＮの全ての電源をＯＮ（稼動停止待機状態（待機モード）から稼動状態に切り換え）にし（ステップＳ２３）、上記ステップＳ３に戻る。
【０１１７】
なお、上記図７及び図８の処理においては、ルートノードからコンテンツ保持ノードに対して、コンテンツ送信要求メッセージが送信されるように構成したが、ルートノードからユーザノードに対してコンテンツ保持ノードのノード情報（ＩＰアドレス等を含む）が送信され、当該ユーザノードがコンテンツ保持ノードに対してコンテンツ送信要求メッセージを送信するように構成しても良い。
【０１１８】
また、上記ステップＳ１２において、制御部１１は、コンテンツ提供サーバＳＡのサーバ負荷量を算出するように構成したが、別の例として、制御部１１は、自己のルーティングテーブルに基づいて稼動状態にあるノードの数を算出し、上記ステップＳ１３において、当該算出したノードの数が、上述した図５に示すＮ１からＮ２までの範囲内にあるか否かを判断し、算出したノードの数が、Ｎ１からＮ２までの範囲内にないと判断した場合には自己の稼動を停止し、Ｎ１からＮ２までの範囲内にあると判断した場合には自己の稼動の停止を待機する稼動停止待機状態に切り換えるように構成しても良い。
【０１１９】
以上説明したように、上記実施形態によれば、ノードにおいて稼動停止指令があった場合に、コンテンツ提供サーバＳＡに課されるサーバ負荷量が、コンテンツ提供サーバＳＡの能力限界値を超えているか否かを判断し、当該サーバ負荷量が上記能力限界値を超えていない場合には自己の稼動を停止し、当該サーバ負荷量が上記能力限界値を超えている場合には必要な電源（例えば、制御部１１、記憶部１２及び通信部２０に供給される電源）以外の電源（例えば、表示部１６におけるディスプレイ等に供給される電源）のみを切り自己の稼動の停止を待機する稼動停止待機状態に切り換えるように構成したので、各ノードにおいて自律的に最適な稼動制御を行い、コンテンツ提供サーバＳＡへの負荷を軽減させつつ、当該ノードにおける省エネをも向上させることができる（各ノードにおける省エネと、コンテンツ提供サーバＳＡへの負荷集中回避の両立を実現）。
【０１２０】
また、ノードにおいて稼動停止指令があった場合に、稼動状態にあるノードの数が、図５に示すようなＮ１からＮ２までの範囲内にあるか否かを判断し、当該ノードの数が上記範囲内にない（言い換えれば、コンテンツ提供サーバＳＡのサーバ負荷量が能力限界値を超えていない）場合には自己の稼動を停止し、上記ノードの数が上記範囲内にある場合には必要な電源（例えば、制御部１、記憶部１２及び通信部２０に供給される電源）以外の電源（例えば、表示部１６におけるディスプレイ等に供給される電源）のみを切り自己の稼動の停止を待機する稼動停止待機状態に切り換えるように構成したので、各ノードにおいて自律的に最適な稼動制御を行い、コンテンツ提供サーバＳＡへの負荷を軽減させつつ、当該ノードにおける省エネをも向上させることができる。
【０１２１】
また、上記サーバ負荷量又は上記ノード数は各ノードにおいて算出するようにしたので、ネットワーク８に負荷をかけず、より迅速にサーバ負荷量又はノードの数を取得することができる。
【０１２２】
なお、上記実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバーレイネットワーク９を前提として説明したが、本発明はこれに限定されるものではない。  
【図面の簡単な説明】
【０１２３】
【図１】本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
【図２】ルーティングテーブルが作成される様子の一例を示す図である。
【図３】ルーティングテーブルの一例を示す図である。
【図４】コンテンツ保持ノードから送出されたパブリッシュメッセージの流れの一例をＤＨＴのＩＤ空間にて示した概念図である。
【図５】コンテンツ提供サーバＳＡのサーバ負荷量と、参加ノード数との関係を示す図である。
【図６】ノードの概要構成例を示す図である。
【図７】各ノードの制御部１１における処理を示すフローチャートである。
【図８】ファイル要求・取得処理の詳細を示すフローチャートである。
【符号の説明】
【０１２４】
Ａ〜Ｚ  ノード
８  ネットワーク
９  オーバーレイネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
２０  通信部
２１  入力部
２２  バス
Ｓ  コンテンツ配信システム
【図１】
2008181408.tif 000003
【図２】
2008181408.tif 000004
【図３】
2008181408.tif 000005
【図４】
2008181408.tif 000006
【図５】
2008181408.tif 000007
【図６】
2008181408.tif 000008
【図７】
2008181408.tif 000009
【図８】
2008181408.tif 000010