JP2011109180A - 通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システム - Google Patents

Abstract

【課題】 クライアントからの要求を複数のデータ配信サーバのいずれかに振り分ける通信制御装置を備えるデータ配信システムにおいて、データ配信サーバと通信制御装置との間の通信量を低減する。
【解決手段】 本発明は、複数のデータ配信サーバと、１又は複数の通信制御装置とを有するデータ配信システムに関する。データ配信サーバは、現在の負荷状況に係る情報を有するサーバ負荷情報を生成して通信制御装置に送信する。そして、通信制御装置は、データ配信サーバからサーバ負荷情報を取得する手段と、過去に取得したサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、クライアントからの割り当て要求に対して割り当てるデータ配信サーバを選択する手段と、選択したデータ配信サーバからクライアント装置へ配信データを配信するように通信制御する手段とを有する。
【選択図】 図１

Description

この発明は、通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムに関し、例えば、動画像データのストリーム配信を行うデータ配信サーバを複数備えるＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）システムに適用することができる。

従来、ＶＯＤシステム（データ配信システム）において、クライアントに動画像データをストリーム配信するデータ配信サーバ（ＶＯＤサーバ）が複数存在する場合においては、ディスパッチャという通信制御装置が存在し、配信要求をしてきたクライアントに対し配信要求先のデータ配信サーバを振り分けて指定する事で負荷を分散させていた。

従来のディスパッチャを備えるシステムとしては、特許文献１に記載のマルチタスクシステムがある。

特開２０００−２８４９８０号公報

しかしながら、特許文献１の記載技術では、１つのディスパッチャで集中して通信制御を行っているため、クライアント数が大きくなるとディスパッチャがボトルネックとなる。このため大規模なシステムにおいては複数のディスパッチャを並列的に用いることが必要となるが、複数のディスパッチャが、各サーバの負荷を調べるために密に通信を行うとサーバのみならずネットワークの負荷も増大させる事になる。

そのため、ディスパッチャ（通信制御装置）を備えるデータ配信システムにおいて、データ配信サーバとディスパッチャ（通信制御装置）との間の通信量を低減することができる通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムが望まれている。

第１の本発明は、クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置において、（１）データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、（２）上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、（３）上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、（４）上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段とを有することを特徴とする。

第２の本発明は、通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバにおいて、（１）当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、（２）上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段とを有することを特徴とする。

第３の本発明の通信制御プログラムは、（１）クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置に搭載されたコンピュータを、（２）データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、（３）上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、（４）上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、（５）上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段として機能させることを特徴とする。

第４の本発明のデータ配信プログラムは、（１）通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバに搭載されたコンピュータを、（２）当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、（３）上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段として機能させることを特徴とする。

第５の本発明は、クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバと、上記クライアント装置と上記データ配信サーバとの間の通信を制御する１又は複数の通信制御装置とを有するデータ配信システムにおいて、（１）それぞれの上記データ配信サーバとして第２の本発明のデータ配信サーバを適用し、（２）それぞれの上記通信制御装置として第１の本発明の通信制御装置を適用したことを特徴とする。

本発明によれば、クライアントからの要求を複数のデータ配信サーバのいずれかに振り分ける通信制御装置を備えるデータ配信システムにおいて、データ配信サーバと通信制御装置との間の通信量を低減することができる。

第１の実施形態に係るデータ配信システムの全体構成について示したブロック図である。 第１の実施形態に係るデータ配信サーバからディスパッチャに送信されるサーバ負荷情報の内容について示した説明図である。 第１の実施形態に係るデータ配信システムにおける、各装置間の動作例について示したシーケンス図である。 第１の実施形態に係るディスパッチャにおけるサーバ選択動作の処理について示したフローチャートである。 第２の実施形態に係るディスパッチャにおけるサーバ選択動作の処理について示したフローチャートである。 第３の実施形態に係るストリーム配信終了予定情報の内容例について示した説明図である。 第３の実施形態に係るディスパッチャの処理において用いられるｄｅａｌｌｏｃａｔｅｄ関数の処理内容の例について示した説明図である。 第３の実施形態に係るストリーム配信終了予定情報の具体例について示した説明図である。

（Ａ）第１の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第１の実施形態を、図面を参照しながら詳述する。なお、第１の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。

（Ａ−１）第１の実施形態の構成
図１は、この実施形態のデータ配信システム１０の全体構成を示すブロック図である。なお、図１において、括弧内に記載された符号は、後述する第２及び第３の実施形態において用いる符号である。

データ配信システム１０は、４台のデータ配信サーバ２０（２０−１〜２０−４）、通信制御システム３０、Ｎ台のクライアント４０−１〜４０−Ｎを有している。また、通信制御システム３０には、Ｐｒｏｘｙ３１、及び、３台のディスパッチャ３２（３２−１〜３２−３）が配置されている。

なお、データ配信サーバ２０、ディスパッチャ３２、クライアント４０の台数は限定されないものである。

データ配信サーバ２０は、いずれかのディスパッチャ３２の制御に応じたクライアント４０へ、動画像データをストリーム配信する装置である。この実施形態においては、データ配信サーバ２０は、動画像データを配信するものとして説明するが、動画像データに音声データを付加して配信するようにしても良いし、音声データだけを配信するようにしても良い。

ここで、データ配信サーバ２０は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクなどのプログラムの実行構成、及び、他の通信装置と通信をするためのインターフェースを有する装置に、実施形態のデータ配信プログラム等をインストールすることにより構築するようにしても良い。

データ配信サーバ２０は、所定の間隔ごとに、当該データ配信サーバ２０の負荷状況に係る情報（以下、「サーバ負荷情報」という）を、各ディスパッチャ３２に与える。サーバ負荷情報の詳細については、後述する動作説明において詳述する。

また、データ配信サーバ２０において、上述のサーバ負荷情報を生成して、各ディスパッチャ３２に与える構成以外は、既存のデータ配信システム（ＶＯＤシステム）のデータ配信サーバと同様の構成を適用することができる。

図１において、データ配信サーバ２０−１〜２０−４は、それぞれ動画像データを蓄積（同一のデータでも良いし、それぞれ異なるデータであっても良い）するようにしても良いし、データ配信サーバ２０−１〜２０−４で共通的なストレージ装置（図示せず）を設けて、そのストレージ装置から動画像データを読み込んで保持するようにしても良い。すなわち、データ配信サーバ２０−１〜２０−４が動画像データを保持する方法は限定されないものである。なお、図１においては、説明を簡易にするため、データ配信サーバ２０−１〜２０−４は、それぞれ同じ動画像データを保持することが可能であるものとして説明する。

Ｐｒｏｘｙ３１は、クライアント４０とディスパッチャ３２との間の通信を中継する機能を担っている。Ｐｒｏｘｙ３１は、クライアント４０から、いずれかのデータ配信サーバ２０をデータ配信に割り当てる要求（以下、「サーバ割当要求」という）を受付けて、そのサーバ割当要求を、いずれかのディスパッチャ３２に振り分けて転送し、以後、そのクライアント４０とディスパッチャ３２との間の通信を中継する。

図１では、例として、クライアント４０とディスパッチャ３２の間にＰｒｏｘｙ３１が存在しているが、Ｐｒｏｘｙ３１は必須ではなく省略することができる。例えば、予めディスパッチャ３２ごとに特定クライアント４０を割り当て（例えば、静的にクライアント４０側に設定したり、ＤＮＳサーバ（図示せず）により割り振る等）、クライアント４０が直接ディスパッチャ３２にアクセスするようにしても良い。

また、Ｐｒｏｘｙ３１がサーバ割当要求を、いずれかのクライアント４０に割り当てる方法については限定されないものであり、例えば、ランダムに選択したり、ラウンドロビン方式により選択したり等、既存の負荷分散方式を適用するようにしても良い。

クライアント４０−１〜４０−Ｎは、既存のデータ配信システム（ＶＯＤシステム）におけるクライアント装置と同様のものを適用することができる。

ディスパッチャ３２は、データ配信サーバ２０とクライアント４０との間の通信に係る制御を行うものである。

ディスパッチャ３２は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ、ハードディスクなどのプログラムの実行構成、及び、他の通信装置と通信をするためのインターフェースを有する装置に、実施形態の通信制御プログラム等をインストールすることにより構築するようにしても良い。

ディスパッチャ３２は、所定の間隔ごとに、各データ配信サーバ２０−１〜２０−４のサーバ負荷情報を取得する。

そして、ディスパッチャ３２は、クライアント４０からサーバ割当要求を受取ると、各データ配信サーバ２０−１〜２０−４から過去に取得したサーバ負荷情報を利用して、そのクライアント４０に割り当てるデータ配信サーバ２０を選択する。そして、ディスパッチャ３２は、少なくとも選択したデータ配信サーバ２０の識別情報を有するサーバ割当要求の応答（以下、「サーバ割当応答」という）を、そのクライアント４０に、Ｐｒｏｘｙ３１を介して送信する。クライアント４０は、サーバ割当応答を受取ると、そのサーバ割当応答に含まれるデータ配信サーバ２０の識別情報を抽出し、その識別情報のデータ配信サーバ２０へアクセスし、実際の配信要求を行う。以降、そのデータ配信サーバ２０は、サーバ割当応答に基づきアクセスしてきたクライアント４０に、ストリーム配信を行う。

それぞれのディスパッチャ３２−１〜３２−３が、データ配信サーバ２０−１〜２０−４のサーバ負荷情報を保持する方法としては、例えば、それぞれのディスパッチャ３２−１〜３２−３が、データ配信サーバ２０−１〜２０−４へサーバ負荷情報を要求して読込むようにしても良いし、逆に、データ配信サーバ２０−１〜２０−４からディスパッチャ３２−１〜３２−３へサーバ負荷情報を配信するようにしても良い。すなわち、ディスパッチャ３２−１〜３２−３において、定期的にデータ配信サーバ２０−１〜２０−４からサーバ負荷情報を保持することができれば、その通信手順は限定されないものである。なお、サーバ負荷情報の詳細については、後述する動作説明において詳述する。

（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態のデータ配信システム１０の動作を説明する。

（Ａ−２−１）サーバ負荷情報について
まず、ディスパッチャ３２における、サーバ負荷情報に係る処理について説明する。

図２は、データ配信サーバ２０からディスパッチャ３２に与えられるサーバ負荷情報に含まれる内容の例について示した説明図である。

図２に示すように、ここでは、サーバ負荷情報には、「ＳｅｒｖｅｒＩＤ」、「Ｐｒｉｏｒｉｔｙ」、「ｓｔｒｅａｍ」、「ｕｐｄａｔｅｔｉｍｅ」の情報が含まれているものとして説明する。

「ＳｅｒｖｅｒＩＤ」は、当該データ配信サーバ２０の識別情報であり、例えば、アドレス情報やドメイン名等が適用される。

「Ｐｒｉｏｒｉｔｙ」は、当該データ配信サーバ２０の優先度の高低を示すパラメータである。Ｐｒｉｏｒｉｔｙは、データ配信サーバ２０ごとに予め異なる値が設定されているものとする。詳細については後述するが、ディスパッチャ３２では、この優先度も考慮してデータ配信サーバ２０に対するストリーム配信の割当を行う。Ｐｒｉｏｒｉｔｙとしては、例えば、優先度が高いほど、小さな数値を設定するようにしても良い。

「ｓｔｒｅａｍ」は、当該データ配信サーバ２０の、余剰の処理能力を示すパラメータである。第１の実施形態においては、「ｓｔｒｅａｍ」は、当該データ配信サーバ２０において、配信可能な残りのストリーム数を示すものとする。例えば、当該データ配信サーバ２０が同時にクライアント４０へ配信可能なストリームの本数が１０であり、現在５本配信中である場合には、配信可能な残りのストリーム数を示すｓｔｒｅａｍは、「５」となる。

「ｕｐｄａｔｅｔｉｍｅ」は、当該サーバ負荷情報が更新された時間（生成された時間）を示すものとする。

（Ａ−２−２）各装置間の処理について
図３は、データ配信システム１０構成する各装置間の処理について示したシーケンス図である。

図３では、説明を簡易にするため、クライアント４０−１、ディスパッチャ３２−１、データ配信サーバ２０−１の間の処理に係るシーケンス図として示しているが、実際には、データ配信システム１０には、図１に示すように、クライアント４０、ディスパッチャ３２、データ配信サーバ２０は、それぞれ複数配置されている。

図３では、まず、クライアント４０−１からＰｒｏｘｙ３１に、サーバ割当要求が与えられ、Ｐｒｏｘｙ３１により、そのサーバ割当要求が、ディスパッチャ３２−１に与えられたものとする（Ｓ１０１）。以下では、ディスパッチャ３２−１に係る動作について説明するが、その他のディスパッチャ３２−２、３２−３も、サーバ割当要求が与えられた場合の動作は同様であるので、説明を省略する。

次に、ディスパッチャ３２−１では、クライアント４０−１からのサーバ割当要求が与えられると、クライアント４０−１に対して割り当てるデータ配信サーバ２０の選択が行われる（Ｓ１０２）。

ここでは、ディスパッチャ３２−１において、基本的にはデータ配信サーバ２０は優先度順（サーバ負荷情報におけるｐｒｉｏｒｉｔｙで表される優先度順）に割り当てるものとするが、配信限界に達して割り当て不可能なデータ配信サーバ２０への割当を避けるため、サーバ負荷情報のｓｔｒｅａｍが所定よりも小さいサーバを割り当てないようにする。サーバ負荷情報は、取得時からの経過時間に従属して信頼度が下がるので、これらの情報を基にどのサーバを割り当てるかを判断する。

ここでは、ステップＳ１０２の処理において、ディスパッチャ３２−１により、データ配信サーバ２０−１が選択されたものとするが、ディスパッチャ３２−１のデータ配信サーバ２０を選択する処理の詳細については後述する。

次に、ディスパッチャ３２−１により、ステップＳ１０２で選択されたデータ配信サーバ２０−１に対して、サーバ割当要求が送信される（Ｓ１０３）。

次に、データ配信サーバ２０−１では、クライアント４０−１に対して仮割り当てが行われ、データ配信サーバ２０−１へのアクセス情報がディスパッチャ３２−１に送信される（Ｓ１０４）。

次に、ディスパッチャ３２−１により、アクセス情報が、サーバ割当要求の送信元であるクライアント４０−１に送信される（Ｓ１０５）。

次に、クライアント４０−１により、アクセス情報に基づいたデータ配信サーバ２０−１に配信要求が送信される（Ｓ１０６）。

次に、データ配信サーバ２０−１からクライアント４０−１に配信要求に基づいたデータ配信がおこなわれる（Ｓ１０７）。

（Ａ−２−３）データ配信サーバの選択処理について
図４は、上述のステップＳ１０２における、ディスパッチャ３２−１のデータ配信サーバ２０の選択処理について示したフローチャートである。

また、図４のフローチャートでは、ループ処理に用いる変数として「Ｉ」を用いるものとして説明する。また、図４のフローチャートでは、ループ処理に用いる定数としてＭ（データ配信サーバ２０の台数を表す）を用いるものとする。

まず、ディスパッチャ３２−１では、経過時間に基づきｓｔｒｅａｍに対する閾値が、以下の（１）式を用いて求められる(Ｓ２０１)。

閾値＝α（ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ）＋初期値 …（１）
（１）式で、αは予め設定された所定の正の値である。なお、αはディスパッチャ３２の総数に比例する値を適用することが望ましい。これはＰｒｏｘｙ３１が各ディスパッチャ３２に均等に割り当て要求を分配していると仮定して設定している（もしくは各ディスパッチャ３２にクライアント４０が均等に割り当てられている）。

また、（１）式で、ｎｏｗは現在の時刻であり、ｕｐｄａｔｅｔｉｍｅは最後に取得したサーバ負荷情報におけるｕｐｄａｔｅｔｉｍｅが適用される。すなわち、「ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ」は、データ配信サーバ２０について最後に取得したサーバ負荷情報が生成された時刻から現在までの経過時間を示している。

なお、ここでは説明を簡易にするため、上述のステップＳ２０１において算出される閾値は、データ配信サーバ２０−１〜２０−４で全て同じ（すなわち、データ配信サーバ２０−１〜２０−４でサーバ負荷情報が生成されるタイミングが同じ）であるものとして説明するが、適用するｕｐｄａｔｅｔｉｍｅがデータ配信サーバ２０ごとに異なる場合には、上述のステップＳ２０１の処理もデータ配信サーバ２０ごとに行う必要がある。

また、（１）式において初期値は、限定されないものであり、任意の値が設定されるものとする。

次に、後述するループ処理に用いられる変数Ｉが初期化（Ｉ＝０）される（Ｓ２０２）。なお、Ｉ＝０の場合には、後述するステップＳ２０３〜Ｓ２０５のループ処理では、優先順位（サーバ負荷情報におけるＰｒｉｏｒｉｔｙにより定まる順位）が最も高いデータ配信サーバ２０が処理対象のサーバとして処理が行われ、Ｉ＝１では２番目に優先順位が高いデータ配信サーバ２０の処理が行われるものとして説明する。例えば、データ配信サーバ２０−１、２０−２、２０−３、２０−４の順で優先順位が設定されていた場合には、１番目（Ｉ＝０）はデータ配信サーバ２０−１、２番目（Ｉ＝１）はデータ配信サーバ２０−２、３番目（Ｉ＝２）はデータ配信サーバ２０−３、４番目（Ｉ＝３）はデータ配信サーバ２０−４が、それぞれ処理対象のサーバとなる。

ディスパッチャ３２−１におけるループ処理では、まず、処理対象のサーバのサーバ負荷情報における最新のｓｔｒｅａｍが、上述のステップＳ２０１で算出した閾値よりも大きいか否かが判定される（Ｓ２０３）。

ステップＳ２０３において、ｓｔｒｅａｍが閾値よりも大きい場合には、その処理対象のサーバが、サーバ割当要求に対して割り当てるデータ配信サーバ２０として選択され、処理が終了する。

一方、ステップＳ２０３において、ｓｔｒｅａｍが閾値以下の場合には、その処理対象のサーバは、サーバ割当要求に対して割り当てるデータ配信サーバ２０からはずされる。そして、変数Ｉがインクリメント（Ｉ＝Ｉ＋１）され（Ｓ２０４）、さらに、変数Ｉ＝Ｍであるか否かが判定される（Ｓ２０５）。ステップＳ２０５において、変数Ｉ＝Ｍでない場合（まだ処理対象のサーバとなっていないデータ配信サーバ２０がある場合）には、上述のステップＳ２０３の処理から動作し、変数Ｉ＝Ｍの場合（全てのデータ配信サーバ２０が処理対象のサーバとなった）場合には、サーバ割当要求に対して割り当てるデータ配信サーバ２０がないものとして処理が終了する。

以上のように、ディスパッチャ３２では、各データ配信サーバ２０について最後に取得したサーバ負荷情報におけるｓｔｒｅａｍの値と、最後に取得したサーバ負荷情報が生成された時刻から現在までの経過時間とを利用して、現在の各データ配信サーバ２０の負荷状況を推定し、その推定結果を考慮して、サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する。

例えば、上記の（１）式においてα＝２で初期値＝０が適用され、データ配信サーバ２０−１のｓｔｒｅａｍが５、データ配信サーバ２０−２のｓｔｒｅａｍが１０であり、データ配信サーバ２０−１の優先度が最も高く、その次にデータ配信サーバ２０−２が高い場合を想定する。この場合、経過時間（ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ）が２．５秒後に、閾値がデータ配信サーバ２０−１のｓｔｒｅａｍの値（５）に達するので、その時点でデータ配信サーバ２０−１は、割り当ての対象から外され、それ以降はデータ配信サーバ２０−２が割り当てられることになる。閾値の予測が正しいとすればデータ配信サーバ２０−１との無駄な通信を避ける事ができる。

（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。

ディスパッチャ３２では、サーバ負荷情報の内容と、最後にサーバ負荷情報が生成された時刻からの経過時間（ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ）とを利用して、配信受付可能なデータ配信サーバ２０を推定し、配信受付不可能なデータ配信サーバ２０との無駄な通信を避ける事ができる。例えば、第１の実施形態において、仮に、配信受付不可能なデータ配信サーバ２０の推定を行わなかったとすると、他のディスパッチャ３２により割り当てられサーバ情報と実際の情報に開きが生じた場合でもそのまま割り当てを試み続けるという事が起き、通信に失敗してしまうという問題が発生する。

また、サーバ負荷情報の内容だけでなく、最後にサーバ負荷情報が生成された時刻からの経過時間（ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ）とを利用して、配信受付可能なデータ配信サーバ２０を推定するので、例えば、サーバ負荷情報だけに基づいて推定する場合よりも少ない頻度でサーバ負荷情報を取得しておけば良いため、データ配信サーバ２０とディスパッチャ３２との間の通信量を低減させることができる。

また、データ配信システム１０では、ディスパッチャ３２−１〜３２−３は、それぞれ並列的に単独で動作させているため、通常時におけるディスパッチャ３２同士で同期処理や、一部のディスパッチャ３２の障害発生時の切替処理を不要としており、構築コストの低減や保守性が向上するといった効果を奏する。

（Ｂ）第２の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第２の実施形態を、図面を参照しながら詳述する。なお、第２の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。

（Ｂ−１）第２の実施形態の構成
第２の実施形態のデータ配信システム１０Ａも、図１を用いて説明することができる。

第２の実施形態のデータ配信システム１０Ａでは、第１の実施形態のデータ配信システム１０がデータ配信システム１０Ａに置き換わっているが、それ以外の構成については第１の実施形態と同様であるので詳しい説明を省略する。

データ配信システム１０Ａは、ディスパッチャ３２（３２−１〜３２−３）が、ディスパッチャ３２Ａ（３２Ａ−１〜３２Ａ−３）に置き換わっているが、それ以外の構成については第１の実施形態と同様であるので詳しい説明は省略する。

ディスパッチャ３２Ａは、サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する処理（上述の図３のステップＳ１０２の処理）が、第１の実施形態のディスパッチャ３２と異なるだけである。なお、ディスパッチャ３２Ａにおける、サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する処理の詳細については、後述する動作説明において詳述する。

（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態のデータ配信システム１０Ａの動作を説明する。

データ配信システム１０Ａを構成する各装置間の処理についても上述の図３により示すことができる。ただし、第２の実施形態のデータ配信システム１０Ａでは、図３におけるステップＳ１０２の処理（サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する処理）だけが、第１の実施形態と異なるので、以下ではステップＳ１０２に係る処理についてのみ説明する。

図５は、ディスパッチャ３２Ａ−１で、上述のステップＳ１０２に相当する処理（データ配信サーバ２０の選択処理）について示したフローチャートである。

また、図５のフローチャートでは、第１の実施形態（上述の図４参照）と同様に、ループ処理に用いる変数として「Ｉ」、ループ処理に用いる定数としてＭ（データ配信サーバ２０の台数）を用いるものとする。

また、各ディスパッチャ３２Ａでは、各データ配信サーバ２０から受信したサーバ負荷情報を蓄積し、図５のフローチャートに係る動作において、その蓄積したサーバ負荷情報の履歴を用いるものとする。

まず、ディスパッチャ３２Ａでは、後述するループ処理に用いられる変数Ｉが初期化（Ｉ＝０）される（Ｓ３０１）。なお、Ｉ＝０の場合には、後述するステップＳ３０２〜Ｓ３０５のループ処理では、第１の実施形態と同様に、優先順位（サーバ負荷情報におけるＰｒｉｏｒｉｔｙにより定まる順位）が最も高いデータ配信サーバ２０が処理対象のサーバとして処理が行われ、Ｉ＝１では２番目に優先順位が高いデータ配信サーバ２０の処理が行われるものとして説明する。

ディスパッチャ３２Ａ−１におけるループ処理では、ディスパッチャ３２Ａ−１において、各ディスパッチャ３２Ａでは、蓄積したサーバ負荷情報の履歴にもとづいて、各データ配信サーバ２０のサーバ負荷情報におけるｓｔｒｅａｍの値の変化傾向を分析する。そして、ディスパッチャ３２Ａ−１では、その変化傾向に基づいて現在の各データ配信サーバ２０における余剰の処理能力を示す値（以下、「ｎｅｗ＿ｓｔｒｅａｍ」という）を算出する（Ｓ３０２）。なお、ｎｅｗ＿ｓｔｒｅａｍを算出する具体的な処理については後述する。

次に、ディスパッチャ３２Ａ−１では、上述のステップＳ３０２で算出したｎｅｗ＿ｓｔｒｅａｍが、所定の閾値よりも大きいか否かが判定される（Ｓ３０３）。ステップＳ３０３において用いられる閾値は、任意の値を設定することができるが、例えば「０」を適用するようにしても良い。

ステップＳ３０３において、ｓｔｒｅａｍが閾値よりも大きい場合には、その処理対象のサーバが、サーバ割当要求に対して割り当てるデータ配信サーバ２０として選択され、処理が終了する。

一方、ステップＳ３０３において、ｓｔｒｅａｍが閾値以下の場合には、その処理対象のサーバは、サーバ割当要求に対して割り当てるデータ配信サーバ２０からはずされる。そして、変数Ｉがインクリメント（Ｉ＝Ｉ＋１）され（Ｓ３０４）、さらに、変数Ｉ＝Ｍであるか否かが判定される（Ｓ３０５）。ステップＳ３０５において、変数Ｉ＝Ｍでない場合（まだ処理対象のサーバとなっていないデータ配信サーバ２０がある場合）には、上述のステップＳ３０２の処理から動作し、変数Ｉ＝Ｍの場合（全てのデータ配信サーバ２０が処理対象のサーバとなった場合）には、サーバ割当要求に対して割り当てるデータ配信サーバ２０がないものとして処理が終了する。

［ｎｅｗ＿ｓｔｒｅａｍの算出方法について］
次に、上述のステップＳ３０２におけるｎｅｗ＿ｓｔｒｅａｍの算出方法の詳細について説明する。

まず、ディスパッチャ３２Ａ−１では、各データ配信サーバ２０から受信して蓄積したサーバ負荷情報の履歴にもとづいて、各データ配信サーバ２０のサーバ負荷情報におけるｓｔｒｅａｍの値の変化傾向を分析する。ここでは、例として、各ディスパッチャ３２Ａでは、各データ配信サーバ２０に係るｓｔｒｅａｍの値が上昇傾向にあるか、下降傾向にあるかを以下の（２）式を用いて判定するものとして説明する。

なお、（２）式において、α_１＋α_２＋α_３＋…＋α_ｉ＝１、及び、α_１＞α_２＞α_３＞…＞α_ｉの関係が成り立つ値が予め設定されているものとする。また、（２）式において、ｓｔｒｅａｍ、ｓｔｒｅａｍ_１、ｓｔｒｅａｍ_２、ｓｔｒｅａｍ_３、…、ｓｔｒｅａｍ_ｉは、変化傾向の判定対象となるデータ配信サーバ２０から、ディスパッチャ３２Ａに与えられたサーバ負荷情報におけるｓｔｒｅａｍの値の履歴を示している。すなわち、ｓｔｒｅａｍが最新の値を示しており、ｓｔｒｅａｍ_ｉが最も古い値を示している。ｉの値は、任意の値を設定するようにしても良い。

δ＝α_１（ｓｔｒｅａｍ−ｓｔｒｅａｍ_１）＋α_２（ｓｔｒｅａｍ_１−ｓｔｒｅａｍ_２）
＋ … ＋α_ｉ（ｓｔｒｅａｍ_ｉ−１−ｓｔｒｅａｍ_ｉ） …（２）
そして、ディスパッチャ３２Ａでは、上記の（２）式により求められたδをさらに、以下の（３）式に適用することにより、当該データ配信サーバ２０に、現在割り当て可能なストリームの本数を推定する。

なお、（３）式において、ＭＡＸ（…）は、ｎｅｗ＿ｓｔｒｅａｍの値を算出するための関数である。例えば、ＭＡＸ（ａ，ｂ）と表した場合、ａ≧ｂならばＭＡＸ（ａ，ｂ）の結果としてａが返され、ａ＜ｂならばＭＡＸ（ａ，ｂ）の結果としてｂが返されるものとする。すなわち、（３）式においては、ａがｂ（０）より以上の値である場合にはｎｅｗ＿ｓｔｒｅａｍ＝ａとなり、ａが０より小さい値である場合には、ｎｅｗ＿ｓｔｒｅａｍ＝０となる。

また、サーバ情報更新間隔は、データ配信サーバ２０において、サーバ負荷情報が生成される間隔を示す。各データ配信サーバ２０のサーバ情報更新間隔としては、任意の値を設定することができるが、第２の実施形態においては、各データ配信サーバ２０のサーバ情報更新間隔は全て同じ値が設定されており、各ディスパッチャ３２にもその値が記憶されているものとして説明する。

次に、（３）を適用した場合の具体的な計算例について説明する。以下では、例として、α_１＝０．８、α_２＝０．２、サーバ情報更新間隔＝１０秒であるものとする。また、データ配信サーバ２０−１ではｓｔｒｅａｍ＝５、ｓｔｒｅａｍ_１＝１５、ｓｔｒｅａｍ_２＝２５であるものとする。さらに、データ配信サーバ２０−１ではｓｔｒｅａｍ＝４、ｓｔｒｅａｍ_１＝５、ｓｔｒｅａｍ_２＝６であるものとする。

そして、以下の（４）式は、上述の条件において、ディスパッチャ３２Ａ−１で、データ配信サーバ２０−１について、ｕｐｄａｔｅｔｉｍｅから５秒後に算出されるδであり、以下の（５）式は、（４）式で算出されたδを用いて算出されたｎｅｗ＿ｓｔｒｅａｍである。

また、以下の（６）式は、上述の条件において、ディスパッチャ３２Ａ−１で、データ配信サーバ２０−２について、ｕｐｄａｔｅｔｉｍｅから５秒後に算出されるδであり、以下の（７）式は、（６）式で算出されたδを用いて算出されたｎｅｗ＿ｓｔｒｅａｍである。

上述の例の場合、データ配信サーバ２０−１は、以下の（４）式、（５）式に示すように、５秒後にはｎｅｗ＿ｓｔｒｅａｍ＝０となり、その時点で、このデータ配信サーバ２０−１には、サーバ割当要求に対して割り当てるサーバとして選択されないことになる。

一方、データ配信サーバ２０−２は、以下の（６）式、（７）式に示すように、５秒後にもｎｅｗ＿ｓｔｒｅａｍ＝３．５なので、優先順位がデータ配信サーバ２０−１＞データ配信サーバ２０−２でもデータ配信サーバ２０−２が割り当てられる。

（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、以下のような効果を奏することができる。

ディスパッチャ３２Ａでは、サーバ負荷情報の履歴にもとづいて、各データ配信サーバ２０のサーバ負荷情報におけるｓｔｒｅａｍの値の変化傾向を分析し、その分析結果に基づいて、各データ配信サーバ２０の現在の負荷状況を推定し、データ配信サーバ２０の選択に利用している。例えば、第１の実施形態において、第２の実施形態のような推定を行わなかったとすると、あるデータ配信サーバ２０のアクセス数が急激に増大していて既に配信限界に達していても、そのデータ配信サーバ２０を選択してしまうという問題がある。

（Ｃ）第３の実施形態
以下、本発明による通信制御装置、通信制御プログラム、データ配信サーバ、データ配信プログラム、及び、データ配信システムの第３の実施形態を、図面を参照しながら詳述する。なお、第３の実施形態においては、本発明の通信制御装置はディスパッチャであるもとして説明している。

（Ｃ−１）第３の実施形態の構成
第３の実施形態のデータ配信システム１０Ｂも、図１を用いて説明することができる。

第３の実施形態のデータ配信システム１０Ｂでは、第２の実施形態のデータ配信システム１０がデータ配信システム１０Ｂに置き換わっている。また、第２の実施形態のデータ配信サーバ２０（２０−１〜２０−４）が、データ配信サーバ２０Ｂ（２０Ｂ−１〜２０Ｂ−４）に置き換わっているが、それ以外の構成については第２の実施形態と同様であるので詳しい説明を省略する。

データ配信システム１０Ｂでは、ディスパッチャ３２Ａ（３２Ａ−１〜３２Ａ−３）が、ディスパッチャ３２Ｂ（３２Ｂ−１〜３２Ｂ−３）に置き換わっているが、それ以外の構成については第２の実施形態と同様であるので詳しい説明は省略する。

データ配信サーバ２０Ｂは、ディスパッチャ３２Ｂに与えるサーバ負荷情報の内容が、上述の図２に示す内容に加えて、現在当該データ配信サーバ２０Ｂがデータ配信を行っているストリームについて、ストリーム配信が終了する予定に係る情報（以下、「ストリーム配信終了予定情報」という）が含まれている点で、第２の実施形態のデータ配信サーバ２０と異なっている。

図６は、データ配信サーバ２０Ｂが送信するサーバ負荷情報に含まれる、ストリーム配信終了予定情報の内容例について示した説明図である。

図６に示すように、ストリーム配信終了予定情報には、Ａ_１〜Ａ_ｊ、Ｋ_１〜Ｋ_ｊの情報が含まれている。Ａ_１〜Ａ_ｊは、それぞれ、当該サーバ負荷情報が生成された時刻から何秒後であるかを示し、Ｋ_１〜Ｋ_ｊは、それぞれＡ_１〜Ａ_ｊに係る時刻に、当該データ配信サーバ２０Ｂにおいて、データ配信が終了するストリームの本数を示している。例えば、０秒〜Ａ_１秒後までにデータ配信が終了するストリームの本数が１であればＫ_１には１が設定され、Ａ_１秒後からＡ_２秒後までの間にデータ配信が終了するストリームの本数が２であればＫ_１には２が設定されることになる。

なお、Ａ_１〜Ａ_ｊに設定する具体的な時間は限定されないものであるが、この実施形態においては、例えば、Ａ_１〜Ａ_ｊを全て１秒間隔で設定（１秒、２秒、３秒、…、ｊ秒）するものとして説明する。また、ｊの値についても限定されないものであるが、この実施形態では、サーバ情報更新間隔と同じ値が設定されるものとして説明する。データ配信サーバ２０Ｂでは、それぞれのストリームについて、動画像データの長さ（再生時間）と、現在の送信位置（再生位置）とが把握されており、それらの情報に基づいて、ストリーム配信終了予定情報は生成される。

ディスパッチャ３２Ｂは、サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する処理（上述の図３のステップＳ１０２の処理）が、第２の実施形態のディスパッチャ３２と異なるだけである。なお、ディスパッチャ３２Ｂにおいて、サーバ割当要求に対して割り当てるデータ配信サーバ２０を選択する処理の詳細については、後述する動作説明において詳述する。

また、各ディスパッチャ３２Ｂでは、第２の実施形態と同様に、各データ配信サーバ２０から受信したサーバ負荷情報を蓄積している。

（Ｃ−２）第３の実施形態の動作
次に、以上のような構成を有する第３の実施形態のデータ配信システム１０Ｂの動作を説明する。

データ配信システム１０Ｂを構成する各装置間の処理についても上述の図３により示すことができる。ただし、第３の実施形態のデータ配信システム１０Ｂでは、図３におけるステップＳ１０２の処理だけが、第２の実施形態と異なるので、以下ではステップＳ１０２に係る処理についてのみ説明する。

第３の実施形態において上述のステップＳ１０２に相当する処理（データ配信サーバ２０Ｂの選択処理）についても、上述の図５を用いて示すことができる。ただし、第３の実施形態のディスパッチャ３２Ｂでは、図５におけるステップＳ３０２の処理（ｎｅｗ＿ｓｔｒｅａｍの算出処理）だけが、第２の実施形態と異なるので、以下ではステップＳ３０２に係る処理についてのみ説明する。

まず、ディスパッチャ３２Ｂ−１では、各データ配信サーバ２０Ｂから受信して蓄積したサーバ負荷情報（ストリーム配信終了予定情報を含む）の履歴にもとづいて、各データ配信サーバ２０のサーバ負荷情報におけるｓｔｒｅａｍの値の過去の変化傾向を、第２の実施形態と同様に上記の（２）式によりδを求めることにより分析する。

そして、ディスパッチャ３２Ｂでは、上記の（２）式により求められたδをさらに、以下の（８）式に適用することにより、当該データ配信サーバ２０Ｂに、現在割り当て可能なストリームの本数を推定する。

なお、（８）式において、ＭＡＸは、上記の（３）式と同様に、ｎｅｗ＿ｓｔｒｅａｍの値を算出するための関数である。例えば、ＭＡＸ（ａ，ｂ）と表した場合、ａ≧ｂならばＭＡＸ（ａ，ｂ）の結果としてａが返され、ａ＜ｂならばＭＡＸ（ａ，ｂ）の結果としてｂが返されるものとする。

また、（８）式において、ｄｅａｌｌｏｃａｔｅｄもｎｅｗ＿ｓｔｒｅａｍの値を算出するための関数である。

図７は、ｄｅａｌｌｏｃａｔｅｄ関数の処理についてプログラム言語（例えば、Ｃ言語）で表記した場合の内容について示した説明図である。

図７に示すように、ｄｅａｌｌｏｃａｔｅｄ関数は、時間を示すｔｉｍｅ変数を入力すると、ｉｆ文により、ｔｉｍｅがストリーム配信終了予定情報におけるＡ_１よりも大きい場合には、Ｋ_１を戻り値として返し、ｔｉｍｅがＡ_２よりも大きい場合はＫ_１＋Ｋ_２を返し、…、ｔｉｍｅがＡ_ｊよりも大きい場合にはＫ_１＋Ｋ_２＋…＋Ｋ_ｊを返す処理を行う。

すなわち、ｄｅａｌｌｏｃａｔｅｄ関数は、ｎｏｗ−ｕｐｄａｔｅｔｉｍｅを入力すると、最後に当該データ配信サーバ２０Ｂにおいてサーバ負荷情報が生成された時刻から現在時刻までの間（ｕｐｄａｔｅｔｉｍｅ−ｎｏｗ）に、当該データ配信サーバ２０においてストリーム配信が終了するストリームの本数を把握することができる。この実施形態においては、ｄｅａｌｌｏｃａｔｅｄ関数の処理は、図７のプログラム処理により示したが、同様の処理が可能であれば、その処理手順は限定されないものである。

このように、ディスパッチャ３２Ｂでは、上記の（８）式のように、当該データ配信サーバ２０のサーバ負荷情報におけるｓｔｒｅａｍの値の過去の変化傾向を示すδと、当該データ配信サーバ２０においてストリーム配信が終了するストリームの本数（ｄｅａｌｌｏｃａｔｅｄ（ｎｏｗ−ｕｐｄａｔｅｔｉｍｅ））とを利用してｎｅｗ＿ｓｔｒｅａｍを算出している。

次に、上記の（８）式を適用した場合の具体的な計算例について説明する。以下では、例として、α_１＝０．８、α_２＝０．２、サーバ情報更新間隔＝１０秒であるものとする。また、データ配信サーバ２０−１ではｓｔｒｅａｍ＝５、ｓｔｒｅａｍ_１＝１５、ｓｔｒｅａｍ_２＝２５であるものとする。さらに、データ配信サーバ２０−１ではｓｔｒｅａｍ＝４、ｓｔｒｅａｍ_１＝５、ｓｔｒｅａｍ_２＝６であるものとする。

図８は、ストリーム配信終了予定情報の具体例について示した説明図である。

データ配信サーバ２０Ｂ−１のサーバ負荷情報におけるストリーム配信終了予定情報は図８（ａ）のような内容であったものとし、データ配信サーバ２０Ｂ−１のサーバ負荷情報におけるストリーム配信終了予定情報は図８（ｂ）のような内容であったものとする。

この場合、ｕｐｄａｔｅｔｉｍｅから５秒後にはデータ配信サーバ２０Ｂ−１のｎｅｗ＿ｓｔｒｅａｍ＝０となり、割り当て出来なくなるが、データ配信サーバ２０Ｂ−２は終了するストリームが幾つかあるのでｎｅｗ＿ｓｔｒｅａｍ＝０とはならず割り当てが可能である。

（Ｃ−３）第３の実施形態の効果
第３実施形態によれば、以下のような効果を奏することができる。

ディスパッチャ３２Ｂでは、ストリーム配信終了予定情報を利用して、各データ配信サーバ２０Ｂの現在の負荷状況を推定している。これにより、第２の実施形態と比較して、より精度の高い負荷状況の推定を行うことができる。例えば、第２の実施形態においては、あるデータ配信サーバ２０の負荷の変化傾向が過去において上昇傾向であっても、ストリーム配信終了予定情報において、配信終了予定のストリームが多い場合には、実際割り当て可能なのにも関わらず割り当て不可と判断される可能性がある。

（Ｄ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｄ−１） 上記の各実施形態において、データ配信サーバからクライアントへのストリーム配信において、各ストリームのビットレートは異なるビットレートとしても良い。この場合、サーバ割当要求等の制御信号に、各クライアントが配信要求するデータのビットレートの情報が含まれるようにしても良いし、データ配信サーバ側で、予めクライアントごとのビットレートを登録しておくようにしても良い。

そして、各ストリームのビットレートが可変である場合には、サーバ負荷情報のｓｔｒｅａｍのパラメータの単位は図２に示すようなストリームの本数ではなく、その他の余剰の処理能力を示す単位を適用するようにしても良い。

例えば、１０００ｋｂｐｓのストリーム１本で処理能力を１０単位必要とし、５００ｋｂｐｓのストリーム１本で処理能力５単位を必要とする単位等を適用するようにしても良い。この場合、例えば、任意のデータ配信サーバ２０が全体で５０単位の処理能力を有していると想定すると、このデータ配信サーバ２０は、５００ｋｂｐｓのストリームなら１０本、１０００ｋｂｐｓのストリームなら５本同時に配信できることになる。そして、このデータ配信サーバ２０が、１０００ｋｂｐｓのストリームを３本配信中には、サーバ負荷情報におけるｓｔｒｅａｍのパラメータは、５０−（１０×３）＝２０単位となる。

（Ｄ−２）上記の各実施形態において、ディスパッチャは、優先度を考慮して、サーバ割当要求に対して割り当てるデータ配信サーバを選択する処理を行っているが、優先度を考慮しないようにしても良い。例えば、第１の実施形態において、ステップＳ２０３〜ステップＳ２０５の処理は、データ配信サーバに付与された優先度順に行っているが、ランダムな順番や、優先度を考慮しない固定の順番や、識別情報をキーに昇順で並べた順番等、その他の基準により定められる順番で実施するようにしても良い。

（Ｄ−３）上記の各実施形態において、データ配信システムには、複数のディスパッチャが配置されているが、ディスパッチャは1つとしても良い。

（Ｄ−４）上記の各実施形態においては、サーバ負荷情報には、ｕｐｄａｔｅｔｉｍｅ（当該サーバ負荷情報が生成された時刻）の情報が含まれているが、これを省略して、ディスパッチャ側で、サーバ負荷情報を受信した時刻をｕｐｄａｔｅｔｉｍｅに置き換えて適用するようにしても良い。

１０…データ配信システム、２０、２０−１〜２０−４…データ配信サーバ、３０…通信制御システム、３１…Ｐｒｏｘｙ、３２、３２−１〜３２−３…ディスパッチャ、４０、３０−１〜３０−Ｎ…クライアント。

Claims (8)

1. クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置において、
   データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、
   上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、
   上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、
   上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段と
   を有することを特徴とする通信制御装置。
2. サーバ負荷情報には、そのサーバ負荷情報が生成された時刻に係る情報が含まれていることを特徴とする請求項１に記載の通信制御装置。
3. 上記サーバ選択手段は、過去にデータ配信サーバから取得したサーバ負荷情報の履歴に基づいて、そのデータ配信サーバの負荷に係る変動傾向を分析し、その分析結果を利用して、そのデータ配信サーバの現在の負荷状況を推定することを特徴とする請求項１又は２に記載の通信制御装置。
4. サーバ負荷情報には、そのサーバ負荷情報がデータ配信サーバにおいて生成された時点で、そのデータ配信サーバで現在配信中のストリームの終了予定時刻に係るストリーム配信終了予定情報が含まれており、
   上記サーバ選択手段は、上記サーバ負荷情報取得手段が過去にデータ配信サーバから取得したサーバ負荷情報に含まれるストリーム配信終了予定情報も利用して、そのデータ配信サーバの現在の負荷状況を推定することを特徴とする請求項１又は２に記載の通信制御装置。
5. 通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバにおいて、
   当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、
   上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段と
   を有することを特徴とするデータ配信サーバ。
6. クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバとの間の通信を制御する通信制御装置に搭載されたコンピュータを、
   データ配信サーバのそれぞれについて、現在の負荷状況に係るサーバ負荷情報を取得するサーバ負荷情報取得手段と、
   上記クライアント装置から、データ配信サーバを割り当てる割当要求を受付けるサーバ割当要求受付手段と、
   上記サーバ負荷情報取得手段が過去に取得した、データ配信サーバごとのサーバ負荷情報を利用して、そのデータ配信サーバの現在の負荷状況を推定し、その推定結果を考慮して、上記割当要求に対して割当てるデータ配信サーバを選択するサーバ選択手段と、
   上記サーバ選択手段が選択したデータ配信サーバから、上記クライアント装置に、配信データを配信するように、上記サーバ選択手段が選択したデータ配信サーバ、及び上記クライアント装置を制御する通信制御手段と
   して機能させることを特徴とする通信制御プログラム。
7. 通信制御装置の制御に応じたクライアント装置に対して、配信データのストリーム配信を行うデータ配信サーバに搭載されたコンピュータを、
   当該データ配信サーバの、現在の負荷状況に係る情報を有するサーバ負荷情報を生成するサーバ負荷情報生成手段と、
   上記サーバ負荷情報生成手段が生成したサーバ負荷情報を、上記通信制御装置に与えるサーバ負荷情報送信手段と
   して機能させることを特徴とするデータ配信プログラム。
8. クライアント装置と、クライアント装置に配信データのストリーム配信を行う複数のデータ配信サーバと、上記クライアント装置と上記データ配信サーバとの間の通信を制御する１又は複数の通信制御装置とを有するデータ配信システムにおいて、
   それぞれの上記データ配信サーバとして請求項５に記載のデータ配信サーバを適用し、
   それぞれの上記通信制御装置として請求項１に記載の通信制御装置を適用したこと
   を特徴とするデータ配信システム。

Images