ツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステム
【課題】 ツリー上の全てのノードに配送データを迅速に配備させることができるツリー状ネットワーク再構成装置を提供する。
【解決手段】 本発明は、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に関する。そして、除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段とを備えることを特徴とする。
【解決手段】 本発明は、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に関する。そして、除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段とを備えることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムに関し、例えば、分散配置された複数のコンテンツ配信サーバを論理的にツリー状に配置したシステムにおいて、ツリー途中のノード（但し、ノードはコンテンツ配信サーバを意味する）に障害が発生した場合の対応に適用し得るものである。
【背景技術】
【０００２】
ユーザ端末に対してコンテンツ（例えば、映像コンテンツ）を配信する複数のコンテンツ配信サーバ（以下、配信サーバと呼ぶ）を分散配置したコンテンツ配信システムがある。このようなコンテンツ配信システムの中には、上述した複数の配信サーバを論理的にはツリー状に配置し、ツリーのルートノードからエンドノードに向かってコンテンツを枝分かれしながら配送することにより、各配信サーバに同一コンテンツを配備させ、各配信サーバは自己が収容するユーザ端末にコンテンツを配信するシステムがある。
【０００３】
ここで、ツリーのルートノードからエンドノードに向かってコンテンツを配送している際中に、ツリー上のある中間ノードにおいて障害が発生した場合、その中間ノードの先のノードにコンテンツを配備できない。そのため、障害が発生した中間ノードを介さずに、全てのノードにコンテンツを配備できるようにツリーを再構成する必要がある。特許文献１の実施形態４には、ツリーの再構成方法が記載されている。この再構成方法は、障害が発生した中間ノードの下流のノード毎に、そのノードを収容する他のノードを決定するものである。収容する他のノードは、ツリー上のエンドノードの中から決定される。障害が発生した中間ノードに接続されている下流ノードが複数ある場合に、それぞれの下流ノードを収容する他のノードが決定され、下流ノードによって収容される他のノードが異なることもある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２５６２２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、コンテンツ配送中に中間ノードに障害が発生した場合、その障害ノードの下流ノードを収容することとなったエンドノードまで、コンテンツが配送されていないこともあり、ツリーを再構成して、再構成したツリーを適用しても障害ノードの下流側のノードへコンテンツを配送できない恐れもある。
【０００６】
障害ノードの下流ノードを収容することとなったエンドノードまでコンテンツが配送されていたとしても、再構成前にエンドノードであったノードが中間ノードとして下流への配送を行うため、ルートノードからの必要ホップ数が再構成前より大きくなったノードが多く、ツリー上の全てのノードにコンテンツを配備するのにかなりの長時間を要する。特に、置き換えられたノードの配送能力が低い場合には、かかる配備時間の課題はより大きなものとなる。
【０００７】
そのため、ツリー上の全てのノードに配送データを迅速に配備させることができるツリー状ネットワーク再構成装置及びプログラムが望まれている。
【課題を解決するための手段】
【０００８】
第１の本発明は、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置において、（１）除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、（２）置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、（３）置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段とを備えることを特徴とする。
【０００９】
第２の本発明のツリー状ネットワーク再構成プログラムは、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に搭載されるコンピュータを、（１）除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、（２）置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、（３）置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段として機能させることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ツリー上の全てのノードに配送データを迅速に配備させることができるツリー状ネットワーク再構成装置及びプログラムを実現することができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態のコンテンツ配信システムの全体構成を示すブロック図である。
【図２】第１の実施形態における複数の配信サーバの論理的な接続関係を示す説明図である。
【図３】第１の実施形態における配信サーバの内部構成を示す機能ブロック図である。
【図４】第１の実施形態におけるコンテンツ管理サーバの内部構成を示す機能ブロック図である。
【図５】第１の実施形態における配送情報データベースにおける置き換えノード候補を評価するための情報の構成を示す説明図である。
【図６】第１の実施形態におけるコンテンツ管理サーバが実行する配送指示動作を示すフローチャートである。
【図７】第１の実施形態において、管理者からの配送指示に対し、コンテンツ配送が正常になされる場合の処理の流れを示すシーケンス図である。
【図８】第１の実施形態において、管理者からの配送指示に応じて開始しようとしたコンテンツ配送の配送先を、障害の配信サーバのために置き換える必要が生じた場合の処理の流れを示すシーケンス図である。
【図９】第１の実施形態におけるコンテンツ管理サーバが実行するツリーの再構成処理を示すフローチャートである。
【図１０】第１の実施形態における、障害ノードの置き換え候補と、障害ノードに直接接続されている上流ノードとの距離を計測する処理を示すシーケンス図である。
【図１１】第１の実施形態におけるツリーの再構成後の構成を、従来におけるツリーの再構成後の構成と共に示す説明図である。
【図１２】第２の実施形態におけるコンテンツ管理サーバが実行するツリーの再構成処理を示すフローチャートである。
【図１３】第２の実施形態における配送情報データベースにおける置き換えノード候補を評価するための情報の構成を示す説明図である。
【発明を実施するための形態】
【００１２】
（Ａ）第１の実施形態
以下、本発明によるツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムの第１の実施形態を、図面を参照しながら説明する。第１の実施形態のツリー状ネットワークシステムは、コンテンツ配信システムである。
【００１３】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態のコンテンツ配信システム１の全体構成を示すブロック図である。
【００１４】
図１において、第１の実施形態のコンテンツ配信システム１は、複数の配信サーバ２−０〜２−Ｎと、コンテンツ管理サーバ３と、配送情報データベース（配送情報ＤＢ）４とがネットワーク５を介して通信可能に接続されている。
【００１５】
ネットワーク５は、１つのネットワーク（例えば、ＩＰネットワーク）であっても良く、また、複数のネットワークが融合したものであっても良い。さらに、ネットワーク５は、スター状、リング状、メッシュ状等のいずれの接続形態のものであっても良い。
【００１６】
第１の実施形態のコンテンツ配信システム１は、このようなネットワーク５の構成に拘わらず、複数の配信サーバ２−０〜２−Ｎの論理的な接続関係が定まっている。すなわち、第１の実施形態のコンテンツ配信システム１の場合、複数の配信サーバ（適宜、ノードと呼ぶ）２−０〜２−Ｎは、論理的には、図２に示すようにツリー状に接続されている（図２は配信サーバが１２個の場合を示している）。但し、コンテンツ管理サーバ３及びツリーデータベース４は、このツリー状ネットワークから離れて設けられている。ここで、ツリー状ネットワークとは、１つのルートノード２−０から徐々に枝分かれしつつ、末端のエンドノード２−５、２−７〜２−１１へのコンテンツの配信経路が１本道になっているネットワークである。
【００１７】
ルートノード２−０は、予め定まっている次（下流）のノード（図２の例では２−１及び２−２）へコンテンツを送信だけするノードである。各エンドノード２−５、２−７〜２−１１はそれぞれ、予め定まっている前（上流）のノードから送信されたコンテンツを受信するだけのノードである。中間ノード２−１〜２−４、２−６は、予め定まっている前（上流）のノードから送信されたコンテンツを受信すると共に、そのコンテンツを予め定まっている次（下流）のノードへ送信するノードである。
【００１８】
この明細書において、「配送」とは各配信サーバにコンテンツを配備するために配信サーバから他の配信サーバへコンテンツを送信することを言い、一方、「配信」とは配信サーバが自己に配備されたコンテンツをユーザ端末へ送信することを言うこととする。
【００１９】
各配信サーバ２−０〜２−Ｎはそれぞれ、配送されたコンテンツを自己に配備して、自己に割り当てられているユーザ端末にコンテンツを配信するサーバである。各配信サーバ２−０〜２−Ｎは、ユーザ端末の位置や密度等を考慮しながら、各地域に分散的に配置されているものである。
【００２０】
図３は、配信サーバ２−ｎ（ｎは０〜Ｎ）の内部構成を示した機能ブロック図であり、特には、中間ノードの内部構成を示している。
【００２１】
配信サーバ２−ｎは、通信部１０、配送コンテンツ受信部１１、コンテンツ格納部１２、配送コンテンツ送信部１３、配送制御部１４、コンテンツ配信部１５及び配信制御部１６を有する。
【００２２】
通信部１０は、ネットワーク５側との通信（送受信）を行うものである。ネットワーク５が、例えばＩＰネットワークであれば、通信部１０は、ＴＣＰ／ＩＰ送受信部となる。なお、図３では、配信サーバ間でコンテンツを配送する通信部もユーザ端末にコンテンツを配信する通信部も共通なものを示したが、これら通信部が別個に設けられたものであっても良い。
【００２３】
配送コンテンツ受信部１１は、上流ノードから配送（送信）された通信部１０を介して与えられたコンテンツを受信処理して、コンテンツ格納部１２に格納させるものである。
【００２４】
コンテンツ格納部１２は、配送されたコンテンツを格納するものである。ここで、ユーザ端末に配信するためにコンテンツを格納する格納部と、上流ノードから配送されたコンテンツを下流ノードに送信するまで一時的に格納する格納部とを別個に設けるようにしても良い。このような２つの格納部構成の場合には、後者の格納部から前者の格納部へ移し替えることも適宜実行される。
【００２５】
配送コンテンツ送信部１３は、コンテンツ格納部１２に格納されているコンテンツを、通信部１０を介して、下流ノードへ送信（配送）するものである。
【００２６】
配送制御部１４は、コンテンツ配送に係る各種の制御処理を実行するものである。例えば、配送制御部１４は、配送コンテンツ受信部１１によるコンテンツの受信が終了した場合には、受信が正常に終了したことを通信部１０を介して配送元の配信サーバに通知し、受信が途中で失敗したときには受信エラーを通信部１０を介して配送元の配信サーバに通知する。また例えば、配送制御部１４は、通信部１０を介してコンテンツ管理サーバ３から配送指示が与えられたときに、配送コンテンツ送信部１３による下流ノードへのコンテンツ配送を起動するものである。さらに例えば、配送制御部１４は、通信部１０を介して、下流ノードからコンテンツの受信終了の通知や受信エラーを受け取ったときには、通信部１０を介してコンテンツ管理サーバ３へ配送指示に従った配送を実行した旨やエラー発生を返信するものである。また例えば、配送制御部１４は、下流ノードへのコンテンツ配送を開始しようとして又はコンテンツ配送中に、下流ノードの障害発生を認識したときには、通信部１０を介してコンテンツ管理サーバ３へ障害発生又はエラー発生を通知するものである。
【００２７】
第１に、コンテンツを配送する下流ノードの情報は配送指示に含まれていても良い。第２に、下流ノードの情報は配送指示に含まれておらず、配送制御部１４が内部に下流ノードの情報を保持しておき、配送指示時に、その情報を取り出すようにしても良い。第３に、下流ノードの情報が配送指示に含まれていればそれに従い、下流ノードの情報が配送指示に含まれていなければ配送制御部１４が内部に保持しておいた下流ノードの情報を利用するようにしても良い。後述するツリーの再構成後において、第１及び第３の方法では、配送指示に下流ノードの情報を含めることで再構成後の下流ノードへ配送を行うことができる。第２の方法の場合、配送指示に先立ち、再構成後の下流ノードの情報が与えられて配送制御部１４が保持し、その後、配送指示が与えられることになる。
【００２８】
コンテンツ配信部１５は、コンテンツ格納部１２に格納されているコンテンツを、通信部１０を介して、ユーザ端末へ配信するものである。コンテンツ配信部１５は、配送コンテンツ送信部１３と共用させたものであっても良い。
【００２９】
配信制御部１６は、ユーザ端末へのコンテンツ配信を制御するものである。ここで、ユーザ端末へのコンテンツ配信は、所定時刻になったときや、上位装置（図示せず）からに指示に従って、当該配信サーバ２−ｎが管轄する全てのユーザ端末へ一斉若しくは逐次配信であっても良く、また、配信を要求したユーザ端末への個別配信であっても良い。
【００３０】
図３は、上述したように、中間ノードとなっている配信サーバ２−ｎの内部構成を示している。ルートノードとなっている配信サーバ２−０は、配送コンテンツをネットワークから受け入れる構成がないものであっても良い。この場合、管理者のファイル設定操作等によって、コンテンツ格納部１２にコンテンツを格納させることになる。また、ルートノードとなっている配信サーバ２−０も、図３と同様な構成を有し、配信サーバとは異なる外部装置が送信したコンテンツをネットワーク５から取り込んで、コンテンツ格納部１２にコンテンツを格納させるようにしても良い。エンドノードとして、中間ノードとなることができるエンドノードの他、中間ノードとなることができないエンドノードがあっても良い。中間ノードとなることができるエンドノードは、図３に示す構成を有する。中間ノードとなることができないエンドノードは、コンテンツを下流ノードへ配送する構成がないものであっても良い。
【００３１】
コンテンツ管理サーバ３は、全て（但し、障害が発生しているものを除く）の配信サーバ２−０〜２−Ｎにコンテンツを配備させるべく、コンテンツの配送を管理、制御するサーバである。なお、コンテンツ管理サーバ３は、ユーザ端末へのコンテンツへの配信についても、管理、制御するものであっても良い。
【００３２】
図４は、コンテンツ管理サーバ３の内部構成を示した機能ブロック図である。コンテンツ管理サーバ３の一部機能が、ＣＰＵ及びＣＰＵが実行するプログラムによって実現されている場合であっても、機能的には、コンテンツ管理サーバ３の内部構成を図４で示すことができる。
【００３３】
図４において、コンテンツ管理サーバ３は、通信部２０、管理者インタフェース部２１、ツリー基本構成格納部２２、障害ノード格納部２３、ツリー再構成部２４及び配送指示制御部２５を有する。
【００３４】
通信部２０は、ネットワーク５側との通信（送受信）を行うものである。ネットワーク５が、例えばＩＰネットワークであれば、通信部２０は、ＴＣＰ／ＩＰ送受信部となる。
【００３５】
管理者インタフェース部２１は、キーボード、マウス、ディスプレイ等でなり、管理者による操作入力（例えば、配送指示）を取り込んだり、当該コンテンツ管理サーバ３における処理結果やガイダンスメッセージ等を管理者に知得させたりするものである。図４では、管理者が、コンテンツ管理サーバ３に直接操作するものを示したが、管理者がパソコンなどでなる管理者端末を操作し、その管理者端末とコンテンツ管理サーバ３との通信によって、管理者がコンテンツ管理サーバ３に指示を与えるものであっても良い。
【００３６】
ツリー基本構成格納部２２は、全ての配信サーバ２−０〜２−Ｎの図２に示すような基本的なツリー構成の情報を格納しているものであり、その格納情報は、適宜、配送指示制御部２５によって読み出されるものである。ここで、基本的なツリー構成とは、いずれの配信サーバにも障害が発生していないときに、コンテンツの配送に利用するツリー構成をいう。後述するように、いずれかの配信サーバに障害が発生した場合にはツリーの再構成が実行される。この場合において、障害ノードが復旧したときには、ツリー基本構成格納部２２に格納されている基本的なツリー構成を再度適用するようにしても良く、また、再構成されたツリーに、復旧したノードを所定ルールに従って追加して、新たな基本的なツリー構成としてツリー基本構成格納部２２に上書きするようにしても良い。以下では、障害ノードが復旧したときには、ツリー基本構成格納部２２に格納されている基本的なツリー構成を再度適用するものとして説明する。
【００３７】
障害ノード格納部２３は、障害が発生中の配信サーバの情報（サーバの識別情報や障害件時刻等）を格納しているものであり、格納情報は、配送指示制御部２５によってアクセス（書込み、読出し、消去等）される。障害ノード格納部２３に障害が発生した配信サーバの情報が格納されているときには、後述するツリーの再構成処理で決定された、その障害発生の配信サーバに置き換わる配信サーバの情報も併せて格納されるようになされている。
【００３８】
配信サーバに障害があることは、上流の配信サーバがコンテンツを配送しようとしたときに検出することができる。また、コンテンツ管理サーバ３が定期的に各配信サーバの状態を確認して障害の発生を検出することもできる。
【００３９】
ツリー再構成部２４は、いずれかの配信サーバに障害が発生した場合、すなわち、基本的なツリー構成では、コンテンツが配送されない配信サーバが生じる場合に、配送指示制御部２５の制御下で、ツリーを再構成するものである。ツリーの再構成処理は、いずれかの配信サーバに障害が生じたことを検出されたときに実行される。ツリー再構成部２４による再構成方法については、後述する動作説明で明らかにする。
【００４０】
配送指示制御部２５は、管理者からの配送指示を受け、その配送指示に係る配送元及び配送先の配信サーバ間の配送状況や、配送元及び配送先の配信サーバの障害有無等を確認し、基本的構成のツリー上のいずれかの配信サーバ若しくは再構成したツリー上のいずれかの配信サーバに対し、通信部２０を介してコンテンツの配送指示を与えるものである。配送指示制御部２５は、複数種類のコンテンツの配送を並行的に制御しても良い。配送指示制御部２５は、それぞれのコンテンツをルートノード２−０に配備した時刻を管理している。
【００４１】
配送情報データベース４は、詳細構成の図示は省略するが、コンテンツ管理サーバ３が処理時に参照する少なくとも２種類の情報を格納しているものである。第１の情報は、各配信サーバについて、コンテンツが未配送か配送済かを表す配送状況の情報である。配送に係るコンテンツが複数種類ある場合には、それぞれのコンテンツについて配送状況の情報が格納される。第２の情報は、基本的なツリー構成における中間ノードに障害が発生した場合において、その中間ノードに置き換わって、その中間ノードの下流ノードへのコンテンツ配送を行うノードとなり得る置き換え候補と、その候補を評価するための情報（候補評価用情報）である。
【００４２】
図１では、配送情報データベース４もネットワーク５の要素となっているものを示したが、配送情報データベース４が、コンテンツ管理サーバ３に対して専用回線によって接続されていても良く、また、コンテンツ管理サーバ３にケーブル等で直接接続されたものであっても良い。このような場合、コンテンツ管理サーバ３は、通信部２０の他に配送情報データベース４にアクセスするための構成要素を備えることになる。
【００４３】
図５は、配送情報データベース４における上述した候補評価用情報（第２の情報）の構成例を示す説明図であり、置き換え候補となり得る一部の配信サーバの情報を示している。
【００４４】
図５において、候補評価用情報は、置き換え候補の識別情報毎の行（レコード）を有し、各行は、その置き換え候補のサーバとしてのスペック（サーバとして備わっている処理能力）の情報と、距離情報とでなる。
【００４５】
スペック情報としては、例えば、（ａ）下流ノードを収容できる数（下流ノードと接続可能なパス本数）、（ｂ）下流ノードへの各パスにおける通信帯域、（ｃ）コンテンツ配信可能本数（現在の状態から増加することが可能な余裕の配信本数）が記述される。距離情報は、当初は空欄であって、障害ノードが生じてその行のノードが置き換え候補となったときに、後述するように計測されて書き入れられるものである。
【００４６】
図５の例では、配信サーバ２−７は置き換え候補になり得るサーバであり、配信サーバ２−７は、最大５個の下流ノードへコンテンツを配送することが可能であり、５本の下流ノードへのパスはそれぞれ、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］の通信帯域を確保でき、現状より１２０個多いユーザ端末への配信が可能である。距離として「８．１」が記述されているが、これは、後述するよう距離計測処理がなされて書き入れられたものである。
【００４７】
この第１の実施形態の場合、障害ノードに置き換えられたノードは、下流ノードへのコンテンツ配送だけでなく、障害ノードに割り当てられているユーザ端末へのコンテンツ配信を引き継ぐ。但し、障害ノードに置き換えられたノードは、下流ノードへのコンテンツ配送だけを引き継ぎ、障害ノードに割り当てられているユーザ端末へのコンテンツ配信は他のルールによって引き継ぐノードを決定するようにしても良い。例えば、障害ノードとの距離が近いノード（若しくは基本構成上で障害ノードとのホップ数が少ないノード）で、コンテンツ配信に余裕があるノードが、障害ノードに割り当てられているユーザ端末へのコンテンツ配信を引き継ぐようにしても良い。このような場合であれば、（ｃ）のコンテンツ配信可能本数は候補評価用情報から除外される。
【００４８】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るコンテンツ配信システム１の動作を説明する。以下では、ツリーの再構成に関係する動作を中心に説明する。
【００４９】
管理者は、コンテンツ管理サーバ３に対して、基本的なツリー構成上、直接接続されている２つの配信サーバ（若しくはこれら配信サーバを結ぶパス）を指定してコンテンツの配送を指示する。このとき、コンテンツ管理サーバ３は、図６に示す適用ツリーの決定動作を実行する。
【００５０】
なお、配送に係るコンテンツが複数種類存在する場合には、管理者はコンテンツの種類を指定して配送を指示することになる。例えば、管理者は、ディスプレイ上に基本的なツリー構成を表示させ、その表示されたツリー構成のいずれかのパスを表示画面上で指定（例えばクリック）することにより、配送指示に係るパス（２つの配信サーバ）を指定する。なお、ディスプレイ上に基本的なツリー構成を表示させる際、全ての配信サーバについて、配送情報データベース４に格納されている配送状況を取出し、コンテンツが未配送の配信サーバと配送済の配信サーバとを区別（例えば、表示色を変える）して表示し、効率的にコンテンツ配送の指示を発行することができるようにしても良い。
【００５１】
コンテンツ管理サーバ３は、図６に示す処理を開始すると、まず、配送指示に係るコンテンツの各配信サーバへの配送状況を配送情報データベース４から取出すと共に、内蔵する障害ノード格納部２３から障害情報を取り出す（ステップ１００）。
【００５２】
そして、コンテンツ管理サーバ３は、障害ノードが存在するか否かを判別する（ステップ１０１）。障害ノードが存在しない場合には、コンテンツ管理サーバ３は、基本的なツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、基本的なツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０２）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。
【００５３】
障害ノードがあると、コンテンツ管理サーバ３は、障害検出時刻と、コンテンツをルートノード２−０に配備した時刻とを比較することにより、今回の配送指示に係るコンテンツの一連の配送動作が開始された以降に障害が発生した否かを判別する（ステップ１０４）。
【００５４】
今回の配送指示に係るコンテンツの一連の配送動作が開始される前に障害が発生していると、コンテンツ管理サーバ３は、再構成されたツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、再構成されたツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０５）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。すなわち、コンテンツをルートノード２−０に配備する前に、障害ノードが生じていた場合には、再構成されたツリー構成を適用する。ステップ１０５を実行する際に、並行して、ツリーの再構成処理が行われていても良い。
【００５５】
一方、障害検出時刻と、コンテンツをルートノード２−０に配備した時刻との比較により、基本構成のツリー構成での配送を行っている際中に、いずれかのノードに障害が発生したと判別した場合には、コンテンツ管理サーバ３は、障害ノードの下流ノードへのコンテンツ配送が終了しているか否かを判別する（ステップ１０６）。障害ノードの下流ノードへのコンテンツ配送が終了していると、コンテンツ管理サーバ３は、基本的なツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、基本的なツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０２）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。これに対して、障害ノードの下流ノードへのコンテンツ配送がなされていないと、コンテンツ管理サーバ３は、再構成されたツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、再構成されたツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０５）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。
【００５６】
コンテンツ管理サーバ３は、図６に示す処理を実行し、障害ノードが生じた場合に、常に、再構成されたツリー構成を適用するのではなく、ツリー全体に対するコンテンツの配送状況に鑑み、障害ノードが生じた以降でも、基本的なツリー構成を適用するか、再構成されたツリー構成を適用するかを定める。従って、再構成されたツリー構成を適用することに一律に決めたような場合に比較し、コンテンツが配送されないノードが生じるようなことを防止できる。
【００５７】
以上では、管理者が配送元及び配信先の配信サーバを特定した配送指示をコンテンツ管理サーバ３に対して与える場合を説明したが、全ノードへの配送指示をコンテンツ管理サーバ３に対して与えるようにしても良い。全ノードへの配送指示が与えられたコンテンツ管理サーバ３は、基本的なツリー構成におけるルートノード側のパスから、パスを１つずつ順に取出し、取出したパスに係る上流及び下流の配信サーバに係る配送指示を形成し、図６に示す配送指示が入力された場合の処理を実行するようにすれば良い。
【００５８】
図７は、管理者からの配送指示に対し、コンテンツ配送が正常になされる場合の処理の流れを示すシーケンス図である。
【００５９】
管理者６がコンテンツ管理サーバ３にコンテンツ配送指示を発行すると（ステップ２００）、コンテンツ管理サーバ３は、配送状況を配送情報データベース４から取出したりしながら（ステップ２０１；図６のステップ１００参照）、上述した図６の処理により、配送元（上流）の配信サーバ２−Ｕと配送先（下流）の配信サーバ２−Ｌとを確定し、上流の配信サーバ２−Ｕに対し、下流の配信サーバ２−Ｌへのコンテンツ配送を指示する（ステップ２０２）。
【００６０】
この指示に従い、上流の配信サーバ２−Ｕは、下流の配信サーバ２−Ｌへコンテンツを配送する（ステップ２０３）。下流の配信サーバ２−Ｌは、コンテンツの受信が正常に終了した場合には、受信が正常に終了したことを上流（配送元）の配信サーバ２−Ｕに通知し（ステップ２０４）、上流の配信サーバ２−Ｕは、このとき、コンテンツ管理サーバ３へ配送指示に従った配送を実行した旨を返信する（ステップ２０５）。
【００６１】
これにより、コンテンツ管理サーバ３は、配信サーバ２−Ｌへコンテンツを配送した旨の情報を配送情報データベース４へ与えて、配送情報データベース４の配信サーバ２−Ｌについての配送状況を配送済に更新させる（ステップ２０６）。そして、コンテンツ管理サーバ３は、配送情報データベース４からの格納応答を受けて、管理者６に対して、与えられた配送指示の配送が正常終了したことを通知する（ステップ２０７）。
【００６２】
図７に示す処理を、配送元及び配信先の配信サーバの組み合わせを換えて繰り返し行うことにより、ツリー状の全てのノード（配信サーバ）にコンテンツを配備することができる。
【００６３】
図８は、管理者からの配送指示に応じて開始しようとしたコンテンツ配送の配送先を、障害の配信サーバのために置き換える必要が生じた場合の処理の流れを示すシーケンス図であり、図７との同一処理には同一符号を付している。
【００６４】
管理者からの配送指示に応じ、コンテンツ管理サーバ３が、上流の配信サーバ２−Ｕに対し、下流の配信サーバ２−Ｌへのコンテンツ配送を指示し、上流の配信サーバ２−Ｕが、下流の配信サーバ２−Ｌへコンテンツを配送しようとするまでの処理の流れは図７の場合と同様である（ステップ２００〜２０３）。
【００６５】
下流の配信サーバ２−Ｌに障害が発生していると（ステップ２５０）、上流の配信サーバ２−Ｕがコンテンツを下流の配信サーバ２−Ｌへ配送しようとしても配送できない。上流の配信サーバ２−Ｕは、下流の配信サーバ２−Ｌとのセッションが確立できないことや、下流の配信サーバ２−Ｌから、受信が正常に終了したことの通知が届かないこと等により、下流の配信サーバ２−Ｌに障害が発生していることを検出し、コンテンツ管理サーバ３に配送エラーを返信する（ステップ２５１）。
【００６６】
このとき、コンテンツ管理サーバ３は、下流の配信サーバ２−Ｌに障害が発生していることの障害情報を内部に格納すると共に（ステップ２５２）、後述するようなツリーの再構成処理を実行する（ステップ２５３）。
【００６７】
ツリーの再構成処理により、障害ノード２−Ｌに置き換える配信サーバ２−Ｌｎｅｗが定まると、コンテンツ管理サーバ３は、上流の配信サーバ２−Ｕに対し、置換配信サーバ２−Ｌｎｅｗへのコンテンツ配送を指示する（ステップ２５４）。このような配送指示に応じた上流の配信サーバ２−Ｕ及び置換配信サーバ２−Ｌｎｅｗの処理は、図７の場合と同様である。
【００６８】
すなわち、上流の配信サーバ２−Ｕは、この配送指示に従い、置換配信サーバ２−Ｌｎｅｗへコンテンツを配送し（ステップ２５５）、置換配信サーバ２−Ｌｎｅｗは、コンテンツの受信が正常に終了したときに、受信が正常に終了したことを上流の配信サーバ２−Ｕに通知し（ステップ２５６）、上流の配信サーバ２−Ｕは、コンテンツ管理サーバ３へ配送指示に従った配送を実行した旨を返信し（ステップ２５７）、コンテンツ管理サーバ３は、置換配信サーバ２−Ｌｎｅｗへコンテンツを配送した旨の情報を配送情報データベース４へ与えて、配送情報データベース４の配信サーバ２−Ｌｎｅｗについての配送状況を配送済に更新させ（ステップ２５８）、コンテンツ管理サーバ３は、配送情報データベース４からの格納応答を受けて、管理者６に対して、与えられた配送指示の配送が終了したことを通知する（ステップ２５９）。但し、この終了通知では、配信ノード２−Ｌに障害が発生していたため、それに置き換わる配信サーバ２−Ｌｎｅｗへコンテンツを配送したことを管理者に通知する。
【００６９】
例えば、図２における配信サーバ２−０から配信サーバ２−２への配送指示時において、配送先の配信サーバ２−２に障害が発生していた場合には、配信サーバ２−２の下流の配信サーバ２−５、２−６、２−１０へコンテンツを配送できなくなる。そのため、配信サーバ２−２に置き換わる配信サーバを定めて、配信サーバ２−２の下流の配信サーバ２−５、２−６、２−１０へコンテンツを配送できるようにする。なお、第１の実施形態の場合、障害の配信サーバに置き換わった配信サーバは、障害の配信サーバに割り当てられていたユーザ端末への配信をも行うものとなる。
【００７０】
また例えば、図２における配信サーバ２−４から配信サーバ２−９への配送指示時において、配送先の配信サーバ２−９に障害が発生していた場合には、配信サーバ２−９の下流には配信サーバは存在しない。しかし、障害の配信サーバに割り当てられていたユーザ端末への配信を行う必要があるので、このようなエンドノードに障害が発生している場合にも、障害の配信サーバ２−９の配信を引き継ぐ配信サーバを定めることを要する。
【００７１】
図８では、置換配信サーバ２−Ｌｎｅｗへコンテンツを常に配送するものを示したが、コンテンツ管理サーバ３は、置換配信サーバ２−Ｌｎｅｗが定まると、置換配信サーバ２−Ｌｎｅｗについての配送状況を配送情報データベース４から取出し、置換配信サーバ２−Ｌｎｅｗへの配送が既に済んでいる場合にはコンテンツの配送を実行せずに直ちに管理者に終了通知を行い、置換配信サーバ２−Ｌｎｅｗへの配送が済んでいない場合には置換配信サーバ２−Ｌｎｅｗへのコンテンツの配送を実行し、管理者に終了通知を行うようにしても良い。
【００７２】
図８は、配送指示に係る配送先の配信サーバに障害が発生していた場合を示しているが、配送指示に係る配送元（上流）の配信サーバに障害が発生していた場合にも、コンテンツ管理サーバ３は、障害ノード２−Ｕに置き換える配信サーバ２−Ｕｎｅｗが定めて、その置換配信サーバ２−Ｕｎｅｗに対し、配信サーバ２−Ｌへのコンテンツ配送を指示するようにしても良い。例えば、配送指示を与えようとして行ったセッションの確立動作でも、配送元（上流）の配信サーバ２−Ｕとのセッションを確立できないことにより、コンテンツ管理サーバ３は、配送元（上流）の配信サーバの障害発生を検出することができる。
【００７３】
図９は、コンテンツ管理サーバ３が実行するツリーの再構成処理（再構成プログラム）を示すフローチャートである。例えば、上述した図８のステップ２５３の処理として、ツリーの再構成処理が実行される。再構成処理が起動される場合は、上述した図８のような状況には限定されない。例えば、定期的な障害監視処理でいずれかのノードの障害が検出されたときに、ツリーの再構成処理を起動し、それ以降のコンテンツの配送指示に対応可能としておくようにしても良い。
【００７４】
コンテンツ管理サーバ３は、図９に示す処理を開始するとまず、まず、置き換え候補を選出する（ステップ３００）。置き換え候補の選出方法は限定されるものではない。例えば、選出する候補の最少数を定めておくようにしても良い。また例えば、基本的なツリー構成におけるエンドノードだけを置き換え候補とするようにしても良い。さらに例えば、基本的なツリー構成において、障害ノードの下流に位置していないノードを置き換え候補とするようにしても良い。また例えば、ルートノードからのホップ数が多い方のノードを置き換え候補とするようにしても良い。
【００７５】
コンテンツ管理サーバ３は、置き換え候補を選出すると、次に、各置き換え候補の配信サーバについて配送情報データベース４に格納されているスペック情報に基づいて、置き換え候補の絞り込みを行う（ステップ３０１）。例えば、置き換え候補が収容できる下流ノードの数は、障害ノードが収容（接続）していた下流ノードの数以上になっている、置き換え候補における下流ノードへの各パスにおける通信帯域は、障害ノードの各パスにおける通信帯域を確保できる、置き換え候補は障害ノードに割り当てられていた全てのユーザ端末を引き受けられるという３つの要件を全て満たす置き換え候補に絞り込まれる。なお、このステップ３０１は、スペック情報に基づいて、要件の充足、不充足だけをマークするようにし、置き換え候補の絞り込みを実行せず、後述するステップ３０３による置き換えノードの決定処理で、マークした要件の充足性を利用するようにしても良い。上記では、障害ノードのスペック若しくは実績値を基準（閾値）として、置き換え候補のスペックの充足性を判断するものを示したが、障害ノードのスペック若しくは実績値に所定数を掛けた値を閾値として、置き換え候補のスペックの充足性を判断するようにしても良い。障害ノードが収容していたユーザ端末数をＭとした場合、Ｍ×ａ（ａは１．２）を閾値として置き換え候補の余裕配信数を評価するようにしても良い。
【００７６】
その後、コンテンツ管理サーバ３は、絞り込んだ各置き換え候補のそれぞれについて順次、障害ノードに直接接続されている上流ノードとの距離を計測させ、得られた距離情報を配送情報データベース４に格納させる（ステップ３０２）。
【００７７】
そして、コンテンツ管理サーバ３は、計測した距離が最も短い置き換え候補を、障害ノードに置き換えるノードと決定し（ステップ３０３）、決定したノードを障害ノードに置き換えて適用されるように、内部の格納情報を変更する（ステップ３０４）。コンテンツ管理サーバ３は、例えば、内蔵する障害ノード格納部２３に、障害ノードの情報に対応付けて、その障害ノードに置き換わるノードの情報を格納する。
【００７８】
図１０は、コンテンツ管理サーバ３の主導の元で実行される、置き換え候補と、障害ノードに直接接続されている上流ノードとの距離を計測する処理（ステップ３０２）を示すシーケンス図である。
【００７９】
コンテンツ管理サーバ３は、障害ノードに直接接続されている上流ノード２−Ｘに対し、置き換え候補のノード２−Ｙを特定した距離情報の取得要求（例えばネットワークアドレスで置き換え候補のノード２−Ｙを特定する）を送出する（ステップ４００）。このとき、上流ノード２−Ｘは、折り返しを指示した情報を含むパケットを置き換え候補のノード２−Ｙに送信すると共に、その送信時刻を取得して格納する（ステップ４０１、４０２）。置き換え候補のノード２−Ｙは、そのようなパケットが到来したときにはそのパケットを折り返す（ステップ４０３）。上流ノード２−Ｘは、このような折り返しパケットが戻ってきたときには、その受信時刻を取得し（ステップ４０４）、送信時刻と受信時刻の差に予め求めておいたネットワーク５での平均通信速度を乗算してネットワーク距離を算出し（ステップ４０５）、算出したネットワーク距離をコンテンツ管理サーバ３に返信する（ステップ４０６）。置き換えノードの決定では、距離の大小が問題となるので、上述のような往復での距離を算出して用いても問題となることはない。
【００８０】
障害ノードに置き換わるノードが決定され、ツリーが再構成されると、障害ノードが復旧するまで、この際構成されたツリー構成に従い、ルートノードからの各ノードへのコンテンツ配送が実行される。
【００８１】
次に、上述した置き換えノードの決定方法を、具体例を挙げて説明する。以下、図２に示す基本的なツリー構成における配信サーバ２−２に障害が発生し、配信サーバ２−２に置き換わる置き換えノードの決定が必要となったとする。図２に示すように、配信サーバ２−２は下流へのパスが２本のサーバである。また、それら各パスの通信帯域がそれぞれ５［ＧＢ／ｓ］、５［ＧＢ／ｓ］のものであり、配信サーバ２−２は、割り当てられている配信本数が９０本のものであるとする。
【００８２】
ここで、置き換え候補は少なくとも３候補とし、障害ノードの下流に位置していないエンドノードであって、ルートノードからのホップ数が多い方のエンドノードを優先して置き換え候補にすることになっているとする。エンドノードは、下流へのコンテンツ配送を今まで実行していないので、中間ノードより、下流へのコンテンツ配送能力に余裕が高いと推測される。また、置き換えにより、ルートノードから置き換えノードまでのホップ数が、置き換え前より改善される度合いが高くなると推測されるため、ルートノードからのホップ数が多い方のエンドノードを優先させることは好ましい。さらに、障害ノードの下流に位置しているノードを置き換え候補とした場合には、ツリー状の上下が逆転する部分も生じてツリーの変更度合いが大きいので、障害ノードの下流に位置していないエンドノードを置き換え候補とすることは好ましい。
【００８３】
なお、上述した選定方法に限定されないことは勿論である。例えば、中間ノードを置き換え候補にするような選定方法であっても良い。
【００８４】
上述した選定方法を適用した場合、障害ノード（障害が発生した配信サーバ）２−２の置き換え候補は、ノード２−７〜２−９となる。仮に、少なくとも４つを候補とする場合であれば、置き換え候補は、ノード２−７〜２−９、２−１１となる。
【００８５】
置き換え候補２−７〜２−９が、図５に示すスペックのものであったとする。障害ノード２−２は下流へのパスが２本であるので、いずれの置き換え候補２−７〜２−９も下流へのパス本数の要件は充足する。障害ノード２−２の各パスの通信帯域がそれぞれ５α、５β［Ｂ／ｓ］であるので、これ以上の通信帯域を確保できる置き換え候補２−７及び２−９は通信帯域の要件を充足する。障害ノード２−２に割り当てられている配信本数が９０本であるので、余裕配信本数がこれ以上である置き換え候補２−７及び２−９は引き受けられる配信本数の要件を充足する。
【００８６】
以上のスペックに基づく置き換え候補の絞り込みでは、置き換え候補２−７及び２−９が残る。そこで、コンテンツ管理サーバ３は、このようにして残った置き換え候補２−７及び２−９のそれぞれと、障害ノード２−２の上位ノード２−０とのネットワーク距離を計測させる。この計測結果が、図５に示すような場合、コンテンツ管理サーバ３は、ネットワーク距離が短い方の置き換え候補であるノード（配信サーバ）２−９を、障害ノード２−２に置き換えるノードに決定する。
【００８７】
図１１（Ａ）は、ノード２−９を障害ノード２−２に置き換えた、再構成されたツリーの構成を示している。ノード２−９は、障害ノード２−２に置き換えられたので、再構成前とは異なり、障害ノード２−２の上流ノード２−０からコンテンツが配送されるものとなる。
【００８８】
図１１（Ｂ）は、ノード２−２に障害が発生した場合において、特許文献１に記載の再構成方法を適用して再構成されたツリーの構成を示している。すなわち、障害ノード２−２の下流のノード２−５及び２−６をそれぞれ、どのノードに収容させるという観点から再構成が実行され、ノード２−５をノード２−７に収容させ、ノード２−６をノード２−９に収容させると決定された場合を示している。
【００８９】
図１１（Ａ）及び図１１（Ｂ）の比較から明らかなように、第１の実施形態の再構成方法を適用した方が、図２に示す当初の基本構成に近似したものとなっている。
【００９０】
以上では、中間ノード２−２に障害が発生した場合を示したが（ルートノードに障害が発生した場合も同様な方法を適用できる）、エンドノードに障害が発生した場合は、例えば、以下のように処理する。ここで、エンドノード２−９に障害が発生したとする。このノード２−９はエンドノードであるので、コンテンツを下流へ配送する機能を備えていない。そのため、ノード２−９に障害が発生した場合には、ノード２−９に割り当てられている配信本数（ユーザ端末）を引く継ぐノードを定めれば良い。
【００９１】
フローチャート等の図示は省略するが、コンテンツ管理サーバ３は、まず、引き継ぎ候補を選定する。ここでの引き継ぎ候補の選定方法も任意である。例えば、コンテンツの配送負荷が増えないので、中間ノードを引き継ぎ候補とするようにしても良い。コンテンツ管理サーバ３は、障害ノード２−９に割り当てられている配信本数以上の余裕配信本数を有する引き継ぎ候補に絞る。絞っても複数の引き継ぎ候補が残った場合には、コンテンツ管理サーバ３は、障害ノード２−９の上流ノード２−４との距離に基づいて、最終的に引き継ぐノードを決定する。障害ノード２−９と置き換えるわけではないので、障害ノード２−９の上流ノード２−４との距離が直接影響することはないが、障害ノードと引き継ぐノードとの距離は短い方が好ましい。障害ノードと引き継ぐノードとの距離を計測できないので、障害ノードと引き継ぐノードとの距離に代えて、障害ノード２−９の上流ノード２−４と引き継ぐノードとの距離を用いることにした。
【００９２】
図示は省略するが、コンテンツ管理サーバ３は、例えば、定期的に障害ノードが復旧したか否かを監視し、障害ノードが復旧すると、基本的なツリー構成に従って、各ノードにコンテンツを配送する状態に戻す。また例えば、コンテンツ管理サーバ３は、管理者から、障害ノードが復旧した旨の入力があると、基本的なツリー構成に従って、各ノードにコンテンツを配送する状態に戻す。
【００９３】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、コンテンツ配送中に配送済みノードでサーバ障害が発生した場合には、再構成したツリー構成を適用せずに、基本的なツリー構成をそのまま適用して、ツリー上の全てのノードに対するコンテンツ配送を実現し、新たな種類のコンテンツ配送から再構成したツリー構成を適用するようにしたので、コンテンツの配送中に、適用するツリー構成が切り分かることにより、配送されないノードが生じるような恐れが小さくすることができる。
【００９４】
また、第１の実施形態によれば、障害ノードが生じたときに、ツリー上でその障害ノードに置き換えるノードを決定して置き換えるようにしたので、ツリー構成を再構成しても、ツリー構成の変化を少なく抑えることができる。すなわち、ツリーを再構成しても、ルートノードからのホップ数が多くコンテンツが配送されるまでに長時間を要するようなノードの出現を抑えることができる。
【００９５】
さらに、第１の実施形態によれば、置き換え候補となるノードについてスペック（処理能力）の情報を格納しておき、障害ノードが担っていた機能の実現を確保できることを確認して置き換えノードを決定するようにしたので、置き換えられたノードの能力不足により、コンテンツの配送や配信に悪影響が生じるようなことを未然に防止することができる。
【００９６】
さらにまた、第１の実施形態によれば、障害ノードが担っていた機能をスペック的に充足できる置き換え候補が複数ある場合には、ネットワーク距離に基づいて置き換えノードを決定するようにしたので、障害ノードを置き換えたツリー構成において、その置き換えノードへのコンテンツ配送時間を短くすることができる。
【００９７】
また、第１の実施形態によれば、コンテンツの配送中に障害が生じた場合には、配送処理の一環として、その障害ノードに置き換わるノードを決定し、決定ノードにコンテンツを配送するようにしたので（図８参照）、全てのノードにコンテンツを配送して配備させるのに要する時間が、障害ノードの発生によって徒に長くなることを抑えることができる。
【００９８】
（Ｂ）第２の実施形態
次に、本発明によるツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムの第２の実施形態を、図面を参照しながら説明する。第２の実施形態のツリー状ネットワークシステムも、コンテンツ配信システムである。
【００９９】
第２の実施形態のコンテンツ配信システム１Ａの全体構成も、第１の実施形態の説明で用いた図１で表わすことができる。また、第２の実施形態の配信サーバ２−ｎの内部構成も、第１の実施形態の説明で用いた図３で表わすことができる。さらに、第２の実施形態のコンテンツ管理サーバ３も、第１の実施形態の説明で用いた図４で表わすことができる。
【０１００】
第２の実施形態は、コンテンツ管理サーバ３が実行するツリーの再構成処理、すなわち、障害ノードに置き換わるノードの決定処理が第１の実施形態と異なっており、その他の処理は、第１の実施形態と同様である。図１２は、第２の実施形態のコンテンツ管理サーバ３が実行するツリーの再構成処理（再構成プログラム）を示すフローチャートである。例えば、上述した図８のステップ２５３の処理として、ツリーの再構成処理が実行される。
【０１０１】
コンテンツ管理サーバ３は、図１２に示す処理を開始するとまず、まず、置き換え候補を選出する（ステップ５００）。第２の実施形態の場合も、置き換え候補の選出方法は限定されるものではなく、第１の実施形態の説明で例示したような方法を挙げることができる。
【０１０２】
コンテンツ管理サーバ３は、置き換え候補を選出すると、次に、各置き換え候補の配信サーバについて配送情報データベース４に格納されているスペック情報に基づいて、スペックの性能値を算出し、得られたスペックの性能値を配送情報データベース４に格納させる（ステップ５０１）。
【０１０３】
図１３は、第２の実施形態の配送情報データベース４における候補評価用情報の構成例を示す説明図であり、置き換え候補となり得る一部の配信サーバの情報を示している。
【０１０４】
図１３において、候補評価用情報は、置き換え候補の識別情報毎の行（レコード）を有し、各行は、その候補ノードのサーバとしてのスペックの生値情報と、スペックの段階値情報と、スペックの性能値と、距離情報と、優先度（トータル評価値）とでなる。図１２に示す処理を開始する前では、スペックの生値情報だけが記述され、スペックの段階値情報、スペックの性能値、距離情報、及び、優先度（トータル評価値）は空欄となっており、図１２に示す処理の進行と共に、徐々に記述されていくものである。
【０１０５】
スペックの生値情報は、第１の実施形態で「スペック情報」と呼んでいた情報であり、例えば、（ａ）下流ノードを収容できる数（下流ノードと接続可能なパス本数）、（ｂ）下流ノードへの各パスにおける通信帯域、（ｃ）コンテンツ配信可能本数（現在の状態から増加することが可能な余裕の配信本数）が該当する。
【０１０６】
スペックの段階値情報は、スペックの生値情報が取り得る範囲を複数の範囲に分割し、生値が属する分割範囲がどの評価段階に属するかを示す値に置き換えたものである（全ての項目について、段階値の大小は、その項目での評価の高低にあっている）。評価段階に対応した生値の分割範囲は、障害ノードの現状の状況によって変わるものである。
【０１０７】
図１３の場合、置き換え候補２−７〜２−９においてスペックの生値情報（ａ）である下流ノードを収容できる数はそれぞれ、下流への５本、３本、４本のパスに対応し得るものである。障害ノードの下流へのパス本数が２本であったとする。障害ノードの下流へのパス本数が２本の場合、図１３のスペックの段階値情報（ａ）である下流ノードを収容できる数におけるスペックの段階値情報は、確保可能なパス数が０又は１のときに段階値を「０」、確保可能なパス数が２〜４のときに段階値を「１」、確保可能なパス数が５以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「１」、「１」となる。仮に、障害ノードの下流へのパス本数が５本であり、障害ノードの下流へのパス本数が５本の場合、確保可能なパス数が０〜４のときに段階値を「０」、確保可能なパス数が５又は６のときに段階値を「１」、確保可能なパス数が７以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「１」、「０」、「０」となる。
【０１０８】
以上では、障害ノードの下流へのパス本数に応じて、各段階値が取り得る生値の範囲を切り替える場合を示したが、障害ノードの下流へのパス本数に関係なく、各段階値が取り得る生値の範囲を固定的に定めるものであっても良い。
【０１０９】
通信帯域やコンテンツ配信可能本数についても、同様な方法により、スペックの生値情報からスペックの段階値情報が形成される。但し、通信帯域は、各パス毎に定まっているので、各パス毎に、段階値に変換した後、それらの段階値情報の平均値をとって、通信帯域についての段階値情報とする（なお、平均値として小数を認めるようにしても良く、また、整数に制限する場合であれば切り捨て若しくは四捨五入処理を行う）。
【０１１０】
なお、図１３の場合では、置き換え候補２−７〜２−９においてスペックの生値情報（ｂ）である下流ノードへの各パスにおける通信帯域はそれぞれ、下流への１０［ＧＢ／ｓ］（５本）、５［ＧＢ／ｓ］（３本）、１０［ＧＢ／ｓ］（４本）の通信帯域に対応し得るものである。障害ノードの下流への通信帯域が５［ＧＢ／ｓ］であったとする。障害ノードの下流への通信帯域が５［ＧＢ／ｓ］の場合、図１３のスペックの段階値情報（ｂ）である下流ノードへの各パスにおける通信帯域におけるスペックの段階値情報は、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ５［ＧＢ／ｓ］未満のときに段階値を「０」、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ５［ＧＢ／ｓ］以上かつ１０［ＧＢ／ｓ］未満のときに段階値を「１」、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ１０［ＧＢ／ｓ］以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「１」、「２」となる。
【０１１１】
次に、置き換え候補２−７〜２−９においてスペックの生値情報（ｃ）であるコンテンツ配信可能本数はそれぞれ、１２０本、０本、１１０本に対応し得るものである。障害ノードのコンテンツ配信可能本数が１００本であったとする。障害ノードの下流へのコンテンツ配信可能本数が５０本の場合、図１３のスペックの段階値情報（ｃ）であるコンテンツ配信可能本数におけるスペックの段階値情報は、コンテンツ配信可能本数が５０本未満のときに段階値を「０」、コンテンツ配信可能本数が５０本以上かつ１００本未満のときに段階値を「１」、コンテンツ配信可能本数が１００本以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「０」、「２」となる。
【０１１２】
図１３では、全ての項目（下流へのパス本数、通信帯域、コンテンツ配信可能本数）共に段階数が３段階のものを示したが、項目によって段階数を変えるようにしても良い。
【０１１３】
各項目の段階値情報を統合したものが、スペックの性能値である。図１３では、各項目の段階値情報を乗算したものをスペックの性能値としたものを示したが、他の統合方法を適用するようにしても良い。例えば、各項目の段階値情報を重み付け加算したものをスペックの性能値とするようにしても良い。
【０１１４】
なお、図１３の場合では、スペックの段階値情報の性能値は、「スペックの段階値情報（ａ）である下流ノードを収容できる数」と、「スペックの段階値情報（ｂ）である下流ノードへの各パスにおける通信帯域におけるスペックの段階値情報」と、「スペックの段階値情報（ｃ）であるコンテンツ配信可能本数におけるスペックの段階値情報」との積より、置き換え候補２−７〜２−９のスペックの段階値情報である性能値はそれぞれ、「８」、「０」、「４」となる。
【０１１５】
スペックの性能値を算出すると、その後、コンテンツ管理サーバ３は、各置き換え候補のそれぞれについて順次、障害ノードに直接接続されている上流ノードとの距離を計測させ、得られた距離情報を配送情報データベース４に格納させる（ステップ５０２）。第２の実施形態の場合、スペック情報に基づいた置き換え候補の絞り込みは実行しないので、距離の計測は、選出された全ての置き換え候補について実行される。
【０１１６】
そして、コンテンツ管理サーバ３は、配送情報データベース４に格納されたスペックの性能値及び距離情報に基づいて、各置き換え候補のそれぞれについて、スペックの性能値及び距離情報を融合したトータル評価値である優先度を計算し（ステップ５０３）、優先度が最も高い置き換え候補を、障害ノードに置き換えるノードと決定し（ステップ５０４）、決定したノードを障害ノードに置き換えて適用されるように、内部の格納情報を変更する（ステップ５０５）。
【０１１７】
スペックの性能値及び距離情報が反映された優先度を算出できるものであれば、その算出方法は問われないものである。図１３は、スペックの性能値を距離情報で割った後、１０（補正値）倍した値を優先値としている。図１３の例では、優先度Ｐは、「図１３のスペックの段階値情報である性能値」と、「距離」の商より、置き換え候補２−７〜２−９のスペックの段階値情報である性能値はそれぞれ、「９．８７」、「０」、「８．８８」（小数点第３位以下を切り捨て）となり、優先度Ｐが最も大きな値となる置き換え候補２−７が障害ノードに置き換わるノードとして決定される。
【０１１８】
第２の実施形態によっても、第１の実施形態とほぼ同様な効果を奏することができる。第２の実施形態によれば、置き換え候補のスペックを段階的に評価して優先度に反映させ、その優先度に基づいて、障害ノードに置き換わるノードを決定するようにしたので、負荷の小さいノードが置き換わるノードとして決定される可能性が高く、負荷が第１の実施形態より分散するといった効果を期待できる。
【０１１９】
因みに、第１の実施形態の場合、スペックの充足性だけを判定していたため、スペックが充足されていれば負荷が能力（スペック）に近く余裕が少なくても、置き換わるノードとして決定される可能性がかなりあった。
【０１２０】
（Ｃ）他の実施形態
上記各実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【０１２１】
上記各実施形態では、置き換えノードの選択に利用する配信サーバのスペックが、下流ノードへのパス数、通信帯域及び余裕配信本数であるものを示したが、置き換えノードの選択に利用するスペックはこれらに限定されるものではない。例えば、配信サーバに搭載されているＣＰＵの動作クロック周波数や、配信サーバに搭載されているメモリの総容量若しくは空き容量などを、置き換えノードの選択に利用するスペックとして用いるようにしても良い。適用するスペックの組み合わせも、上記各実施形態のものに限定されない。例えば、下流ノードへのパス数、通信帯域及びＣＰＵの動作クロック周波数を利用するようにしても良い。
【０１２２】
上記各実施形態では、スペック以外に障害ノードに置き換わるノードの決定に用いるパラメータが、障害ノードの上流ノードと置き換え候補とのネットワーク距離であるものを示したが、これに代え、又は、これに加え、他のパラメータを利用するようにしても良い。
【０１２３】
例えば、各パスが双方向に通信可能とみなした場合において、障害ノードの上流ノードと、置き換え候補とを、基本的なツリー構成上で最短に結ぶパス数（ホップ数）であっても良い。ノード２−ｉ及び２−ｊ間のパスをＰ（２−ｉ，２−ｊ）で表わすこととする。例えば、図２において、ノード２−５に障害が発生し、障害ノードの上流ノードがノード２−２である場合において、置き換え候補がノード２−１１であれば、パスＰ（２−０，２−２）、Ｐ（２−０，２−１）及びＰ（２−１，２−１１）の３個のパスで両ノードを結ぶことができる。ノード２−５に障害が発生し、障害ノードの上流ノードがノード２−２である場合において、置き換え候補がノード２−７であれば、パスＰ（２−０，２−２）、Ｐ（２−０，２−１）、Ｐ（２−１，２−３）及びＰ（２−３，２−７）の４個のパスで両ノードを結ぶことができる。このようなパラメータは、ネットワーク距離に近似したものと取り扱うことが可能である。
【０１２４】
また例えば、コンテンツ管理サーバと置き換え候補とのネットワーク上の距離を、置き換えノードの決定に利用するようにしても良い。ここで、コンテンツ管理サーバがルートノードと共通になっている場合や、コンテンツ管理サーバが、基本的なツリー構成においてルートノードの上流に位置させている場合においては、ネットワーク距離に代え、コンテンツ管理サーバと、置き換え候補とを、基本的なツリー構成上で最短に結ぶパス数（ホップ数）を適用するようにしても良い。置き換えノードと、コンテンツ管理ノードとで制御情報等の授受が多くなるような場合であれば、このような制御情報の授受を迅速に実行させることができる。
【０１２５】
上記各実施形態では、コンテンツ管理サーバ３が置き換え候補のスペックの情報を格納しておき、置き換えノードの決定処理で格納されているスペック情報を利用するものを示したが、置き換え候補となり得る各ノードがそれぞれ、自己のスペックの情報を格納していて、コンテンツ管理サーバ３が置き換え候補からその候補のスペック情報をその都度収集し、置き換えノードの決定処理で用いるようにしても良い。
【０１２６】
また、上記各実施形態では、ツリー構成を再構成させる事象がいずれかのノードの障害である場合を示したが、他の事象であっても良い。例えば、ノードを定期点検するために、ツリー状ネットワークから切り離す場合のツリーの再構成の場合にも、本発明を適用することができる。
【０１２７】
さらに、上記各実施形態では、ユーザ端末に対してコンテンツを配信する複数の配信サーバを、論理的にはツリー状に分散配置したコンテンツ配信システムに、本発明を適用したものを示したが、本発明の用途はこれに限定されない。複数のサーバが論理的にはツリー状に配置され、ツリーのルートノードからエンドノードに向かって配送データ（コンテンツに限定されない）を枝分かれしながら配送することにより、各サーバに同一データを配備させるシステムであれば良い。従って、サーバからユーザ端末等にデータを配信する機能がないシステムであっても良い。
【符号の説明】
【０１２８】
１…コンテンツ配信システム、２−０〜２−Ｎ…配信サーバ、３…コンテンツ管理サーバ、４…配送情報データベース（配送情報ＤＢ）、１０…通信部、１１…配送コンテンツ受信部、１２…コンテンツ格納部、１３…配送コンテンツ送信部、１４…配送制御部、２０…通信部、２１…管理者インタフェース部、２２…ツリー基本構成格納部、２３…障害ノード格納部、２４…ツリー再構成部、２５…配送指示制御部。
【技術分野】
【０００１】
本発明は、ツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムに関し、例えば、分散配置された複数のコンテンツ配信サーバを論理的にツリー状に配置したシステムにおいて、ツリー途中のノード（但し、ノードはコンテンツ配信サーバを意味する）に障害が発生した場合の対応に適用し得るものである。
【背景技術】
【０００２】
ユーザ端末に対してコンテンツ（例えば、映像コンテンツ）を配信する複数のコンテンツ配信サーバ（以下、配信サーバと呼ぶ）を分散配置したコンテンツ配信システムがある。このようなコンテンツ配信システムの中には、上述した複数の配信サーバを論理的にはツリー状に配置し、ツリーのルートノードからエンドノードに向かってコンテンツを枝分かれしながら配送することにより、各配信サーバに同一コンテンツを配備させ、各配信サーバは自己が収容するユーザ端末にコンテンツを配信するシステムがある。
【０００３】
ここで、ツリーのルートノードからエンドノードに向かってコンテンツを配送している際中に、ツリー上のある中間ノードにおいて障害が発生した場合、その中間ノードの先のノードにコンテンツを配備できない。そのため、障害が発生した中間ノードを介さずに、全てのノードにコンテンツを配備できるようにツリーを再構成する必要がある。特許文献１の実施形態４には、ツリーの再構成方法が記載されている。この再構成方法は、障害が発生した中間ノードの下流のノード毎に、そのノードを収容する他のノードを決定するものである。収容する他のノードは、ツリー上のエンドノードの中から決定される。障害が発生した中間ノードに接続されている下流ノードが複数ある場合に、それぞれの下流ノードを収容する他のノードが決定され、下流ノードによって収容される他のノードが異なることもある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−２５６２２
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、コンテンツ配送中に中間ノードに障害が発生した場合、その障害ノードの下流ノードを収容することとなったエンドノードまで、コンテンツが配送されていないこともあり、ツリーを再構成して、再構成したツリーを適用しても障害ノードの下流側のノードへコンテンツを配送できない恐れもある。
【０００６】
障害ノードの下流ノードを収容することとなったエンドノードまでコンテンツが配送されていたとしても、再構成前にエンドノードであったノードが中間ノードとして下流への配送を行うため、ルートノードからの必要ホップ数が再構成前より大きくなったノードが多く、ツリー上の全てのノードにコンテンツを配備するのにかなりの長時間を要する。特に、置き換えられたノードの配送能力が低い場合には、かかる配備時間の課題はより大きなものとなる。
【０００７】
そのため、ツリー上の全てのノードに配送データを迅速に配備させることができるツリー状ネットワーク再構成装置及びプログラムが望まれている。
【課題を解決するための手段】
【０００８】
第１の本発明は、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置において、（１）除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、（２）置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、（３）置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段とを備えることを特徴とする。
【０００９】
第２の本発明のツリー状ネットワーク再構成プログラムは、分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に搭載されるコンピュータを、（１）除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、（２）置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、（３）置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段として機能させることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ツリー上の全てのノードに配送データを迅速に配備させることができるツリー状ネットワーク再構成装置及びプログラムを実現することができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態のコンテンツ配信システムの全体構成を示すブロック図である。
【図２】第１の実施形態における複数の配信サーバの論理的な接続関係を示す説明図である。
【図３】第１の実施形態における配信サーバの内部構成を示す機能ブロック図である。
【図４】第１の実施形態におけるコンテンツ管理サーバの内部構成を示す機能ブロック図である。
【図５】第１の実施形態における配送情報データベースにおける置き換えノード候補を評価するための情報の構成を示す説明図である。
【図６】第１の実施形態におけるコンテンツ管理サーバが実行する配送指示動作を示すフローチャートである。
【図７】第１の実施形態において、管理者からの配送指示に対し、コンテンツ配送が正常になされる場合の処理の流れを示すシーケンス図である。
【図８】第１の実施形態において、管理者からの配送指示に応じて開始しようとしたコンテンツ配送の配送先を、障害の配信サーバのために置き換える必要が生じた場合の処理の流れを示すシーケンス図である。
【図９】第１の実施形態におけるコンテンツ管理サーバが実行するツリーの再構成処理を示すフローチャートである。
【図１０】第１の実施形態における、障害ノードの置き換え候補と、障害ノードに直接接続されている上流ノードとの距離を計測する処理を示すシーケンス図である。
【図１１】第１の実施形態におけるツリーの再構成後の構成を、従来におけるツリーの再構成後の構成と共に示す説明図である。
【図１２】第２の実施形態におけるコンテンツ管理サーバが実行するツリーの再構成処理を示すフローチャートである。
【図１３】第２の実施形態における配送情報データベースにおける置き換えノード候補を評価するための情報の構成を示す説明図である。
【発明を実施するための形態】
【００１２】
（Ａ）第１の実施形態
以下、本発明によるツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムの第１の実施形態を、図面を参照しながら説明する。第１の実施形態のツリー状ネットワークシステムは、コンテンツ配信システムである。
【００１３】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態のコンテンツ配信システム１の全体構成を示すブロック図である。
【００１４】
図１において、第１の実施形態のコンテンツ配信システム１は、複数の配信サーバ２−０〜２−Ｎと、コンテンツ管理サーバ３と、配送情報データベース（配送情報ＤＢ）４とがネットワーク５を介して通信可能に接続されている。
【００１５】
ネットワーク５は、１つのネットワーク（例えば、ＩＰネットワーク）であっても良く、また、複数のネットワークが融合したものであっても良い。さらに、ネットワーク５は、スター状、リング状、メッシュ状等のいずれの接続形態のものであっても良い。
【００１６】
第１の実施形態のコンテンツ配信システム１は、このようなネットワーク５の構成に拘わらず、複数の配信サーバ２−０〜２−Ｎの論理的な接続関係が定まっている。すなわち、第１の実施形態のコンテンツ配信システム１の場合、複数の配信サーバ（適宜、ノードと呼ぶ）２−０〜２−Ｎは、論理的には、図２に示すようにツリー状に接続されている（図２は配信サーバが１２個の場合を示している）。但し、コンテンツ管理サーバ３及びツリーデータベース４は、このツリー状ネットワークから離れて設けられている。ここで、ツリー状ネットワークとは、１つのルートノード２−０から徐々に枝分かれしつつ、末端のエンドノード２−５、２−７〜２−１１へのコンテンツの配信経路が１本道になっているネットワークである。
【００１７】
ルートノード２−０は、予め定まっている次（下流）のノード（図２の例では２−１及び２−２）へコンテンツを送信だけするノードである。各エンドノード２−５、２−７〜２−１１はそれぞれ、予め定まっている前（上流）のノードから送信されたコンテンツを受信するだけのノードである。中間ノード２−１〜２−４、２−６は、予め定まっている前（上流）のノードから送信されたコンテンツを受信すると共に、そのコンテンツを予め定まっている次（下流）のノードへ送信するノードである。
【００１８】
この明細書において、「配送」とは各配信サーバにコンテンツを配備するために配信サーバから他の配信サーバへコンテンツを送信することを言い、一方、「配信」とは配信サーバが自己に配備されたコンテンツをユーザ端末へ送信することを言うこととする。
【００１９】
各配信サーバ２−０〜２−Ｎはそれぞれ、配送されたコンテンツを自己に配備して、自己に割り当てられているユーザ端末にコンテンツを配信するサーバである。各配信サーバ２−０〜２−Ｎは、ユーザ端末の位置や密度等を考慮しながら、各地域に分散的に配置されているものである。
【００２０】
図３は、配信サーバ２−ｎ（ｎは０〜Ｎ）の内部構成を示した機能ブロック図であり、特には、中間ノードの内部構成を示している。
【００２１】
配信サーバ２−ｎは、通信部１０、配送コンテンツ受信部１１、コンテンツ格納部１２、配送コンテンツ送信部１３、配送制御部１４、コンテンツ配信部１５及び配信制御部１６を有する。
【００２２】
通信部１０は、ネットワーク５側との通信（送受信）を行うものである。ネットワーク５が、例えばＩＰネットワークであれば、通信部１０は、ＴＣＰ／ＩＰ送受信部となる。なお、図３では、配信サーバ間でコンテンツを配送する通信部もユーザ端末にコンテンツを配信する通信部も共通なものを示したが、これら通信部が別個に設けられたものであっても良い。
【００２３】
配送コンテンツ受信部１１は、上流ノードから配送（送信）された通信部１０を介して与えられたコンテンツを受信処理して、コンテンツ格納部１２に格納させるものである。
【００２４】
コンテンツ格納部１２は、配送されたコンテンツを格納するものである。ここで、ユーザ端末に配信するためにコンテンツを格納する格納部と、上流ノードから配送されたコンテンツを下流ノードに送信するまで一時的に格納する格納部とを別個に設けるようにしても良い。このような２つの格納部構成の場合には、後者の格納部から前者の格納部へ移し替えることも適宜実行される。
【００２５】
配送コンテンツ送信部１３は、コンテンツ格納部１２に格納されているコンテンツを、通信部１０を介して、下流ノードへ送信（配送）するものである。
【００２６】
配送制御部１４は、コンテンツ配送に係る各種の制御処理を実行するものである。例えば、配送制御部１４は、配送コンテンツ受信部１１によるコンテンツの受信が終了した場合には、受信が正常に終了したことを通信部１０を介して配送元の配信サーバに通知し、受信が途中で失敗したときには受信エラーを通信部１０を介して配送元の配信サーバに通知する。また例えば、配送制御部１４は、通信部１０を介してコンテンツ管理サーバ３から配送指示が与えられたときに、配送コンテンツ送信部１３による下流ノードへのコンテンツ配送を起動するものである。さらに例えば、配送制御部１４は、通信部１０を介して、下流ノードからコンテンツの受信終了の通知や受信エラーを受け取ったときには、通信部１０を介してコンテンツ管理サーバ３へ配送指示に従った配送を実行した旨やエラー発生を返信するものである。また例えば、配送制御部１４は、下流ノードへのコンテンツ配送を開始しようとして又はコンテンツ配送中に、下流ノードの障害発生を認識したときには、通信部１０を介してコンテンツ管理サーバ３へ障害発生又はエラー発生を通知するものである。
【００２７】
第１に、コンテンツを配送する下流ノードの情報は配送指示に含まれていても良い。第２に、下流ノードの情報は配送指示に含まれておらず、配送制御部１４が内部に下流ノードの情報を保持しておき、配送指示時に、その情報を取り出すようにしても良い。第３に、下流ノードの情報が配送指示に含まれていればそれに従い、下流ノードの情報が配送指示に含まれていなければ配送制御部１４が内部に保持しておいた下流ノードの情報を利用するようにしても良い。後述するツリーの再構成後において、第１及び第３の方法では、配送指示に下流ノードの情報を含めることで再構成後の下流ノードへ配送を行うことができる。第２の方法の場合、配送指示に先立ち、再構成後の下流ノードの情報が与えられて配送制御部１４が保持し、その後、配送指示が与えられることになる。
【００２８】
コンテンツ配信部１５は、コンテンツ格納部１２に格納されているコンテンツを、通信部１０を介して、ユーザ端末へ配信するものである。コンテンツ配信部１５は、配送コンテンツ送信部１３と共用させたものであっても良い。
【００２９】
配信制御部１６は、ユーザ端末へのコンテンツ配信を制御するものである。ここで、ユーザ端末へのコンテンツ配信は、所定時刻になったときや、上位装置（図示せず）からに指示に従って、当該配信サーバ２−ｎが管轄する全てのユーザ端末へ一斉若しくは逐次配信であっても良く、また、配信を要求したユーザ端末への個別配信であっても良い。
【００３０】
図３は、上述したように、中間ノードとなっている配信サーバ２−ｎの内部構成を示している。ルートノードとなっている配信サーバ２−０は、配送コンテンツをネットワークから受け入れる構成がないものであっても良い。この場合、管理者のファイル設定操作等によって、コンテンツ格納部１２にコンテンツを格納させることになる。また、ルートノードとなっている配信サーバ２−０も、図３と同様な構成を有し、配信サーバとは異なる外部装置が送信したコンテンツをネットワーク５から取り込んで、コンテンツ格納部１２にコンテンツを格納させるようにしても良い。エンドノードとして、中間ノードとなることができるエンドノードの他、中間ノードとなることができないエンドノードがあっても良い。中間ノードとなることができるエンドノードは、図３に示す構成を有する。中間ノードとなることができないエンドノードは、コンテンツを下流ノードへ配送する構成がないものであっても良い。
【００３１】
コンテンツ管理サーバ３は、全て（但し、障害が発生しているものを除く）の配信サーバ２−０〜２−Ｎにコンテンツを配備させるべく、コンテンツの配送を管理、制御するサーバである。なお、コンテンツ管理サーバ３は、ユーザ端末へのコンテンツへの配信についても、管理、制御するものであっても良い。
【００３２】
図４は、コンテンツ管理サーバ３の内部構成を示した機能ブロック図である。コンテンツ管理サーバ３の一部機能が、ＣＰＵ及びＣＰＵが実行するプログラムによって実現されている場合であっても、機能的には、コンテンツ管理サーバ３の内部構成を図４で示すことができる。
【００３３】
図４において、コンテンツ管理サーバ３は、通信部２０、管理者インタフェース部２１、ツリー基本構成格納部２２、障害ノード格納部２３、ツリー再構成部２４及び配送指示制御部２５を有する。
【００３４】
通信部２０は、ネットワーク５側との通信（送受信）を行うものである。ネットワーク５が、例えばＩＰネットワークであれば、通信部２０は、ＴＣＰ／ＩＰ送受信部となる。
【００３５】
管理者インタフェース部２１は、キーボード、マウス、ディスプレイ等でなり、管理者による操作入力（例えば、配送指示）を取り込んだり、当該コンテンツ管理サーバ３における処理結果やガイダンスメッセージ等を管理者に知得させたりするものである。図４では、管理者が、コンテンツ管理サーバ３に直接操作するものを示したが、管理者がパソコンなどでなる管理者端末を操作し、その管理者端末とコンテンツ管理サーバ３との通信によって、管理者がコンテンツ管理サーバ３に指示を与えるものであっても良い。
【００３６】
ツリー基本構成格納部２２は、全ての配信サーバ２−０〜２−Ｎの図２に示すような基本的なツリー構成の情報を格納しているものであり、その格納情報は、適宜、配送指示制御部２５によって読み出されるものである。ここで、基本的なツリー構成とは、いずれの配信サーバにも障害が発生していないときに、コンテンツの配送に利用するツリー構成をいう。後述するように、いずれかの配信サーバに障害が発生した場合にはツリーの再構成が実行される。この場合において、障害ノードが復旧したときには、ツリー基本構成格納部２２に格納されている基本的なツリー構成を再度適用するようにしても良く、また、再構成されたツリーに、復旧したノードを所定ルールに従って追加して、新たな基本的なツリー構成としてツリー基本構成格納部２２に上書きするようにしても良い。以下では、障害ノードが復旧したときには、ツリー基本構成格納部２２に格納されている基本的なツリー構成を再度適用するものとして説明する。
【００３７】
障害ノード格納部２３は、障害が発生中の配信サーバの情報（サーバの識別情報や障害件時刻等）を格納しているものであり、格納情報は、配送指示制御部２５によってアクセス（書込み、読出し、消去等）される。障害ノード格納部２３に障害が発生した配信サーバの情報が格納されているときには、後述するツリーの再構成処理で決定された、その障害発生の配信サーバに置き換わる配信サーバの情報も併せて格納されるようになされている。
【００３８】
配信サーバに障害があることは、上流の配信サーバがコンテンツを配送しようとしたときに検出することができる。また、コンテンツ管理サーバ３が定期的に各配信サーバの状態を確認して障害の発生を検出することもできる。
【００３９】
ツリー再構成部２４は、いずれかの配信サーバに障害が発生した場合、すなわち、基本的なツリー構成では、コンテンツが配送されない配信サーバが生じる場合に、配送指示制御部２５の制御下で、ツリーを再構成するものである。ツリーの再構成処理は、いずれかの配信サーバに障害が生じたことを検出されたときに実行される。ツリー再構成部２４による再構成方法については、後述する動作説明で明らかにする。
【００４０】
配送指示制御部２５は、管理者からの配送指示を受け、その配送指示に係る配送元及び配送先の配信サーバ間の配送状況や、配送元及び配送先の配信サーバの障害有無等を確認し、基本的構成のツリー上のいずれかの配信サーバ若しくは再構成したツリー上のいずれかの配信サーバに対し、通信部２０を介してコンテンツの配送指示を与えるものである。配送指示制御部２５は、複数種類のコンテンツの配送を並行的に制御しても良い。配送指示制御部２５は、それぞれのコンテンツをルートノード２−０に配備した時刻を管理している。
【００４１】
配送情報データベース４は、詳細構成の図示は省略するが、コンテンツ管理サーバ３が処理時に参照する少なくとも２種類の情報を格納しているものである。第１の情報は、各配信サーバについて、コンテンツが未配送か配送済かを表す配送状況の情報である。配送に係るコンテンツが複数種類ある場合には、それぞれのコンテンツについて配送状況の情報が格納される。第２の情報は、基本的なツリー構成における中間ノードに障害が発生した場合において、その中間ノードに置き換わって、その中間ノードの下流ノードへのコンテンツ配送を行うノードとなり得る置き換え候補と、その候補を評価するための情報（候補評価用情報）である。
【００４２】
図１では、配送情報データベース４もネットワーク５の要素となっているものを示したが、配送情報データベース４が、コンテンツ管理サーバ３に対して専用回線によって接続されていても良く、また、コンテンツ管理サーバ３にケーブル等で直接接続されたものであっても良い。このような場合、コンテンツ管理サーバ３は、通信部２０の他に配送情報データベース４にアクセスするための構成要素を備えることになる。
【００４３】
図５は、配送情報データベース４における上述した候補評価用情報（第２の情報）の構成例を示す説明図であり、置き換え候補となり得る一部の配信サーバの情報を示している。
【００４４】
図５において、候補評価用情報は、置き換え候補の識別情報毎の行（レコード）を有し、各行は、その置き換え候補のサーバとしてのスペック（サーバとして備わっている処理能力）の情報と、距離情報とでなる。
【００４５】
スペック情報としては、例えば、（ａ）下流ノードを収容できる数（下流ノードと接続可能なパス本数）、（ｂ）下流ノードへの各パスにおける通信帯域、（ｃ）コンテンツ配信可能本数（現在の状態から増加することが可能な余裕の配信本数）が記述される。距離情報は、当初は空欄であって、障害ノードが生じてその行のノードが置き換え候補となったときに、後述するように計測されて書き入れられるものである。
【００４６】
図５の例では、配信サーバ２−７は置き換え候補になり得るサーバであり、配信サーバ２−７は、最大５個の下流ノードへコンテンツを配送することが可能であり、５本の下流ノードへのパスはそれぞれ、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］、１０［ＧＢ／ｓ］の通信帯域を確保でき、現状より１２０個多いユーザ端末への配信が可能である。距離として「８．１」が記述されているが、これは、後述するよう距離計測処理がなされて書き入れられたものである。
【００４７】
この第１の実施形態の場合、障害ノードに置き換えられたノードは、下流ノードへのコンテンツ配送だけでなく、障害ノードに割り当てられているユーザ端末へのコンテンツ配信を引き継ぐ。但し、障害ノードに置き換えられたノードは、下流ノードへのコンテンツ配送だけを引き継ぎ、障害ノードに割り当てられているユーザ端末へのコンテンツ配信は他のルールによって引き継ぐノードを決定するようにしても良い。例えば、障害ノードとの距離が近いノード（若しくは基本構成上で障害ノードとのホップ数が少ないノード）で、コンテンツ配信に余裕があるノードが、障害ノードに割り当てられているユーザ端末へのコンテンツ配信を引き継ぐようにしても良い。このような場合であれば、（ｃ）のコンテンツ配信可能本数は候補評価用情報から除外される。
【００４８】
（Ａ−２）第１の実施形態の動作
次に、第１の実施形態に係るコンテンツ配信システム１の動作を説明する。以下では、ツリーの再構成に関係する動作を中心に説明する。
【００４９】
管理者は、コンテンツ管理サーバ３に対して、基本的なツリー構成上、直接接続されている２つの配信サーバ（若しくはこれら配信サーバを結ぶパス）を指定してコンテンツの配送を指示する。このとき、コンテンツ管理サーバ３は、図６に示す適用ツリーの決定動作を実行する。
【００５０】
なお、配送に係るコンテンツが複数種類存在する場合には、管理者はコンテンツの種類を指定して配送を指示することになる。例えば、管理者は、ディスプレイ上に基本的なツリー構成を表示させ、その表示されたツリー構成のいずれかのパスを表示画面上で指定（例えばクリック）することにより、配送指示に係るパス（２つの配信サーバ）を指定する。なお、ディスプレイ上に基本的なツリー構成を表示させる際、全ての配信サーバについて、配送情報データベース４に格納されている配送状況を取出し、コンテンツが未配送の配信サーバと配送済の配信サーバとを区別（例えば、表示色を変える）して表示し、効率的にコンテンツ配送の指示を発行することができるようにしても良い。
【００５１】
コンテンツ管理サーバ３は、図６に示す処理を開始すると、まず、配送指示に係るコンテンツの各配信サーバへの配送状況を配送情報データベース４から取出すと共に、内蔵する障害ノード格納部２３から障害情報を取り出す（ステップ１００）。
【００５２】
そして、コンテンツ管理サーバ３は、障害ノードが存在するか否かを判別する（ステップ１０１）。障害ノードが存在しない場合には、コンテンツ管理サーバ３は、基本的なツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、基本的なツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０２）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。
【００５３】
障害ノードがあると、コンテンツ管理サーバ３は、障害検出時刻と、コンテンツをルートノード２−０に配備した時刻とを比較することにより、今回の配送指示に係るコンテンツの一連の配送動作が開始された以降に障害が発生した否かを判別する（ステップ１０４）。
【００５４】
今回の配送指示に係るコンテンツの一連の配送動作が開始される前に障害が発生していると、コンテンツ管理サーバ３は、再構成されたツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、再構成されたツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０５）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。すなわち、コンテンツをルートノード２−０に配備する前に、障害ノードが生じていた場合には、再構成されたツリー構成を適用する。ステップ１０５を実行する際に、並行して、ツリーの再構成処理が行われていても良い。
【００５５】
一方、障害検出時刻と、コンテンツをルートノード２−０に配備した時刻との比較により、基本構成のツリー構成での配送を行っている際中に、いずれかのノードに障害が発生したと判別した場合には、コンテンツ管理サーバ３は、障害ノードの下流ノードへのコンテンツ配送が終了しているか否かを判別する（ステップ１０６）。障害ノードの下流ノードへのコンテンツ配送が終了していると、コンテンツ管理サーバ３は、基本的なツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、基本的なツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０２）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。これに対して、障害ノードの下流ノードへのコンテンツ配送がなされていないと、コンテンツ管理サーバ３は、再構成されたツリー構成に従ってコンテンツを配送することに決定し、管理者から指示された配送指示を、再構成されたツリー構成にあてはめて配送元の配信サーバを定め（ステップ１０５）、その配送元の配信サーバへ配送指示を与える（ステップ１０３）。
【００５６】
コンテンツ管理サーバ３は、図６に示す処理を実行し、障害ノードが生じた場合に、常に、再構成されたツリー構成を適用するのではなく、ツリー全体に対するコンテンツの配送状況に鑑み、障害ノードが生じた以降でも、基本的なツリー構成を適用するか、再構成されたツリー構成を適用するかを定める。従って、再構成されたツリー構成を適用することに一律に決めたような場合に比較し、コンテンツが配送されないノードが生じるようなことを防止できる。
【００５７】
以上では、管理者が配送元及び配信先の配信サーバを特定した配送指示をコンテンツ管理サーバ３に対して与える場合を説明したが、全ノードへの配送指示をコンテンツ管理サーバ３に対して与えるようにしても良い。全ノードへの配送指示が与えられたコンテンツ管理サーバ３は、基本的なツリー構成におけるルートノード側のパスから、パスを１つずつ順に取出し、取出したパスに係る上流及び下流の配信サーバに係る配送指示を形成し、図６に示す配送指示が入力された場合の処理を実行するようにすれば良い。
【００５８】
図７は、管理者からの配送指示に対し、コンテンツ配送が正常になされる場合の処理の流れを示すシーケンス図である。
【００５９】
管理者６がコンテンツ管理サーバ３にコンテンツ配送指示を発行すると（ステップ２００）、コンテンツ管理サーバ３は、配送状況を配送情報データベース４から取出したりしながら（ステップ２０１；図６のステップ１００参照）、上述した図６の処理により、配送元（上流）の配信サーバ２−Ｕと配送先（下流）の配信サーバ２−Ｌとを確定し、上流の配信サーバ２−Ｕに対し、下流の配信サーバ２−Ｌへのコンテンツ配送を指示する（ステップ２０２）。
【００６０】
この指示に従い、上流の配信サーバ２−Ｕは、下流の配信サーバ２−Ｌへコンテンツを配送する（ステップ２０３）。下流の配信サーバ２−Ｌは、コンテンツの受信が正常に終了した場合には、受信が正常に終了したことを上流（配送元）の配信サーバ２−Ｕに通知し（ステップ２０４）、上流の配信サーバ２−Ｕは、このとき、コンテンツ管理サーバ３へ配送指示に従った配送を実行した旨を返信する（ステップ２０５）。
【００６１】
これにより、コンテンツ管理サーバ３は、配信サーバ２−Ｌへコンテンツを配送した旨の情報を配送情報データベース４へ与えて、配送情報データベース４の配信サーバ２−Ｌについての配送状況を配送済に更新させる（ステップ２０６）。そして、コンテンツ管理サーバ３は、配送情報データベース４からの格納応答を受けて、管理者６に対して、与えられた配送指示の配送が正常終了したことを通知する（ステップ２０７）。
【００６２】
図７に示す処理を、配送元及び配信先の配信サーバの組み合わせを換えて繰り返し行うことにより、ツリー状の全てのノード（配信サーバ）にコンテンツを配備することができる。
【００６３】
図８は、管理者からの配送指示に応じて開始しようとしたコンテンツ配送の配送先を、障害の配信サーバのために置き換える必要が生じた場合の処理の流れを示すシーケンス図であり、図７との同一処理には同一符号を付している。
【００６４】
管理者からの配送指示に応じ、コンテンツ管理サーバ３が、上流の配信サーバ２−Ｕに対し、下流の配信サーバ２−Ｌへのコンテンツ配送を指示し、上流の配信サーバ２−Ｕが、下流の配信サーバ２−Ｌへコンテンツを配送しようとするまでの処理の流れは図７の場合と同様である（ステップ２００〜２０３）。
【００６５】
下流の配信サーバ２−Ｌに障害が発生していると（ステップ２５０）、上流の配信サーバ２−Ｕがコンテンツを下流の配信サーバ２−Ｌへ配送しようとしても配送できない。上流の配信サーバ２−Ｕは、下流の配信サーバ２−Ｌとのセッションが確立できないことや、下流の配信サーバ２−Ｌから、受信が正常に終了したことの通知が届かないこと等により、下流の配信サーバ２−Ｌに障害が発生していることを検出し、コンテンツ管理サーバ３に配送エラーを返信する（ステップ２５１）。
【００６６】
このとき、コンテンツ管理サーバ３は、下流の配信サーバ２−Ｌに障害が発生していることの障害情報を内部に格納すると共に（ステップ２５２）、後述するようなツリーの再構成処理を実行する（ステップ２５３）。
【００６７】
ツリーの再構成処理により、障害ノード２−Ｌに置き換える配信サーバ２−Ｌｎｅｗが定まると、コンテンツ管理サーバ３は、上流の配信サーバ２−Ｕに対し、置換配信サーバ２−Ｌｎｅｗへのコンテンツ配送を指示する（ステップ２５４）。このような配送指示に応じた上流の配信サーバ２−Ｕ及び置換配信サーバ２−Ｌｎｅｗの処理は、図７の場合と同様である。
【００６８】
すなわち、上流の配信サーバ２−Ｕは、この配送指示に従い、置換配信サーバ２−Ｌｎｅｗへコンテンツを配送し（ステップ２５５）、置換配信サーバ２−Ｌｎｅｗは、コンテンツの受信が正常に終了したときに、受信が正常に終了したことを上流の配信サーバ２−Ｕに通知し（ステップ２５６）、上流の配信サーバ２−Ｕは、コンテンツ管理サーバ３へ配送指示に従った配送を実行した旨を返信し（ステップ２５７）、コンテンツ管理サーバ３は、置換配信サーバ２−Ｌｎｅｗへコンテンツを配送した旨の情報を配送情報データベース４へ与えて、配送情報データベース４の配信サーバ２−Ｌｎｅｗについての配送状況を配送済に更新させ（ステップ２５８）、コンテンツ管理サーバ３は、配送情報データベース４からの格納応答を受けて、管理者６に対して、与えられた配送指示の配送が終了したことを通知する（ステップ２５９）。但し、この終了通知では、配信ノード２−Ｌに障害が発生していたため、それに置き換わる配信サーバ２−Ｌｎｅｗへコンテンツを配送したことを管理者に通知する。
【００６９】
例えば、図２における配信サーバ２−０から配信サーバ２−２への配送指示時において、配送先の配信サーバ２−２に障害が発生していた場合には、配信サーバ２−２の下流の配信サーバ２−５、２−６、２−１０へコンテンツを配送できなくなる。そのため、配信サーバ２−２に置き換わる配信サーバを定めて、配信サーバ２−２の下流の配信サーバ２−５、２−６、２−１０へコンテンツを配送できるようにする。なお、第１の実施形態の場合、障害の配信サーバに置き換わった配信サーバは、障害の配信サーバに割り当てられていたユーザ端末への配信をも行うものとなる。
【００７０】
また例えば、図２における配信サーバ２−４から配信サーバ２−９への配送指示時において、配送先の配信サーバ２−９に障害が発生していた場合には、配信サーバ２−９の下流には配信サーバは存在しない。しかし、障害の配信サーバに割り当てられていたユーザ端末への配信を行う必要があるので、このようなエンドノードに障害が発生している場合にも、障害の配信サーバ２−９の配信を引き継ぐ配信サーバを定めることを要する。
【００７１】
図８では、置換配信サーバ２−Ｌｎｅｗへコンテンツを常に配送するものを示したが、コンテンツ管理サーバ３は、置換配信サーバ２−Ｌｎｅｗが定まると、置換配信サーバ２−Ｌｎｅｗについての配送状況を配送情報データベース４から取出し、置換配信サーバ２−Ｌｎｅｗへの配送が既に済んでいる場合にはコンテンツの配送を実行せずに直ちに管理者に終了通知を行い、置換配信サーバ２−Ｌｎｅｗへの配送が済んでいない場合には置換配信サーバ２−Ｌｎｅｗへのコンテンツの配送を実行し、管理者に終了通知を行うようにしても良い。
【００７２】
図８は、配送指示に係る配送先の配信サーバに障害が発生していた場合を示しているが、配送指示に係る配送元（上流）の配信サーバに障害が発生していた場合にも、コンテンツ管理サーバ３は、障害ノード２−Ｕに置き換える配信サーバ２−Ｕｎｅｗが定めて、その置換配信サーバ２−Ｕｎｅｗに対し、配信サーバ２−Ｌへのコンテンツ配送を指示するようにしても良い。例えば、配送指示を与えようとして行ったセッションの確立動作でも、配送元（上流）の配信サーバ２−Ｕとのセッションを確立できないことにより、コンテンツ管理サーバ３は、配送元（上流）の配信サーバの障害発生を検出することができる。
【００７３】
図９は、コンテンツ管理サーバ３が実行するツリーの再構成処理（再構成プログラム）を示すフローチャートである。例えば、上述した図８のステップ２５３の処理として、ツリーの再構成処理が実行される。再構成処理が起動される場合は、上述した図８のような状況には限定されない。例えば、定期的な障害監視処理でいずれかのノードの障害が検出されたときに、ツリーの再構成処理を起動し、それ以降のコンテンツの配送指示に対応可能としておくようにしても良い。
【００７４】
コンテンツ管理サーバ３は、図９に示す処理を開始するとまず、まず、置き換え候補を選出する（ステップ３００）。置き換え候補の選出方法は限定されるものではない。例えば、選出する候補の最少数を定めておくようにしても良い。また例えば、基本的なツリー構成におけるエンドノードだけを置き換え候補とするようにしても良い。さらに例えば、基本的なツリー構成において、障害ノードの下流に位置していないノードを置き換え候補とするようにしても良い。また例えば、ルートノードからのホップ数が多い方のノードを置き換え候補とするようにしても良い。
【００７５】
コンテンツ管理サーバ３は、置き換え候補を選出すると、次に、各置き換え候補の配信サーバについて配送情報データベース４に格納されているスペック情報に基づいて、置き換え候補の絞り込みを行う（ステップ３０１）。例えば、置き換え候補が収容できる下流ノードの数は、障害ノードが収容（接続）していた下流ノードの数以上になっている、置き換え候補における下流ノードへの各パスにおける通信帯域は、障害ノードの各パスにおける通信帯域を確保できる、置き換え候補は障害ノードに割り当てられていた全てのユーザ端末を引き受けられるという３つの要件を全て満たす置き換え候補に絞り込まれる。なお、このステップ３０１は、スペック情報に基づいて、要件の充足、不充足だけをマークするようにし、置き換え候補の絞り込みを実行せず、後述するステップ３０３による置き換えノードの決定処理で、マークした要件の充足性を利用するようにしても良い。上記では、障害ノードのスペック若しくは実績値を基準（閾値）として、置き換え候補のスペックの充足性を判断するものを示したが、障害ノードのスペック若しくは実績値に所定数を掛けた値を閾値として、置き換え候補のスペックの充足性を判断するようにしても良い。障害ノードが収容していたユーザ端末数をＭとした場合、Ｍ×ａ（ａは１．２）を閾値として置き換え候補の余裕配信数を評価するようにしても良い。
【００７６】
その後、コンテンツ管理サーバ３は、絞り込んだ各置き換え候補のそれぞれについて順次、障害ノードに直接接続されている上流ノードとの距離を計測させ、得られた距離情報を配送情報データベース４に格納させる（ステップ３０２）。
【００７７】
そして、コンテンツ管理サーバ３は、計測した距離が最も短い置き換え候補を、障害ノードに置き換えるノードと決定し（ステップ３０３）、決定したノードを障害ノードに置き換えて適用されるように、内部の格納情報を変更する（ステップ３０４）。コンテンツ管理サーバ３は、例えば、内蔵する障害ノード格納部２３に、障害ノードの情報に対応付けて、その障害ノードに置き換わるノードの情報を格納する。
【００７８】
図１０は、コンテンツ管理サーバ３の主導の元で実行される、置き換え候補と、障害ノードに直接接続されている上流ノードとの距離を計測する処理（ステップ３０２）を示すシーケンス図である。
【００７９】
コンテンツ管理サーバ３は、障害ノードに直接接続されている上流ノード２−Ｘに対し、置き換え候補のノード２−Ｙを特定した距離情報の取得要求（例えばネットワークアドレスで置き換え候補のノード２−Ｙを特定する）を送出する（ステップ４００）。このとき、上流ノード２−Ｘは、折り返しを指示した情報を含むパケットを置き換え候補のノード２−Ｙに送信すると共に、その送信時刻を取得して格納する（ステップ４０１、４０２）。置き換え候補のノード２−Ｙは、そのようなパケットが到来したときにはそのパケットを折り返す（ステップ４０３）。上流ノード２−Ｘは、このような折り返しパケットが戻ってきたときには、その受信時刻を取得し（ステップ４０４）、送信時刻と受信時刻の差に予め求めておいたネットワーク５での平均通信速度を乗算してネットワーク距離を算出し（ステップ４０５）、算出したネットワーク距離をコンテンツ管理サーバ３に返信する（ステップ４０６）。置き換えノードの決定では、距離の大小が問題となるので、上述のような往復での距離を算出して用いても問題となることはない。
【００８０】
障害ノードに置き換わるノードが決定され、ツリーが再構成されると、障害ノードが復旧するまで、この際構成されたツリー構成に従い、ルートノードからの各ノードへのコンテンツ配送が実行される。
【００８１】
次に、上述した置き換えノードの決定方法を、具体例を挙げて説明する。以下、図２に示す基本的なツリー構成における配信サーバ２−２に障害が発生し、配信サーバ２−２に置き換わる置き換えノードの決定が必要となったとする。図２に示すように、配信サーバ２−２は下流へのパスが２本のサーバである。また、それら各パスの通信帯域がそれぞれ５［ＧＢ／ｓ］、５［ＧＢ／ｓ］のものであり、配信サーバ２−２は、割り当てられている配信本数が９０本のものであるとする。
【００８２】
ここで、置き換え候補は少なくとも３候補とし、障害ノードの下流に位置していないエンドノードであって、ルートノードからのホップ数が多い方のエンドノードを優先して置き換え候補にすることになっているとする。エンドノードは、下流へのコンテンツ配送を今まで実行していないので、中間ノードより、下流へのコンテンツ配送能力に余裕が高いと推測される。また、置き換えにより、ルートノードから置き換えノードまでのホップ数が、置き換え前より改善される度合いが高くなると推測されるため、ルートノードからのホップ数が多い方のエンドノードを優先させることは好ましい。さらに、障害ノードの下流に位置しているノードを置き換え候補とした場合には、ツリー状の上下が逆転する部分も生じてツリーの変更度合いが大きいので、障害ノードの下流に位置していないエンドノードを置き換え候補とすることは好ましい。
【００８３】
なお、上述した選定方法に限定されないことは勿論である。例えば、中間ノードを置き換え候補にするような選定方法であっても良い。
【００８４】
上述した選定方法を適用した場合、障害ノード（障害が発生した配信サーバ）２−２の置き換え候補は、ノード２−７〜２−９となる。仮に、少なくとも４つを候補とする場合であれば、置き換え候補は、ノード２−７〜２−９、２−１１となる。
【００８５】
置き換え候補２−７〜２−９が、図５に示すスペックのものであったとする。障害ノード２−２は下流へのパスが２本であるので、いずれの置き換え候補２−７〜２−９も下流へのパス本数の要件は充足する。障害ノード２−２の各パスの通信帯域がそれぞれ５α、５β［Ｂ／ｓ］であるので、これ以上の通信帯域を確保できる置き換え候補２−７及び２−９は通信帯域の要件を充足する。障害ノード２−２に割り当てられている配信本数が９０本であるので、余裕配信本数がこれ以上である置き換え候補２−７及び２−９は引き受けられる配信本数の要件を充足する。
【００８６】
以上のスペックに基づく置き換え候補の絞り込みでは、置き換え候補２−７及び２−９が残る。そこで、コンテンツ管理サーバ３は、このようにして残った置き換え候補２−７及び２−９のそれぞれと、障害ノード２−２の上位ノード２−０とのネットワーク距離を計測させる。この計測結果が、図５に示すような場合、コンテンツ管理サーバ３は、ネットワーク距離が短い方の置き換え候補であるノード（配信サーバ）２−９を、障害ノード２−２に置き換えるノードに決定する。
【００８７】
図１１（Ａ）は、ノード２−９を障害ノード２−２に置き換えた、再構成されたツリーの構成を示している。ノード２−９は、障害ノード２−２に置き換えられたので、再構成前とは異なり、障害ノード２−２の上流ノード２−０からコンテンツが配送されるものとなる。
【００８８】
図１１（Ｂ）は、ノード２−２に障害が発生した場合において、特許文献１に記載の再構成方法を適用して再構成されたツリーの構成を示している。すなわち、障害ノード２−２の下流のノード２−５及び２−６をそれぞれ、どのノードに収容させるという観点から再構成が実行され、ノード２−５をノード２−７に収容させ、ノード２−６をノード２−９に収容させると決定された場合を示している。
【００８９】
図１１（Ａ）及び図１１（Ｂ）の比較から明らかなように、第１の実施形態の再構成方法を適用した方が、図２に示す当初の基本構成に近似したものとなっている。
【００９０】
以上では、中間ノード２−２に障害が発生した場合を示したが（ルートノードに障害が発生した場合も同様な方法を適用できる）、エンドノードに障害が発生した場合は、例えば、以下のように処理する。ここで、エンドノード２−９に障害が発生したとする。このノード２−９はエンドノードであるので、コンテンツを下流へ配送する機能を備えていない。そのため、ノード２−９に障害が発生した場合には、ノード２−９に割り当てられている配信本数（ユーザ端末）を引く継ぐノードを定めれば良い。
【００９１】
フローチャート等の図示は省略するが、コンテンツ管理サーバ３は、まず、引き継ぎ候補を選定する。ここでの引き継ぎ候補の選定方法も任意である。例えば、コンテンツの配送負荷が増えないので、中間ノードを引き継ぎ候補とするようにしても良い。コンテンツ管理サーバ３は、障害ノード２−９に割り当てられている配信本数以上の余裕配信本数を有する引き継ぎ候補に絞る。絞っても複数の引き継ぎ候補が残った場合には、コンテンツ管理サーバ３は、障害ノード２−９の上流ノード２−４との距離に基づいて、最終的に引き継ぐノードを決定する。障害ノード２−９と置き換えるわけではないので、障害ノード２−９の上流ノード２−４との距離が直接影響することはないが、障害ノードと引き継ぐノードとの距離は短い方が好ましい。障害ノードと引き継ぐノードとの距離を計測できないので、障害ノードと引き継ぐノードとの距離に代えて、障害ノード２−９の上流ノード２−４と引き継ぐノードとの距離を用いることにした。
【００９２】
図示は省略するが、コンテンツ管理サーバ３は、例えば、定期的に障害ノードが復旧したか否かを監視し、障害ノードが復旧すると、基本的なツリー構成に従って、各ノードにコンテンツを配送する状態に戻す。また例えば、コンテンツ管理サーバ３は、管理者から、障害ノードが復旧した旨の入力があると、基本的なツリー構成に従って、各ノードにコンテンツを配送する状態に戻す。
【００９３】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、コンテンツ配送中に配送済みノードでサーバ障害が発生した場合には、再構成したツリー構成を適用せずに、基本的なツリー構成をそのまま適用して、ツリー上の全てのノードに対するコンテンツ配送を実現し、新たな種類のコンテンツ配送から再構成したツリー構成を適用するようにしたので、コンテンツの配送中に、適用するツリー構成が切り分かることにより、配送されないノードが生じるような恐れが小さくすることができる。
【００９４】
また、第１の実施形態によれば、障害ノードが生じたときに、ツリー上でその障害ノードに置き換えるノードを決定して置き換えるようにしたので、ツリー構成を再構成しても、ツリー構成の変化を少なく抑えることができる。すなわち、ツリーを再構成しても、ルートノードからのホップ数が多くコンテンツが配送されるまでに長時間を要するようなノードの出現を抑えることができる。
【００９５】
さらに、第１の実施形態によれば、置き換え候補となるノードについてスペック（処理能力）の情報を格納しておき、障害ノードが担っていた機能の実現を確保できることを確認して置き換えノードを決定するようにしたので、置き換えられたノードの能力不足により、コンテンツの配送や配信に悪影響が生じるようなことを未然に防止することができる。
【００９６】
さらにまた、第１の実施形態によれば、障害ノードが担っていた機能をスペック的に充足できる置き換え候補が複数ある場合には、ネットワーク距離に基づいて置き換えノードを決定するようにしたので、障害ノードを置き換えたツリー構成において、その置き換えノードへのコンテンツ配送時間を短くすることができる。
【００９７】
また、第１の実施形態によれば、コンテンツの配送中に障害が生じた場合には、配送処理の一環として、その障害ノードに置き換わるノードを決定し、決定ノードにコンテンツを配送するようにしたので（図８参照）、全てのノードにコンテンツを配送して配備させるのに要する時間が、障害ノードの発生によって徒に長くなることを抑えることができる。
【００９８】
（Ｂ）第２の実施形態
次に、本発明によるツリー状ネットワーク再構成装置及びプログラム、並びに、ツリー状ネットワークシステムの第２の実施形態を、図面を参照しながら説明する。第２の実施形態のツリー状ネットワークシステムも、コンテンツ配信システムである。
【００９９】
第２の実施形態のコンテンツ配信システム１Ａの全体構成も、第１の実施形態の説明で用いた図１で表わすことができる。また、第２の実施形態の配信サーバ２−ｎの内部構成も、第１の実施形態の説明で用いた図３で表わすことができる。さらに、第２の実施形態のコンテンツ管理サーバ３も、第１の実施形態の説明で用いた図４で表わすことができる。
【０１００】
第２の実施形態は、コンテンツ管理サーバ３が実行するツリーの再構成処理、すなわち、障害ノードに置き換わるノードの決定処理が第１の実施形態と異なっており、その他の処理は、第１の実施形態と同様である。図１２は、第２の実施形態のコンテンツ管理サーバ３が実行するツリーの再構成処理（再構成プログラム）を示すフローチャートである。例えば、上述した図８のステップ２５３の処理として、ツリーの再構成処理が実行される。
【０１０１】
コンテンツ管理サーバ３は、図１２に示す処理を開始するとまず、まず、置き換え候補を選出する（ステップ５００）。第２の実施形態の場合も、置き換え候補の選出方法は限定されるものではなく、第１の実施形態の説明で例示したような方法を挙げることができる。
【０１０２】
コンテンツ管理サーバ３は、置き換え候補を選出すると、次に、各置き換え候補の配信サーバについて配送情報データベース４に格納されているスペック情報に基づいて、スペックの性能値を算出し、得られたスペックの性能値を配送情報データベース４に格納させる（ステップ５０１）。
【０１０３】
図１３は、第２の実施形態の配送情報データベース４における候補評価用情報の構成例を示す説明図であり、置き換え候補となり得る一部の配信サーバの情報を示している。
【０１０４】
図１３において、候補評価用情報は、置き換え候補の識別情報毎の行（レコード）を有し、各行は、その候補ノードのサーバとしてのスペックの生値情報と、スペックの段階値情報と、スペックの性能値と、距離情報と、優先度（トータル評価値）とでなる。図１２に示す処理を開始する前では、スペックの生値情報だけが記述され、スペックの段階値情報、スペックの性能値、距離情報、及び、優先度（トータル評価値）は空欄となっており、図１２に示す処理の進行と共に、徐々に記述されていくものである。
【０１０５】
スペックの生値情報は、第１の実施形態で「スペック情報」と呼んでいた情報であり、例えば、（ａ）下流ノードを収容できる数（下流ノードと接続可能なパス本数）、（ｂ）下流ノードへの各パスにおける通信帯域、（ｃ）コンテンツ配信可能本数（現在の状態から増加することが可能な余裕の配信本数）が該当する。
【０１０６】
スペックの段階値情報は、スペックの生値情報が取り得る範囲を複数の範囲に分割し、生値が属する分割範囲がどの評価段階に属するかを示す値に置き換えたものである（全ての項目について、段階値の大小は、その項目での評価の高低にあっている）。評価段階に対応した生値の分割範囲は、障害ノードの現状の状況によって変わるものである。
【０１０７】
図１３の場合、置き換え候補２−７〜２−９においてスペックの生値情報（ａ）である下流ノードを収容できる数はそれぞれ、下流への５本、３本、４本のパスに対応し得るものである。障害ノードの下流へのパス本数が２本であったとする。障害ノードの下流へのパス本数が２本の場合、図１３のスペックの段階値情報（ａ）である下流ノードを収容できる数におけるスペックの段階値情報は、確保可能なパス数が０又は１のときに段階値を「０」、確保可能なパス数が２〜４のときに段階値を「１」、確保可能なパス数が５以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「１」、「１」となる。仮に、障害ノードの下流へのパス本数が５本であり、障害ノードの下流へのパス本数が５本の場合、確保可能なパス数が０〜４のときに段階値を「０」、確保可能なパス数が５又は６のときに段階値を「１」、確保可能なパス数が７以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「１」、「０」、「０」となる。
【０１０８】
以上では、障害ノードの下流へのパス本数に応じて、各段階値が取り得る生値の範囲を切り替える場合を示したが、障害ノードの下流へのパス本数に関係なく、各段階値が取り得る生値の範囲を固定的に定めるものであっても良い。
【０１０９】
通信帯域やコンテンツ配信可能本数についても、同様な方法により、スペックの生値情報からスペックの段階値情報が形成される。但し、通信帯域は、各パス毎に定まっているので、各パス毎に、段階値に変換した後、それらの段階値情報の平均値をとって、通信帯域についての段階値情報とする（なお、平均値として小数を認めるようにしても良く、また、整数に制限する場合であれば切り捨て若しくは四捨五入処理を行う）。
【０１１０】
なお、図１３の場合では、置き換え候補２−７〜２−９においてスペックの生値情報（ｂ）である下流ノードへの各パスにおける通信帯域はそれぞれ、下流への１０［ＧＢ／ｓ］（５本）、５［ＧＢ／ｓ］（３本）、１０［ＧＢ／ｓ］（４本）の通信帯域に対応し得るものである。障害ノードの下流への通信帯域が５［ＧＢ／ｓ］であったとする。障害ノードの下流への通信帯域が５［ＧＢ／ｓ］の場合、図１３のスペックの段階値情報（ｂ）である下流ノードへの各パスにおける通信帯域におけるスペックの段階値情報は、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ５［ＧＢ／ｓ］未満のときに段階値を「０」、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ５［ＧＢ／ｓ］以上かつ１０［ＧＢ／ｓ］未満のときに段階値を「１」、確保可能な通信帯域のうち高い通信帯域を有する２本から選択された通信帯域がそれぞれ１０［ＧＢ／ｓ］以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「１」、「２」となる。
【０１１１】
次に、置き換え候補２−７〜２−９においてスペックの生値情報（ｃ）であるコンテンツ配信可能本数はそれぞれ、１２０本、０本、１１０本に対応し得るものである。障害ノードのコンテンツ配信可能本数が１００本であったとする。障害ノードの下流へのコンテンツ配信可能本数が５０本の場合、図１３のスペックの段階値情報（ｃ）であるコンテンツ配信可能本数におけるスペックの段階値情報は、コンテンツ配信可能本数が５０本未満のときに段階値を「０」、コンテンツ配信可能本数が５０本以上かつ１００本未満のときに段階値を「１」、コンテンツ配信可能本数が１００本以上のときに段階値を「２」をとるように定められていれば、置き換え候補２−７〜２−９の下流へのパス本数についての段階値はそれぞれ、「２」、「０」、「２」となる。
【０１１２】
図１３では、全ての項目（下流へのパス本数、通信帯域、コンテンツ配信可能本数）共に段階数が３段階のものを示したが、項目によって段階数を変えるようにしても良い。
【０１１３】
各項目の段階値情報を統合したものが、スペックの性能値である。図１３では、各項目の段階値情報を乗算したものをスペックの性能値としたものを示したが、他の統合方法を適用するようにしても良い。例えば、各項目の段階値情報を重み付け加算したものをスペックの性能値とするようにしても良い。
【０１１４】
なお、図１３の場合では、スペックの段階値情報の性能値は、「スペックの段階値情報（ａ）である下流ノードを収容できる数」と、「スペックの段階値情報（ｂ）である下流ノードへの各パスにおける通信帯域におけるスペックの段階値情報」と、「スペックの段階値情報（ｃ）であるコンテンツ配信可能本数におけるスペックの段階値情報」との積より、置き換え候補２−７〜２−９のスペックの段階値情報である性能値はそれぞれ、「８」、「０」、「４」となる。
【０１１５】
スペックの性能値を算出すると、その後、コンテンツ管理サーバ３は、各置き換え候補のそれぞれについて順次、障害ノードに直接接続されている上流ノードとの距離を計測させ、得られた距離情報を配送情報データベース４に格納させる（ステップ５０２）。第２の実施形態の場合、スペック情報に基づいた置き換え候補の絞り込みは実行しないので、距離の計測は、選出された全ての置き換え候補について実行される。
【０１１６】
そして、コンテンツ管理サーバ３は、配送情報データベース４に格納されたスペックの性能値及び距離情報に基づいて、各置き換え候補のそれぞれについて、スペックの性能値及び距離情報を融合したトータル評価値である優先度を計算し（ステップ５０３）、優先度が最も高い置き換え候補を、障害ノードに置き換えるノードと決定し（ステップ５０４）、決定したノードを障害ノードに置き換えて適用されるように、内部の格納情報を変更する（ステップ５０５）。
【０１１７】
スペックの性能値及び距離情報が反映された優先度を算出できるものであれば、その算出方法は問われないものである。図１３は、スペックの性能値を距離情報で割った後、１０（補正値）倍した値を優先値としている。図１３の例では、優先度Ｐは、「図１３のスペックの段階値情報である性能値」と、「距離」の商より、置き換え候補２−７〜２−９のスペックの段階値情報である性能値はそれぞれ、「９．８７」、「０」、「８．８８」（小数点第３位以下を切り捨て）となり、優先度Ｐが最も大きな値となる置き換え候補２−７が障害ノードに置き換わるノードとして決定される。
【０１１８】
第２の実施形態によっても、第１の実施形態とほぼ同様な効果を奏することができる。第２の実施形態によれば、置き換え候補のスペックを段階的に評価して優先度に反映させ、その優先度に基づいて、障害ノードに置き換わるノードを決定するようにしたので、負荷の小さいノードが置き換わるノードとして決定される可能性が高く、負荷が第１の実施形態より分散するといった効果を期待できる。
【０１１９】
因みに、第１の実施形態の場合、スペックの充足性だけを判定していたため、スペックが充足されていれば負荷が能力（スペック）に近く余裕が少なくても、置き換わるノードとして決定される可能性がかなりあった。
【０１２０】
（Ｃ）他の実施形態
上記各実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。
【０１２１】
上記各実施形態では、置き換えノードの選択に利用する配信サーバのスペックが、下流ノードへのパス数、通信帯域及び余裕配信本数であるものを示したが、置き換えノードの選択に利用するスペックはこれらに限定されるものではない。例えば、配信サーバに搭載されているＣＰＵの動作クロック周波数や、配信サーバに搭載されているメモリの総容量若しくは空き容量などを、置き換えノードの選択に利用するスペックとして用いるようにしても良い。適用するスペックの組み合わせも、上記各実施形態のものに限定されない。例えば、下流ノードへのパス数、通信帯域及びＣＰＵの動作クロック周波数を利用するようにしても良い。
【０１２２】
上記各実施形態では、スペック以外に障害ノードに置き換わるノードの決定に用いるパラメータが、障害ノードの上流ノードと置き換え候補とのネットワーク距離であるものを示したが、これに代え、又は、これに加え、他のパラメータを利用するようにしても良い。
【０１２３】
例えば、各パスが双方向に通信可能とみなした場合において、障害ノードの上流ノードと、置き換え候補とを、基本的なツリー構成上で最短に結ぶパス数（ホップ数）であっても良い。ノード２−ｉ及び２−ｊ間のパスをＰ（２−ｉ，２−ｊ）で表わすこととする。例えば、図２において、ノード２−５に障害が発生し、障害ノードの上流ノードがノード２−２である場合において、置き換え候補がノード２−１１であれば、パスＰ（２−０，２−２）、Ｐ（２−０，２−１）及びＰ（２−１，２−１１）の３個のパスで両ノードを結ぶことができる。ノード２−５に障害が発生し、障害ノードの上流ノードがノード２−２である場合において、置き換え候補がノード２−７であれば、パスＰ（２−０，２−２）、Ｐ（２−０，２−１）、Ｐ（２−１，２−３）及びＰ（２−３，２−７）の４個のパスで両ノードを結ぶことができる。このようなパラメータは、ネットワーク距離に近似したものと取り扱うことが可能である。
【０１２４】
また例えば、コンテンツ管理サーバと置き換え候補とのネットワーク上の距離を、置き換えノードの決定に利用するようにしても良い。ここで、コンテンツ管理サーバがルートノードと共通になっている場合や、コンテンツ管理サーバが、基本的なツリー構成においてルートノードの上流に位置させている場合においては、ネットワーク距離に代え、コンテンツ管理サーバと、置き換え候補とを、基本的なツリー構成上で最短に結ぶパス数（ホップ数）を適用するようにしても良い。置き換えノードと、コンテンツ管理ノードとで制御情報等の授受が多くなるような場合であれば、このような制御情報の授受を迅速に実行させることができる。
【０１２５】
上記各実施形態では、コンテンツ管理サーバ３が置き換え候補のスペックの情報を格納しておき、置き換えノードの決定処理で格納されているスペック情報を利用するものを示したが、置き換え候補となり得る各ノードがそれぞれ、自己のスペックの情報を格納していて、コンテンツ管理サーバ３が置き換え候補からその候補のスペック情報をその都度収集し、置き換えノードの決定処理で用いるようにしても良い。
【０１２６】
また、上記各実施形態では、ツリー構成を再構成させる事象がいずれかのノードの障害である場合を示したが、他の事象であっても良い。例えば、ノードを定期点検するために、ツリー状ネットワークから切り離す場合のツリーの再構成の場合にも、本発明を適用することができる。
【０１２７】
さらに、上記各実施形態では、ユーザ端末に対してコンテンツを配信する複数の配信サーバを、論理的にはツリー状に分散配置したコンテンツ配信システムに、本発明を適用したものを示したが、本発明の用途はこれに限定されない。複数のサーバが論理的にはツリー状に配置され、ツリーのルートノードからエンドノードに向かって配送データ（コンテンツに限定されない）を枝分かれしながら配送することにより、各サーバに同一データを配備させるシステムであれば良い。従って、サーバからユーザ端末等にデータを配信する機能がないシステムであっても良い。
【符号の説明】
【０１２８】
１…コンテンツ配信システム、２−０〜２−Ｎ…配信サーバ、３…コンテンツ管理サーバ、４…配送情報データベース（配送情報ＤＢ）、１０…通信部、１１…配送コンテンツ受信部、１２…コンテンツ格納部、１３…配送コンテンツ送信部、１４…配送制御部、２０…通信部、２１…管理者インタフェース部、２２…ツリー基本構成格納部、２３…障害ノード格納部、２４…ツリー再構成部、２５…配送指示制御部。
【特許請求の範囲】
【請求項１】
分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置において、
除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、
置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、
置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段と
を備えることを特徴とするツリー状ネットワーク再構成装置。
【請求項２】
上記所定事象が、ツリー状ネットワークのルートノードのサーバから、ツリー構成に沿って、ツリー状ネットワークの全てのサーバに第１のデータを配備させるべく配送している際中にいずれかのサーバに障害が発生したことであり、
障害発生したサーバの下流のサーバに上記第１のデータが既に配送、配備されているかを判別する配送済ノード確認手段と、
障害発生したサーバの下流のサーバに上記第１のデータが配送、配備されていない場合には、上記置換サーバ決定手段が決定したサーバによって置き換えられた再構成されたツリーを、未配送のサーバへの上記第１のデータの配送に適用するツリーに決定すると共に、障害発生したサーバの下流のサーバに上記第１のデータが既に配送、配備されている場合には、再構成前のツリーを、未配送のサーバへの上記第１のデータの配送に適用するツリーに決定し、かつ、今後生じる、新たな第２のデータの配送では、上記置換サーバ決定手段が決定したサーバによって置き換えられた再構成されたツリーを適用するツリーに決定する適用ツリー決定手段と
をさらに有することを特徴とする請求項１に記載のツリー状ネットワーク再構成装置。
【請求項３】
上記置換サーバ決定手段は、スペック情報の各項目がそれぞれ、除外対象の上記サーバで必要な遂行能力を充足していることを個別に確認して、除外対象の上記サーバに置き換わるサーバを決定することを特徴とする請求項１又は２に記載のツリー状ネットワーク再構成装置。
【請求項４】
上記置換サーバ決定手段は、スペック情報の各項目の情報を統合した評価情報を算出して、除外対象の上記サーバに置き換わるサーバを決定することを特徴とする請求項１又は２に記載のツリー状ネットワーク再構成装置。
【請求項５】
上記置換サーバ決定手段は、所定サーバ若しくは外部装置とのネットワーク距離が短い方の上記置き換え候補サーバ、又は、所定サーバ又は外部装置との通信時のホップ数が少ない方の上記置き換え候補サーバを、優先して、除外対象の上記サーバに置き換わるサーバに決定することを特徴とする請求項３又は４に記載のツリー状ネットワーク再構成装置。
【請求項６】
スペック情報は、最小単位ずつ異なる値として記述されていることを特徴とする請求項３〜５のいずれかに記載のツリー状ネットワーク再構成装置。
【請求項７】
スペック情報は、取り得る範囲を複数の範囲に分割し、各分割範囲に付与した段階評価値として記述されていることを特徴とする請求項３〜５のいずれかに記載のツリー状ネットワーク再構成装置。
【請求項８】
分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に搭載されるコンピュータを、
除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、
置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、
置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段と
して機能させることを特徴とするツリー状ネットワーク再構成プログラム。
【請求項１】
分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置において、
除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、
置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、
置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段と
を備えることを特徴とするツリー状ネットワーク再構成装置。
【請求項２】
上記所定事象が、ツリー状ネットワークのルートノードのサーバから、ツリー構成に沿って、ツリー状ネットワークの全てのサーバに第１のデータを配備させるべく配送している際中にいずれかのサーバに障害が発生したことであり、
障害発生したサーバの下流のサーバに上記第１のデータが既に配送、配備されているかを判別する配送済ノード確認手段と、
障害発生したサーバの下流のサーバに上記第１のデータが配送、配備されていない場合には、上記置換サーバ決定手段が決定したサーバによって置き換えられた再構成されたツリーを、未配送のサーバへの上記第１のデータの配送に適用するツリーに決定すると共に、障害発生したサーバの下流のサーバに上記第１のデータが既に配送、配備されている場合には、再構成前のツリーを、未配送のサーバへの上記第１のデータの配送に適用するツリーに決定し、かつ、今後生じる、新たな第２のデータの配送では、上記置換サーバ決定手段が決定したサーバによって置き換えられた再構成されたツリーを適用するツリーに決定する適用ツリー決定手段と
をさらに有することを特徴とする請求項１に記載のツリー状ネットワーク再構成装置。
【請求項３】
上記置換サーバ決定手段は、スペック情報の各項目がそれぞれ、除外対象の上記サーバで必要な遂行能力を充足していることを個別に確認して、除外対象の上記サーバに置き換わるサーバを決定することを特徴とする請求項１又は２に記載のツリー状ネットワーク再構成装置。
【請求項４】
上記置換サーバ決定手段は、スペック情報の各項目の情報を統合した評価情報を算出して、除外対象の上記サーバに置き換わるサーバを決定することを特徴とする請求項１又は２に記載のツリー状ネットワーク再構成装置。
【請求項５】
上記置換サーバ決定手段は、所定サーバ若しくは外部装置とのネットワーク距離が短い方の上記置き換え候補サーバ、又は、所定サーバ又は外部装置との通信時のホップ数が少ない方の上記置き換え候補サーバを、優先して、除外対象の上記サーバに置き換わるサーバに決定することを特徴とする請求項３又は４に記載のツリー状ネットワーク再構成装置。
【請求項６】
スペック情報は、最小単位ずつ異なる値として記述されていることを特徴とする請求項３〜５のいずれかに記載のツリー状ネットワーク再構成装置。
【請求項７】
スペック情報は、取り得る範囲を複数の範囲に分割し、各分割範囲に付与した段階評価値として記述されていることを特徴とする請求項３〜５のいずれかに記載のツリー状ネットワーク再構成装置。
【請求項８】
分散配置された複数のサーバが論理的にはツリー状に接続されているネットワークから、所定事象の出現に基づき、１つのサーバを除外した構成にツリー構成を再構成するツリー状ネットワーク再構成装置に搭載されるコンピュータを、
除外対象の上記サーバに置き換わる候補である置き換え候補サーバを選出する候補選出手段と、
置き換え候補サーバのそれぞれについて、そのサーバのスペックの情報を取り込む候補スペック情報取込手段と、
置き換え候補サーバのスペック情報から見て、その置き換え候補サーバが除外対象の上記サーバの遂行能力以上を確保できることを１条件として、除外対象の上記サーバに置き換わるサーバを決定する置換サーバ決定手段と
して機能させることを特徴とするツリー状ネットワーク再構成プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−５４６７４（Ｐ２０１２−５４６７４Ａ）
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願番号】特願２０１０−１９４０１１（Ｐ２０１０−１９４０１１）
【出願日】平成２２年８月３１日（２０１０．８．３１）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願日】平成２２年８月３１日（２０１０．８．３１）
【出願人】（３０８０３３７２２）株式会社ＯＫＩネットワークス (165)
【Ｆターム（参考）】
[ Back to top ]