JP2003143222A

JP2003143222A - ネットワーク制御システム

Info

Publication number: JP2003143222A
Application number: JP2001340720A
Authority: JP
Inventors: Yasunari Suzuki; 保成鈴木
Original assignee: Victor Company of Japan Ltd
Current assignee: Victor Company of Japan Ltd
Priority date: 2001-11-06
Filing date: 2001-11-06
Publication date: 2003-05-16

Abstract

(57)【要約】【課題】ストリーム・データの伝送に影響を与えるこ
となく伝送帯域幅を有効活用して、ストリーム・データ
の通信コストを低減すること。【解決手段】ストリーム・データを伝送する際に、空
き領域となっている伝送帯域を、リアルタイム性を必要
としない優先度の低いトラヒックの伝送処理に利用す
る。これにより、ストリーム・データの伝送に影響を与
えることなく伝送帯域を有効に活用し、ストリーム・デ
ータの通信コストを低減する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＶｏＤ（Video on
Demand）のように、サーバに蓄積されたデジタル・コ
ンテンツを、ネットワークを介してリアルタイム配信す
るシステムにおいて、伝送帯域を有効利用するためのネ
ットワーク制御システムに関する。

【０００２】

【従来の技術】従来、ネットワーク上で、ＶｏＤなどの
音声や動画のリアルタイム配信等、特定の通信のための
帯域を予約し、一定の通信速度を保証するためのネット
ワーク制御技術として、例えばＱｏＳ（Quality of Ser
vice）があり、ＡＴＭ（Asynchronous Transfer Mode）
などに実装されている。そして、様々な通信インフラが
混在するインターネット上でＱｏＳを実現するために、
ＲＳＶＰ（Resource reSerVation Protocol）やＤｉｆ
ｆ−Ｓｅｒｖ（Differentiated Services）などが知ら
れている。

【０００３】このようなネットワーク制御技術では、ク
ライアントからサーバへのアクセス量の最大値に基づい
てストリーム・データの伝送帯域幅を確保することによ
りストリーム・データの再生までの待ち時間を最小にし
たり、サーバからクライアントへのデータ転送量が伝送
帯域幅を超える場合にはその超過分を空き帯域に回すこ
とにより再生開始後のネットワーク品質を保証したりし
て、伝送帯域を有効に利用することを可能にしている。

【０００４】

【発明が解決しようとする課題】ところが、従来のネッ
トワーク制御技術において、クライアントからサーバへ
のアクセス量の最大値に基づいてストリーム・データの
伝送帯域幅を決定するようにすると、ネットワークの混
雑時でもストリーム・データの再生までの待ち時間が最
小になる等の利点があるものの、ストリーム・データの
伝送処理全体としてみれば伝送帯域の利用効率は悪く、
ストリーム・データ再生のための通信コストが高くなっ
てしまう。

【０００５】また、従来のネットワーク制御技術におい
て、サーバからクライアントへのデータ伝送量が伝送帯
域幅を超えた場合、その超過分を空き帯域に回すように
すると、データ伝送量が伝送帯域幅を超える時間帯のみ
ならず、伝送が完了するまでのその後の時間帯にも影響
を与えるようになり、ストリーム・データの再生待ち時
間が増加する要因となってしまう。

【０００６】本発明は、このような問題に鑑みてなされ
たものであり、ストリーム・データの伝送に影響を与え
ることなく伝送帯域幅を有効活用して、ストリーム・デ
ータの通信コストを低減することができるネットワーク
制御システムを提供することを目的とする。

【０００７】

【課題を解決するための手段】上記目的を達成するた
め、本ネットワーク制御システムは、（ａ）隣接する同
士が相互に接続する複数のノードと、（ｂ）ノードのい
ずれか１つに接続され、ストリーム・データを保持する
少なくとも１つ以上のコンテンツ・サーバと、（ｃ）ノ
ードのいずれか１つに接続され、ファイルを保持する少
なくとも１つ以上のファイル・サーバと、（ｄ）ノード
のいずれか１つに接続され、ストリーム・データをコン
テンツ・サーバに要求する少なくとも１つ以上のクライ
アントと、（ｅ）ノード毎にそれぞれ接続され、コンテ
ンツ・サーバからクライアントに転送されるストリーム
・データをキャッシュしながら中継する複数のプロキシ
・キャッシュ・サーバと、（ｆ）ノード毎にそれぞれ接
続され、ファイル・サーバあるいはコンテンツ・サーバ
あるいは別のファイル・サーバに転送されるファイルを
キャッシュしながら中継する複数のファイル転送サーバ
と、（ｇ）ノード毎にそれぞれ接続され、ストリーム・
データあるいはファイルの要求元からのリクエストの度
に起動され、当該リクエストを要求先に中継し、要求先
からの応答がストリーム・データあるいはファイルの転
送を伴う場合には当該応答データを待ち行列の最後尾に
格納するプロセスと、予め所定の数のプロセスが起動さ
れ、要求先からのストリーム・データあるいはファイル
を要求元に所定の速度で伝送する定レート送出プロセス
と、待ち行列の先頭から応答データを１つずつ取り出
し、空き状態の定レート送出プロセスに渡すプロセスと
を実行する転送レート制御サーバとを有する。そして、
定レート送出プロセスは、優先順位毎にバッファを有
し、待ち行列の先頭から取り出した応答データを該応答
データの優先順位に従ってバッファに割り振って格納
し、優先順位の高いバッファから優先的に応答データを
取り出して伝送することを特徴とする。

【０００８】この第１の特徴によれば、ノード間の伝送
帯域の空き帯域を、リアルタイム性が必要とされない優
先度の低いトラヒックの伝送処理に利用するので、優先
度の高いストリーム・データの伝送に影響を与えること
なく伝送帯域を有効活用することができ、ストリーム・
データの通信コストを低減することができる。

【０００９】また、定レート送出プロセスは、応答デー
タの伝送中に当該応答データより優先順位の高い応答デ
ータの伝送が開始された場合には、優先順位の低い応答
データの伝送を中断し、優先順位の高い応答データの伝
送終了後に優先順位の低い応答データの伝送を再開す
る。これにより、ストリーム・データ伝送への影響をよ
り確実に抑えることができる。

【００１０】

【発明の実施の形態】以下、本発明の実施に形態につい
て、図１〜図２５を参照しながら詳細に説明する。

【００１１】［ネットワーク制御システムの構成］図１
は、本実施形態におけるネットワークの構成例を模式化
した図であり、各ノードＡ〜Ｄ毎に、コンテンツ・サー
バＡ１，Ｂ１，Ｃ１，Ｄ１、ファイル・サーバＡ２，Ｂ
２，Ｃ２，Ｄ２、及びクライアントＡ１，Ａ２，Ｂ１，
Ｂ２，Ｃ１，Ｃ２，Ｄ１，Ｄ２が接続されている。尚、
図示した例では、ノードＡ〜Ｄ毎にコンテンツ・サーバ
とファイル・サーバが１台とクライアントが２台接続さ
れている例を示しているが、これに本発明はこれに限定
されず、コンテンツ・サーバ、ファイル・サーバ及びク
ライアントを各ノードに０台ないし複数台接続してネッ
トワークを構成するようにしても良い。

【００１２】各ノード間Ａ−Ｂ，Ｂ−Ｃ，Ｃ−Ｄは、Ｗ
ＡＮ（Wide Area Network）によって接続される。この
ＷＡＮは、高速デジタル専用線やＡＴＭ（Asynchronous
Transfer Mode）専用線、ＷＤＭ（Wavelength Divisio
n Multiplexing）など、一定の帯域が保証できる電気通
信回線であればどのような形態であっても良く、例え
ば、ＲＳＶＰ（Resource reSerVation Protocol）やＤ
ｉｆｆ−Ｓｅｒｖ（Differentiated Services）などの
ようにＩＰネットワーク上で帯域保証されるものや、Ｉ
ＥＥＥ−８０２．１ｐのようにレイヤ２（Layer 2）で
あるイーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登
録商標））上で保証されるもの、ＭＰＬＳ（Multi Prot
ocol Label Switching）等の帯域保証されたＶＰＮ（Vi
rtual Private Network）でもあっても構わない。

【００１３】［ノードの構成］上記ノードＡ〜Ｄはそれ
ぞれ、図２に例示するように、隣接するノードと相互に
接続するためのルータ２、ノード内のＬＡＮ（Local Ar
ea Network）３、及びＬＡＮ３に接続されるプロキシ・
キャッシュ・サーバ１０、転送レート制御サーバ２０、
及びファイル転送サーバ３０を備え、ＬＡＮ３にはファ
イル・サーバ４、コンテンツ・サーバ５、クライアント
６が接続される。

【００１４】［プロキシ・キャッシュ・サーバの構成］
図３は、図２に示したプロキシ・キャッシュ・サーバ１
０の構成例を示す図である。図示したように、プロキシ
・キャッシュ・サーバ１０は、ＣＰＵ（Central Proces
sing Unit）１１、ＲＡＭ（Random Access Memory）１
２、ＨＤＤ（Hard Disk Drive）１３、ネットワークＩ
／Ｆ１４などから構成される。ＲＡＭ１２は、ＣＰＵ１
１にて実行されるプログラム及び作業エリア用の領域と
して用いられ、また、プロキシ・キャッシュ・サーバ１
０に対するリクエストを管理するセッション・テーブル
１５が格納される。ＨＤＤ１３には、アプリケーション
・プログラム１６の保存領域と、キャッシュ領域１７が
確保される。

【００１５】図４は、セッション・テーブル１５のレイ
アウト例を示している。このセッション・テーブル１５
には、ストリームデータのＵＲＬ（Uniform Resource L
ocators）、リクエストを受付けた下流の接続識別子、
下流のリクエスト・タイプ、下流のプロキシ・フラグ、
上流への接続識別子、問い合わせ書き換えフラグ、転送
フラグとから構成される。

【００１６】図５は、プロキシ・キャッシュ・サーバ１
０の処理動作を制御するアプリケーション・プログラム
１６の機能構成例を示している。アプリケーション・プ
ログラム１６は、(1)リクエスト処理機能、(2)コンテン
ツ転送機能、(3)コンテンツ削除機能とからなる。(1)リ
クエスト処理機能は、(1-1)リクエスト受付け機能、(1-
2)コンテンツ・サーバに対する処理機能、(1-3)リクエ
スト応答機能とからなる。また、(2)コンテンツ転送機
能は、(2-1)プロキシ・サーバ間の転送機能、(2-2)クラ
イアントへの転送機能とからなる。

【００１７】このアプリケーション・プログラム１６の
各機能は、マルチＯＳ（Multi Operating System）配下
で、ＣＰＵ１１によりそれぞれ並行して実行される。

【００１８】図６は、プロキシ・キャッシュ・サーバ１
０に対するストリーミング・データの流れを模式化した
図である。プロキシ・キャッシュ・サーバ１０は、下流
から「取得指示」または「問い合わせ」を受付け、それ
を上流へ受け渡す。あるいは、自ノード内のクライアン
ト６からコンテンツをリクエストされた場合には、上流
に「取得指示」または「問い合わせ」を行う。また、自
ノード内に目的のファイル・サーバ４やコンテンツ・サ
ーバ５がある場合には、ファイルやコンテンツを取得す
る。更に、プロキシ・キャッシュ・サーバ１０は、上流
から送られてくる「取得指示応答」、「問い合わせ肯定
応答」または「アクセス否定応答」を受け、また、下流
に「取得指示応答」、「問い合わせ肯定応答」または
「アクセス否定応答」を送る。尚、図７は「取得指示」
のデータ構造、図８は「問い合わせ」のデータ構造、図
９は「取得指示応答」のデータ構造、図１０は「問い合
わせ肯定応答」のデータ構造、図１１は「アクセス否定
応答」のデータ構造を例示している。

【００１９】［転送レート制御サーバの構成］図１２
は、転送レート制御サーバ２０の機能構成を例示したブ
ロック図である。図示したように、転送レート制御サー
バ２０は、ファイル転送ヘッダー中継／解析プロセス２
１、リクエストヘッダー中継／解析プロセス２２、キャ
ッシュ用スケジューラプロセス２３、ファイル転送用ス
ケジューラプロセス２４、定レート送出プロセス２５ａ
〜２５ｃの３種類のプロセスを有し、隣接するノード間
の帯域に応じた転送セッション数だけデータを伝送し、
残りを待ち行列２６，２７に入れることにより、伝送速
度の低下を防止する。

【００２０】ファイル転送ヘッダー中継／解析プロセス
２１は、上流側からリクエストされる度に起動され、当
該要求を下流側に中継し、下流側からの応答がファイル
の転送を伴う場合にはファイル用転送リクエスト待ち行
列２６の最後尾に、上流及び下流の接続情報等を格納す
る。

【００２１】リクエストヘッダー中継／解析プロセス２
２は、下流側からリクエストされる度に起動され、当該
要求を上流側に中継し、上流側からの応答がコンテンツ
の転送を伴う場合にはキャッシュ用転送リクエスト待ち
行列２７の最後尾に、上流及び下流の接続情報等を格納
する。

【００２２】キャッシュ用スケジューラプロセス２３
は、キャッシュ用転送リクエスト待ち行列２７の先頭か
ら接続情報等を１つずつ取り出し、空き状態の定レート
送出プロセス２５に渡す。

【００２３】ファイル転送用スケジューラプロセス２４
は、ファイル用転送リクエスト待ち行列２６の先頭から
接続情報等を１つずつ取り出し、空き状態の定レート送
出プロセス２５に渡す。

【００２４】定レート送出プロセス２５は、予め所定の
数のプロセスが起動され、上流からのデータを下流側
に、あるいは下流からのデータを上流側に基本転送速度
で伝送する。尚、図１２に示した例では、３つの定レー
ト送出プロセス２５ａ〜２５ｃを備えた例を示したが、
これに限定されるものではない。基本転送速度（コンテ
ンツをリアルタイム伝送するために必要な伝送速度と同
じ速度、もしくはより速い速度）と定レート送出プロセ
ス２５の数との積により求まる帯域幅の合計が、隣接す
るノード間の帯域幅以下となるように、所定の数を設定
する。または、ネットワーク全体の中で、最も狭いネッ
トワークの帯域幅以下となるように、所定の数を設定し
ても良い。あるいは、基本転送速度を各ノード間で同一
の値とし、基本転送速度と定レート送出プロセス２５数
との積により求まる帯域幅の合計が、各ノード間の帯域
幅以下となるように、各ノード間の定レート送出プロセ
ス２５の数を設定しても良い。

【００２５】尚、図１２に示した例では、ファイル転送
ヘッダー中継／解析プロセス２１は上流側のファイル転
送サーバからのリクエストを下流側のファイル転送サー
バに中継し、定レート送出プロセス２５は下流側のファ
イル転送サーバからのデータを上流側のファイル転送サ
ーバに伝送する例を示しているが、逆方向の流れもあり
得る。つまり、ファイル転送ヘッダー中継／解析プロセ
ス２１は下流側のファイル転送サーバからのリクエスト
を上流側のファイル転送サーバに中継し、定レート送出
プロセス２５は上流側のファイル転送サーバからのデー
タを下流側のファイル転送サーバに伝送するケースもあ
り得る。

【００２６】各定レート送出プロセス２５ａ〜２５ｃ
は、図１３に示すように、優先順位毎に複数のデータ入
力用バッファ２８を有し、バッファ２８内のデータを下
流側あるいは上流側に一定の基本伝送速度で伝送する。
図示した例では、リアルタイム性を必要とするストリー
ム・データを格納するためのバッファ２８を高優先順位
とし、リアルタイム性を必要としないファイルを格納す
るためのバッファ２８を低優先順位とし、ファイル用転
送リクエスト待ち行列２６及びキャッシュ用転送リクエ
スト待ち行列２７の先頭から取り出した応答データを該
応答データの優先順位に従ってバッファ２８に割り振っ
て格納する。

【００２７】そして、伝送する際には、定レート送出プ
ロセス２５内の優先順位スケジューラ２９が、各優先順
位毎のバッファ２８が空き状態かどうかを調べ、データ
が格納されているバッファ２８のうち最も優先順位の高
いバッファ２８から優先的にデータを取り出してルータ
２に出力する。

【００２８】これにより、転送レート制御サーバ２０
は、例えば図１４（ｂ）に示すように、従来までのスト
リーム・データ伝送の空き時間（図１４（ａ）を参照）
に優先度の低いファイル伝送を行うことができ、ストリ
ーム伝送に影響を与えることなく伝送帯域を有効に利用
することができる。

【００２９】従来、リアルタイム性を必要としないトラ
ヒックをノード間で伝送する場合、ノード内のファイル
転送サーバから転送レートサーバを経由せずに直接ルー
タ経由で隣接ノードに伝送することがあるが、ファイル
転送サーバはＷＡＮ帯域の空き帯域が分からないため
に、例えばＴＣＰ／ＩＰ（Transmission Control Proto
col/Internet Protocol）のように、輻輳状態を検出し
て伝送速度を調節したり、頻発するパケット・ロスを検
出したりして、ベストエフォートでトラヒックを伝送す
る必要があった。

【００３０】ところが、従来のようにしてリアルタイム
性を必要としないトラヒックを伝送すると、帯域の急激
な変化に対応することができずに、パケット・ロスや輻
輳状態、余剰状態を引き起こすことがある。また、リア
ルタイム性を必要とする優先度の高いトラヒックでＷＡ
Ｎが占有されている状態が続くと、タイムアウトにより
伝送途中で接続が切断されてしまう。

【００３１】これに対して、本実施形態に示すように、
本発明では転送レート制御サーバ２０の定レート送出プ
ロセス２５がリアルタイム性を必要としないトラヒック
を空き帯域に混載して伝送するため、上記のような従来
の問題の発生を防止することができる。尚、リアルタイ
ム性を必要としないトラヒックとしては、例えば、スト
リームのアップロード処理、分散配置されているミラー
・サーバにデータを配布する処理、翌朝１０時までとい
った時間的に厳しくない大量のデータ転送処理等があ
る。

【００３２】［ファイル転送サーバの構成］ファイル転
送サーバ３０は、図１５に示すように、ファイル受信プ
ロセス３１、スケジューラプロセス３２、ファイル送信
プロセス３３ａ〜３３ｃを有している。ファイル受信
プロセス３１は、上流のファイル転送サーバから伝送さ
れたファイルを受信し、受信したファイルをファイル・
スプール３４に格納すると共に、ファイル転送リクエス
ト待ち行列３５の最後尾に転送リクエストを格納する。

【００３３】スケジューラプロセス３２は、ファイル転
送リクエスト待ち行列３５の先頭から転送リクエストを
１つずつ取り出し、空き状態のファイル送信プロセス３
３に渡す。

【００３４】各ファイル送信プロセス３３ａ〜３３ｃ
は、所定の数起動され、上流のファイル転送サーバから
転送されたデータを下流側に基本転送速度で伝送する。

【００３５】尚、図１３に示した例では、ファイル受信
プロセス３１は上流側のファイル転送サーバからファイ
ルを受信し、受信したファイルをスケジューラプロセス
３２が下流側に伝送する例を示しているが、ファイル受
信プロセス３１は下流側のファイル転送サーバからファ
イルを受信し、受信したファイルをスケジューラプロセ
ス３２が上流側に伝送する場合もあり得る。

【００３６】［ネットワーク制御システムの動作］次
に、図１６〜図２５を参照して、サーバ側からクライア
ント側にストリーム・データを配信する処理を例に、本
ネットワーク制御システムの動作について、プロキシ・
キャッシュ・サーバ１０、転送レート制御サーバ２０、
ファイル転送サーバ３０毎に詳細に説明する。

【００３７】《プロキシ・キャッシュ・サーバの動作》
図１６は、プロキシ・キャッシュ・サーバ１０の処理動
作例を示すフローチャートであり、ストリーム・データ
（コンテンツ）の配信要求元であるクライアント６が、
接続しているプロキシ・キャッシュ・サーバ１０に対し
て「取得指示」リクエストを送信することで、処理が開
始され、以下の処理を実行する。ここで、「取得指示」
リクエストには、図７に示したように、データタイプ、
プロキシ・フラグ、ストリーム・データの所在場所を示
すＵＲＬが格納されている。尚、プロキシ・フラグは、
プロキシ・キャッシュ・サーバ１０に対する「取得指
示」リクエストの発行元を識別するためのフラグであ
り、発行元がクライアント６である場合には「ｎｏ」を
設定し、発行元がプロキシ・キャッシュ・サーバ１０で
ある場合には「ｙｅｓ」を設定する。

【００３８】図１６のフローチャートにおいて、まず、
プロキシ・キャッシュ・サーバ１０が転送レート制御サ
ーバ２０を経由して下流からのリクエストがあるか否か
を所定のサイクルで監視し（Step01）、下流からのリク
エストがあった場合には、リクエストされたコンテンツ
がＨＤＤ１３内のキャッシュ領域１７にキャッシュされ
ているか否かを判定する（Step02）。

【００３９】判定の結果、リクエストされたコンテンツ
がキャッシュされていない場合には、プロキシ・キャッ
シュ・サーバ１０は、上流に「取得指示」リクエストを
送る（Step03）。そして、プロキシ・キャッシュ・サー
バ１０は、「取得指示」リクエストに従って上流から伝
送されてくるコンテンツをＨＤＤ１３内のキャッシュ領
域１７にキャッシュしながら、転送レート制御サーバ２
０を経由して当該コンテンツを下流に転送し、転送終了
後、Step01へ戻る（Step04）。

【００４０】一方、リクエストされたコンテンツがキャ
ッシュされている場合には、プロキシ・キャッシュ・サ
ーバ１０は、上流に「問い合わせ」リクエストを送る
（Step03）。そして、プロキシ・キャッシュ・サーバ１
０は、「問い合わせ」リクエストに対する上流からの応
答内容を判定する（Step06）。

【００４１】上流からの応答内容が「問い合わせ肯定応
答」であった場合には、プロキシ・キャッシュ・サーバ
１０は、ＨＤＤ１３内のキャッシュ領域１７にキャッシ
ュしているコンテンツを、転送レート制御サーバ２０を
経由して当該コンテンツを下流に転送し、転送終了後、
Step01へ戻る（Step07）。

【００４２】上流からの応答内容が「取得指示応答」で
あった場合には、プロキシ・キャッシュ・サーバ１０
は、上流から伝送されてくるコンテンツをＨＤＤ１３内
のキャッシュ領域１７にキャッシュしながら、転送レー
ト制御サーバ２０を経由して当該コンテンツを下流に転
送し、転送終了後、Step01へ戻る（Step04）。

【００４３】《転送レート制御サーバの動作》次に、図
１７〜図１９を参照して、転送レート制御サーバ２０の
動作を、リクエストヘッダー中継／解析プロセス２２、
ファイル転送ヘッダー中継／解析プロセス２１、キャッ
シュ用スケジューラプロセス２３、ファイル転送用スケ
ジューラプロセス２４、定レート送出プロセス２５の各
プロセス毎に、詳細に説明する。

【００４４】『リクエストヘッダー中継／解析プロセ
ス』はじめに、図１７のフローチャートを参照して、転
送レート制御サーバ２０によるリクエストヘッダー中継
／解析プロセス２２の処理動作例について説明する。

【００４５】リクエストヘッダー中継／解析プロセス２
２は、下流のサーバからのリクエストがあるか否かを所
定のサイクルで監視しており（Step10）、下流からのリ
クエストがあった場合、上流のサーバにリクエストを中
継する（Step11）。

【００４６】その後、上流のサーバからの当該リクエス
トに対する応答内容を解析し（Step12）、上流のサーバ
からの応答内容がコンテンツの転送を含んでいた場合
（「取得指示応答」であった場合）には、リクエストヘ
ッダー中継／解析プロセス２２は、上流及び下流の接続
情報等をキャッシュ用転送リクエスト待ち行列２７の最
後尾に格納し、再度Step10へ戻る（Step14）。

【００４７】一方、上流のサーバからの応答内容がコン
テンツの転送を含んでいない場合（「取得指示応答」以
外であった場合）には、リクエストヘッダー中継／解析
プロセス２２は接続を終了し、再度Step10へ戻る（Step
15）。

【００４８】『ファイル転送ヘッダー中継／解析プロセ
ス』次に、図１８のフローチャートを参照して、転送レ
ート制御サーバ２０によるファイル転送ヘッダー中継／
解析プロセス２１の処理動作例について説明する。

【００４９】ファイル転送ヘッダー中継／解析プロセス
２１は、上流のサーバからのリクエストがあるか否かを
所定のサイクルで監視しており（Step20）、上流からの
リクエストがあった場合、キャッシュ用転送リクエスト
待ち行列２７が満杯であるか否かを判別し、満杯である
場合にはビジー状態である旨を上流のファイル転送サー
バに通知して、再度Step20に戻る（Step21）。

【００５０】一方、キャッシュ用転送リクエスト待ち行
列２７が満杯でない場合には、ファイル転送ヘッダー中
継／解析プロセス２１は、上流のファイル転送サーバか
らのリクエストを下流のサーバに中継する（Step22）。

【００５１】その後、下流のサーバからの当該リクエス
トに対する応答内容を解析し（Step23）、下流のサーバ
からの応答内容がコンテンツの転送を含んでいた場合に
は、リクエストヘッダー中継／解析プロセス２２は、上
流及び下流の接続情報等をファイル転送用リクエスト待
ち行列２６の最後尾に格納し、再度Step20へ戻る（Step
25）。一方、上流のサーバからの応答内容がコンテンツ
の転送を含んでいない場合には、ファイル転送ヘッダー
中継／解析プロセス２１は接続を終了し、再度Step20へ
戻る（Step26）。

【００５２】尚、転送先のファイル転送サーバのディス
ク空き容量が不十分である場合や、接続することにより
転送先のファイル転送サーバの最大同時接続数を超える
場合などにおいても、ファイル転送ヘッダー中継／解析
プロセス２１は接続を終了するものとし、この場合、転
送元のファイル転送サーバが所定の時間をおいて再度転
送を試みる。

【００５３】『キャッシュ用転送スケジューラプロセ
ス』次に、図１９のフローチャートを参照して、転送レ
ート制御サーバ２０によるキャッシュ用スケジューラプ
ロセス２３の処理動作例について説明する。

【００５４】キャッシュ用スケジューラプロセス２３
は、定レート送出プロセス２５のキャッシュ用空きフラ
グに基づいて、空き状態の定レート送出プロセス２５が
あるか否かを監視している（Step30）。

【００５５】そして、空き状態の定レート送出プロセス
２５がある場合には、キャッシュ用スケジューラプロセ
ス２３は、キャッシュ用転送リクエスト待ち行列２７の
先頭から接続情報等を取り出し、空き状態の定レート送
出プロセス２５に渡す（Step31）。

【００５６】一方、空き状態の定レート送出プロセス２
５がない場合には、キャッシュ用スケジューラプロセス
２３は、空き状態の定レート送出プロセス２５が生じる
まで待機する。

【００５７】『ファイル転送用スケジューラプロセス』
次に、図２０のフローチャートを参照して、転送レート
制御サーバ２０によるファイル転送用スケジューラプロ
セス２４の処理動作例について説明する。

【００５８】ファイル転送用スケジューラプロセス２４
は、定レート送出プロセス２５のファイル転送用空きフ
ラグに基づいて、空き状態の定レート送出プロセス２５
があるか否かを監視している（Step40）。

【００５９】そして、空き状態の定レート送出プロセス
２５がある場合には、ファイル転送用スケジューラプロ
セス２４は、ファイル転送用リクエスト待ち行列２６の
先頭から接続情報等を取り出し、空き状態の定レート送
出プロセス２５に渡す（Step41）。

【００６０】一方、空き状態の定レート送出プロセス２
５がない場合には、ファイル転送用スケジューラプロセ
ス２４は、空き状態の定レート送出プロセス２５が生じ
るまで待機する。

【００６１】『定レート送出プロセス』次に、図２１の
フローチャートを参照して、転送レート制御サーバ２０
による定レート送出プロセス２５の処理動作例について
説明する。

【００６２】まず、定レート送出プロセス２５は、キャ
ッシュ用空きフラグとファイル転送用空きフラグを立
て、キャッシュ用スケジューラプロセス２３やファイル
転送用スケジューラプロセス２４から接続情報等を渡さ
れるのを待つ（Step50）。

【００６３】次に、定レート送出プロセス２５は、キャ
ッシュ用空きフラグが立っているか否かを判定し、立っ
ている場合にはStep52の処理へ、立っていない場合には
Step55の処理へと移行する（Step51）。

【００６４】キャッシュ用空きフラグが立っている場
合、定レート送出プロセス２５は、次に、キャッシュ用
の接続情報があるか否かを判別し（Step52）、キャッシ
ュ用の接続情報がある場合にはキャッシュ用空きフラグ
を降ろして（Step53）、キャッシュ用の接続情報等を取
得する（Step54）。逆に、キャッシュ用の接続情報がな
い場合には、定レート送出プロセス２５は、上記Step53
〜Step54の処理をスキップして、Step55の処理へと移行
する。

【００６５】Step55の処理において、定レート送出プロ
セス２５は、ファイル転送用空きフラグが立っているか
否かを判定し、立っている場合にはStep56の処理へ、立
っていない場合にはStep59の処理へと移行する（Step5
5）。

【００６６】ファイル転送用空きフラグが立っている場
合、定レート送出プロセス２５は、次に、ファイル転送
用の接続情報があるか否かを判別し（Step56）、ファイ
ル転送用の接続情報がある場合にはファイル転送用空き
フラグを降ろして（Step57）、ファイル転送用の接続情
報等を取得する（Step58）。逆に、ファイル転送用の接
続情報がない場合には、定レート送出プロセス２５は、
上記Step57〜Step58の処理をスキップして、Step59の処
理へと移行する。

【００６７】Step59の処理において、定レート送出プロ
セス２５は、キャッシュ用接続情報があるか否かを判定
し（Step59）、ある場合には所定量のコンテンツを伝送
する（Step60）。そして、定レート送出プロセス２５
は、コンテンツの伝送の完了を確認すると（Step61）、
キャッシュ用の接続を終了し、キャッシュ用空きフラグ
を降ろす（Step62）。そして、所定の時間待機した後、
再度Step51へ戻る（Step63）。

【００６８】一方、Step59の処理において、キャッシュ
用接続情報がない場合には、定レート送出プロセス２５
は、ファイル転送用接続情報があるか否かを判定し（St
ep64）、ファイル転送用接続情報がある場合には、所定
量のファイルを伝送する（Step65）。そして、ファイル
伝送の完了を確認すると（Step66）、ファイル転送用の
接続を終了し、ファイル転送用空きフラグを降ろす（St
ep67）。そして、所定の時間待機した後、再度Step51へ
戻る（Step63）。

【００６９】このように、キャッシュ用接続情報がない
場合に、ファイル転送用接続情報を用いてデータ伝送を
行うようにしているため、優先度の高いキャッシュ転送
を優先的に行いつつ、チャネルの伝送速度を一定のレー
トで行うことができる。

【００７０】また、定レート送出プロセスは、ファイル
の伝送中により優先順位の高いストリーム・データの伝
送が開始された場合には、ファイルの伝送を中断し、ス
トリーム・データの伝送終了後にファイルの伝送を再開
するようにしている。従って、ストリーム・データ伝送
への影響をより確実に抑えることができる。

【００７１】《ファイル転送サーバの動作》次に、図２
２〜図２４を参照して、ファイル転送サーバ３０の動作
例を、ファイル受信プロセス３１、スケジューラプロセ
ス３２、ファイル送信プロセス３３の各プロセス毎に説
明する。

【００７２】『ファイル受信プロセス』図２２は、ファ
イル受信プロセス３１の処理動作例を示すフローチャー
トである。

【００７３】まず、ファイル受信プロセス３１は、上流
のファイル転送サーバから「ファイル転送リクエスト」
があるか否かを所定のサイクルで監視している（Step7
0）。そして、「ファイル転送リクエスト」があると、
ファイル受信プロセス３１は、起動中のファイル受信プ
ロセス３１の数が所定数を超えているか否かを判別し
（Step71）、超えている場合には、「受信否定応答」を
上流のファイル転送サーバに応答し、再度Step70に戻る
（Step72）。

【００７４】一方、ファイル受信プロセス３１の数が所
定数を超えていない場合、ファイル受信プロセス３１
は、ファイル転送リクエストヘッダーを受信し（Step7
3）、受信したヘッダー内のファイルサイズを参照し
て、ファイルスプール３４に空き領域があるか否かを判
別する（Step74）。判別の結果、空き領域がない場合に
は、「受信否定応答」を上流のファイル転送サーバに応
答し、再度Step70に戻る（Step72）。逆に、判別の結
果、空き領域がない場合には、ファイル受信プロセス３
１は、新たな子プロセスをフォーク（fork）した後、再
度Step70に戻る（Step75）。

【００７５】フォークされたファイル受信プロセス３１
は、接続してきたファイル転送サーバに「肯定応答」を
返し（Step76）、ファイル転送サーバから送られてきた
ファイルを受信してファイルスプール３４に蓄積する
（Step77）。そして、ファイル受信が完了すると、フォ
ークされたファイル受信プロセス３１は、「転送リクエ
スト」をファイル転送用リクエスト待ち行列２６の最後
尾に格納し、処理を終了する（Step78）。

【００７６】『スケジューラプロセス』図２３は、スケ
ジューラプロセス３２の処理動作例を示すフローチャー
トである。

【００７７】まず、スケジューラプロセス３２は、所定
の時間待機した後（Step80）、ファイル送信プロセス３
３の空きフラグを調べ（Step81）、空き状態のファイル
送信プロセス３３があるか否かを判別する（Step82）。
判別した結果、空き状態のファイル送信プロセス３３が
ある場合、スケジューラプロセス３２は、ファイル転送
用待ち行列２６の先頭から「転送リクエスト」を取り出
して空き状態のファイル送信プロセス３３に渡し、再度
Step80に戻る（Step83）。

【００７８】『ファイル送信プロセス』図２４は、ファ
イル送信プロセス３３の処理動作例を示すフローチャー
トである。

【００７９】ファイル送信プロセス３３は、起動時に空
きフラグを立て（Step90）、スケジューラプロセス３２
から「転送リクエスト」が渡されるまで待機する（Step
91）。

【００８０】そして、「転送リクエスト」を受け取る
と、ファイル送信プロセス３３は空きフラグを降ろし
（Step92）、下流のファイル転送サーバに接続して「転
送リクエスト」を送り（Step93）、下流のファイル転送
サーバからの応答を待つ（Step94）。

【００８１】そして、下流のファイル転送サーバからの
応答を受け取ると、応答内容を解析し、送られてきた応
答が「肯定応答」であるか否かを判別する（Step95）。
判別した結果、送られてきた応答が「肯定応答」でない
場合（「否定応答」である場合）、下流のファイル転送
サーバとの接続を終了し（Step96）、一定時間待機した
後、再度Step93に戻る（Step97）。判別した結果、送ら
れてきた応答が「肯定応答」である場合、下流のファイ
ル転送サーバにファイルを伝送し（Step98）、接続を終
了した後、再度Step90に戻る（Step99）。

【００８２】ここで、図１に示したファイル・サーバＢ
１からコンテンツ・サーバＢ１に対してファイル転送を
行う場合を具体例として、本ネットワーク制御システム
のファイル転送動作例を、図２５を参照しながら説明す
る。

【００８３】まず、転送元サーバＤ２から、転送元サー
バＤ２が接続しているノードＤのファイル転送サーバＤ
にファイルが転送される（矢印１）。次に、ファイル転
送サーバＤから転送レート制御サーバＤを経由して、ノ
ードＣのファイル転送サーバＣにファイルが転送される
（矢印２）。次に、ファイル転送サーバＣから転送レー
ト制御サーバＣを経由して、ノードＢのファイル転送サ
ーバＢにファイルが転送される（矢印３）。最後に、フ
ァイル転送サーバＢから転送先サーバＢ１へファイルが
転送される（矢印４）。

【００８４】ファイル送信プロセス３３においては、フ
ァイル受信プロセス３１による受信処理が完了した後、
隣接ノードへのファイル転送を開始する、これにより、
ノード間のＷＡＮ帯域の余り方に起因する、受信スピー
ドが送信スピードを上回って帯域を余らせてしまうとい
った問題の発生を防止することができる。

【００８５】以上に説明したように、本実施形態におけ
るネットワーク制御システムにおいては、定レート送出
プロセス２５が、各優先順位毎のバッファ２８が空き状
態かどうかを調べ、データが格納されているバッファ２
８のうち最も優先順位の高いバッファ２８から優先的に
データを取り出してルータ２に出力するようにして、ス
トリーム・データの空き時間にリアルタイム性を必要と
しないファイル伝送を行う、これにより、ストリーム伝
送に影響を与えることなく、帯域制御を行うことが可能
となり、ストリーム・データの再生までの待ち時間を抑
えつつ伝送帯域を有効に利用することができ、ストリー
ム伝送の通信コストを削減することができる。

【００８６】また、本実施形態におけるネットワーク制
御システムにおいては、定レート送出プロセス２５のプ
ロセス数を調整することにより、ストリーム・データの
再生までの遅延時間を許容範囲内に抑えつつ、全体の通
信量以上の任意の回線帯域を設定することができるの
で、通信回線の利用効率を向上させることが可能とな
り、また、一日や一週間といった単位でトラヒックを平
均化するともできる。

【００８７】以上、本発明の実施形態について詳細に説
明したが、この実施の形態による本発明の開示の一部を
なす論述及び図面により本発明が限定されることはな
い。この実施の形態に基づいて当業者等によりなされる
他の実施の形態、実施例及び運用技術等は全て本発明の
範疇に含まれることは言うまでもない。

【００８８】

【発明の効果】本発明によれば、ストリーム・データを
伝送する際、空き領域となっている伝送帯域を、リアル
タイム性を必要としない優先度の低いトラヒックの伝送
処理に利用するので、ストリーム・データの伝送に影響
を与えることなく伝送帯域を有効に活用し、ストリーム
・データ伝送に係る通信コストを削減することができ
る。

【図面の簡単な説明】

【図１】本実施形態におけるネットワークの構成例を模
式化した図である。

【図２】図１に示したノードの内部構成を例示する模式
図である。

【図３】図２に示したプロキシ・キャッシュ・サーバの
内部構成を例示する模式図である。

【図４】図３に示したセッションテーブルのデータフォ
ーマットを例示する模式図である。

【図５】図１に示したアプリケーションプログラムの構
成を例示する模式図である。

【図６】図３に示したノードプロキシ・キャッシュ・サ
ーバの動作例を説明するための模式図である。

【図７】本実施形態における「取得指示」リクエストの
データ構造例を示す図である。

【図８】本実施形態における「問い合わせ」リクエスト
のデータ構造例を示す図である。

【図９】本実施形態における「取得指示応答」のデータ
構造例を示す図である。

【図１０】本実施形態における「問い合わせ肯定応答」
のデータ構造例を示す図である。

【図１１】本実施形態における「アクセス否定応答」の
データ構造例を示す図である。

【図１２】図２に示した転送レート制御サーバの内部構
成を例示する模式図である。

【図１３】図１２に示した定レート送出プロセスにより
チャネル優先制御処理を説明するための模式図である。

【図１４】図１２に示した定レート送出プロセスにより
チャネル優先制御処理を説明するための模式図である。

【図１５】図２に示したプロキシ・キャッシュ・サーバ
の内部構成例を示す模式図である。

【図１６】図２に示したプロキシ・キャッシュ・サーバ
の処理動作例を示すフローチャートである。

【図１７】図２に示した転送レートサーバのリクエスト
ヘッダー中継／解析プロセスの処理動作例を示すフロー
チャートである。

【図１８】図２に示した転送レートサーバのファイル転
送ヘッダー中継／解析プロセスの処理動作例を示すフロ
ーチャートである。

【図１９】図２に示した転送レートサーバのキャッシュ
用スケジューラプロセスの処理動作例を示すフローチャ
ートである。

【図２０】図２に示した転送レートサーバのファイル転
送用スケジューラプロセスの処理動作例を示すフローチ
ャートである。

【図２１】図２に示した転送レートサーバの定レート送
出プロセスの処理動作例を示すフローチャートである。

【図２２】図２に示したファイル転送サーバのファイル
受信プロセスの処理動作例を示すフローチャートであ
る。

【図２３】図２に示したファイル転送サーバのスケジュ
ーラプロセスの処理動作例を示すフローチャートであ
る。

【図２４】図２に示したファイル転送サーバのファイル
送信プロセスの処理動作例を示すフローチャートであ
る。

【図２５】本実施形態におけるファイル伝送処理の動作
手順例を示すフローチャートである。

【符号の説明】

１....ノード（Node）２....ルータ（Router）３....ＬＡＮ（Local Area Network）４....ファイル・サーバ（File Server）５....コンテンツ・サーバ（Contents Server）６....クライアント（Client）１０....プロキシ・キャッシュ・サーバ（Proxy Cache
Server）１１....ＣＰＵ（Central Processing Unit）１２....ＲＡＭ（Random Access Memory）１３....ＨＤＤ（Hard Disk Drive）１４....ネットワークＩ／Ｆ（Network I/F）１５....セッション・テーブル（Session Table）１６....アプリケーション・プログラム（Application
Program）１７....キャッシュ領域２０....転送レート制御サーバ２１....ファイル転送ヘッダー中継／解析プロセス２２....リクエストヘッダー中継／解析プロセス２３....キャッシュ用スケジューラプロセス２４....ファイル転送用スケジューラプロセス２５ａ〜２５ｃ....定レート送出プロセス２６....ファイル転送用リクエスト待ち行列２７....キャッシュ用転送リクエスト待ち行列２８....データ入力用バッファ２８....バッファ２９....優先順位スケジューラ３０....ファイル転送サーバ３１....ファイル受信プロセス３２....スケジューラプロセス３３ａ〜３３ｃ....ファイル送信プロセス３４....ファイル・スプール３５....ファイル転送ヘッダー中継プロセス

Claims

【特許請求の範囲】

【請求項１】隣接する同士が相互に接続する複数のノ
ードと、前記ノードのいずれか１つに接続され、ストリーム・デ
ータを保持する少なくとも１つ以上のコンテンツ・サー
バと、前記ノードのいずれか１つに接続され、ファイルを保持
する少なくとも１つ以上のファイル・サーバと、前記ノードのいずれか１つに接続され、前記ストリーム
・データを前記コンテンツ・サーバに要求する少なくと
も１つ以上のクライアントと、前記ノード毎にそれぞれ接続され、前記コンテンツ・サ
ーバから前記クライアントに転送されるストリーム・デ
ータをキャッシュしながら中継する複数のプロキシ・キ
ャッシュ・サーバと、前記ノード毎にそれぞれ接続され、前記ファイル・サー
バから前記コンテンツ・サーバに転送されるファイル、
あるいは前記ファイル・サーバから別のファイル・サー
バに転送されるファイルをキャッシュしながら中継する
複数のファイル転送サーバと、前記ノード毎にそれぞれ接続され、前記ストリーム・デ
ータあるいはファイルの要求元からのリクエストの度に
起動され、当該リクエストを要求先に中継し、要求先か
らの応答がストリーム・データあるいはファイルの転送
を伴う場合には当該応答データを待ち行列の最後尾に格
納するプロセスと、予め所定の数のプロセスが起動さ
れ、要求先からのストリーム・データあるいはファイル
を要求元に所定の速度で伝送する定レート送出プロセス
と、前記待ち行列の先頭から応答データを１つずつ取り
出し、空き状態の前記定レート送出プロセスに渡すプロ
セスとを実行する転送レート制御サーバとを有し、前記定レート送出プロセスは、優先順位毎にバッファを
有し、前記待ち行列の先頭から取り出した応答データを
該応答データの優先順位に従って前記バッファに割り振
って格納し、優先順位の高いバッファから優先的に応答
データを取り出して伝送することを特徴とするネットワ
ーク制御システム。
【請求項２】請求項１に記載のネットワーク制御シス
テムにおいて、前記定レート送出プロセスは、応答データの伝送中に当
該応答データより優先順位の高い応答データの伝送が開
始された場合には、優先順位の低い応答データの伝送を
中断し、前記優先順位の高い応答データの伝送終了後に
前記優先順位の低い応答データの伝送を再開することを
特徴とするネットワーク制御システム。