(57)【特許請求の範囲】
【請求項１】
隣接する同士が相互に接続する複数のノードと、
前記ノードのいずれか１つに接続され、コンテンツを保持する少なくとも１つ以上のコンテンツ・サーバと、
前記ノードのいずれか１つに接続され、前記コンテンツの送信を前記コンテンツ・サーバに要求する少なくとも１つ以上のクライアントと、
前記ノード毎にそれぞれ接続され、前記コンテンツ・サーバから前記クライアントに転送されるストリーム・データをキャッシュする複数のプロキシ・キャッシュ・サーバと、
前記ノード毎にそれぞれ接続され、前記各隣接ノード間のデータ転送速度を制御する転送レート制御サーバとを有し、
前記各プロキシ・キャッシュ・サーバは、
前記クライアントがある下流側から要求されたコンテンツがキャッシュされていなければ、当該コンテンツの取得指示を前記コンテンツ・サーバがある上流側に送るプロセスと、
前記取得指示に対して上流側から送られてくる当該コンテンツをキャッシュしながら下流側に転送するプロセスと、
下流側から要求されたコンテンツがキャッシュされていれば、当該コンテンツの更新の有無を上流側に問い合わせるプロセスと、
前記問い合わせに対する上流側からの回答が更新無しの場合にはキャッシュされているコンテンツを下流側に転送するプロセスと、
前記問い合わせに対する上流側からの回答が更新有りの場合にはキャッシュされているコンテンツを削除して、上流側から送られてくる当該コンテンツをキャッシュしながら下流側に転送するプロセスとを並行して実行し、
前記転送レート制御サーバは、
下流側からの要求の度に起動され、当該要求を上流側に中継し、上流側からの応答がコンテンツの転送を伴う場合には当該応答データを待ち行列の最後尾に格納するプロセスと、
予め所定の数のプロセスが起動され、上流からのストリーム・データを下流側に所定の速度で伝送する定レート送出プロセスと、
前記待ち行列の先頭から応答データを１つずつ取り出し、空き状態の前記定レート送出プロセスに渡すプロセスとを並行して実行することを特徴とするネットワーク制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＶｏＤ（Video on Demand）のように、サーバに蓄積されたデジタル・コンテンツを、ネットワークを介してリアルタイム配信するシステムにおいて、伝送帯域を有効利用するためのネットワーク制御システムに関する。
【０００２】
【従来の技術】
従来、ネットワーク上で、ＶｏＤなどの音声や動画のリアルタイム配信等、特定の通信のための帯域を予約し、一定の通信速度を保証する技術として、例えばＱｏＳ（Quality of Service）があり、ＡＴＭ（Asynchronous Transfer Mode）などに実装されている。そして、様々な通信インフラが混在するインターネット上でＱｏＳを実現するために、ＲＳＶＰ（Resource reSerVation Protocol）やＤｉｆｆ−Ｓｅｒｖ（Differentiated Services）などが知られている。これらは、サーバとクライアントの経路にあるノード（ルータやスイッチ等のネットワーク機器など）間で伝送帯域を予約することで、リアルタイム伝送に要求される伝送帯域を保証している。これにより、音声や動画のリアルタイム配信やテレビ電話など、通信の遅延や停止が許されないサービスの、即時性や連続性を実現している。
【０００３】
【発明が解決しようとする課題】
このように、従来、サーバとクライアント間の伝送帯域を予約するためには、途中の経路にあるネットワーク機器を順番に帯域予約を行う必要がある。
【０００４】
しかしながら、特にインターネットでは、サーバとクライアント間にルータ等のノードが数多く介在する場合が多い。それら全てのルータに対して予約設定をするためには、経路上の全区間の帯域が予約可能でなければならない。従って、帯域が余っていない区間では、帯域予約をするために待たされたり、帯域予約できなかったりする場合が生じる。
【０００５】
しかも、帯域予約設定中においても、待たされている区間以外の区間は予約されており、その予約された区間は未使用帯域となってしまう。帯域予約が必要な区間はＷＡＮ（Wide Area Network）であり、一般に高速デジタル専用線やＡＴＭ専用線等を利用して構築されており、これらの回線使用料は高額であるため、未使用帯域の区間が多くなるにつれて伝送コストも高額になってしまう。
【０００６】
例えば、図２５に示すように、サーバＳ１〜Ｓ３及びクライアントＣ１〜Ｃ３がノードＡ〜Ｅに接続されているネットワーク構成において、図２６（ａ）に示すように、ストリームデータが伝送されるものとする。つまり、トラヒックＴ１はサーバＳ１からノードＡ，Ｂ，Ｃを経由してクライアントＣ１に、トラヒックＴ２はサーバＳ２からノードＢ，Ｃ，Ｄを経由してクライアントＣ２に、トラヒックＴ３はサーバＳ３からノードＣ，Ｄ，Ｅを経由してクライアントＣ３に、それそれ流れるものとする。
【０００７】
ここで、ノードＡ〜Ｅの各区間には同時に１つのストリーム分の帯域しかないとすると、トラヒックＴ１〜Ｔ３を同時に流そうとした場合、帯域予約の設定を最適化したとしても、図２６（ｂ）に示しように、未使用の帯域（図中、斜線部分）が生じてしまう。例えば、トラヒックＴ２−１は、トラヒックＴ１−１の伝送が終了してノードＢ〜Ｃの区間の帯域が空き状態になっても、トラヒックＴ３−１の伝送が終了してノードＣ〜Ｄの区間の帯域に空きが生じるまで待たされることになる。
【０００８】
本発明は、このような問題に鑑みてなされたものであり、伝送経路上のネットワーク機器の帯域予約を必要とせず、アクセス集中による遅延を減少させ、転送速度の低下を防止することができるネットワーク制御システムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明の特徴は、コンテンツ・サーバとクライアント間の伝送経路上の接続点（ノード）に、コンテンツ・サーバからクライアントに転送されるストリーム・データをキャッシュするプロキシ・キャッシュ・サーバと転送レート制御サーバとを配置し、隣接するノード間の複数のストリーム伝送をシリアライズ化することと、各ノード間におけるストリーム・データの転送速度を制御することである。このプロキシ・キャッシュ・サーバは、（１）下流側から要求されたコンテンツがキャッシュされていなければ、当該コンテンツの取得指示を上流側に送るプロセスと、（２）取得指示に対して上流側から送られてくる当該コンテンツをキャッシュしながら下流側に転送するプロセスと、（３）下流側から要求されたコンテンツがキャッシュされていれば、当該コンテンツの更新の有無を上流側に問い合わせるプロセスと、（４）問い合わせに対する上流側からの回答が更新無しの場合にはキャッシュされているコンテンツを下流に転送するプロセスと、（５）問い合わせに対する上流側からの回答が更新有りの場合にはキャッシュされているコンテンツを削除して、上流側から送られてくる当該コンテンツをキャッシュしながら下流側に転送するプロセスとを並行して実行し、転送レートサーバは、（６）下流側からの要求の度に起動され、当該要求を上流側に中継し、上流側からの応答がコンテンツの転送を伴う場合には当該応答データを待ち行列の最後尾に格納するプロセスと、（７）予め所定の数のプロセスが起動され、上流からのデータを下流側に所定の速度で伝送する定レート送出プロセスと、（８）待ち行列の先頭から応答データを１つずつ取り出し、空き状態の定レート送出プロセスに渡すプロセスとを並行して実行する。
【００１０】
プロキシ・キャッシュ・サーバは、隣接するノードのプロキシ・キャッシュ・サーバにストリーム・データを転送する際に、隣接ノードとの間の伝送帯域があいているかどうかを判断するだけで良いため、従来のような帯域予約の設定は不要となり、安価に且つ高速にストリーム配信を行うことができる。
【００１１】
例えば、図２５に示したネットワーク構成において、ノードＢ〜Ｄにそれぞれプロキシ・キャッシュ・サーバを配置すると、トラヒックＴ１−１の伝送が終了してノードＡ〜Ｃの区間の帯域が空き状態になれば、トラヒックＴ３−１の伝送終了を待たずに、トラヒックＴ１−２のノードＡ〜Ｂの区間やトラヒックＴ２−１のノードＢ〜Ｃの区間についてストリーム転送を前倒しで開始することができる。その結果、図２６（ｃ）に示すように、未使用の帯域（図中、斜線部分）を大幅に減少させることができる。
【００１３】
この際、前記所定の速度を、前記コンテンツをリアルタイム伝送するために必要な伝送速度と同じ速度、もしくはより速い速度に設定することが好ましい。また、所定の速度と前記所定の数との積により求まる帯域幅の合計が、帯域幅の最も狭いネットワークの帯域幅以下となるように、前記所定の数を設定する。あるいは、所定の速度を前記各ノード間で同一の値とし、前記所定の速度と前記所定の数との積により求まる帯域幅の合計が、各ノード間の帯域幅以下となるように、各ノード間の前記所定の数を設定する。
【００１４】
これにより、転送レート制御サーバによって、ノード間でストリーム転送を所定の速度で、且つノード間の帯域に応じた転送セッション数に制限するように制御することができるため、より効率よくストリーム転送を行うことができる。尚、上流からのストリーム転送は、一度プロキシ・キャッシュ・サーバにて受けることにより、転送レート制御サーバによって待ち行列に入れられても、下流への配信遅延を防止することができ、転送速度の低下を防ぐことができる。
【００１５】
【発明の実施の形態】
以下、本発明の実施に形態について、図面を参照しながら詳細に説明する。
【００１６】
（第１実施例）
図１は、本実施例におけるネットワークの構成例を模式化した図であり、各ノードＡ〜Ｅ毎にコンテンツ・サーバＡ１〜Ｅ２及びクライアントＡ１〜Ｅ２が接続されている。尚、図示した例では、ノード毎にコンテンツ・サーバ及びクライアントを２台ずつ接続した例を示しているが、これに限定されず、コンテンツ・サーバ及びクライアントは各ノードに０台ないし複数台接続される構成も可能である。
【００１７】
各ノード間Ａ−Ｂ，Ｂ−Ｃ，Ｃ−Ｄ，Ｄ−Ｅは、ＷＡＮを通じて接続されている。このＷＡＮは、高速デジタル専用線やＡＴＭ専用線、ＷＤＭ（Wavelength Division Multiplexing）など、一定の帯域が保証できるものであれば良く、また、ＲＳＶＰやＤｉｆｆ−ｓｅｒｖなどのようにＩＰネットワーク上で帯域保証されるものや、ＩＥＥＥ−８０２．１ｐのようにレイヤ２（Layer 2）であるイーサネット（Ethernet）上で保証されるものでも構わない。
【００１８】
図２は、図１に示したノードＡ〜Ｅのうち、任意のノード１の構成例を詳細に示した図である。図示したように、ノード１は、隣接するノードと相互に接続するためのルータ２と、ノード内のＬＡＮ３、及びＬＡＮ３に接続されるプロキシ・キャッシュ・サーバ１０とから構成される。また、ＬＡＮ３には、コンテンツ・サーバ４とクライアント５とが接続されている。
【００１９】
図３は、図２に示したプロキシ・キャッシュ・サーバ１０の構成例を示す図である。図示したように、プロキシ・キャッシュ・サーバ１０は、ＣＰＵ（Central Processing Unit）１１、ＲＡＭ（Random Access Memory）１２、ＨＤＤ（Hard Disk Drive）１３、ネットワークＩ／Ｆ１４などから構成される。ＲＡＭ１２は、ＣＰＵ１１にて実行されるプログラム及び作業エリア用の領域として用いられ、また、後述するセッション・テーブル１５が格納される。ＨＤＤ１３には、アプリケーション・プログラム１６の保存領域と、キャッシュ領域１７が確保される。
【００２０】
図４は、プロキシ・キャッシュ・サーバ１０に対するリクエストを管理する、セッション・テーブル１５のレイアウト例を示している。このセッション・テーブル１５には、ストリームデータのＵＲＬ（Uniform Resource Locators）、リクエストを受付けた下流の接続識別子、下流のリクエスト・タイプ、下流のプロキシ・フラグ、上流への接続識別子、問い合わせ書き換えフラグ、転送フラグとから構成される。
【００２１】
図５は、プロキシ・キャッシュ・サーバ１０の処理動作を制御するアプリケーション・プログラム１６の機能構成例を示している。アプリケーション・プログラム１６は、(1)リクエスト処理機能、(2)コンテンツ転送機能、(3)コンテンツ削除機能とからなる。(1)リクエスト処理機能は、(1-1)リクエスト受付け機能、(1-2)コンテンツ・サーバに対する処理機能、(1-3)リクエスト応答機能とからなる。また、(2)コンテンツ転送機能は、(2-1)プロキシ・サーバ間の転送機能、(2-2)クライアントへの転送機能とからなる。
【００２２】
このアプリケーション・プログラム１６の各機能は、マルチＯＳ（Multi Operating System）配下で、それぞれ並行して実行されても良い。
【００２３】
図６は、プロキシ・キャッシュ・サーバ１０に対するデータの流れを模式化した図である。プロキシ・キャッシュ・サーバ１０は、下流から「取得指示」または「問い合わせ」を受付け、それを上流へ受け渡す。あるいは、自ノード内のクライアント５からコンテンツをリクエストされた場合には、上流に「取得指示」または「問い合わせ」を行う。また、自ノード内に目的のコンテンツ・サーバ４がある場合には、コンテンツを取得する。更に、プロキシ・キャッシュ・サーバ１０は、上流から送られてくる「取得指示応答」、「問い合わせ肯定応答」または「アクセス否定応答」を受け、また、下流に「取得指示応答」、「問い合わせ肯定応答」または「アクセス否定応答」を送る。尚、図７は「取得指示」のデータ構造、図８は「問い合わせ」のデータ構造、図９は「取得指示応答」のデータ構造、図１０は「問い合わせ肯定応答」のデータ構造、図１１は「アクセス否定応答」のデータ構造を例示している。
【００２４】
次に、本実施例におけるストリーム配信の処理動作例を詳細に説明する。
【００２５】
ストリーム配信の手順として、まずストリームデータ（コンテンツ）の要求元であるクライアント５から該クライアント５が接続しているプロキシ・キャッシュ・サーバ１０に対して「取得指示」リクエストが送られる。送られる「取得指示」リクエストには、図７に示すように、データタイプ、プロキシ・フラグ、ストリームデータの所在場所を示すＵＲＬが格納されている。尚、プロキシ・フラグは、プロキシ・キャッシュ・サーバ１０に対する「取得指示」リクエストの発行元を識別するフラグであり、発行元がクライアント５である場合には「ｎｏ」を設定し、発行元がプロキシ・キャッシュ・サーバ１０である場合には「ｙｅｓ」を設定する。
【００２６】
これ以降、「取得指示」リクエストを受けたプロキシ・キャッシュ・サーバ１０の(1)リクエスト処理機能による処理動作例を、図１２〜図１６のフローチャートを参照しながら、詳細に説明する。
【００２７】
図１２は、(1)リクエスト処理機能の中の(1-1)リクエスト受付け機能による処理動作例を示すフローチャートである。
【００２８】
まず、プロキシ・キャッシュ・サーバ１０は、データタイプの内容を判定する（Step11）。
【００２９】
ここでは、データタイプには「取得指示」が設定されているので、次に、「取得指示」データ内のプロキシ・フラグの内容をセッション・テーブル１５のプロキシ・フラグ欄に設定する（Step12）。
【００３０】
更に、プロキシ・キャッシュ・サーバ１０は、セッション・テーブル１５の各項目の設定を行う。設定する項目は、ストリームデータのＵＲＬ、下流の接続識別子、下流のリクエスト・タイプ（「取得指示」）、上流への接続識別子、転送フラグ（「ｎｏ」）である（Step13）。
【００３１】
次に、プロキシ・キャッシュ・サーバ１０は、「取得指示」リクエストされたストリームデータが、ＨＤＤ１３内のキャッシュ領域１７にキャッシュ（一時保管）されているか否かを判定する（Step14）。
【００３２】
「取得指示」リクエストされたストリームデータがキャッシュ領域１７にキャッシュされていなければ、下流から受けたストリームデータの所在場所を示すＵＲＬをもとに、「取得指示」のリクエストデータを作成する。尚、この際に、プロキシ・フラグには「ｙｅｓ」を設定する（Step15）。そして、上流のプロキシ・キャッシュ・サーバ１０に対して「取得指示」リクエストを送る（Step16）。
【００３３】
「取得指示」リクエストされたストリームデータがキャッシュ領域１７にキャッシュされていれば、キャッシュされているデータの更新日時、データサイズをもとに「問い合わせ」リクエストを作成し（Step17）、上流のプロキシ・キャッシュ・サーバ１０に対して「問い合わせ」リクエストを送る（Step18）。
【００３４】
このようにして、「取得指示」または「問い合わせ」リクエストを送られた上流のプロキシ・キャッシュ・サーバ１０は、同様にして、図１２に示す処理動作を行う。
【００３５】
まず、プロキシ・キャッシュ・サーバ１０は、データタイプの内容を判定し（Step11）、データタイプが「取得指示」である場合には、Step12〜Step18の処理を行う。
【００３６】
データタイプが「問い合わせ」である場合には、プロキシ・キャッシュ・サーバ１０は、セッション・テーブル１５のプロキシ・フラグに「ｙｅｓ」を設定する（Step21）。更に、プロキシ・キャッシュ・サーバ１０は、セッション・テーブル１５の各項目の設定を行う。設定する項目は、ストリームデータのＵＲＬ、下流の接続識別子、下流のリクエスト・タイプ（「問い合わせ」）、上流への接続識別子、転送フラグ（「ｎｏ」）である（Step22）。
【００３７】
次に、プロキシ・キャッシュ・サーバ１０は、「問い合わせ」リクエストされたストリームデータが、ＨＤＤ１３内のキャッシュ領域１７にキャッシュ（一時保管）されているか否かを判定する（Step23）。
【００３８】
「問い合わせ」リクエストされたストリームデータがキャッシュ領域１７にキャッシュされていなければ、セッション・テーブル１５の問い合わせ書き換えに「ｎｏ」を設定し（Step28）、下流から受けた「問い合わせ」リクエストの各項目をコピーし（Step29）、上流のプロキシ・キャッシュ・サーバ１０に対して「問い合わせ」リクエストを送る（Step27）。
【００３９】
「問い合わせ」リクエストされたストリームデータがキャッシュ領域１７にキャッシュされていれば、キャッシュされているデータの更新日時、データサイズと、下流から送られた「問い合わせ」リクエスト内の作成日時、データサイズとを比較し、下流から送られた「問い合わせ」リクエスト内の作成日時、データサイズの方が新しい場合（つまり、キャッシュされているデータが古い場合）には、Step28以降の処理を行う。
【００４０】
下流から送られた「問い合わせ」リクエスト内の作成日時、データサイズの方が古い場合（つまり、キャッシュされているデータが最新データである場合）には、セッション・テーブル１５の問い合わせ書き換えに「ｙｅｓ」を設定し（Step25）、キャッシュされているデータの更新日時、データサイズをもとに「問い合わせ」リクエストを作成し（Step26）、上流のプロキシ・キャッシュ・サーバ１０に対して「問い合わせ」リクエストを送る（Step27）。
【００４１】
以上の各処理を、ストリームデータが所在するコンテンツ・サーバ４が接続しているプロキシ・キャッシュ・サーバ１０に達するまで、繰り返す。
【００４２】
図１３は、ストリームデータが所在するコンテンツ・サーバ４が接続しているプロキシ・キャッシュ・サーバ１０の処理動作例（（1-2）コンテンツ・サーバに対する処理機能）を示すフローチャートである。
【００４３】
ストリームデータが所在するコンテンツ・サーバ４が接続しているプロキシ・キャッシュ・サーバ１０は、下流のプロキシ・キャッシュ・サーバ１０からのリクエストのデータタイプを判定する（Step31）。
【００４４】
下流のプロキシ・キャッシュ・サーバ１０からのリクエストが「問い合わせ」である場合には、コンテンツ・サーバ４に対して、「問い合わせ」リクエスト内のＵＲＬに合致するストリームデータがあるかどうか問い合わせる（Step32）。
【００４５】
コンテンツ・サーバ４からの応答が、該当データなしの場合には、プロキシ・キャッシュ・サーバ１０は、下流のプロキシ・キャッシュ・サーバ１０に対して「アクセス否定応答」を返す（Step35）。
【００４６】
コンテンツ・サーバ４からの応答が、該当データありの場合には、プロキシ・キャッシュ・サーバ１０は、コンテンツ・サーバ４から受け取ったストリームデータの作成日時、データサイズと、「問い合わせ」リクエスト内のデータの作成日時、データサイズとを比較し（Step33）、一致する場合には、下流のプロキシ・キャッシュ・サーバ１０に「問い合わせ肯定応答」を返す（Step34）。一致しない場合には、後述するStep37の処理を行う。
【００４７】
一方、Step31の判定処理で、下流のプロキシ・キャッシュ・サーバ１０からのリクエストが「取得指示」である場合には、コンテンツ・サーバ４に対して、「取得指示」リクエスト内のＵＲＬに合致するストリームデータがあるかどうか問い合わせる（Step36）。
【００４８】
コンテンツ・サーバ４からの応答が、該当データなしの場合には、プロキシ・キャッシュ・サーバ１０は、下流のプロキシ・キャッシュ・サーバ１０に対して「アクセス否定応答」を返す（Step35）。
【００４９】
コンテンツ・サーバ４からの応答が、該当データありの場合には、プロキシ・キャッシュ・サーバ１０は、コンテンツ・サーバ４から受け取ったストリームデータの作成日時、データサイズ、及びデータ（実体）をもとに「取得指示肯定応答」を作成し、下流のプロキシ・キャッシュ・サーバ１０に返す（Step37）。
【００５０】
以上、ストリームデータが所在するコンテンツ・サーバ４が接続しているプロキシ・キャッシュ・サーバ１０の処理動作であり、以後は下流のプロキシ・キャッシュ・サーバ１０の処理へと移行する。
【００５１】
図１４は、上流からの応答を受けた、下流のプロキシ・キャッシュ・サーバ１０の処理動作例（(1-3)リクエスト応答機能）を示すフローチャートである。上流のプロキシ・キャッシュ・サーバ１０からの応答を受けた、下流のプロキシ・キャッシュ・サーバ１０の処理は、応答内容及びセッション・テーブル１５の内容により、処理動作が異なる。
【００５２】
まず、プロキシ・キャッシュ・サーバ１０は、上流からの応答内容を判定する（Step41）。
【００５３】
上流からの応答内容が「取得指示肯定応答」である場合には、応答内容に含まれているストリームデータの作成日時、データサイズを、ＨＤＤ１３内のキャッシュ領域１７に格納する（Step42）。そして、応答内容に含まれているストリームデータ（実体）を受信しつつ、ＨＤＤ１３内のキャッシュ領域１７に格納する（Step43）。一定量のストリームデータを受信したら、セッション・テーブル１５の転送フラグを「ｙｅｓ」に設定し（Step44）、残りのストリームデータを最後まで受信しつつ、ＨＤＤ１３内のキャッシュ領域１７に格納する（Step45）。尚、(3)コンテンツ削除処理機能のプログラムが、ＨＤＤ１３内のキャッシュ領域１７の残容量がなくならないように監視しており、キャッシュデータが増加し所定の残容量以下になった場合、アクセス日時の古いキャッシュデータから順次削除する。
【００５４】
Step41の判定処理で、上流からの応答内容が「問い合わせ肯定応答」である場合には、セッション・テーブル１５の下流リクエスト・タイプが「問い合わせ」であるかどうか判定し（Step51）、下流リクエスト・タイプが「問い合わせ」である場合には、次にセッション・テーブル１５の問い合わせ書き換えが「ｎｏ」であるかどうか判定する（Step52）。セッション・テーブル１５の問い合わせ書き換えが「ｎｏ」である場合には、下流のプロキシ・キャッシュ・サーバ１０に「問い合わせ肯定応答」を応答し（Step54）、セッション・テーブル１５から削除する（Step55）。
【００５５】
セッション・テーブル１５の下流リクエスト・タイプが「取得指示」である場合（Step51）、もしくは下流リクエスト・タイプが「ｙｅｓ」である場合（Step52）には、セッション・テーブル１５の転送フラグを「ｙｅｓ」に設定する（Step53）。
【００５６】
Step41の判定処理で、上流からの応答内容が「アクセス否定応答」である場合には、下流のプロキシ・キャッシュ・サーバ１０に「アクセス否定応答」を応答し（Step56）、セッション・テーブル１５から削除する（Step57）。
【００５７】
以上、上流からの応答を受けたプロキシ・キャッシュ・サーバ１０の処理動作を、クライアント５が接続しているプロキシ・キャッシュ・サーバ１０に達するまで、繰り返す。
【００５８】
次に、プロキシ・キャッシュ・サーバ１０の(2)コンテンツ転送機能について、図１５〜図１６を参照しながら詳細に説明する。尚、(2)コンテンツ転送機能のプログラムは、(1)リクエスト処理機能のプログラムと、マルチタスクにより並行して動作する。
【００５９】
図１５は、(2-1)プロキシ・サーバ間の転送機能による、プロキシ・キャッシュ・サーバ１０の処理動作例を示すフローチャートである。
【００６０】
図１５に示すように、通常はアイドル状態にあり、所定のサイクルでセッション・テーブル１５内の転送フラグ及びプロキシ・フラグを監視している（Step61）。
【００６１】
そして、セッション・テーブル１５内の転送フラグが「ｙｅｓ」で、且つプロキシ・フラグが「ｙｅｓ」である項目があれば、その項目の下流への接続識別子を用いて取得指示応答を返すことで、下流にストリームデータを転送する（Step62）。そして、セッション・テーブル１５から当該項目を削除する（Step63）。
【００６２】
この(2-1)プロキシ・サーバ間の転送機能のプログラムでは、同時に１つの取得応答指示しか下流側に応答しないようにすることで、ＷＡＮ帯域の占有を保証することができる。尚、この転送処理における転送速度は、リアルタイム伝送するために必要な伝送速度と同じ速度、もしくはより速い速度に設定する。
【００６３】
以上の(2-1)プロキシ・サーバ間の転送機能による処理動作を、クライアント５が接続しているプロキシ・キャッシュ・サーバ１０に達するまで、繰り返す。
【００６４】
図１６は、クライアント５が接続しているプロキシ・キャッシュ・サーバ１０の処理動作例（(2-2)クライアントへの転送機能）を示すフローチャートである。
【００６５】
図１６に示すように、通常はアイドル状態にあり、所定のサイクルでセッション・テーブル１５内の転送フラグ及びプロキシ・フラグを監視している（Step71）。
【００６６】
そして、セッション・テーブル１５内の転送フラグが「ｙｅｓ」で、且つプロキシ・フラグが「ｙｅｓ」である項目があれば、転送フラグを「ｎｏ」に設定し別プロセスを起動する（Step72）。尚、元のプロセスはアイドル状態に戻る。
【００６７】
そして、起動した別プロセスにより、その項目の下流への接続識別子を用いて取得指示応答を返すことで、下流にストリームデータを転送する（Step73）。そして、セッション・テーブル１５から当該項目を削除する（Step74）。
【００６８】
(2-1)プロキシ・サーバ間の転送機能との違いは、クライアント５への転送処理は、ＷＡＮの帯域占有を考慮する必要がないため、同時に複数のクライアントに転送するためにクライアントの数分プロセスを起動することである。また、ストリームデータの転送速度は、リアルタイム伝送と同じ速度とする。
【００６９】
以上、第１実施例にて説明したように、本発明によれば、ボトルネックとなるＷＡＮの入り口に、コンテンツ・サーバからクライアントに転送されるストリーム・データをキャッシュするプロキシ・キャッシュ・サーバを配置し、隣接するノード間の複数のストリーム伝送をシリアライズ化することで、帯域予約の設定は不要となり、安価に且つ高速にストリーム配信を行うことができる。
【００７０】
（第２実施例）
第１実施例では、コンテンツ・サーバとクライアント間の伝送経路上のノードに、コンテンツ・サーバからクライアントに転送されるストリーム・データをキャッシュするプロキシ・キャッシュ・サーバを配置し、隣接するノード間の複数のストリーム伝送をシリアライズ化する方式を説明した。
【００７１】
ところで、図２５に示したネットワーク構成において、各サーバＳ１〜Ｓ３と各クライアントＣ１〜Ｃ３間のリクエストが均等で、各区間Ａ〜Ｂ〜Ｃ〜Ｄ〜Ｅに同時に１つのストリーム転送分の帯域しかないと仮定すると、区間Ａ〜Ｂや区間Ｄ〜Ｅよりも、区間Ｂ〜Ｃや区間Ｃ〜Ｄにおける転送頻度が多くなる。そのため、ノードＢ，Ｃ，Ｄにおいて隣接するノードにストリーム・データを転送するスケジュールの待ち行列が長くなり、サーバＳ１〜Ｓ３とクライアントＣ１〜Ｃ３間の伝送遅延の中でその部分の占める割合が増大する。
【００７２】
そこで、第２実施例では、コンテンツ・サーバとクライアント間の伝送経路上のノードに、プロキシ・キャッシュ・サーバと転送レート制御サーバを配置し、隣接するノード間の帯域に応じた転送セッション数だけ伝送し、残りを待ち行列に入れることにより、転送速度の低下を防ぐ方式について、詳細に説明する。
【００７３】
１つのストリーム・データを転送する速度を基本転送速度とし、システム系で転送することが想定されるストリーム・データをリアルタイム再生するために必要な伝送速度より、この基本転送速度を高く設定する。
【００７４】
ノード間のＷＡＮ帯域を、基本転送速度のｎ倍に制御データ用の帯域を加えた値以上にすると、図１７に示すように、基本転送速度で伝送する転送チャネルをチャネル１〜ｎのｎ個設けることができ、同時にｎ個分のストリーム・データを転送することができる。
【００７５】
しかしながら、ストリーム・データの転送を行う際に、あるチャネルにおいて基本転送以上の速度で送出されてしまうと、他のチャネルで基本転送速度が得られないなど、チャネル毎の帯域に偏りが生じてしまう恐れがある。
【００７６】
そこで、図１８に示すように、各転送チャネルの転送レートと同時転送数を管理する、転送レート制御サーバ２０を、伝送経路上のノード１に設置する。そして、ストリーム・データのノード間転送を行う際に、転送レート制御サーバ２０を経由するようにして、転送リクエストを待ち行列に入れ、その待ち行列から所定の同時転送数（ｎチャネル）分を取り出し、各転送チャネル１〜ｎを基本転送速度で転送するように制御する。これにより、ノード間を結ぶネットワークの転送速度を超えることなく、個々のストリーム・データを隣接するノードに基本転送速度で転送することができる。
【００７７】
尚、第１実施例で説明したように、上流のノードから転送されてくるストリーム・データは、一旦プロキシ・キャッシュ・サーバ１０で受けることで、滞りなく下流のノードに転送することができる。図１９は、ノードＤに繋がっているコンテンツ・サーバＤ１が保有するデジタル・コンテンツを、ノードＢに繋がっているクライアントＢ１にストリーム配信する場合の接続関係を模式化した図である。クライアントＢ１から、ノードＢのプロキシ・キャッシュ・サーバＢ、上流のノードＣの転送レート制御サーバＣ、プロキシ・キャッシュ・サーバＣ、更に上流のノードＤの転送レート制御サーバＤ、プロキシ・キャッシュ・サーバＤを経由して、コンテンツ・サーバＤ１に接続される。
【００７８】
図２０は、転送レート制御サーバ２０の機能構成を例示したブロック図である。図示したように、転送レート制御サーバ２０は、リクエストヘッダー中継／解析プロセス２１、スケジューラプロセス２３、定レート送出プロセス２４の３種類のプロセスを有する。
【００７９】
リクエストヘッダー中継／解析プロセス２１は、下流側からリクエストされる度に起動され、当該要求を上流側に中継し、上流側からの応答がコンテンツの転送を伴う場合には転送リクエスト待ち行列２２の最後尾に、上流及び下流の接続情報等を格納する。
【００８０】
スケジューラプロセス２３は、転送リクエスト待ち行列２２の先頭から接続情報等を１つずつ取り出し、空き状態の定レート送出プロセス２４に渡す。
【００８１】
定レート送出プロセス２４は、予め所定の数のプロセスが起動され、上流からのデータを下流側に基本転送速度で伝送する。尚、図２０に示した例では、３つの定レート送出プロセス２４ａ〜２４ｃを備えた例を示したが、これに限定されるものではない。既に説明したように、基本転送速度（コンテンツをリアルタイム伝送するために必要な伝送速度と同じ速度、もしくはより速い速度）と定レート送出プロセス２４の数との積により求まる帯域幅の合計が、隣接するノード間の帯域幅以下となるように、所定の数を設定する。または、ネットワーク全体の中で、最も狭いネットワークの帯域幅以下となるように、前記所定の数を設定しても良い。あるいは、基本転送速度を各ノード間で同一の値とし、基本転送速度と定レート送出プロセス２４数との積により求まる帯域幅の合計が、各ノード間の帯域幅以下となるように、各ノード間の定レート送出プロセス２４の数を設定しても良い。
【００８２】
図２１は、本実施例におけるプロキシ・キャッシュ・サーバ１０の概略処理の動作例を示すフローチャートである。
【００８３】
プロキシ・キャッシュ・サーバ１０は、転送レート制御サーバ２０を経由して下流からのリクエストがあるかどうか、所定のサイクルで監視しており（Step01）、下流からのリクエストがあった場合、リクエストされたコンテンツがＨＤＤ１３内のキャッシュ領域１７にキャッシュされているかどうかを判定する（Step02）。
【００８４】
キャッシュされていない場合には、上流に「取得指示」リクエストを送る（Step03）。その後、上流から転送されてきたコンテンツを、ＨＤＤ１３内のキャッシュ領域１７にキャッシュしながら転送レート制御サーバ２０を経由して下流に転送する（Step04）。
【００８５】
キャッシュされている場合には、上流に「問い合わせ」リクエストを送る（Step05）。その後、上流からの応答が「問い合わせ肯定応答」であった場合には、ＨＤＤ１３内のキャッシュ領域１７にキャッシュしているコンテンツを転送レート制御サーバ２０を経由して下流に転送する（Step07）。上流からの応答が「取得指示応答」であれば、上流から転送されてきたコンテンツを、ＨＤＤ１３内のキャッシュ領域１７にキャッシュしながら転送レート制御サーバ２０を経由して下流に転送する（Step04）。
【００８６】
次に、図２２〜図２４を参照しながら、転送レート制御サーバ２０の各プロセスの処理動作について詳細に説明する。
【００８７】
図２２は、リクエストヘッダー中継／解析プロセス２１の処理動作例を示すフローチャートである。リクエストヘッダー中継／解析プロセス２１は、下流からのリクエストがあるかどうか、所定のサイクルで監視しており（Step80）、下流からのリクエストがあった場合、上流にリクエストを中継する（Step81）。
【００８８】
その後、リクエストヘッダー中継／解析プロセス２１は、上流からの応答内容を解析し（Step82）、上流からの応答内容がコンテンツの転送を含んでいた場合（「取得指示応答」であった場合）には（Step83）、上流及び下流の接続情報等を転送リクエスト待ち行列２２の最後尾に格納する（Step84）。
【００８９】
上流からの応答内容がコンテンツの転送を含んでいない場合（「取得指示応答」以外の場合）には（Step83）、接続を終了する（Step85）。
【００９０】
図２３は、スケジューラプロセス２３の処理動作例を示すフローチャートである。スケジューラプロセス２３は、定レート送出プロセス２４の管理を行っており、空き状態の定レート送出プロセス２４があるかどうか監視している（Step88）。空き状態の定レート送出プロセス２４がある場合には、転送リクエスト待ち行列２２の先頭から接続情報等を取り出し、空き状態の定レート送出プロセス２４に渡す（Step89）。空き状態の定レート送出プロセス２４がない場合には、空き状態の定レート送出プロセス２４が生じるまで待つ。
【００９１】
図２４は、定レート送出プロセス２４の処理動作例を示すフローチャートである。定レート送出プロセス２４は、空きフラグを「ＯＮ（空き状態）」に設定し（Step91）、スケジューラプロセス２３から接続情報等を渡されるのを待っている。スケジューラプロセス２３から接続情報等を渡されたら（Step92）、定レート送出プロセス２４は、空きフラグを「ＯＦＦ（閉じ状態）」に設定し（Step93）、渡された接続情報等を取得して（Step94）、プロキシ・キャッシュ・サーバ１０を介して上流からコンテンツを受け取りながら、所定の基本転送速度で下流に転送する（Step95）。全てのデータの転送が終了したら、再びStep91へ戻り、空きフラグを「ＯＮ（空き状態）」に設定して、スケジューラプロセス２３から接続情報等を渡されるのを待つ。
【００９２】
次に、クライアントからコンテンツ・サーバまでの一連の動作について、図１９に示したネットワーク構成をモデルに説明する。ここでは、ノードＢに繋がっているクライアントＢ１から、コンテンツＤ１が保有するデジタル・コンテンツのストリーム配信をリクエストする場合を想定する。
【００９３】
まずクライアントＢ１からのリクエストはノードＢのプロキシ・キャッシュ・サーバＢに送られ、リクエストされたコンテンツをプロキシ・キャッシュ・サーバＢがキャッシュしていて、コンテンツＤ１が保有するコンテンツのタイムスタンプと一致する場合には、変更されていないと判断してプロキシ・キャッシュ・サーバＢがキャッシュするコンテンツがクライアントＢ１に転送される。
【００９４】
同様に、リクエストされたコンテンツをプロキシ・キャッシュ・サーバＣがキャッシュしていて、コンテンツＤ１が保有するコンテンツのタイムスタンプと一致する場合には、プロキシ・キャッシュ・サーバＣがキャッシュするコンテンツがクライアントＢ１に転送される。この際、転送レート制御サーバＣにて転送用の帯域が得られ次第、プロキシ・キャッシュ・サーバＣから転送レート制御サーバＣを経由して、更にプロキシ・キャッシュ・サーバＢを経由して、クライアントＢ１に転送される。
【００９５】
途中経路上のプロキシ・キャッシュ・サーバＢ，Ｃ，Ｄのいずれにもキャッシュされていなかったり、いずれかにキャッシュされていてもコンテンツＤ１が保有するコンテンツのタイムスタンプと一致しなかったりする場合には、コンテンツＤ１が保有するコンテンツがクライアントＢ１に転送される。
【００９６】
以上のようにコンテンツがクライアントＢ１に転送される際に、途中経路での転送レートは各転送レート制御サーバＣ，Ｄによって基本転送速度として保証されており、コンテンツの先頭がクライアントＢ１に到達してから再生を始めても、コンテンツの到着が再生に間に合わずに、途中で途切れたり、乱れたりといったことを防ぐことができる。
【００９７】
以上、本発明の実施形態について詳細に説明したが、本発明は本実施例に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更を成し得ることは言うまでもない。
【００９８】
【発明の効果】
本発明によれば、ネットワークの途中経路のネットワーク機器の帯域予約を不要にし、伝送効率を高めることができるため、低価格で高品質のリアルタイム伝送サービスを実現することができる。
【００９９】
また、コンテンツ・サーバとクライアント間において、End-to-Endの帯域保証を行う必要がないため、インターネットのような複数のネットワークが介在している場合でも、複数のネットワークに跨って帯域保証の設定を行う必要がなく、システム構成を簡略化することができる。
【０１００】
また、個々のコンテンツの伝送レートを保証しつつ、同一ＷＡＮ区間に複数のコンテンツを同時に並行して転送できるため、ボトルネックとなるＷＡＮ入口での待ち行列を短くすることができ、コンテンツの要求から再生までの時間を短縮することができる。
【図面の簡単な説明】
【図１】本実施形態におけるネットワークの構成例を模式化した図である。
【図２】本実施形態の第１実施例におけるノードの構成を例示する図である。
【図３】本実施形態におけるプロキシ・キャッシュ・サーバの構成を例示する図である。
【図４】本実施形態におけるプロキシ・キャッシュ・サーバのセッション・テーブルのレイアウトを例示する図である。
【図５】本実施形態におけるプロキシ・キャッシュ・サーバを制御する、アプリケーション・プログラムの構成を例示する図である。
【図６】本実施形態におけるノードを中心としたデータの流れを例示する図である。
【図７】本実施形態における「取得指示」リクエストのデータ構造例を示す図である。
【図８】本実施形態における「問い合わせ」リクエストのデータ構造例を示す図である。
【図９】本実施形態における「取得指示応答」のデータ構造例を示す図である。
【図１０】本実施形態における「問い合わせ肯定応答」のデータ構造例を示す図である。
【図１１】本実施形態における「アクセス否定応答」のデータ構造例を示す図である。
【図１２】本実施形態におけるプロキシ・キャッシュ・サーバのリクエスト受付け機能による処理動作例を示すフローチャートである。
【図１３】本実施形態におけるプロキシ・キャッシュ・サーバのコンテンツ・サーバに対する処理機能による処理動作例を示すフローチャートである。
【図１４】本実施形態におけるプロキシ・キャッシュ・サーバのリクエスト応答機能による処理動作例を示すフローチャートである。
【図１５】本実施形態におけるプロキシ・キャッシュ・サーバのプロキシ・サーバ間の転送機能による処理動作例を示すフローチャートである。
【図１６】本実施形態におけるプロキシ・キャッシュ・サーバのクライアントへの転送機能による処理動作例を示すフローチャートである。
【図１７】本実施形態の第２実施例におけるノード間のＷＡＮ帯域に転送チャネルを設けた例を示す図である。
【図１８】本実施形態の第２実施例におけるノードの構成を例示する図である。
【図１９】本実施形態の第２実施例におけるノード間の接続関係を例示する図である。
【図２０】本実施形態の転送レート制御サーバの機能構成を例示する図である。
【図２１】本実施形態の第２実施例におけるプロキシ・キャッシュ・サーバの概略処理動作例を示すフローチャートである。
【図２２】本実施形態の第２実施例における転送レート制御サーバのリクエストヘッダー中継／解析プロセスの処理動作例を示すフローチャートである。
【図２３】本実施形態の第２実施例における転送レート制御サーバのスケジューラプロセスの処理動作例を示すフローチャートである。
【図２４】本実施形態の第２実施例における転送レート制御サーバの定レート送出プロセスの処理動作例を示すフローチャートである。
【図２５】典型的なネットワークの構成例を模式化した図である。
【図２６】トラヒックパターンを示した図であり、（ａ）はストリーム・データの構造、（ｂ）は従来のトラヒックパターン、（ｃ）は本発明を適用したトラヒックパターンを例示している。
【符号の説明】
１....ノード（Node）
２....ルータ（Router）
３....ＬＡＮ（Local Area Network）
４....コンテンツ・サーバ（Contents Server）
５....クライアント（Client）
１０....プロキシ・キャッシュ・サーバ（Proxy Cache Server）
１１....ＣＰＵ（Central Processing Unit）
１２....ＲＡＭ（Random Access Memory）
１３....ＨＤＤ（Hard Disk Drive）
１４....ネットワークＩ／Ｆ（Network I/F）
１５....セッション・テーブル（Session Table）
１６....アプリケーション・プログラム（Application Program）
１７....キャッシュ領域
２０....転送レート制御サーバ
２１....リクエストヘッダー中継／解析プロセス
２２....転送リクエスト待ち行列
２３....スケジューラプロセス
２４....定レート送出プロセス
【図１】
0003873691.tif 000002
【図２】
0003873691.tif 000003
【図３】
0003873691.tif 000004
【図４】
0003873691.tif 000005
【図５】
0003873691.tif 000006
【図６】
0003873691.tif 000007
【図７】
0003873691.tif 000008
【図８】
0003873691.tif 000009
【図９】
0003873691.tif 000010
【図１０】
0003873691.tif 000011
【図１１】
0003873691.tif 000012
【図１２】
0003873691.tif 000013
【図１３】
0003873691.tif 000014
【図１４】
0003873691.tif 000015
【図１５】
0003873691.tif 000016
【図１６】
0003873691.tif 000017
【図１７】
0003873691.tif 000018
【図１８】
0003873691.tif 000019
【図１９】
0003873691.tif 000020
【図２０】
0003873691.tif 000021
【図２１】
0003873691.tif 000022
【図２２】
0003873691.tif 000023
【図２３】
0003873691.tif 000024
【図２４】
0003873691.tif 000025
【図２５】
0003873691.tif 000026
【図２６】
0003873691.tif 000027