JP2003223384A - ファイル配信システム - Google Patents

Abstract

(57)【要約】 【課題】 オリジナルサーバからミラーサーバへのファ
イル配信を効率よく行う。 【解決する手段】 マルチキャストプロトコルを利用し
て複数のミラーサーバへ同時にファイルを配信する。こ
のとき、送信側で、ネットワーク帯域の管理、送信ファ
イルの順序制御、優先制御および帯域制御を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はオリジナルのファイ
ルを蓄積するオリジナルサーバからミラーサーバへのフ
ァイルコピーの技術に関する。

【０００２】

【従来の技術】ある１台のオリジナルサーバから分散さ
れた複数のミラーサーバにファイルのコピーを行う場
合、ファイルの伝播方向は「オリジナルサーバからミラ
ーサーバ」の方向であるが、ファイルを送るという処理
の起動は、オリジナルサーバ側から行う方法と、ミラー
サーバ側から行う方法との２種類がある。ミラーサーバ
側から起動する場合、ある一つのファイルを伝播させる
という処理であっても、ファイルの送信処理はミラーサ
ーバごとに個別に行われ、複数のミラーサーバが同時に
ファイルを取得しようとした場合には、オリジナルサー
バで過負荷が起きる可能性がある。オリジナルサーバ側
から起動する場合には、ファイルを配信すべきミラーサ
ーバを把握し、ミラーサーバへのファイルヘ配信の進捗
具合、ネットワーク負荷、サーバ負荷などを考慮しなが
らファイル配信することが可能である。

【０００３】現在広く使われているファイル配信方式の
うち、ミラーサーバ側から起動するものとしては、UNIX
（登録商標）で広く使われているミラーデーモン、Gnut
ella、Napsterなどが良く知られている。これらはいず
れもTCP/IPを用いた１対１のファイル配信方式である。
ミラーデーモンはサーバの状態やネットワーク負荷を計
測する手段をもたず、無理のないファイル配布を行うに
は、あらかじめネットワーク形態や配布ポリシーをきち
んと定めておく必要がある。GnutellaやNapsterのよう
なPeer-to-Peerファイル配信方式は、ミラー側でファイ
ルをダウンロードするオリジナルサーバを自由に選ぶこ
とができ、同一のファイルが置かれているサーバが複数
あるのであれば、それらのサーバの中で最も負荷の軽い
ものを選ぶことができる。ミラーデーモンと比べると、
GnutellaやNapsterはオリジナルサーバを柔軟に選ぶこ
とができるのが強みである。

【０００４】一方、オリジナルサーバ側からファイル配
信を起動するものとしては、Akamai社のキャッシュサー
バやNEC社のVoDシステムなどがある。これらのシステム
は、主にビデオストリームの配信範囲など特定のサービ
ス向けに用意されているものが大部分であり、ファイル
配信プロトコルもHTTP（Hyper Text Transfer Protoco
l）、FTP（File Transfer Protocol）、TFTP（Trivial
File Transfer Protocol）など、簡易なTCP/IP上のファ
イル転送プロトコルを用いたものが多い。これらのシス
テムでは、ファイル配信を行う頻度や配布先のサーバ数
などがそれほど大きい場合を想定しておらず、それより
は転送されたファイルを利用するVoDシステムなどのア
プリケーションとの連携に多くの機能が実装されてい
る。

【０００５】

【発明が解決しようとする課題】しかし、従来のファイ
ル配信方式ではいずれも、ミラーサーバの数が増えれ
ば、同じファイル送信をミラーサーバの数だけ行わなく
てはならず、ファイルの配信に時間がかかってしまう。

【０００６】本発明は、このような課題を解決し、効率
よくファイルを配信することのできるファイル配信シス
テムを提供することを目的とする。

【０００７】

【課題を解決するための手段】本発明は、オリジナルの
ファイルを蓄積するルートサーバと、このルートサーバ
からオリジナルのファイルのコピーを受け取って蓄積す
る１以上のリーフサーバとをネットワーク内に備えたフ
ァイル配信システムにおいて、前記ネットワークは、特
定の宛先アドレスが付与されたパケットをそのアドレス
で示されるグループに属する複数の宛先に同報配信する
マルチキャストプロトコル、特にIPマルチキャストプロ
トコルあるいはそれに準じたプロトコルが利用可能なネ
ットワークであり、ルートサーバは、マルチキャストプ
ロトコルにより、１以上のリーフサーバの少なくとも一
部に同時にファイルを配信するマルチキャストプロトコ
ル処理手段を備えたことを特徴とする。

【０００８】本明細書においては、ファイルの蓄積に加
え配信処理を行うサーバを特に「ルートサーバ」、配信
されたファイルを受信して蓄積するサーバを特に「リー
フサーバ」ともいう。ルートサーバは、オリジナルサー
バに配信処理機能をもたせたものでもよく、オリジナル
サーバとは別に制御サーバを備えたものでもよい。リー
フサーバも同様に、ミラーサーバに受信処理機能をもた
せたものでもよく、別途受信処理サーバを備えたもので
もよい。

【０００９】オリジナルサーバの内容を複数のミラーサ
ーバに個々にコピーする場合、ファイルサイズが大き
く、またミラーサーバの数が増えると、ファイルのコピ
ーに時間がかかる。これに対してマルチキャストプロト
コルを用いてファイルを配信すれば、送信が１回で済
み、時間の節約になる。

【００１０】ネットワークの形態によっては、例えば衛
星回線を利用したものなど、ルートサーバからリーフサ
ーバの方向へのデータ通信だけ可能な非対称な場合があ
る。その場合には、同じデータを複数回送信する。これ
により、送達確認を行わなくとも、信頼性の高ファイル
配信を行うことができる。

【００１１】ただし、マルチキャストプロトコルでは、
それ自体にはネットワークの輻輳具合によって転送帯域
を動的に変更する機能がないため、全体のネットワーク
帯域を管理し、送信速度の合計が全体のネットワーク帯
域を越えないようにデータの送出を行うことが必要とな
る。

【００１２】そこで、ルートサーバには、配信するファ
イルごとにマルチキャストプロトコル処理手段からのデ
ータの送出速度を可変に設定する手段を備えることが望
ましい。

【００１３】また、ルートサーバには、配信するファイ
ルごとに複数段階のいずれかの配信優先度を設定する手
段と、ネットワークが許す最大帯域情報を保持し、最上
級の優先度のファイルには指定された帯域を確保し、下
位の優先度のファイルと上位の優先度のファイルとが同
時に送信される場合には、上位の優先度のファイル送信
のための帯域を優先的に確保する帯域管理手段と備える
こともできる。この場合、帯域管理手段は、下位の優先
度のファイル送信に対して最低保証帯域を設定する手段
を含み、上位優先度のファイル送信が下位優先度のファ
イル送信から帯域を奪う場合に、最低保証帯域を侵食す
るような帯域略奪を許さないようにすることが望まし
い。

【００１４】ルートサーバには、ファイルの送信を開始
する時間を設定する手段を備えることが望ましい。ま
た、一定時間を越えてもファイルの送信が完了しなかっ
た場合にはファイルの送信を強制停止する手段を含むこ
とが望ましい。配信に失敗したファイルについて、あら
かじめ定められた、またはランダムに割り当てられた時
間が経過した後に、再びマルチキャストプロトコルによ
る配信を開始する手段を含むこともできる。その場合、
あらかじめ定められた回数にわたりマルチキャストでの
配信に失敗した場合に、そのリーフサーバに対して個別
に送信する手段を含むこともできる。

【００１５】ルートサーバは、配信しようとする複数の
ファイルを順番に蓄え、前のファイルの配信が終了する
のを待って次のファイルをマルチプロトコル処理手段に
渡す配信キューを備えることがよい。配信優先度を設け
る場合には、その優先度ごとに配信キューを設ける。配
信キューに蓄えられているファイルの順序を変更する手
段を備えこともできる。

【００１６】ルートサーバは、送信するファイルサイズ
が大きい場合に、それをあらかじめ定められたサイズの
ブロックに分割する手段を備えることが望ましい。この
場合、ルートサーバは分割されたブロックにシリアル番
号を付加する手段を備え、リーフサーバは分割されたブ
ロックのシリアル番号からそれらの順序を正しく復元す
る手段を備えることがよい。

【００１７】また、分割されたブロックにCRC (Cyclic
Redundancy Check)などの誤り検出符号とシリアル番号
とを付加して複数回にわたり前記マルチキャストプロト
コル処理手段から送信させる手段を含み、リーフサーバ
は、受信した複数のブロックから誤り訂正符号の正しい
ものをシリアル番号順に取り出して一つのファイルに組
み立てる手段を含むこともできる。この場合、送達確認
ができない場合でも、ファイル配信の信頼性を高めるこ
とができる。

【００１８】ルートサーバは、指定されたディレクトリ
の下のファイルを定期的に調べ、前回配信を行った時間
以降に変更が加えられたファイルあるいは新たに追加さ
れたファイルが存在する場合には、それらのファイルを
配信すべきファイルとして指定する手段を備えることが
望ましい。

【００１９】ルートサーバは、同一のファイルを配信す
る場合であっても、宛先のリーフサーバによって、マル
チキャストで配信するか他のプロトコルで個別に配信す
るかを選択する手段を備えることが望ましい。

【００２０】

【発明の実施の形態】図１は本発明の基本的な実施形態
を示すブロック構成図である。このファイル配信システ
ムは、IPネットワーク１内に、オリジナルのファイルを
蓄積するルートサーバ２と、このルートサーバ２からオ
リジナルのファイルのコピーを受け取って蓄積する１以
上のリーフサーバ３とを備える。IPネットワーク１はIP
マルチキャストプロトコルが利用可能なネットワークで
あり、ルートサーバ２は、IPマルチキャストプロトコル
により、リーフサーバ３の少なくとも一部に同時にファ
イルを配信することができる。

【００２１】図２はルートサーバ２のファイル配信に関
係する構成部分を示すブロック構成図である。このルー
トサーバ２は、ファイルを投入するファイル投入部１
１、送り手側でファイル配信を実行するファイル配信部
１２、送信レートを管理する帯域管理部１３、公知の高
信頼マルチキャストプロトコルを用いてファイル送信制
御を行うマルチキャストプロトコル処理部１４およびネ
ットワークインタフェース１５を備え、ファイル配信部
１２には、送られるファイルの優先度ごとに複数の配信
キュー１６が設けられる。

【００２２】ファイル配信部１２は、マルチキャストプ
ロトコル処理部１４に対し、あらかじめ定められたスケ
ジュールで配信しようとするファイルを渡す。このファ
イルには、配信開始時間、配信終了時間、配信速度、配
信優先度、使用マルチキャストアドレス、使用ポート番
号、宛先サーバのIPアドレス、シリアル番号といった情
報が付加される。配信開始時間は、ファイルの送信を開
始する時間である。配信終了時間は、その時間になって
も配信が終了しなかったら、いったん配信を終了する時
間である。配信速度はファイルを送信する速度であり、
IPパケットの送信間隔を制御するためのものである。配
信優先度は、ファイル送信の際に帯域を割り当てる優先
度を表し、より優先度の高いファイル送信に対し、帯域
が優先的に割り当てられる。配信開始時間、配信終了時
間、配信速度、配信優先度は、ファイルごとに送信管理
ファイルを作成して管理することができる。使用マルチ
キャストアドレスは、ファイルを送信するときに用いら
れるマルチキャストアドレスを表す。配信先のリーフサ
ーバはそれぞれがどのマルチキャストアドレスに参加し
ているかが定められており、マルチキャストアドレスを
変えることによって、ファイルが配信されるリーフサー
バを切り替えることができる。配信先を切り替えたりTC
P／IPを用いるかマルチキャストを用いるか切り替える
設定についても、上述した送信管理ファイルにより管理
される。使用ポート番号は、マルチキャストアドレスご
とに一意に定まるように設定する。宛先サーバのIPアド
レスは、マルチキャストプロトコル処理部１４がマルチ
キャスト配信時のエラー訂正のために用いられる。シリ
アル番号は、ファイルを送信する際の順序のチェックに
用いられる。

【００２３】マルチキャストプロトコル処理部１４は、
信頼性あるマルチキャスト通信を実現するために用いら
れる。通常のIPマルチキャストでは、TCP／IP通信とは
異なり、IPパケットが失われたり到着順序が違ったりし
ても訂正を行うことはない。これに対しマルチプロトコ
ル処理部１４は、受信側でIPパケットの到着順序が入れ
替わったり、失われたIPパケットじ生じたりすると、再
送などによる訂正を行う。

【００２４】ネットワークインタフェース１５は、一般
に広く使われている10/100Base-Tに対応してネットワー
クカードであり、最低限、IPパケットを送出する機能を
もつ。

【００２５】図３はファイル配信の基本シーケンスを示
す。

【００２６】ファイル配信部１２は、定期的に配信キュ
ー１６をチェックし、配信キュー１６の先頭のファイル
が配信時間になると、そのファイルを配信するための帯
域が確保できるかどうかを帯域管理部１３に問い合わせ
てチェックする。帯域管理部１３では、送信優先度をチ
ェックし、これから配信しようとするファイルが現在送
信中のものよりも優先度が高ければ、優先的に帯域を割
当てる。帯域管理部１３に問い合わせて帯域が確保でき
れば、指定されたマルチキャストアドレス、ポート番
号、配信速度でマルチキャストプロトコル処理部１４に
ファイルを渡し、ファイルの配信を開始する。

【００２７】リーフサーバ３では、すべのファイルを受
信し終えると、配信されたファイルの付加情報としてシ
リアル番号が存在するかどうかを調べる。シリアル番号
が存在する場合には、シリアル番号の順序を検証し、番
号の抜けが存在する場合には、あらかじめ定められた時
間、抜けた番号のファイルが到着するのを待つ。抜けた
番号のファイルがあらかじめ定められた時間待っても到
着しない場合には、そのファイルの再送をルートサーバ
２に要求する。

【００２８】ルートサーバ２は、要求されたファイル
を、今度はTCP／IP通信で送信する。

【００２９】各部の動作についてさらに詳しく説明す
る。

【００３０】図４はファイル投入部１１の処理の流れを
示す。ファイル投入部１１は、ルートサーバ２内の記憶
装置またはオリジナルサーバ（図示せず）から、指定さ
れたディレクトリの下を定期的に巡回し、前回配信を行
った時間以降に変更が加わっているファイル、あるいは
追加されたファイルが存在すれば、それらのファイルを
アーカイブにまとめ、配信開始時間、配信終了時間、配
信速度および配信優先度を指定してファイル配信部１２
に投入する。同一のファイルを配信する場合であって
も、宛先のリーフサーバによって、マルチキャストで配
信するか、TCP通信で配信するか、ルートサーバ２内に
設けられた設定ファイルなどにより確認する。

【００３１】図５はファイル配信部１２の処理の流れの
一例を示す。この例は、ファイルの送達確認を行う機能
がない場合の処理例である。ファイル配信部１２は、フ
ァイル投入部１１からファイルを受け取ると、そのファ
イルの優先度ごとの配信キュー１６に蓄積する。このと
き、送信するファイルサイズが大きい場合には、それ
を、例えば１ＭＢ単位など、あらかじめ定められたサイ
ズのブロックに分割し、それぞれのブロックにCRCおよ
びシリアル番号を付加しておく。配信キュー１６には、
配信開始時間順に蓄積する。配信キュー１６の先頭ファ
イルが配信時間になると、マルチキャストプロトコル処
理部１４による前のファイルの配信が終了していること
を確認し、帯域管理部１３に帯域確保を要求する。帯域
が確保できると、ファイルをマルチキャストプロトコル
処理部１４へ渡す。このとき、同じファイルを複数回に
わたりマルチキャストプロトコル処理部１４へ渡し、同
じファイルを複数回送信するようにする。これにより、
送達確認を行わなくても、信頼性の高ファイル配信を行
うことができる。

【００３２】図６はファイル配信部１２の処理の流れの
別の例を示す。この例はファイル配信の送達が確認でき
る場合の処理例である。この場合、ファイル配信が失敗
したときのみ再配信を行う。すなわち、配信が失敗した
ときには、所定の時間またはランダムに割り振った時間
の後に再配信の処理を繰り返し、失敗回数があらかじめ
定められた回数を越えた場合には、TCPを用いて同じフ
ァイルをユニキャスト配信する。

【００３３】図７は帯域管理部１３の処理の流れを示
す。帯域管理部１３は、ネットワークが許す最大帯域情
報を保持し、最上級の優先度のファイルに対しては指定
された帯域を確保し、下位の優先度のファイルと上位の
優先度のファイルとが同時に送信される場合には、上位
の優先度のファイル送信のための帯域を優先的に確保す
る。また、上位優先度のファイル送信が下位優先度のフ
ァイル送信から帯域を奪う場合には、下位優先度のファ
イルには最低保証帯域を設定し、最低保証帯域を侵食す
るような帯域割当を防止する。

【００３４】帯域管理部１３による帯域割当のアルゴリ
ズムについて、 A：ネットワークが許す全体帯域 B：優先度「１」（最優先）のファイル配信に割り当て
られた全帯域 b：優先度「１」の配信個別の帯域 C：優先度「２」（次優先）のファイル配信に割り当て
られた全帯域 c：優先度「２」の配信個別の帯域 D：優先度「３」（低優先）のファイル配信に割り当て
られた全帯域 d：優先度「３」の配信個別の帯域 Bmin：優先度「２」のファイル配信の最低保証帯域 Dmin：優先度「３」のファイル配信の最低保証帯域 D = A-(B+C)、B =Σb（ただし D = Dmin） として説明する。

【００３５】優先度「１」のファイルが帯域bの増加を
要求した場合 (1) b ＞ A-(B+Cmin+Dmin)の場合は拒否 (2) b ＜ A-(B+C+Dmin)の場合 D' = D-b（ただしD' ＞= Dmin） Cは変更なし B' = B+b (3) A-(B+C+Dmin) ＜ b ＜ A-(B+Cmin+Dmin） D' = Dmin C' = A-(B+b+Dmin)（ただしC' ＞= Cmin） B' = B+b 帯域に変更があれば、優先度「３」、「２」、「１」の
順に帯域割り当てを実行する。

【００３６】優先度「１」のファイルが帯域bを減らす
要求をした場合 (1) Cが配信中の場合 C' = C+b (2) Cが配信中でない場合 D' = D+b 帯域に変更があれば、優先度「１」、「２」、「３」の
順に帯域割り当てを実行する。

【００３７】優先度「２」のファイルが帯域c（c ＞
C）を要求した場合 (1) c ＜= A-(B+D)の場合 C' = c、D' = D+(C-c) (2) A-(B+D) ＜c ＜= A-(B+Dmin)の場合 C' = c、D' = D-(C'-C) (3) c ＞ A-(B+Dmin)の場合 C' = A-(B+Dmin)、D' = Dmin 帯域に変更があれば、優先度「３」、「２」の順に帯域
割り当てを実行する。

【００３８】優先度「２」のファイルが帯域c （c ＜
C）を要求をした場合 (1) c ＞= Cminの場合 C' = c、D' = D+C-c (2) c ＜ Cminの場合 C' = Cmin、D' = D+C-Cmin 優先度「２」、「３」の順に帯域割り当てを実行する。

【００３９】優先度「３」のファイルによる帯域d（d
＞ D）の要求は受け付けない。

【００４０】優先度「３」のファイルが帯域d（d ＜
D）を要求した場合 (1) d ＞=Dminの場合 D' = d、C'= C+D-d (2) d ＜Dminの場合 D' = Dmin、C' = C+D-Dmin 優先度「３」に対して帯域割り当てを実行する。

【００４１】図８はマルチキャストプロトコル処理部１
４の処理の流れを示す。マルチキャストプロトコル処理
部１４は、ファイル配信部１２からファイルを受け取る
と、それを、帯域管理部により確保された帯域に応じた
データ送信速度で、マルチキャストプロトコルにより配
信する。一定時間を越えてもファイルの送信が完了しな
かった場合には、ファイルの送信を強制停止する。

【００４２】図９はリーフサーバ３の受信部の処理の流
れの一例を示す。この例は、ファイルの送達確認を行う
機能がない場合の処理例である。リーフサーバ３はマル
チプロトコトルによるデータ配信に対応しており、ルー
トサーバ２からのファイルを複数回受信する。受信した
ファイルが分割されたものである場合には、シリアル番
号順に並べ替えて復元する。受信成功が成功した場合に
は、そのファイルを所定の場所に格納する。

【００４３】図１０はリーフサーバ３の受信部の処理の
流れの別の例を示す。この例は、ファイル配信の送達が
確認できる場合の処理例であり、ファイル配信が失敗し
た場合には、TCPを用いて再送を要求する。失敗回数が
あらかじめ定められた回数を越える場合には、TCPを用
いたユニキャスト配信でファイルが送られてくるので、
それを受信する。

【００４４】現在標準化されているIPマルチキャストプ
ロトコルでは、受信側からデータの再送を要求するよう
にはなっていない。そのため、リーフサーバ３からの再
送要求にはTCPを用いる。また、ネットワークの形態に
よっては、ルートサーバ２からリーフサーバ３方向への
データ通信だけが可能な非対称なものも考えられる。そ
の場合には、別経路で再送を要求する。

【００４５】

【実施例】図１１は本発明の具体的な実施例を示す図で
あり、あるネットワーク事業者とコンテンツプロバイダ
がストリーム配信サービスを行う場合のネットワーク構
成を示す。

【００４６】ユーザの端末２１は、上述したリーフノー
ドに相当するエッジノード２２に接続され、エッジノー
ド２２はIPネットワーク２３に接続される。このIPネッ
トワーク２３にはまた、上述したルートノードに相当す
るコンテンツプロバイダの配信センタ２４が接続され
る。エッジノード２２にはルータ３１、ミラーサーバ３
２、ストリームサーバ３３および衛星回線受信アンテナ
３４が設けられる。IPネットワーク２３には多数のアク
セスポイント４１が設けられ、それぞれに、エッジノー
ド２２と同等のエッジノード、衛星回線送信アンテナ４
２、あるいはその他のノードが接続される。配信センタ
２４には、ルータ５１、オリジナルサーバ５２、ストリ
ームサーバ５３および制御サーバ５４が設けられる。

【００４７】このサービスでは、ミラーサーバを全国に
配置するため、配信には、衛星回線を利用したIPマルチ
キャストを用いる。衛星回線を用いる長所は、地上回線
と比べるとはるかにコストを低減できることである。た
だし、衛星回線では配信センタ２４からエッジノード２
２方向のデータ転送しかできないため、配信時の誤り訂
正を行ったり、制御サーバ５４からエッジノード２２の
ミラーサーバ３２やストリームサーバ３３を管理するた
めに、低帯域の地上回線を別途設ける。

【００４８】配信センタ２４内の制御サーバ５４は、衛
星回線の帯域を管理し、また、オリジナルサーバ５２か
らファイル配信を行う場合や、ストリーム配信を行う場
合には、送出の前に帯域の割当を行う。

【００４９】このとき、ストリーム配信については優先
度「１」（最優先度）で帯域を割り当て、帯域が確保で
きない場合にはファイル配信用の帯域を小さくして確保
する。ファイル配信用の帯域を奪っても確保できなかっ
た場合には、そのストリーム配信はキャンセルされる。

【００５０】ファイル配信は、優先度「２」以下で帯域
が確保され、基本的には空いている帯域すべてを用いて
ファイル配信を行う。下位の優先度のファイル配信は、
上位の優先度ファイルの配信から要求があれば、帯域を
圧縮させられる。上位の優先度のファイル配転は、下位
の優先度のファイル配信から帯域を奪われることはな
い。ファイルの送信は要求があるとすぐに開始される
が、帯域が確保できなかった場合には配信キューに積ま
れ、送信に必要な帯域が確保されるまでは送信が開始さ
れない。

【００５１】受信側のミラーサーバ３２では、ファイル
を受信すると、そのファイルのバージョン番号を調べ、
自分が受信したファイルのバージョン番号を地上回線経
由で制御サーバ５４に通知する。

【００５２】制御サーバ５４は、受け取ったバージョン
番号によって、そのミラーサーバ３２へのファイル配信
がうまくいったと認識する。送信側でファイルの送信が
失敗したことを検知できた場合、制御サーバ５４は送信
に失敗したファイルを配信キューの最後に積み直す。こ
のようにして、あらかじめ定められた回数だけ再送を行
い、最後まで配信が成功しなかった場合には、ファイル
の送信に失敗したことをミラーサーバ３２に伝え、ミラ
ーサーバ３２に配信ファイルをダウンロードするように
要求する。

【００５３】要求を受けたミラーサーバ３２は、配信フ
ァイルを個別にダウンロードし、ダウンロードが無事終
了した場合には、バージョン情報を制御サーバ５４に返
す。この場合にもミラーサーバ３２によるファイル受信
が失敗した場合には、制御サーバ５４はファイルの送信
を断念する。

【００５４】ストリーム配信の場合は、必ず帯域の確保
が先に行われ、帯域が確保できない場合には配信が行わ
れない。ストリーム配信は制御サーバ５４であらかじめ
開始時間と終了時間とを設定することができ、開始時間
になると自動的に帯域が確保れ、終了時間になると帯域
が解放される。制御サーバ５４におけるストリーム配信
の予約時には、予約時に要求された帯域が未来の終了時
間まで確保可能かどうかを計算しているため、ストリー
ム配信開始時間になるまでストリーム配信が可能かどう
かわからないという事態は起こらない。

【００５５】以上のようにして、衛星回線を用いてファ
イル配転とストリーム配信を行うシステムが実現され
る。

【００５６】

【発明の効果】以上説明したように、本発明によれば、
従来はミラーサーバへのファイル配信にはTCP/IP通信し
か用いられなかったところにマルチキャストを適用する
ことにより、複数のミラーサーバに短時間でミラーリン
グを行うことが可能となる。

【００５７】また、同じデータを複数回にわたりマルチ
キャスト配信することで、衛星からの電波を受け取るこ
としかできない単なる受信端末で、通信端末とはみなさ
れないような端末に対しても、信頼性の高いファイルの
ミラーリングを行うことが可能となる。

【００５８】TCP/IP通信では人が明示的に配信速度を指
定することはできないが、本発明では、ファイルごとに
配信速度を指定することができる。また、ファイルに優
先度を付けることもできる。

【００５９】送信開始時間を設定した場合には、ネット
ワークが空いている時間帯を狙ってファイル配信を行う
ことができる。

【００６０】時間に制限を設けてある一定時間が過ぎて
もファイルの送信が終了しなかった場合にはファイルの
送信を停止することで、ネッワークの品質が悪く要求さ
れた速度でファイルを送信することができない場合に、
無駄な処理を減らすことができる。

【００６１】配信に失敗した場合、従来のシステムでは
ファイル配信がそこでストップしてエラー扱いになる
が、本発明では、時間をおいて再送することにより、よ
り障害に強いシステムとなる。

【００６２】マルチキャトス配信に失敗した場合にはTC
P/IP通信を用いて配信することで、確実にファイルを配
信することができる。

【００６３】従来はファイル配信のイベントが生じると
即座にファイル送信を行っていたが、本発明では、帯域
が足りない場合にはキューイングを行うことで、ひとつ
のファイルの送信にかかる時間をある水準以上に抑える
ことができる。また、キューイングの段階で送信イベン
トに優先度を設けることで、効率的に優先制御を行うこ
とができる。さらに、キューに積まれているファイルの
送信順序を変更することもできる。

【００６４】送信するファイルサイズが大きい場合に、
従来はファイルを分割して配信することができないため
帯域を占有してしまっていたが、本発明では、ファイル
を分割して別々の配信イベントで配信でき、効率的な配
信を行うことができる。また、分割されたファイルにシ
リアル番号を付加することで、受信側でのファイルの整
合性を保つことができる。

【００６５】ルートサーバの配信ファイルをオペレータ
渡しではなく配信用ディレクトリを設けて、変更が加え
られたファイルあるいは新たに追加されたファイルを自
動的に配信することもできる。

【００６６】さらに本発明によれば、同一のファイルを
配信する場合でもネットワークの制限などによって用い
ることのできるプロトコルに違いがある場合、宛先ごと
に配信プロトコルを設定することができる。

【図面の簡単な説明】

【図１】本発明の基本的な実施形態を示すブロック構成
図。

【図２】ルートサーバのファイル配信に関係する構成部
分を示すブロック構成図。

【図３】ファイル配信の基本シーケンスを示す図。

【図４】ファイル投入部の処理の流れを示すフローチャ
ート。

【図５】ファイル配信部の処理の流れの一例を示すフロ
ーチャート。

【図６】ファイル配信部の処理の流れの別の例を示すフ
ローチャート。

【図７】帯域管理部の処理の流れを示すフローチャー
ト。

【図８】マルチキャストプロトコル処理部の処理の流れ
を示すフローチャート。

【図９】リーフサーバの受信部の処理の流れの一例を示
すフローチャート。

【図１０】リーフサーバの受信部の処理の流れの別の例
を示すフローチャート。

【図１１】本発明の具体的な実施例を示す図。

【符号の説明】

１、２３ IPネットワーク ２ ルートサーバ ３ リーフサーバ １１ ファイル投入部 １２ ファイル配信部 １３ 帯域管理部 １４ マルチキャストプロトコル処理部 １５ ネットワークインタフェース １６ 配信キュー ２１ ユーザの端末 ２２ エッジノード ２４ 配信センタ ３１、５１ ルータ ３２ ミラーサーバ ３３、５３ ストリームサーバ ３４ 衛星回線受信アンテナ ４１ アクセスポイント ４２ 衛星回線送信アンテナ ５２ オリジナルサーバ ５４ 制御サーバ

Claims (22)

【特許請求の範囲】
1. 【請求項１】 オリジナルのファイルを蓄積するルート
   サーバと、このルートサーバからそれぞれオリジナルの
   ファイルのコピーを受け取って蓄積する１以上のリーフ
   サーバとをネットワーク内に備えたファイル配信システ
   ムにおいて、 前記ネットワークは、特定の宛先アドレスが付与された
   パケットをそのアドレスで示されるグループに属する複
   数の宛先に同報配信するマルチキャストプロトコルが利
   用可能なネットワークであり、 前記ルートサーバは、前記マルチキャストプロトコルに
   より、前記１以上のリーフサーバの少なくとも一部に同
   時にファイルを配信するマルチキャストプロトコル処理
   手段を備えたことを特徴とするファイル配信システム。
2. 【請求項２】 前記ルートサーバは、同じデータを複数
   回にわたり前記マルチキャストプロトコル処理手段から
   送信させる手段を含む請求項１記載のファイル配信シス
   テム。
3. 【請求項３】 前記ルートサーバは、配信するファイル
   ごとに前記マルチキャストプロトコル処理手段からのデ
   ータの送出速度を可変に設定する手段を備えた請求項１
   記載のファイル配信システム。
4. 【請求項４】 前記ルートサーバは、 配信するファイルごとに複数段階のいずれかの配信優先
   度を設定する手段と、 ネットワークが許す最大帯域情報を保持し、最上級の優
   先度のファイルには指定された帯域を確保し、下位の優
   先度のファイルと上位の優先度のファイルとが同時に送
   信される場合には、上位の優先度のファイル送信のため
   の帯域を優先的に確保する帯域管理手段とを備えた請求
   項１記載のファイル配信システム。
5. 【請求項５】 前記帯域管理手段は、下位の優先度のフ
   ァイル送信に対して最低保証帯域を設定する手段を含む
   請求項４記載のファイル配信システム。
6. 【請求項６】 前記ルートサーバは、ファイルの送信を
   開始する時間を設定する手段を備えた請求項１記載のフ
   ァイル配信システム。
7. 【請求項７】 前記ルートサーバは、一定時間を越えて
   もファイルの送信が完了しなかった場合にはファイルの
   送信を強制停止する手段を含む請求項１記載のファイル
   配信システム。
8. 【請求項８】 前記ルートサーバは、配信に失敗したフ
   ァイルについて、あらかじめ定められた、またはランダ
   ムに割り当てられた時間が経過した後に、再び前記マル
   チキャストプロトコル処理手段からの配信を開始する手
   段を含む請求項７記載のファイル配転システム。
9. 【請求項９】 前記ルートサーバは、あらかじめ定めら
   れた回数にわたりマルチキャストでの配信に失敗した場
   合には、そのリーフサーバに対して個別に送信する手段
   を含む請求項１記載のファイル配信システム。
10. 【請求項１０】 前記ルートサーバは、配信しようとす
    る複数のファイルを順番に蓄え、前のファイルの配信が
    終了するのを待って、次のファイルを前記マルチプロト
    コル処理手段に渡す配信キューを備えた請求項１記載の
    ファイル配信システム。
11. 【請求項１１】 前記ルートサーバは、それぞれが配信
    しようとする複数のファイルを順番に蓄え、前のファイ
    ルの配信が終了するの待って次のファイルを前記マルチ
    プロトコル処理手段に渡す複数の配信キューを配信優先
    度ごとに備えた請求項４記載のファイル配信システム。
12. 【請求項１２】 前記ルートサーバは、前記配信キュー
    に蓄えられているファイルの順序を変更する手段を備え
    た請求項１０または１１記載のファイル配信システム。
13. 【請求項１３】 前記ルートサーバは、送信するファイ
    ルサイズが大きい場合に、それをあらかじめ定められた
    サイズのブロックに分割する手段を備えた請求項１記載
    のファイル配信システム。
14. 【請求項１４】 前記ルートサーバは、分割されたブロ
    ックにシリアル番号を付加する手段を備え、 前記リーフサーバは、分割されたブロックのシリアル番
    号からそれらの順序を正しく復元する手段を備えた請求
    項１３記載のファイル配信システム。
15. 【請求項１５】 前記ルートサーバは、分割されたブロ
    ックに誤り検出符号とシリアル番号とを付加して複数回
    にわたり前記マルチキャストプロトコル処理手段から送
    信させる手段を含み、 前記リーフサーバは、受信した複数のブロックから誤り
    検出符号の正しいものをシリアル番号順に取り出して一
    つのファイルに組み立てる手段を含む請求項１３記載の
    ファイル配信システム。
16. 【請求項１６】 前記ルートサーバは、指定されたディ
    レクトリの下のファイルを定期的に調べ、前回配信を行
    った時間以降に変更が加えられたファイルあるいは新た
    に追加されたファイルが存在する場合には、それらのフ
    ァイルを配信すべきファイルとして指定する手段を備え
    た請求項１記載のファイル配信システム。
17. 【請求項１７】 前記ルートサーバは、同一のファイル
    を配信する場合であっても、宛先のリーフサーバによっ
    て、マルチキャストで配信するか他のプロトコルで個別
    に配信するかを選択する手段を備えた請求項１記載のフ
    ァイル配信システム。
18. 【請求項１８】 蓄積しているオリジナルのファイルを
    コピーして１以上のリーフサーバに配信する手段を備え
    たファル配信サーバにおいて、 前記配信する手段は、特定の宛先アドレスが付与された
    パケットをそのアドレスで示されるグループに属する複
    数の宛先に同報配信するマルチキャストプロトコル処理
    手段を備えたことを特徴とするファイル配信サーバ。
19. 【請求項１９】 ルートサーバからファイルのコピーを
    受け取って蓄積するリーフサーバにおいて、前記ルート
    サーバからマルチキャストプロトコルにより配信された
    ファイルを受信する手段を備えたリーフサーバ。
20. 【請求項２０】 請求項１ないし１６のいずれか記載の
    ファイル配信システムにおけるルートサーバを実現する
    ためのプログラム。
21. 【請求項２１】 請求項１ないし１６のいずれか記載の
    ファイル配信システムにおけるリーフサーバを実現する
    ためのプログラム。
22. 【請求項２２】 請求項２０または２１記載のプログラ
    ムが記録された記録媒体。