JP2000183873A

JP2000183873A - データ転送方法

Info

Publication number: JP2000183873A
Application number: JP35344298A
Authority: JP
Inventors: Takahiro Aoki; 隆浩青木
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1998-12-11
Filing date: 1998-12-11
Publication date: 2000-06-30
Also published as: US6563822B1

Abstract

(57)【要約】【課題】ネットワークの負担を低減し、受信側端末のバ
ッファの破綻を可能な限り回避するような、再送制御及
びフロー制御を有するデータ転送方法を提供する。【解決手段】同一サブネットＳＮ１内の所定の端末（例
えばＣ１）が、再送要求及び再送データをマルチキャス
トで送出し、該同一サブネットＳＮ１内の該所定の端末
以外の端末（例えばＣ４）が、該サブネット外の端末Ｔ
１に対しては、再送要求及び再送データをユニキャスト
で送出する。また、サーバＳ１が送信するデータの送信
レート及びサービス時間に応じて相手端末（例えばＣ
１）が必要バッファ量を確保したり、サーバＳ１が、相
手端末（例えばＣ１）からのバッファ量の通知を基に送
出レートを変更する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ転送方法に
関し、特にネットワーク上で複数の端末にデータを送信
する場合のデータ転送方法に関するものである。近年、
インターネットやイントラネットなどのネットワークを
利用した様々なサービスが注目されて来ている。例え
ば、ネットワークを使って映像や音声を配信するサービ
スが挙げられる。これらは、ユーザがサーバに蓄えられ
た映像や音声データにアクセスして、自由に視聴できる
サービスである。

【０００２】これらのサービスは通常１対１でデータを
送り合う、ユニキャストというデータ転送方法で行われ
ている。また、複数のユーザに同時にデータを送るサー
ビスもあり、その一例としてマルチキャストがある。以
下に、ユニキャスト及びマルチキャストのそれぞれの動
作を図１７及び１８を参照して説明する。

【０００３】（１）ユニキャスト：図１７ユニキャストでは１対１のデータ送信を行う。すなわち
図１７に示されるように、送信側であるサーバＳ１は送
信相手Ｃ１の固有のアドレス「192.168.100.201」を宛
先にしてデータを送信する。このとき、データは宛先で
ある送信相手Ｃ１に送信される。

【０００４】（２）マルチキャスト：図１８マルチキャストでは、サービス毎にマルチキャスト用の
アドレスを用意しておく。例えば、アドレス「224.1.1.
100」をスポーツ番組用と決めておく。このサービスを
受信したいユーザは「224.1.1.100」というマルチキャ
ストアドレスへ参加することによってデータを受信する
ことができる。

【０００５】送信側であるサーバはユニキャストと同様
に、アドレス「224.1.1.100」に対してデータを送れば
よい。すると、データ送信の過程で必要に応じてデータ
のコピーが作られ、最終的に受信を希望した全ての端末
（Ｃ１及びＣ４）にデータが送られることになる。マル
チキャストではデータを受信する端末が何台あろうと、
サーバによるデータ送出は1回でよいので、ネットワー
ク及びサーバの負担が軽くなるという特徴がある。

【０００６】従って、マルチキャストは、放送のような
サービス形態でスポーツやイベント、講演映像の中継な
どネットワークやサーバに大きな負担を掛ける映像デー
タなどを送る際に大きな効果が期待できる。しかし、マ
ルチキャストにはデータの到着を保証する仕組みがな
い。つまり、サーバはデータを一方的に送るのみで、途
中でデータがロスしたとしても何ら措置が取られない。

【０００７】また、受信側の各端末が映像や音声データ
を消費していくレートと、サーバの送出レートに差があ
ると、受信側端末のバッファがアンダーフローやオーバ
ーフローしてしまう可能性がある。このような観点か
ら、ネットワークでデータを配信する際にロスしたパケ
ットを補償する再送制御と、受信側端末のバッファがオ
ーバーフローやアンダーフローしないように制御するフ
ロー制御とが必要とされる。

【０００８】

【従来の技術】（１）再送制御に関する従来の技術まず送信側端末（例えばサーバ）は、送信パケット中に
パケットデータごとに連続するシーケンス番号を埋め込
む。受信側端末（クライアント）は、シーケンス番号を
調べることでパケットのロスを検出できる。パケットロ
スを検出した受信側端末は、送信側端末にデータの再送
を要求し、送信側端末が要求されたデータを送ることで
データが補償される。

【０００９】（２）フロー制御に関する従来の技術固定レート制御映像や音声データの場合、データの消費レートが予め決
まっているので、送信側端末はそのレートでデータを送
り続ける。例えば、6Mbpsの映像の場合、送信側端末は6
Mbpsのレートでデータを送る。

【００１０】ウィンドウ制御これは、受信側端末がデータを受信する度に、データを
受け取ったという通知と共に自分のバッファの残り容量
を送信側端末に通知する方法である。送信側端末は受信
側端末のバッファの空き容量を基にデータを送る。図１
９に示されるように、受信側端末のバッファに１００Ｋ
Ｂ空きがあるなら、送信側端末は１００ＫＢ送るという
様なことを繰り返す（ＴＣＰで使われている方法）。

【００１１】ＡＣＫベース制御図２０に示されるように、まず、送信側端末は一定のレ
ートでデータを送る。送信側端末の送出レートは実際の
映像や音声の消費レートより若干高めに設定しておく。
すると受信側端末のバッファにはデータが溜まってい
く。受信側端末は自分のバッファが溢れそうなのを検知
したら、バッファが溢れそうだという意味のパケット
（＝ＡＣＫパケット）を送信側端末に送る。このパケッ
トを受け取った送信側端末は一定の時間送出を止めるこ
とで受信側端末のバッファオーバーフローを抑止する。

【００１２】

【発明が解決しようとする課題】（１）再送制御に関す
る問題点上記の従来の再送制御は、ユニキャストのデータ転送に
おいては特に問題はないが、マルチキャストの場合、受
信している端末数を特定することが出来ないため、大量
の再送要求パケットが発生してしまう可能性がある（図
２１参照）。この場合、再送処理だけでなく、その他の
データ転送も出来なくなり、ネットワーク全体に悪影響
が及ぶ可能性もある。

【００１３】（２）フロー制御に関する問題点上記固定レート制御における問題点は、送信側端末の
送出レートが一定であったとしても、送出を続けていく
と受信側端末のバッファの破綻は起こり得るということ
である（図２２参照）。これは、送信側端末と受信側端
末のクロックの進み方の僅かなズレが原因で起こる。例
えば、送信側端末側のクロックでは１時間経過したの
に、受信側端末では、５９分５９秒であったりするため
に発生する。このようなズレは、マルチキャストの場合
も同様に各端末について生じる（図２３参照）。

【００１４】また、上記ウィンドウ制御及びＡＣＫベ
ース制御における共通の問題点としては、以下の３点
が挙げられる。（i）マルチキャストでの利用が考慮されていないウィンドウ制御の場合、複数の受信側端末から異なる
バッファの空き容量が通知された時、どれだけのデータ
を送ればよいのか分からない。また、ＡＣＫベース制御
の場合、最終的に最もバッファの埋まっている受信側
端末のみが制御対象になってしまい、他の受信側端末は
全く考慮されなくなってしまう。

【００１５】（ii）ネットワークディレイに弱いウィンドウ制御の場合、受信側端末から、バッファの
空きを通知するパケットが送信側端末に到着しない限り
送信側端末は次のデータを送ることが出来ない。そのた
めディレイの大きなネットワークではスループット性能
が低下してしまう。

【００１６】ＡＣＫベース制御の場合、ディレイが大
きいネットワークだと、受信側端末からのＡＣＫパケッ
トが送信側端末に着き、送出停止の効果が出る前に受信
側端末のバッファが破綻してしまう可能性がある。つま
り、両者とも大規模なネットワークでの利用には不向き
である。（iii）通信パケットの増加ウィンドウ制御の場合、受信側端末が空きバッファを
通知→送信側端末がデータを送出、という流れになって
いるため、送出パケット数と制御パケット数が比例する
関係になる。

【００１７】ＡＣＫベース制御の場合も送出レート
や、ＡＣＫを受け取っての停止時間によるが、やはり送
出パケット数と制御パケット数は比例する関係になる。
すなわち、送出パケット数が多い程、制御パケット数も
多くなり、フロー制御用に多くのパケットがネットワー
クを流れることになる。従って本発明は、ネットワーク
の負担を低減し、受信側端末のバッファの破綻を可能な
限り回避するような、再送制御及びフロー制御を有する
データ転送方法を提供することを課題とする。

【００１８】

【課題を解決するための手段】〔１〕上記の課題を解決
するため、本発明に係るデータ転送方法は、同一サブネ
ット内の所定の端末が、再送要求及び再送データをマル
チキャストで送出するローカル再送制御ステップと、該
同一サブネット内の該所定の端末以外の端末が、該サブ
ネット外の端末に対しては、再送要求及び再送データを
ユニキャストで送出するグローバル再送制御ステップと
を有することを特徴としている。

【００１９】すなわち、ローカル再送制御ステップで
は、図1に原理的に示す如く、同一サブネットＳＮ１内
の所定の端末Ｃ１が受信データ中にパケットロスを検出
した場合、該端末Ｃ１は、該サブネットＳＮ１内に対し
ては再送要求をマルチキャストパケットとして送出す
る。該サブネットＳＮ１内で再送要求を受け且つ要求
されているパケットを持っている端末Ｃ３は該パケット
を該サブネットＳＮ１内でマルチキャストで再送す
る。

【００２０】また、グローバル再送制御ステップでは、
図２に原理的に示す如く、同一サブネットＳＮ１内の所
定の端末以外の端末、例えば端末Ｃ４が同一サブネット
ＳＮ１外の端末Ｔ１に再送要求を送る場合、該端末Ｃ４
は予め再送要求する相手の端末Ｔ１と（例えばルータＲ
を介して）コネクションを張っておき、この相手端末Ｔ
１との間で再送要求及び再送データをユニキャスト
で送受信する。

【００２１】このようにしてローカル再送制御では、各
端末固有のパケットロスをサブネット内という狭い範囲
内に限定することができ、同じデータを持っている端末
がサブネット内にあるならばサブネット内の要求パケッ
ト、再送パケットのやりとりで再送が完了するため、サ
ーバやネットワークにかかる負荷を大幅に低減すること
ができる。

【００２２】また、グローバル再送制御では、ルータな
どによるパケットロスのようにサブネット内の全端末に
共通してロスしたパケットを、ユニキャストで再送要求
することにより、ネットワーク全体に余分なデータを送
らないようにすることができる。また、グローバル再送
要求を行う相手をサーバだけに限定せずサブネット外の
端末としたことで、サーバの負荷が低減され、大規模な
ネットワークにも対応が可能である。

【００２３】〔２〕また、本発明に係るデータ転送方法
は、上記の本発明〔１〕において、該ローカル再送制御
ステップは、該同一サブネット内の他の端末が再送要求
又は再送データを送出したことを検知したとき、該所定
の端末が該再送要求又は再送データの送出を停止すると
いう条件の下で該マルチキャストを実行することができ
る。

【００２４】すなわち、再送要求も再送データも、他端
末が先に送出していることを検出した場合は、自局は送
出しないという一定の条件の下でローカル再送制御をマ
ルチキャストで行うことにより、転送パケット数の抑制
ができる。〔３〕また、本発明に係るデータ転送方法は、上記の本
発明〔１〕において、該グローバル再送制御ステップ
は、予め固定的に張られたコネクションにより該ユニキ
ャストを実行することができる。

【００２５】すなわちこれは、データ送出の有無に関わ
らず、再送要求を出す端末と再送要求を受ける端末が予
め互いのアドレスを教え合っておくことにより常にコネ
クションを張っておく方法であり、ネットワークの構成
が変化しない場合に有効である。このように、常にコネ
クションを張っておくことによって、コネクション確立
までに時間をかけることなく、必要時には即座に再送制
御を行うことができる。

【００２６】〔４〕また、本発明に係るデータ転送方法
は、上記の本発明〔１〕において、該グローバル再送制
御ステップは、該ユニキャストで使用するコネクション
のアドレスが、データ送出用アドレスとは異なるように
することができる。これは、再送要求を出す端末と再送
要求を受ける端末がダイナミックにコネクションを張る
場合に有効である。この場合、再送要求を受ける端末は
例えばコネクションを募集するパケットをマルチキャス
トでネットワークに送り、コネクションを張りたい端末
がそのコネクション募集のパケットに応じる形でコネク
ションを張ることになる。

【００２７】このときデータ送出用のアドレスを用いて
コネクションの募集及び応募を行う場合、コネクション
を張りたい端末は募集のパケットを該データ送出用のア
ドレスで受信しようとした時点で、該募集のパケット以
外のデータが該データ送出用アドレスに（サーバ等か
ら）送出されていると、このデータを受信してしまう。
すなわち、該端末は必要としないデータまで受信してし
まう可能性がある。

【００２８】従って、コネクション管理用とデータ送出
用の各アドレスを別々にしておくことで、必要のないデ
ータが端末に送られないようにすることができる。〔５〕また、本発明に係るデータ転送方法は、上記の本
発明〔１〕において、該サブネット外の端末をサーバと
することができる。〔６〕また、本発明に係るデータ転送方法は、上記の本
発明〔５〕において、該サーバが送信するデータの送信
レート及びサービス時間に応じて相手端末が必要バッフ
ァ量を確保するフロー制御ステップをさらに備えること
ができる。（以下、この方式を「可変バッファ方式」と
呼ぶことがある。）すなわち、図３に示す如く、各端末がサービス開始前に
送信されるデータのレート及びサービス時間をサーバに
問い合わせる。各端末は、送信されるデータのレート及
びサービス時間に自局で認識している予想クロック誤差
を加味して、必要とされるバッファ量を計算し、確保す
ることでバッファ破綻を回避する。

【００２９】例えば、クロックの誤差を±１００ｐｐｍ
と仮定する。データレート＝６Ｍｂｐｓの映像を２時間
再生するならば、と計算できる。このように、予想されるクロックの誤
差、データのレート、再生時間が分かれば、必要なバッ
ファ量が決まる。そして、各端末が上記のバッファ量を
確保するので、無駄なバッファを廃し、メモリを効率よ
く利用できる。

【００３０】〔７〕また、本発明に係るデータ転送方法
は、上記の本発明〔５〕において、該サーバが相手端末
からのバッファ量の通知を基に送出レートを変更するフ
ロー制御ステップをさらに備えることができる。（以
下、この方式を「可変送出レート方式」と呼ぶことがあ
る。）すなわち、サーバは定められたレート（例えば、６Ｍｂ
ｐｓ）でデータを送出する一方で、例えば定期的に端末
にバッファ状態を問い合わせ、該端末からのバッファ量
の通知を基に送出レートの変更を行う（図４参照）。こ
のレート決定手順について、ユニキャストの場合を例に
挙げて図５により説明する。

【００３１】時間間隔Ｔ'の前後で測定したバッファ量
をそれぞれ、ｂ'、ｂとする。また、その間の送出レー
トをＲ'、また、バッファ量の目標値をβとする。現在
のバッファ量ｂと目標バッファ量βとの差（＝β−ｂ）
を△βと定義する。次の周期Ｔでの送出レートRを下記
の式（１）に従って決定する。

【００３２】

【数１】ここで、ｐ，ｑは０〜１の値をとる任意のパラメータで
ある。そして、式（１）の第１項はバッファを目標値に
近づけるための項目である。つまり目標のバッファ量と
現在のバッファ量の差が△βであるが、△β／Ｔという
項目は次のＴ秒間で差△βを埋めるために必要なレート
を表している。一方、同第２項はバッファを安定させる
力を表している。Ｔ'秒間でバッファがｂ'→ｂと変化し
たため、これを打ち消すためには、（ｂ−ｂ'）／Ｔ'だ
けレートから差し引けばよい。

【００３３】なお、ｐ，ｑを変化させることでレート修
正の性質を変化させることが出来る。ｐが大きいと、目
標値への収束が早くなるが、その分、レートの安定性が
損なわれる。ｑが大きいとバッファは安定するが目標値
への収束には時間がかかる。そのためｐ,ｑは利用され
る環境に応じて決定される。〔８〕また、本発明に係るデータ転送方法は、上記の本
発明〔７〕において、該フロー制御ステップは、該サー
バがマルチキャストによりバッファ量の通知を要求し、
各端末がユニキャストで通知を行うステップを含むこと
ができる。

【００３４】すなわち、サーバがマルチキャストでデー
タを送出する場合には、該サーバはマルチキャストで対
象とする全端末にバッファ量の通知を要求する。該端末
は要求に応じてバッファ量の通知を行う。このとき、ユ
ニキャストで通知を行うことにより、ネットワークの負
担を軽減することができる。なお、マルチキャストで端
末に対して通知要求をする場合、サーバは各端末の総バ
ッファに占める該送出データの割合をレート設定の目標
として、上記の発明〔７〕によるレートを調節する。

【００３５】ｎ番目の端末の通知バッファ総量をＢ_n、
バッファ内のデータ量をｂ_nとする（図６参照）。サー
バの送出レートにより端末のバッファ量が△βだけ増え
たとする。この時の平均バッファ使用率ｗは、

【００３６】

【数２】と表せる。ここから逆に△βを求めると、次式で与えら
れる。

【００３７】

【数３】例えば、平均値として、各端末のバッファが半分だけ埋
まるようにレートを調節したい場合、ｗ＝０．５と指定
する。

【００３８】各端末からの通知を基にして、式（３）か
ら△βを計算し、式（１）から送出レートを計算する。

〔９〕また、本発明に係るデータ転送方法は、上記の本
発明〔６〕又は本発明〔８〕において、該フロー制御ス
テップは、該相手端末について、バッファ量に応じてオ
ーバーフローしそうな端末のグループとアンダーフロー
しそうな端末のグループに分け、各グループに対応した
複数の送出レートでデータを送信するステップを含むこ
とができる。

【００３９】すなわち、可変送出レート方式において
は、サーバは、相手端末からのバッファ量の通知を基
に、バッファがオーバーフローしそうな端末のグループ
とアンダーフローしそうな端末のグループに分け、それ
ぞれのグループのバッファ量の平均値に対応した送出レ
ートで各グループの端末に送信データを分けてマルチキ
ャストを実行する。

【００４０】また、可変バッファ方式においては、予め
予想された時間よりも長い時間のサービスを行う必要が
生じた場合に、新たな送出レートを使用してデータ送出
を行う。複数の送出レートを使用することで、サーバ及
びネットワークの負荷は増えるが、相手端末のバッファ
破綻までの時間を延ばすことが出来る。

【００４１】〔１０〕また、本発明に係るデータ転送方
法は、上記の本発明〔５〕において、該サーバからデー
タを受信する端末である相手端末が自局のクロックと該
サーバのクロックとを同期させるフロー制御ステップを
さらに備えることができる（クロック同調方式）。すな
わち、本発明は端末のクロックをサーバのクロックの進
み方に合わせるものである。サーバはある時間間隔（一
定でなくて構わない）で対象の端末に対して、「同期化
パケット」を送る。このパケットには、サーバ自身の現
在時刻（あるいは起動してからの時刻）を入れておく。
あるいはデータパケット中にサーバの時刻を埋め込んで
もよい。

【００４２】このパケットを受け取った端末は、受け取
った時の自局の時刻（あるいは起動してからの時刻）と
ともにサーバ自身の現在時刻（あるいは起動してからの
時刻）を記録しておく。この操作を何度か繰り返し、プ
ロットすると図７のようになる。このプロットされた点
を最小二乗法などで直線近似する。

【００４３】Ｔ_s＝ａＴ_c＋ｂ・・・式（４）ただし、Ｔ_sはサーバの時刻、Ｔ_cは端末の時刻である。
上式のａがサーバと端末のクロックの進み方の違いを表
している。端末側で映像や音声をデコードする際には、
サーバから受けた時刻により上記の式（４）に従った時
刻を求めて使う。

【００４４】〔１１〕また、本発明に係るデータ転送方
法は、上記の本発明〔１０〕において、該フロー制御ス
テップとして、該相手端末がサービス開始前に予め該ク
ロックの同期を取ることができる。すなわち、サーバが
上記「同期化パケット」をサービスの有無とは別に送出
しておくことにより、端末がサービス開始前に予め該ク
ロックの同期を取ることができる。これにより、サービ
ス開始直後の誤差が小さくなる。

【００４５】〔１２〕また、本発明に係るデータ転送方
法は、上記の本発明〔１１〕において、予め該クロック
の同期を取るために、該サーバが自局からの時刻通知パ
ケットをデータ送出用アドレスとは異なるアドレスを用
いて該相手端末に通知することができる。すなわち、サ
ーバが上記「同期化パケット」の送出をデータ送出アド
レスと異なるアドレスを用いて行う。これにより、サー
ビスが行われていない端末やネットワークに余計なデー
タが送られなくて済む。

【００４６】

【発明の実施の形態】（１）再送制御に関する実施例本発明に係るデータ転送方法における再送制御の動作を
図８に示すシステム構成例を参照して以下に説明する。
なお同図では、ローカル再送制御とグローバル再送制御
を組み合わせたネットワーク全体での再送制御が例示さ
れている。また、同図においてサーバＳ１は、サブネッ
トＳＮ１〜ＳＮ６をそれぞれ構成する端末（クライアン
ト）Ｃ１〜Ｃ６に対しマルチキャストでデータを送信し
ているものとする。

【００４７】まず、各サブネットＳＮ１〜ＳＮ６内で
は、所定の端末がローカル再送制御を行えるように設定
されている。例えば、サブネットＳＮ１，ＳＮ２，ＳＮ
５，及びＳＮ６における端末Ｃ２及びＣ３、並びにサブ
ネットＳＮ３及びＳＮ４における端末Ｃ１及びＣ３はロ
ーカル制御を行うことができ、これらの端末がパケット
ロスを検出した場合は、再送要求及び再送データをマル
チキャストで送出するものとして予め設定されている。

【００４８】また、それぞれのサブネット内で上記所定
の端末以外の端末はグローバル再送制御を行えるように
設定されている。例えば、サブネットＳＮ１，ＳＮ２，
ＳＮ５，及びＳＮ６における端末Ｃ１、並びにサブネッ
トＳＮ３及びＳＮ４における端末Ｃ２はグローバル再送
制御を行うことができ、これらの端末がパケットロスを
検出した場合は、サブネット外の端末（サーバを含む）
に対して再送要求及び再送データをユニキャストで送出
するものとして予め設定されている。

【００４９】次に、ローカル再送制御においては、例え
ばサブネットＳＮ１における端末Ｃ２がNo.100のデータ
のロスを検出したとき、この端末Ｃ２は、このデータに
ついて再送要求をマルチキャストで端末Ｃ１及びＣ３に
対して送出する。ただし、同じくNo.100のデータのロス
を検出した端末Ｃ３が端末Ｃ２よりも先に再送要求を送
出しているときには、端末Ｃ３による再送要求がマルチ
キャストで既に送出されているため、端末Ｃ２はNo.100
のデータについての再送要求が成されたことを検知する
ことができ、自局から同一の再送要求を送出するのを控
える。同様に、再送データの送出についても重複送出を
避けることができる。

【００５０】一方、グローバル再送制御においては、例
えばサブネットＳＮ１の端末Ｃ１がパケットロスを検出
したとき、この端末Ｃ１は予め固定的にコネクションを
張っていたサーバＳ１に対してグローバル再送要求を行
い、これに応答してサーバＳ１は当該データを該端末Ｃ
１に再送する。ここで、再送要求を出す端末と再送要求
を受ける端末が、固定的ではなくダイナミックにコネク
ションを張ることも可能である。この場合、図９に示す
如く、コネクション管理用とデータ送出用で同じアドレ
ス「224.1.1.40」を用いると、サービスを受けていない
端末であっても、コネクションを張るためにアドレス
「224.1.1.40」に参加しているため、データが送出され
てしまう可能性がある。

【００５１】そこで、図１０に示す如く、コネクション
管理用とデータ送出用で異なるアドレスを用いることが
望ましい。この例では、コネクション管理用にアドレス
「224.1.1.50」を使用し、データ送出用にアドレス「22
4.1.1.40」を使用しているが、サービスを受けていない
端末はコネクション管理用アドレス「224.1.1.50」には
参加しているが、データ送出用にアドレス「224.1.1.4
0」には参加していないので、データは送られて来な
い。

【００５２】（２）フロー制御に関する実施例図１１は、本発明に係るデータ転送方法におけるフロー
制御のシステム構成例を示したものである。管理サーバ
Ｓ１０は、記憶装置１０、テープ装置２０、及びカメラ
・マイク等３０が接続されたデータ送出サーバＳ２０が
所定の送信レート及びサービス時間でデータ送出を行う
ように制御している。そこで、各端末（クライアント）
Ｃ１〜Ｃ４は、管理サーバＳ１０に対しデータの送信レ
ート及びサービス時間を問い合わせ、これに基づいて必
要バッファ量を確保してからサービスを受ける。

【００５３】一方、本発明に係るデータ転送方法におけ
るフロー制御では、サーバ側から各端末に対してバッフ
ァ量の状況を要求してもよく、この場合の手順が図１２
に示されている。まず、マルチキャスト環境では相手端
末が不特定なため、通知パケットがネットワークで衝突
する可能性がある。これを回避するためには、各端末が
ランダムな時間に自己のバッファ量を通知すればよい。

【００５４】具体的には、サーバは、モニター開始時間
（１）、モニター時間（２）、及び通知最大待ち時間
（３）の情報を含んだバッファ量通知要求パケットを送
る。各端末は、このバッファ量通知要求パケットを受信
した後、モニター開始時間（１）が経過した後にバッフ
ァ量の１回目の記録を行う。これは式（１）における
ｂ'に相当する。次に、モニター時間（２）が経過した
後にバッファ量の２回目の記録を行う。これは式（１）
におけるｂに相当する。さらに、０から通知最大待ち時
間（３）が経過するまでのランダムの時間だけ待機した
後にバッファ量通知パケットを送出する。

【００５５】サーバは、各端末から受信したバッファ量
通知パケットの内容に基づき、式（3）及び式（1）を用
いて目標バッファ量を得るための送出レートを算出した
後、送出レートを変更する。なお、図１３はサーバがデ
ータの送出レートを制御しない場合の各端末Ｃ１〜Ｃ４
のバッファ量の推移をグラフに示したものであり、図１
４はサーバが各端末Ｃ１〜Ｃ４からのバッファ量の通知
を基に送出レートを制御した場合の各端末のバッファ量
をグラフに示したものである。

【００５６】図１３と図１４を比較すると送出レートを
制御した図１４の方がバッファ上限に達するバッファ破
綻までの時間を延ばすことが可能であることが分かる。
また、サーバと各端末のクロックのズレが正規分布して
いると仮定した場合、送出レートの制御無しの図１５
（１）と、送出レートを制御した同図（２）を比較する
と、サーバが各端末からのバッファ量の通知を基に送出
レートを制御することにより、最悪時のクロックのズレ
が半分になるという効果が得られる。

【００５７】ただし、上記のフロー制御を行ってもサー
ビスを行って行くにつれ、図１６（１）に示す如く各端
末のバッファ量に差が出て来る。そこで、バッファが破
綻する前に、オーバーフローしそうな端末のグループ
（端末Ｃ１及びＣ２）（同図（２）参照）とアンダーフ
ローしそうな端末のグループ（端末Ｃ３及びＣ４）（同
図（３）参照）に分けて、サーバが各グループに適する
送出レートでデータを送信してもよい。

【００５８】

【発明の効果】以上説明したように、本発明に係るデー
タ転送方法によれば、同一サブネット内の所定の端末
が、再送要求及び再送データをマルチキャストで送出
し、該同一サブネット内の該所定の端末以外の端末が、
該サブネット外の端末に対しては、再送要求及び再送デ
ータをユニキャストで送出するように構成したので、サ
ーバやネットワークへの負担を大幅に軽減できる。ま
た、サーバが送信するデータの送信レート及びサービス
時間に応じて相手端末が必要バッファ量を確保したり、
サーバが、相手端末からのバッファ量の通知を基に送出
レートを変更するフロー制御ステップを実行すれば受信
側の無駄なバッファを廃し、バッファの破綻を可能な限
り回避することができる。

【図面の簡単な説明】

【図１】本発明に係るデータ転送方法におけるローカル
再送制御の動作説明図である。

【図２】本発明に係るデータ転送方法におけるグローバ
ル再送制御の動作説明図である。

【図３】本発明に係るデータ転送方法におけるフロー制
御による可変バッファ方式の説明図である。

【図４】本発明に係るデータ転送方法におけるフロー制
御による可変送出レート方式の説明図（１）である。

【図５】本発明に係るデータ転送方法におけるフロー制
御による可変送出レート方式の説明図（２）である。

【図６】本発明に係るデータ転送方法における端末のバ
ッファ量を説明するための図である。

【図７】本発明に係るデータ転送方法におけるサーバ時
刻と端末時刻の関係を示したグラフ図である。

【図８】本発明に係るデータ転送方法における再送制御
のシステム構成例を示したブロック図である。

【図９】本発明に係るデータ転送方法におけるグローバ
ル再送制御を行うためにコネクション管理用とデータ送
出用で同じアドレスを用いた場合の動作説明図である。

【図１０】本発明に係るデータ転送方法におけるグロー
バル再送制御を行うためにコネクション管理用とデータ
送出用で異なるアドレスを用いた場合の動作説明図であ
る。

【図１１】本発明に係るデータ転送方法におけるフロー
制御のシステム構成を示したブロック図である。

【図１２】本発明に係るデータ転送方法におけるフロー
制御によるバッファ量の通知を示したタイムチャート図
である。

【図１３】レート制御しない場合の各端末におけるバッ
ファ量の推移を示したグラフ図である。

【図１４】本発明に係るデータ転送方法におけるフロー
制御によってレート制御した場合の各端末におけるバッ
ファ量の推移を示したグラフ図である。

【図１５】本発明に係るデータ転送方法におけるフロー
制御によるレート制御の効果を説明するためのグラフ図
である。

【図１６】本発明に係るデータ転送方法におけるフロー
制御によるグループ化を説明するためのグラフ図であ
る。

【図１７】一般的なユニキャストの動作説明図である。

【図１８】一般的なマルチキャストの動作説明図であ
る。

【図１９】従来例におけるウインドウ制御によるフロー
制御の動作説明図である。

【図２０】従来例におけるＡＣＫベース制御によるフロ
ー制御の動作説明図である。

【図２１】従来例における再送要求時のパケット衝突例
を説明するための図である。

【図２２】ユニキャストにおける端末のバッファ量の変
化を示したグラフ図である。

【図２３】マルチキャストにおける各端末のバッファ量
の変化を示したグラフ図である。

【符号の説明】

Ｃ１〜Ｃ４端末（クライアント）ＲルータＴ１サーバまたは端末ＳＮ１〜ＳＮ６サブネットＳ１サーバＳ１０管理サーバＳ２０データ送出サーバ１０記憶装置２０テープ装置３０カメラ、マイク等図中、同一符号は同一又は相当部分を示す。

フロントページの続きＦターム(参考） 5B089 GA11 GA18 GB01 JA07 JA33 JB04 JB11 JB22 KA07 KB06 KC23 KC29 KD01 KE09 MA01 MA03 5K030 HA08 HB12 HB15 KA06 KA08 LA01 LA15 LB20 LC01 LD06 LD18 5K033 AA03 AA07 CB03 CB06 CB13 CB15 DB16 5K034 AA02 AA09 BB07 DD02 EE11 HH09 LL01 NN22

Claims

【特許請求の範囲】

【請求項１】同一サブネット内の所定の端末が、再送要
求及び再送データをマルチキャストで送出するローカル
再送制御ステップと、該同一サブネット内の該所定の端末以外の端末が、該サ
ブネット外の端末に対しては、再送要求及び再送データ
をユニキャストで送出するグローバル再送制御ステップ
と、を有することを特徴とするデータ転送方法。
【請求項２】請求項１において、該ローカル再送制御ステップは、該同一サブネット内の
他の端末が再送要求又は再送データを送出したことを検
知したとき、該所定の端末が該再送要求又は再送データ
の送出を停止するという条件の下で該マルチキャストを
実行するステップを含むことを特徴としたデータ転送方
法。
【請求項３】請求項１において、該グローバル再送制御ステップは、予め固定的に張られ
たコネクションにより該ユニキャストを実行するステッ
プを含むことを特徴としたデータ転送方法。
【請求項４】請求項１において、該グローバル再送制御ステップでは、該ユニキャストで
使用するコネクションのアドレスがデータ送出用アドレ
スと異なることを特徴とするデータ転送方法。
【請求項５】請求項１において、該サブネット外の端末がサーバであることを特徴とする
データ転送方法。
【請求項６】請求項５において、該サーバが送信するデータの送信レート及びサービス時
間に応じて相手端末が必要バッファ量を確保するフロー
制御ステップをさらに備えたことを特徴とするデータ転
送方法。
【請求項７】請求項５において、該サーバが、相手端末からのバッファ量の通知を基に送
出レートを変更するフロー制御ステップをさらに備えた
ことを特徴とするデータ転送方法。
【請求項８】請求項７において、該フロー制御ステップは、該サーバがマルチキャストに
よりバッファ量の通知を要求し、各端末がユニキャスト
で通知を行うステップを含むことを特徴としたデータ転
送方法。
【請求項９】請求項６又は請求項８において、該フロー制御ステップは、該相手端末について、バッフ
ァ量に応じてオーバーフローしそうな端末のグループと
アンダーフローしそうな端末のグループに分け、各グル
ープに対応した複数の送出レートでデータを送信するス
テップを含むことを特徴としたデータ転送方法。
【請求項１０】請求項５において、該サーバからデータを受信する端末である相手端末が自
局のクロックと該サーバのクロックとを同期させるフロ
ー制御ステップをさらに備えたことを特徴とするデータ
転送方法。
【請求項１１】請求項１０において、該フロー制御ステップは、該相手端末がサービス開始前
に予め該クロックの同期を取るステップを含むことを特
徴としたデータ転送方法。
【請求項１２】請求項１１において、該フロー制御ステップは、予め該クロックの同期を取る
ために、該サーバが自局からの時刻通知パケットをデー
タ送出用アドレスとは異なるアドレスを用いて該相手端
末に通知することを特徴とするデータ転送方法。