JP2004080070A - データ転送方法及びデータ転送システム並びにコンテンツ配信システム - Google Patents
データ転送方法及びデータ転送システム並びにコンテンツ配信システム Download PDFInfo
- Publication number
- JP2004080070A JP2004080070A JP2002233363A JP2002233363A JP2004080070A JP 2004080070 A JP2004080070 A JP 2004080070A JP 2002233363 A JP2002233363 A JP 2002233363A JP 2002233363 A JP2002233363 A JP 2002233363A JP 2004080070 A JP2004080070 A JP 2004080070A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- data packet
- acknowledgment
- terminal device
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
【課題】上位のアプリケーションに対してTCPと同様な高い信頼性と高速データ転送サービスを極めて小さなオーバーヘッドで実現するデータ転送方法及びシステムを実現する。
【解決手段】送信側の端末装置(1)は、送信すべきデータパケットを作成し、パケット単位のシーケンス番号を付加してネットワークに送信するパケット送信手段(10)と、受信側の端末装置からの確認応答に基づいてデータパケットの送信速度を制御するフロー制御手段(15)と、フロー制御手段からの出力に応じてパケット送信速度を設定するシェーピング手段(11)とを具え、受信側の端末装置(3)は、受信したデータパケットを蓄積する主記憶装置(12)と、受信したデータパケットの確認応答を受信データパケットの受信速度から独立した一定の周期で送信側端末装置に返送する確認応答送信手段(13)とを具えることを特徴とする。
【選択図】 図3
【解決手段】送信側の端末装置(1)は、送信すべきデータパケットを作成し、パケット単位のシーケンス番号を付加してネットワークに送信するパケット送信手段(10)と、受信側の端末装置からの確認応答に基づいてデータパケットの送信速度を制御するフロー制御手段(15)と、フロー制御手段からの出力に応じてパケット送信速度を設定するシェーピング手段(11)とを具え、受信側の端末装置(3)は、受信したデータパケットを蓄積する主記憶装置(12)と、受信したデータパケットの確認応答を受信データパケットの受信速度から独立した一定の周期で送信側端末装置に返送する確認応答送信手段(13)とを具えることを特徴とする。
【選択図】 図3
Description
【0001】
【発明の属する技術分野】
本発明は、端末間で広帯域かつ信頼性のあるデータ転送を行うためのデータ転送方法及びシステム、並びにこのデータ転送方法を利用したコンテンツ配信システムに関するものである。
【0002】
【従来の技術】
近年、高速ネットワーク転送技術が安価に入手できるようになってきた。今後、一般家庭の端末においても1Gbpsのような超高速インターフェイスが急速に普及すると考えられる。また、ネットワークの高速化と歩調を合わせて、高速ネットワークを介して送受信されるコンテンツも従来のWebコンテンツに代わって、音声や動画等の大容量容コンテンツが急速に増加している。したがって、高速ネットワークの性能を最大限に引き出して、大容量のコンテンツを高速に端末間で交換できることが強く求められている。
【0003】
通常のコンテンツを配信する際のトランスポート層のプロトコルとして、現在のインターネットにおいてはTCPとUDPという2通りの方式が主に利用されている。TCPでは、揖失パケットの再送機能や順序逆転パケットの整列機能を有しており、上位のアプリケーションに対して、信頼性の高いストリーム型のサービスを提供する。一方、UDPは、損失パケットの再送機能や順序逆転パケットの整列機能は持たず、上位のアプリケーションに対して、信頼性の低いデータグラム型のサービスを提供する。これら2つのプロトコルは、利用目的に応じて最適な方式が利用されている。
【0004】
さて、ネットワークを介してやり取りされる音声や動画等の大容量コンテンツは、MPEG2等のさまざまな方式で圧縮(エンコード)されている。このような圧縮方式に共通していえることは、データの部分的な喪失や誤りが存在するとコンテンツの品質に大きな影響を与える、ということである。これはデータが時間軸方向や空間軸方向に庄縮されているため1箇所の誤りによって、これら時間軸方向や空間軸方向の他のデータに対しても影響を与えてしまうためである。インターネットは一般にベストエフォート型であり、データの到達性や遅延時間、到着順序に関する保証を行わない。したがってインターネットを介して前記の様なコンテンツの転送を行う場合には、データの損失、遅延、順序逆転に対する特別な配慮が必要となる。そのための方法として現在利用されている方式は、大きく2つの方向性をもつ。
【0005】
一つはダウンロード型と呼ばれるもので、エンコード方式には手を加えずに、信頼性の高いトランスポート層の機能を用いてデータを転送する方式である。データ転送途中に発生したデータのロスや誤りは、トランスポート層において回復されるため、アプリケーション層のエンコードやデコードの際に、エラー訂正等の特別な仕組みを必要としない。このような目的で、インターネットで一般に利用されているトランスポート層は、TCP(Transport Control Protocol)と呼ばれるプロトコルである(RFC793)。TCPを利用することによって、アプリケーション層は実装を単純化することができる反面、トランスポート層において複雑な処理を行う必要がある。コンテンツの転送においてダウンロード型を利用できるのは、映画などの蓄積可能なコンテンツである。
【0006】
一方、コンテンツを転送するもうひとつの方向性としてストリーム型と呼ばれるものがある。信頼性の低い(誤り訂正機能を持たない)トランスポート層を利用してデータを転送する代わりに、誤り訂正等の機能をアプリケーション層やプレゼンテーション層に実装する方式である。トランスポート層が単純な処理ですむ反面、アプリケーション層ではエンコードやデコードの際に、誤りの影響を最小限に抑えるために数多くの複雑な処理が要求される。このようなストリーム型のデータ転送に一般に利用されているトランスポート層のプロトコルはUDP(User Datagram Protocol)と呼ばれている(RFC768)。UDPはパケットの喪失や順序逆転に対する再送機能や再配列機能を持たず、上位層に対してベストエフォート型のパケット転送サービスを提供する。アプリケーションの実装が複雑になるが、前記のダウンロード型と異なり、データの損失や遅延に対してアプリケーションやコンテンツに特化した処理を、アプリケーション層で独自に行うことが可能となる。コンテンツの転送においてストリーム型を利用するのは、主として生中継のようにリアルタイム性が要求されるコンテンツや、マルチキャストのように非常に多数のクライアントに対する同報通信の場合などである。前者ではパケットの再送による遅延が問題となるために、再送制御機能のないUDPを利用している。後者では、クライアントの数が非常に多くなった場合に、クライアント単位で再送制御を行うとサーバーに負荷がかかるため再送制御機能のないUDPを利用している。いずれにしてもUDPを利用した通信では、コンテンツの品質よりもリアルタイム性や同時視聴可能数が重視されている。
【0007】
先に述べたように、音声や動画等のコンテンツはデータの誤りに対して品質の劣化が著しい。前記2つの方式の特徴から言えることは、蓄積可能なコンテンツをインターネット経由で転送する場合には、TCPのように誤り訂正機能を持つ方式を利用するほうが望ましい、ということである。特に近年のコンテンツの大容量化は、画像の解像度やフレーム数など品質の向上を目指した結果であり、今後ますます信頼性の高い広帯域転送方式が必要になると考えられる。
【0008】
【発明が解決しようとする課題】
しかしながら、以上に述べたようなTCPを利用する方式は、今後必要とされる高速転送においてもそのままで適用できるわけではない。ネットワークの帯域幅やプロセッサの処理能力が向上した際に課題となる点は、次のとおりである。
1. 細かなチューニングの課題:TCP等のトランスポート層のプロトコルは、通常OS(オペレーティングシステム)のカーネル領域に実装されるため、一般のアプリケーションプログラムからは、詳細な部分を制御できない。特にTCPのACK(確認応答)を返信する頻度や再送までのタイムアウトの長さなどは、動画再生等のアプリケーションに対して大きな影響を与えるが、これらをアプリケーションから直接利御するのは困難である。
2. ACKによるオーバーヘッド:TCPでは2つのデータパケットの受信に対して、1つのACK(確認応答)パケットが返信される。しかし、高速転送時には次のような問題を招く。通常の端末では、パケットを受信するたびにプロセッサに割り込みが発生するが、これによって2パケットに1回は送・受信処理が中断される。また、頻繁なACKパケットの送受信はI/0バスの競合による使用効率の低下を招く。さらにACKによるネットワーク帯域の消費も無視できない。たとえばEthernet(登録商標)を利用して1Gbpsのデータ送信速度を得るためには、50Mbpsもの確認応答パケットの帯域が必要である。すなわちデータの送信帯域が確認応答の帯域によって影響を受ける、という課題もある。
【0009】
ウィンドウサイズの制限:TCPの転送速度を向上する手法として、ウィンドウサイズを操作する方法がよく利用されるが、ネットワークの帯域は、端末の環境や接続先によって、数kbps〜数百Mbpsまで大きく変化するため、あらゆる場合に通用する最適なウィンドウサイズは一意には決められない。たとえば、遅延の大きな高速リンクに最適化されたウィンドウサイズを低遅延の低速リンクで使用すると、パケット損のために極端に転送速度が劣化する場合がある。また、TCPではウィンドウサイズ内のパケットに対する送信速度調節機構がなくバースト的にトラフィックが送信されるため、受信側での取りこぼしや、ネットワークの不安定さを招く場合がある。
【0010】
本発明はこのような課題を解決するためのものであり、上位のアプリケーションに対してTCPと同様の高い信頼性と高速なデータ転送サービスを、非常に小さなオーバーヘッドで実現する方法および装置を提供することを目的としている。
【0011】
【課題を解決するための手段】
本発明にかかるパケット転送方法は、以下の各項目を達成することによって、前記目的を達成する。
1.アプリケーションソフトウェアとして実装
2.確認応答帯域の削減
3.送信端末からの送信時のシェーピングと速度の自動調節
【0012】
上記各項目の実現手段の詳細は以下のとおりである。
1.アプリケーションソフトウェアとして実装
トランスポート層のプロトコルとしてUDPを利用し、エラー訂正機能・再送制御機能・フロー制御機能等の信頼性を確保するために必要な機能を、アプリケーションソフトウェアのライブラリとして実装可能である。これにより、専用ハードウェアやデバイスドライバを必要としないため、低コストな実装が可能となる。また、TCPは通常オペレーティングシステムの内部で動作するため、ウィンドウサイズや再送頻度等のパラメータをアプリケーションから簡単に変更することが困難であったが、ライブラリとして実装することにより、これらのパラメータをアプリケーションから簡単に変更することが可能となる。これによって、従来技術の課題の1.を解決することができる。
【0013】
2.確認応答帯域の削減
確認応答パケットの送出をデータパケットの受信とは独立に行うことができる。また、単一の確認応答パケットで複数のデータパケットに対する確認応答情報を送信することができる。これらにより確認応答帯域の送受信頻度帯域ともに大幅に削減することが可能となる。たとえば、以下で説明する実施例において、10ミリ秒に1回確認応答をする場合に、TCPと比較して最大1000分の1程度にまで確認応答パケットの帯域を削減することができる。また、これに伴ってI/0バスの競合も最小限に抑えることができるため、前記従来技術の課題の2.を解決することができる。
【0014】
3.送信端末からの送信時のシェーピングと速度の自動調節
送信端末側ではデータパケットの送信時にシェービングを行うことができる。
これによってTCPのウィンドウサイズによる速度調節機構で問題であった、バースト的なトラフィックの流出を防ぎ、同時に所望の帯域を即座に得ることができる。これによって、前記従来技術の課題の3.を解決することができる。
【0015】
次に、確認応答の周期の独立性と送信速度制御機能との相乗効果について説明する。従来のTCPのフロー制御方式においては、送信速度を適切な値に調節するために「ウインドウ」の概念が用いられている。ウインドウは、受信端末からの確認応答を受け取ることなく送信することができるデータ量を意味する。受信端末から確認応答を受信すると、その分ウインドウの位置がスライドして次のデータを送信することができるようになる。このウインドウを用いるシステムでは、ウインドウの幅を調節することにより送信帯域は間接的に制御される。また、データの送信のためには、常時古いデータについて確認応答する必要がある。
これに対して、本発明による送信帯域を直接制御する方式では、「送信速度が受信速度に応じて制御される」ため、言い換えると、「送信端末側のシェーピング手段により、送信帯域を制御している」ため、必ずしも常に確認応答を送受信する必要はない。たとえ送信帯域が超過したとしても、送信されなかったパケットを
後で再送することができる。このことから、結果的に「確認応答の周期を受信速度から独立」させることができ、その結果として受信側端末から送信側端末への確認応答の帯域を節約することができる効果が達成される。これに派生して、TCPにおいて問題となっているバースト的なトラフィックの送信やウインドウサイズのチューニングの必要性といった問題が解消し、しかも、I/Oバスにおける競合やスループットの低下が解消される効果が達成される。
【0016】
【発明の実施の形態】
以下では、本発明の1つの実施形態を図により説明する。
図1は、従来のTCPを利用したデータ転送における、送受信端末間のパケットの流れを示したものである。時間軸は垂直方向に上から下へ向かっている。図中左側の送信端末から同じく右側の受信端末へ向けてデータパケットP21が送信され、これに対して受信端末から送信端末へ確認応答パケットP22が返信される。TCPでは、パケットロスや順序逆転のない定常状態においては、図に示すように2つのデータパケットに対して1つの確認応答パケットが返信される。確認応答パケットの送信頻度はデータパケットの受信頻度に比例するため、高速通信時には、先に述べたような問題が発生する。
【0017】
図2は、本発明に従うシステムにおける、送受信端末間のパケットの流れを時系列的に示したものである。時間軸は垂直方向に上から下へ向かっている。図の左側の送信端末から同じく右側の受信端末へ向けてデータパケットP31が送信され、これに対して受信端末から送信端末へ確認応答パケットP32が周期的に返信される。本発明に従うシステムでは、データパケットの受信頻度とは独立に、定期的に確認応答を返信する。
【0018】
図3は、本発明によるデータ転送システムの一例の構成を示す線図である。送信側端末装置1と受信側端末装置2とが、パケット転送ネットワーク3を介して接続されている。これら端末装置、すなわちパケット送受信装置は、例えば種々の情報やデータを配信するサーバ、通信機能を有するパーソナルコンピュータ、携帯型情報端末、或いは携帯電話とすることができる。従って、例えば、コンテンツ配信サーバと携帯型端末装置又はパーソナルコンピュータとの間のデータやコンテンツの配信、携帯型端末装置間のデータの送受信、携帯型端末装置とパーソナルコンピュータとの間のデータの送受信に本発明を適用することができる。尚、図面上2つの端末装置だけを図示したが、複数の端末装置がパケット転送ネットワーク3に接続されているものとする。
【0019】
データパケットはパケット転送ネットワーク3を介して送信側の端末装置1から受信側の端末装置2へ向けて転送され、これに対する確認応答パケットが受信側端末装置2から送信側端末装置1へ向けて転送される。送信側端末装置1においては、送信手段10において送信するデータを選択し、選択したデータ基づいてデータパケットを作成し、パケット単位のシーケンス番号を付与する。次にシェーピング手段11において送信速度を適切に調節し、パケット転送ネットワーク3へ送信される。一方、受信側端末装置2では、パケット受信手段(図示せず)を介して受信したデータパケットを蓄積手段(主記憶装置)12において蓄積するとともに、確認応答手段13で受信したパケットのシーケンス番号をチェックし、確認応答パケットを作成してパケット送信手段(図示せず)を介してパケット転送ネットワーク3に送信する。その際、確認応答パケットを送信するタイミングを測定するために計時手段14を利用することができる。また、受信速度計測手段(図示せず)を設け、受信したデータパケットの受信速度を計測し、その計測結果を確認応答手段13に供給する。そして、確認応答手段13は、計測された受信速度情報を確認応答に含めることができる。さらに、図6に示す確認応答に含まれる各種のデータ又は情報を作成手段(図示せず)を有し、これらのデータ又は情報は確認応答パケットに含ませることができる。
【0020】
送信された確認応答パケットはパケット転送ネットワーク3を介して送信側端末装置1へ転送される。送信側端末装置1で受信された確認応答パケットは、フロー制御手段15および再送制御手段16で使用される。フロー制御手段15では、確認応答パケットの内容からパケット損率を計算し、データパケットの送信速度の調節にフィードバックを行う。再送制御手段16では、確認応答パケットの内容から再送が必要なパケットを特定し、送信手段10における送信内容に反映する。
【0021】
尚、図3に示す実施例において、各端末装置は、送信側のデータ送信機能及び受信側のデータ受信機能の両方の機能を有する端末装置とすることができ、或いは送信側の機能又は受信側の機能だけを有する端末装置とすることもできる。
【0022】
図4は、図3に示すデータ転送システムにおいて、特にフィードバック制御の動作を説明したものである。本システムは2つのフィードバックループを構成する。すなわち、送信内容フィードバックループLOlと送信速度フィードバックループLO2である。送信内容フィードバックLOlは、確認応答に含まれる受信されなかったパケットのシーケンス番号に基づいて、パケットロスやエラーパケットを再送し、上位のアプリケーションに対してエラーのないデータを渡すためのものである。送信速度フィードバックLO2は、確認応答に含まれる受信側端末装置の受信速度情報に基づいて、ネットワークの利用効率を高め、かつパケットの再送を減らすために最適な送信速度を得るためのものである。
【0023】
送信内容フィードバックLOlには、送信手段10、シェーピング手段11、パケット転送ネットワーク3、確認応答手段13、再送制御手段16が含まれる。送信手段10は、シーケンス番号どおりのパケット送信のほかに、再送制御手段16からの指示にもとづいて、すでに送信したパケットも再送信する。シェーピングはパケットの送信内容にかかわらずすべてのパケットに対して同一のシェーピングを行うことも可能であるが、再送パケットは初回のパケットとは異なるポリシーにもとづいてシェーピングを行ってもよい。シェーピングされたパケットは、パケット転送ネットワーク3において、遅延やロスなどの変化を受けた後、確認応答手段13においてエラーやシーケンス番号内容がチェックされ、確認応答パケットが返送される。再送制御手段16では、確認応答パケットの内容により再送が必要なパケットを決定し、送信手段10に再送の指示を出す。
【0024】
送信速度フィードバックLO2には、シェーピング手段11,パケット転送ネットワーク3、確認応答手段13、フロー制御手段15が含まれる。フロー制御手段15は、確認応答に含まれる受信側端末装置の受信速度情報に基づいてデータパケットの送信速度を調整する機能を有する。シェーピング手段11は、フロー制御手段15からの指示にもとづいて、パケットの送信速度を調節する。パケット転送ネットワークNOlが、ベストエフォート型のネットワークの場合、送信されたパケットは他のトラフィックと合流し、時々刻々変化する遅延やパケットの損失が発生する。パケット転送ネットワーク3を通過したパケットの内容は確認応答手段13でチェックされ、先の送信内容フィードバックLOlにおいて利用されたものと同一のパケットを使ってフロー制御手段15へフィードバックされる。フロー制御手段15では、パケットのロス率や再送回数又は受信側でのパケット受信速度などから、最適な送信速度を決定し、シェーピング手段11対して指示を与える。すなわち、ロス率や再送回数が高い場合や、確認応答パケットが受信されない場合には、シェーピング速度を低く設定し、逆にロス率や再送回数が低い場合には、シェーピング速度を高く設定する。以上の制御により、信頼性の高いデータ転送を最適な速度で実現できる。
【0025】
フロー制御手段15における送信速度の制御方法の具体例について説明する。確認応答送信手段13から得た受信速度Bと目標とするパケットロス率Cとを用いて、新しい送信速度Aを次のように計算することができる。
A=B/(1−B)
例えば、確認応答により送られてきた受信速度が90Mbpsで、目標とするパケットロス率が10%(=0.1)である場合、上記式に基づき、新しい送信速度を100Mbpsに設定することができる。
【0026】
図5は、図1に示す本発明のデータ転送システムにおいて、送信端末から受信端末へ転送されるデータパケットのフォーマットの一例を示す。本パケットは4つのフィールドを含んでいる。すなわち、IPヘッダ21、UDPヘッダ22、パケットのシーケンス番号23、及びペイロード24を含む。IPヘッダ21はIPネットワークを介して、送信端末と受信端末との間でパケットを転送するために利用される。UDPヘッダ22は端末内で複数のアプリケーションからのパケットを区別するために利用される。さらにUDPヘッダ22はチェックサムフィールドを持ち、伝送途中でのパケットの誤りを検査することができる。パケットのシーケンス番号23はネットワーク内でのパケットの順序逆転や損失、重複を検出するために利用される。ペイロードには送信データ全体のうちの一部が格納される。
【0027】
図6は、図1に示す本発明のパケット転送制御システムにおいて、受信端末から送信端末へ転送される確認応答パケットのフォーマットの一例を示す。本パケットは受信レートの通知と転送途中でエラーや損失にあったパケットに対する再送要求を行うためのものである。パケットは6つのフィールドを含んでいる。すなわち、IPヘッダ31、UDPヘッダ32、受信したシーケンス番号の最大値33、受信速度34、確認応答数35、受信されなかったシーケンス番号の列36を含む。IPヘッダ31及びUDPヘッダ32は、データパケットの場合と同じ目的で使用される。受信したシーケンス番号の最大値33は、確認応答パケットを送信する時点で受信されているパケットのシーケンス番号の最大値である。受信速度34は、前回の確認応答パケット送信後に受信されたデータパケットの受信速度である。確認応答数35は、この後に続く未受信パケットのシーケンス番号の列36に含まれる要素の数である。受信されなかったパケットのシーケンス番号の列36は、受信したシーケンス番号の最大値33よりもシーケンス番号が小さいパケットのうち、まだ受信されていないパケットのシーケンス番号の列である。
【0028】
送信端末側では、確認応答パケットに含まれる受信速度34とフロー制御手段15の設定値とを比較することによって、パケットのロス率を計算することができる。また、受信したシーケンス番号の最大値33と受信されなかったシーケンス番号の列36とから、受信端末によってどのパケットが受信され、どのパケットが受信されていないかを、完全に知ることができる。
【0029】
次に、受信側端末装置から送信側端末装置へ送信される確認応答の周期について説明する。確認応答の周期の設定方法については、周期を固定する方法と、ネットワークの状況に応じて動的に制御する方法がある。確認応答の周期を固定する場合、前述したように、例えば10ミリ秒間隔で確認応答を送信することで、1Gbpsの速度でデータを訂正する場合には、TCPと比較して確認応答の帯域を1,000分の1程度まで、削減することができる。一方、確認応答の周期をネットワークの状況に応じて、すなわちネットワークの利用可能帯域に基づいて動的に制御する場合、ネットワークの利用可能帯域が時々刻々変化する状況の中で、変化が激しいときには確認応答の送信頻度を高く設定し、変化が穏やかなときには、確認応答の送信頻度を低く設定することによりネットワークの状況にすばやく適応しつつ、周期を固定した場合に比較して、さらに帯域を節約することができる。尚、ネットワークの利用可能帯域情報として、受信側端末装置におけるデータパケットの受信速度やパケット損率を用いることができる。従って、データパケットの受信速度情報を用いて確認応答の送信周期をダイナミックに制御することにより、帯域を一層節約することができる。
【0030】
確認応答の周期を動的に制御する具体的な制御手順としては、例えば次のような計算を行うことができる。初めに、ネットワークの利用可能帯域Xの変動を、平均利用可能帯域からの分散Zとして、次式にて計算する。
Z=σ(X1, X2, X3………Xn)
ここで、X1, X2, X3………Xnは、帯域の分散の計算に利用したい直前のn回の測定データを用いることができる。この分散Zよって、引数が大きいときには値が小さくなり、引数が小さいときには値が小さくなる関数f(Z)を用いて、新しい確認応答間隔Y=f(Z)を計算することができる。従って、受信側端末装置に、受信速度検出手段から得られた受信速度情報を用いて上述した処理を実行する確認応答周期制御手段を設けることにより、確認応答の送信周期をダイナミックに制御することができる。
【0031】
図7は、確認応答手段13で用いるテーブルの例を示す。確認応答範囲表TOlは、「未受信シーケンス番号最小値」、「既受信シーケンス番号最大値」、「前回確認応答時のバッファ位置」を含む。これらはそれぞれ、受信されていないシーケンス番号の中でもっとも小さな値、現在までに受信したパケットのシーケンス番号の中でもっとも大きな値、そして前回確認応答をした時の受信バッファBOlの最後尾へのポインタである。受信管理表TO2は、2つの列から構成され、各列は「シーケンス番号」と「受信したパケットを保存したバッファ上の位置(ポインタ)」を保持する。受信バッファBOlは、「アドレス」で表される場所に受信した「パケットの内容」が保持される。
【0032】
データパケットが受信されると、パケットのシーケンス番号が検査されると共に同時に、受信バッファBOlの先頭から順にパケットの内容が保存される。また、受信バッファBOlへのポインタが、受信管理表TO2の該当するシーケンス番号の行に記録される。未受信のパケットは、受信管理表TO2ではポインタが空欄であることによって表されている。受信したデータバケットのシーケンス番号は、確認応答範囲表TOlとも比較される。受信パケットのシーケンス番号を既受信シーケンス番号最大値と比較し、受信パケットのシーケンス番号のほうが大きければ、その値で既受信シーケンス番号最大値を上書きする。また、受信パケットのシーケンス番号を未受信シーケンス番号最小値と比較し、一致する場合は、受信管理表TO2を検索して、まだ受信されていないもっとも小さなシーケンス番号で未受信シーケンス番号最小値を上書きする。
【0033】
確認応答パケットを送信する際には、未受信シーケンス番号最小値から既受信シーケンス番号最大値の範囲で、受信管理表TO2からポインタ欄が空欄のものをピックアップすることで、図6に示される確認応答パケットの「受信されなかったパケットのシーケンス番号の列」36と「確認応答数」35とを作成することができる。また、図6中の「受信したシーケンス番号の最大値」33は、図7における既受信シーケンス番号最大値をそのまま使うことができる。
【0034】
図8は、図7で説明した確認応答手段実装のためのテーブルの例から生成された確認応答パケットの例である。確認応答パケットを送信する時点で、受信しているシーケンス番号の最大値は6、受信されていないシーケンス番号の数は2番と5番の2つである。
【0035】
図9〜図11は本発明によるデータ転送システムをコンテンツ配信システムに適用した種々の例を示す。図9に示すコンテンツ配信システムにおいて、パケット転送ネットワーク3に映像コンテンツサーバ40及び携帯端末41a〜41nを接続し、映像コンテンツサーバ40からパケット転送ネットワーク3を介して携帯端末41にコンテンツ配信を行う。本例では、映像コンテンツサーバ40に蓄積されている大容量のコンテンツを携帯電話等の携帯端末41へ高速で転送することができる。一般的に、携帯端末では、バッテリーの持続時間を延ばし、軽量化を図るためにダウンロードにかかる処理をできるだけ簡略化できることが求められる。この場合、本発明によれば、携帯端末のプロセッサに要求される性能を小さくすることができ、携帯端末の小型軽量化に資することができる。
【0036】
図10は、パケット転送ネットワーク3に映像コンテンツサーバ40及びパーソナルコンピュータ(PC)42a〜42nを接続し、映像コンテンツサーバ40に蓄積されている大容量のコンテンツをクライアントPCへ高速に転送するコンテンツ配信システムを示す。本例では、サーバやPCの送受信処理が効率的になるため、サーバでは従来よりも一層多くのクライアントPCに対して映像コンテンツを配信することができる。また、クライアントPCにおいても、従来よりも低コストな装置で同等の処理速度を得ることができる。
【0037】
図11はコンテンツサーバ間においてコンテンツを配信するコンテンツ配信システムを示す。パケット転送ネットワーク3を介して第1の大容量コンテンツサーバと第1のグループの端末装置43a〜43nを接続すると共に、同様にネットワーク3を介して第2の大容量コンテンツサーバ40bと第2のグループの端末装置44a〜44nとを接続する。そして、第1のコンテンツサーバ40aと第2のコンテンツサーバ40bとの間においてネットワーク3を介してコンテンツの配信を行う。本例において、コンテンツサーバ40a及び40bは共に図3に示す送信側端末装置1及び受信側端末装置2の両方の機能を具える。従って、コンテンツサーバ40aと40bとの間において最新のコンテンツを配信するために本発明によるデータ転送方法を適用することができる。映像コンテンツサーバでは、大容量のコンテンツの同期を取ったり、バックアップをとる作業を高速に行う必要があるが、従来のコンテンツ配信システムではこれらの処理を行うためにサーバに対して非常に高い性能が要求されていた。一方、本発明によれば、サーバに要求される性能を軽減することができ、或いは同一の性能のサーバを用いた場合より多くのコンテンツを短時間で送受信することが可能になる。
【0038】
図12は、本発明によるデータ転送システムの変形例を示す線図である。本例は、図3に示すデータ転送システムの変形例であり、図3で用いた部材と同一の構成要素には同一符号を付して説明する。図3に示す実施例では、フロー制御を送信側端末装置において実行したが、本例では、フロー制御を受信側端末装置において行う。受信側端末装置1において、データパケットの受信に応じてパケット受信速度やパケット損率を検出し、検出した受信速度情報を用いフロー制御手段15において送信側端末装置におけるデータパケットの送信速度情報を作成する。すなわち、フロー制御手段15では、必要に応じて受信データの帯域や送信帯域、パケットロス率等から、送信側端末装置が用いるべき最適な送信帯域を計算し、送信端末装置に通知する。尚、受信帯域の計算には時計手段14を用いることができる。例えば、時計手段により一定時間Tの間に受信したデータ量Dを計算し、D/Tにより受信帯域を計算することができる。また、送信帯域の計算精度を向上させるため、受信側端末装置から送信側端末装置へ宛てた送信帯域の指示に、それらの指示の1つ1つを識別するための指示識別子を一緒に送信し、かつ送信側端末装置から送信されるデータパケットに、前記指示識別子を埋め込むことにより、「どの時点送信速度の指示に基づいているか」を受信端末装置が知ることができる。従って、過去のある時点での送信帯域の指示に基づく確認応答パケットのみ取り出して、個別に受信帯域を測定することができる。或いは、送信側端末装置から送信されるデータパケットに、「現在の送信速度」に関する情報を埋め込むことにより、受信側端末装置では、受信したデータパケットを見るだけで、当該データパケットが送信された時点での帯域を正確に知ることができる。これを受信帯域と比較することにより、パケットロス率を正確に計算することができる。
【0039】
作成した送信速度情報は確認応答送信手段13に供給し、確認応答に含ませ、他の情報と共に送信側端末装置1に送信する。この場合、受信側端末装置から送信側端末装置に送信される確認応答に、「新しい送信帯域」を指示するフィールドを設け、当該フィールドにフロー制御手段で計算された送信速度情報を含めることができる。確認応答は送信側端末装置で受信され、送信速度情報がシェーピング手段11に供給され、シェーピング手段11は、送られてきた確認応答の「新しい送信帯域」フィールドに記された帯域に基づいてデータパケットの送信速度を設定する。このように、受信側端末装置においてフロー制御を行うことにより、送信側端末装置の負荷を軽減することができる。
【図面の簡単な説明】
【図1】従来のTCPによるデータ転送の時系列を示す図である。
本発明に従うデータ転送システムの構成例
【図2】本発明によるデータ転送の時系列の一例を示す図である。
【図3】本発明によるデータ転送システムの一例を示す線図である。
【図4】本発明のパケット処理におけるフィードバック処理を示す図である。
【図5】データパケットの一例を示す図である。
【図6】確認応答パケットの一例を示す図である。
【図7】本発明による確認応答ステップ実装のためのテーブルの一例を示す図である。
【図8】確認応答パケットの一例を示す図である。
【図9】本発明によるコンテンツ配信システムの一例を示す線図である。
【図10】本発明によるコンテンツ配信システムの別の実施例を示す線図である。
【図11】本発明によるコンテンツ配信システムの別の実施例を示す線図である。
【図12】本発明によるデータ転送システムの変形例を示す線図である。
【符号の説明】
1 送信側端末装置
2 受信側端末装置
3 パケット転送ネットワーク
10 パケット送信手段
11 シェーピング手段
12 蓄積手段
13 確認応答送信手段
14 計時手段
15 フロー制御手段
16 再送制御手段
P21 データパケット
P22 確認応答パケット
P31 データパケット
P32 確認応答パケット
【発明の属する技術分野】
本発明は、端末間で広帯域かつ信頼性のあるデータ転送を行うためのデータ転送方法及びシステム、並びにこのデータ転送方法を利用したコンテンツ配信システムに関するものである。
【0002】
【従来の技術】
近年、高速ネットワーク転送技術が安価に入手できるようになってきた。今後、一般家庭の端末においても1Gbpsのような超高速インターフェイスが急速に普及すると考えられる。また、ネットワークの高速化と歩調を合わせて、高速ネットワークを介して送受信されるコンテンツも従来のWebコンテンツに代わって、音声や動画等の大容量容コンテンツが急速に増加している。したがって、高速ネットワークの性能を最大限に引き出して、大容量のコンテンツを高速に端末間で交換できることが強く求められている。
【0003】
通常のコンテンツを配信する際のトランスポート層のプロトコルとして、現在のインターネットにおいてはTCPとUDPという2通りの方式が主に利用されている。TCPでは、揖失パケットの再送機能や順序逆転パケットの整列機能を有しており、上位のアプリケーションに対して、信頼性の高いストリーム型のサービスを提供する。一方、UDPは、損失パケットの再送機能や順序逆転パケットの整列機能は持たず、上位のアプリケーションに対して、信頼性の低いデータグラム型のサービスを提供する。これら2つのプロトコルは、利用目的に応じて最適な方式が利用されている。
【0004】
さて、ネットワークを介してやり取りされる音声や動画等の大容量コンテンツは、MPEG2等のさまざまな方式で圧縮(エンコード)されている。このような圧縮方式に共通していえることは、データの部分的な喪失や誤りが存在するとコンテンツの品質に大きな影響を与える、ということである。これはデータが時間軸方向や空間軸方向に庄縮されているため1箇所の誤りによって、これら時間軸方向や空間軸方向の他のデータに対しても影響を与えてしまうためである。インターネットは一般にベストエフォート型であり、データの到達性や遅延時間、到着順序に関する保証を行わない。したがってインターネットを介して前記の様なコンテンツの転送を行う場合には、データの損失、遅延、順序逆転に対する特別な配慮が必要となる。そのための方法として現在利用されている方式は、大きく2つの方向性をもつ。
【0005】
一つはダウンロード型と呼ばれるもので、エンコード方式には手を加えずに、信頼性の高いトランスポート層の機能を用いてデータを転送する方式である。データ転送途中に発生したデータのロスや誤りは、トランスポート層において回復されるため、アプリケーション層のエンコードやデコードの際に、エラー訂正等の特別な仕組みを必要としない。このような目的で、インターネットで一般に利用されているトランスポート層は、TCP(Transport Control Protocol)と呼ばれるプロトコルである(RFC793)。TCPを利用することによって、アプリケーション層は実装を単純化することができる反面、トランスポート層において複雑な処理を行う必要がある。コンテンツの転送においてダウンロード型を利用できるのは、映画などの蓄積可能なコンテンツである。
【0006】
一方、コンテンツを転送するもうひとつの方向性としてストリーム型と呼ばれるものがある。信頼性の低い(誤り訂正機能を持たない)トランスポート層を利用してデータを転送する代わりに、誤り訂正等の機能をアプリケーション層やプレゼンテーション層に実装する方式である。トランスポート層が単純な処理ですむ反面、アプリケーション層ではエンコードやデコードの際に、誤りの影響を最小限に抑えるために数多くの複雑な処理が要求される。このようなストリーム型のデータ転送に一般に利用されているトランスポート層のプロトコルはUDP(User Datagram Protocol)と呼ばれている(RFC768)。UDPはパケットの喪失や順序逆転に対する再送機能や再配列機能を持たず、上位層に対してベストエフォート型のパケット転送サービスを提供する。アプリケーションの実装が複雑になるが、前記のダウンロード型と異なり、データの損失や遅延に対してアプリケーションやコンテンツに特化した処理を、アプリケーション層で独自に行うことが可能となる。コンテンツの転送においてストリーム型を利用するのは、主として生中継のようにリアルタイム性が要求されるコンテンツや、マルチキャストのように非常に多数のクライアントに対する同報通信の場合などである。前者ではパケットの再送による遅延が問題となるために、再送制御機能のないUDPを利用している。後者では、クライアントの数が非常に多くなった場合に、クライアント単位で再送制御を行うとサーバーに負荷がかかるため再送制御機能のないUDPを利用している。いずれにしてもUDPを利用した通信では、コンテンツの品質よりもリアルタイム性や同時視聴可能数が重視されている。
【0007】
先に述べたように、音声や動画等のコンテンツはデータの誤りに対して品質の劣化が著しい。前記2つの方式の特徴から言えることは、蓄積可能なコンテンツをインターネット経由で転送する場合には、TCPのように誤り訂正機能を持つ方式を利用するほうが望ましい、ということである。特に近年のコンテンツの大容量化は、画像の解像度やフレーム数など品質の向上を目指した結果であり、今後ますます信頼性の高い広帯域転送方式が必要になると考えられる。
【0008】
【発明が解決しようとする課題】
しかしながら、以上に述べたようなTCPを利用する方式は、今後必要とされる高速転送においてもそのままで適用できるわけではない。ネットワークの帯域幅やプロセッサの処理能力が向上した際に課題となる点は、次のとおりである。
1. 細かなチューニングの課題:TCP等のトランスポート層のプロトコルは、通常OS(オペレーティングシステム)のカーネル領域に実装されるため、一般のアプリケーションプログラムからは、詳細な部分を制御できない。特にTCPのACK(確認応答)を返信する頻度や再送までのタイムアウトの長さなどは、動画再生等のアプリケーションに対して大きな影響を与えるが、これらをアプリケーションから直接利御するのは困難である。
2. ACKによるオーバーヘッド:TCPでは2つのデータパケットの受信に対して、1つのACK(確認応答)パケットが返信される。しかし、高速転送時には次のような問題を招く。通常の端末では、パケットを受信するたびにプロセッサに割り込みが発生するが、これによって2パケットに1回は送・受信処理が中断される。また、頻繁なACKパケットの送受信はI/0バスの競合による使用効率の低下を招く。さらにACKによるネットワーク帯域の消費も無視できない。たとえばEthernet(登録商標)を利用して1Gbpsのデータ送信速度を得るためには、50Mbpsもの確認応答パケットの帯域が必要である。すなわちデータの送信帯域が確認応答の帯域によって影響を受ける、という課題もある。
【0009】
ウィンドウサイズの制限:TCPの転送速度を向上する手法として、ウィンドウサイズを操作する方法がよく利用されるが、ネットワークの帯域は、端末の環境や接続先によって、数kbps〜数百Mbpsまで大きく変化するため、あらゆる場合に通用する最適なウィンドウサイズは一意には決められない。たとえば、遅延の大きな高速リンクに最適化されたウィンドウサイズを低遅延の低速リンクで使用すると、パケット損のために極端に転送速度が劣化する場合がある。また、TCPではウィンドウサイズ内のパケットに対する送信速度調節機構がなくバースト的にトラフィックが送信されるため、受信側での取りこぼしや、ネットワークの不安定さを招く場合がある。
【0010】
本発明はこのような課題を解決するためのものであり、上位のアプリケーションに対してTCPと同様の高い信頼性と高速なデータ転送サービスを、非常に小さなオーバーヘッドで実現する方法および装置を提供することを目的としている。
【0011】
【課題を解決するための手段】
本発明にかかるパケット転送方法は、以下の各項目を達成することによって、前記目的を達成する。
1.アプリケーションソフトウェアとして実装
2.確認応答帯域の削減
3.送信端末からの送信時のシェーピングと速度の自動調節
【0012】
上記各項目の実現手段の詳細は以下のとおりである。
1.アプリケーションソフトウェアとして実装
トランスポート層のプロトコルとしてUDPを利用し、エラー訂正機能・再送制御機能・フロー制御機能等の信頼性を確保するために必要な機能を、アプリケーションソフトウェアのライブラリとして実装可能である。これにより、専用ハードウェアやデバイスドライバを必要としないため、低コストな実装が可能となる。また、TCPは通常オペレーティングシステムの内部で動作するため、ウィンドウサイズや再送頻度等のパラメータをアプリケーションから簡単に変更することが困難であったが、ライブラリとして実装することにより、これらのパラメータをアプリケーションから簡単に変更することが可能となる。これによって、従来技術の課題の1.を解決することができる。
【0013】
2.確認応答帯域の削減
確認応答パケットの送出をデータパケットの受信とは独立に行うことができる。また、単一の確認応答パケットで複数のデータパケットに対する確認応答情報を送信することができる。これらにより確認応答帯域の送受信頻度帯域ともに大幅に削減することが可能となる。たとえば、以下で説明する実施例において、10ミリ秒に1回確認応答をする場合に、TCPと比較して最大1000分の1程度にまで確認応答パケットの帯域を削減することができる。また、これに伴ってI/0バスの競合も最小限に抑えることができるため、前記従来技術の課題の2.を解決することができる。
【0014】
3.送信端末からの送信時のシェーピングと速度の自動調節
送信端末側ではデータパケットの送信時にシェービングを行うことができる。
これによってTCPのウィンドウサイズによる速度調節機構で問題であった、バースト的なトラフィックの流出を防ぎ、同時に所望の帯域を即座に得ることができる。これによって、前記従来技術の課題の3.を解決することができる。
【0015】
次に、確認応答の周期の独立性と送信速度制御機能との相乗効果について説明する。従来のTCPのフロー制御方式においては、送信速度を適切な値に調節するために「ウインドウ」の概念が用いられている。ウインドウは、受信端末からの確認応答を受け取ることなく送信することができるデータ量を意味する。受信端末から確認応答を受信すると、その分ウインドウの位置がスライドして次のデータを送信することができるようになる。このウインドウを用いるシステムでは、ウインドウの幅を調節することにより送信帯域は間接的に制御される。また、データの送信のためには、常時古いデータについて確認応答する必要がある。
これに対して、本発明による送信帯域を直接制御する方式では、「送信速度が受信速度に応じて制御される」ため、言い換えると、「送信端末側のシェーピング手段により、送信帯域を制御している」ため、必ずしも常に確認応答を送受信する必要はない。たとえ送信帯域が超過したとしても、送信されなかったパケットを
後で再送することができる。このことから、結果的に「確認応答の周期を受信速度から独立」させることができ、その結果として受信側端末から送信側端末への確認応答の帯域を節約することができる効果が達成される。これに派生して、TCPにおいて問題となっているバースト的なトラフィックの送信やウインドウサイズのチューニングの必要性といった問題が解消し、しかも、I/Oバスにおける競合やスループットの低下が解消される効果が達成される。
【0016】
【発明の実施の形態】
以下では、本発明の1つの実施形態を図により説明する。
図1は、従来のTCPを利用したデータ転送における、送受信端末間のパケットの流れを示したものである。時間軸は垂直方向に上から下へ向かっている。図中左側の送信端末から同じく右側の受信端末へ向けてデータパケットP21が送信され、これに対して受信端末から送信端末へ確認応答パケットP22が返信される。TCPでは、パケットロスや順序逆転のない定常状態においては、図に示すように2つのデータパケットに対して1つの確認応答パケットが返信される。確認応答パケットの送信頻度はデータパケットの受信頻度に比例するため、高速通信時には、先に述べたような問題が発生する。
【0017】
図2は、本発明に従うシステムにおける、送受信端末間のパケットの流れを時系列的に示したものである。時間軸は垂直方向に上から下へ向かっている。図の左側の送信端末から同じく右側の受信端末へ向けてデータパケットP31が送信され、これに対して受信端末から送信端末へ確認応答パケットP32が周期的に返信される。本発明に従うシステムでは、データパケットの受信頻度とは独立に、定期的に確認応答を返信する。
【0018】
図3は、本発明によるデータ転送システムの一例の構成を示す線図である。送信側端末装置1と受信側端末装置2とが、パケット転送ネットワーク3を介して接続されている。これら端末装置、すなわちパケット送受信装置は、例えば種々の情報やデータを配信するサーバ、通信機能を有するパーソナルコンピュータ、携帯型情報端末、或いは携帯電話とすることができる。従って、例えば、コンテンツ配信サーバと携帯型端末装置又はパーソナルコンピュータとの間のデータやコンテンツの配信、携帯型端末装置間のデータの送受信、携帯型端末装置とパーソナルコンピュータとの間のデータの送受信に本発明を適用することができる。尚、図面上2つの端末装置だけを図示したが、複数の端末装置がパケット転送ネットワーク3に接続されているものとする。
【0019】
データパケットはパケット転送ネットワーク3を介して送信側の端末装置1から受信側の端末装置2へ向けて転送され、これに対する確認応答パケットが受信側端末装置2から送信側端末装置1へ向けて転送される。送信側端末装置1においては、送信手段10において送信するデータを選択し、選択したデータ基づいてデータパケットを作成し、パケット単位のシーケンス番号を付与する。次にシェーピング手段11において送信速度を適切に調節し、パケット転送ネットワーク3へ送信される。一方、受信側端末装置2では、パケット受信手段(図示せず)を介して受信したデータパケットを蓄積手段(主記憶装置)12において蓄積するとともに、確認応答手段13で受信したパケットのシーケンス番号をチェックし、確認応答パケットを作成してパケット送信手段(図示せず)を介してパケット転送ネットワーク3に送信する。その際、確認応答パケットを送信するタイミングを測定するために計時手段14を利用することができる。また、受信速度計測手段(図示せず)を設け、受信したデータパケットの受信速度を計測し、その計測結果を確認応答手段13に供給する。そして、確認応答手段13は、計測された受信速度情報を確認応答に含めることができる。さらに、図6に示す確認応答に含まれる各種のデータ又は情報を作成手段(図示せず)を有し、これらのデータ又は情報は確認応答パケットに含ませることができる。
【0020】
送信された確認応答パケットはパケット転送ネットワーク3を介して送信側端末装置1へ転送される。送信側端末装置1で受信された確認応答パケットは、フロー制御手段15および再送制御手段16で使用される。フロー制御手段15では、確認応答パケットの内容からパケット損率を計算し、データパケットの送信速度の調節にフィードバックを行う。再送制御手段16では、確認応答パケットの内容から再送が必要なパケットを特定し、送信手段10における送信内容に反映する。
【0021】
尚、図3に示す実施例において、各端末装置は、送信側のデータ送信機能及び受信側のデータ受信機能の両方の機能を有する端末装置とすることができ、或いは送信側の機能又は受信側の機能だけを有する端末装置とすることもできる。
【0022】
図4は、図3に示すデータ転送システムにおいて、特にフィードバック制御の動作を説明したものである。本システムは2つのフィードバックループを構成する。すなわち、送信内容フィードバックループLOlと送信速度フィードバックループLO2である。送信内容フィードバックLOlは、確認応答に含まれる受信されなかったパケットのシーケンス番号に基づいて、パケットロスやエラーパケットを再送し、上位のアプリケーションに対してエラーのないデータを渡すためのものである。送信速度フィードバックLO2は、確認応答に含まれる受信側端末装置の受信速度情報に基づいて、ネットワークの利用効率を高め、かつパケットの再送を減らすために最適な送信速度を得るためのものである。
【0023】
送信内容フィードバックLOlには、送信手段10、シェーピング手段11、パケット転送ネットワーク3、確認応答手段13、再送制御手段16が含まれる。送信手段10は、シーケンス番号どおりのパケット送信のほかに、再送制御手段16からの指示にもとづいて、すでに送信したパケットも再送信する。シェーピングはパケットの送信内容にかかわらずすべてのパケットに対して同一のシェーピングを行うことも可能であるが、再送パケットは初回のパケットとは異なるポリシーにもとづいてシェーピングを行ってもよい。シェーピングされたパケットは、パケット転送ネットワーク3において、遅延やロスなどの変化を受けた後、確認応答手段13においてエラーやシーケンス番号内容がチェックされ、確認応答パケットが返送される。再送制御手段16では、確認応答パケットの内容により再送が必要なパケットを決定し、送信手段10に再送の指示を出す。
【0024】
送信速度フィードバックLO2には、シェーピング手段11,パケット転送ネットワーク3、確認応答手段13、フロー制御手段15が含まれる。フロー制御手段15は、確認応答に含まれる受信側端末装置の受信速度情報に基づいてデータパケットの送信速度を調整する機能を有する。シェーピング手段11は、フロー制御手段15からの指示にもとづいて、パケットの送信速度を調節する。パケット転送ネットワークNOlが、ベストエフォート型のネットワークの場合、送信されたパケットは他のトラフィックと合流し、時々刻々変化する遅延やパケットの損失が発生する。パケット転送ネットワーク3を通過したパケットの内容は確認応答手段13でチェックされ、先の送信内容フィードバックLOlにおいて利用されたものと同一のパケットを使ってフロー制御手段15へフィードバックされる。フロー制御手段15では、パケットのロス率や再送回数又は受信側でのパケット受信速度などから、最適な送信速度を決定し、シェーピング手段11対して指示を与える。すなわち、ロス率や再送回数が高い場合や、確認応答パケットが受信されない場合には、シェーピング速度を低く設定し、逆にロス率や再送回数が低い場合には、シェーピング速度を高く設定する。以上の制御により、信頼性の高いデータ転送を最適な速度で実現できる。
【0025】
フロー制御手段15における送信速度の制御方法の具体例について説明する。確認応答送信手段13から得た受信速度Bと目標とするパケットロス率Cとを用いて、新しい送信速度Aを次のように計算することができる。
A=B/(1−B)
例えば、確認応答により送られてきた受信速度が90Mbpsで、目標とするパケットロス率が10%(=0.1)である場合、上記式に基づき、新しい送信速度を100Mbpsに設定することができる。
【0026】
図5は、図1に示す本発明のデータ転送システムにおいて、送信端末から受信端末へ転送されるデータパケットのフォーマットの一例を示す。本パケットは4つのフィールドを含んでいる。すなわち、IPヘッダ21、UDPヘッダ22、パケットのシーケンス番号23、及びペイロード24を含む。IPヘッダ21はIPネットワークを介して、送信端末と受信端末との間でパケットを転送するために利用される。UDPヘッダ22は端末内で複数のアプリケーションからのパケットを区別するために利用される。さらにUDPヘッダ22はチェックサムフィールドを持ち、伝送途中でのパケットの誤りを検査することができる。パケットのシーケンス番号23はネットワーク内でのパケットの順序逆転や損失、重複を検出するために利用される。ペイロードには送信データ全体のうちの一部が格納される。
【0027】
図6は、図1に示す本発明のパケット転送制御システムにおいて、受信端末から送信端末へ転送される確認応答パケットのフォーマットの一例を示す。本パケットは受信レートの通知と転送途中でエラーや損失にあったパケットに対する再送要求を行うためのものである。パケットは6つのフィールドを含んでいる。すなわち、IPヘッダ31、UDPヘッダ32、受信したシーケンス番号の最大値33、受信速度34、確認応答数35、受信されなかったシーケンス番号の列36を含む。IPヘッダ31及びUDPヘッダ32は、データパケットの場合と同じ目的で使用される。受信したシーケンス番号の最大値33は、確認応答パケットを送信する時点で受信されているパケットのシーケンス番号の最大値である。受信速度34は、前回の確認応答パケット送信後に受信されたデータパケットの受信速度である。確認応答数35は、この後に続く未受信パケットのシーケンス番号の列36に含まれる要素の数である。受信されなかったパケットのシーケンス番号の列36は、受信したシーケンス番号の最大値33よりもシーケンス番号が小さいパケットのうち、まだ受信されていないパケットのシーケンス番号の列である。
【0028】
送信端末側では、確認応答パケットに含まれる受信速度34とフロー制御手段15の設定値とを比較することによって、パケットのロス率を計算することができる。また、受信したシーケンス番号の最大値33と受信されなかったシーケンス番号の列36とから、受信端末によってどのパケットが受信され、どのパケットが受信されていないかを、完全に知ることができる。
【0029】
次に、受信側端末装置から送信側端末装置へ送信される確認応答の周期について説明する。確認応答の周期の設定方法については、周期を固定する方法と、ネットワークの状況に応じて動的に制御する方法がある。確認応答の周期を固定する場合、前述したように、例えば10ミリ秒間隔で確認応答を送信することで、1Gbpsの速度でデータを訂正する場合には、TCPと比較して確認応答の帯域を1,000分の1程度まで、削減することができる。一方、確認応答の周期をネットワークの状況に応じて、すなわちネットワークの利用可能帯域に基づいて動的に制御する場合、ネットワークの利用可能帯域が時々刻々変化する状況の中で、変化が激しいときには確認応答の送信頻度を高く設定し、変化が穏やかなときには、確認応答の送信頻度を低く設定することによりネットワークの状況にすばやく適応しつつ、周期を固定した場合に比較して、さらに帯域を節約することができる。尚、ネットワークの利用可能帯域情報として、受信側端末装置におけるデータパケットの受信速度やパケット損率を用いることができる。従って、データパケットの受信速度情報を用いて確認応答の送信周期をダイナミックに制御することにより、帯域を一層節約することができる。
【0030】
確認応答の周期を動的に制御する具体的な制御手順としては、例えば次のような計算を行うことができる。初めに、ネットワークの利用可能帯域Xの変動を、平均利用可能帯域からの分散Zとして、次式にて計算する。
Z=σ(X1, X2, X3………Xn)
ここで、X1, X2, X3………Xnは、帯域の分散の計算に利用したい直前のn回の測定データを用いることができる。この分散Zよって、引数が大きいときには値が小さくなり、引数が小さいときには値が小さくなる関数f(Z)を用いて、新しい確認応答間隔Y=f(Z)を計算することができる。従って、受信側端末装置に、受信速度検出手段から得られた受信速度情報を用いて上述した処理を実行する確認応答周期制御手段を設けることにより、確認応答の送信周期をダイナミックに制御することができる。
【0031】
図7は、確認応答手段13で用いるテーブルの例を示す。確認応答範囲表TOlは、「未受信シーケンス番号最小値」、「既受信シーケンス番号最大値」、「前回確認応答時のバッファ位置」を含む。これらはそれぞれ、受信されていないシーケンス番号の中でもっとも小さな値、現在までに受信したパケットのシーケンス番号の中でもっとも大きな値、そして前回確認応答をした時の受信バッファBOlの最後尾へのポインタである。受信管理表TO2は、2つの列から構成され、各列は「シーケンス番号」と「受信したパケットを保存したバッファ上の位置(ポインタ)」を保持する。受信バッファBOlは、「アドレス」で表される場所に受信した「パケットの内容」が保持される。
【0032】
データパケットが受信されると、パケットのシーケンス番号が検査されると共に同時に、受信バッファBOlの先頭から順にパケットの内容が保存される。また、受信バッファBOlへのポインタが、受信管理表TO2の該当するシーケンス番号の行に記録される。未受信のパケットは、受信管理表TO2ではポインタが空欄であることによって表されている。受信したデータバケットのシーケンス番号は、確認応答範囲表TOlとも比較される。受信パケットのシーケンス番号を既受信シーケンス番号最大値と比較し、受信パケットのシーケンス番号のほうが大きければ、その値で既受信シーケンス番号最大値を上書きする。また、受信パケットのシーケンス番号を未受信シーケンス番号最小値と比較し、一致する場合は、受信管理表TO2を検索して、まだ受信されていないもっとも小さなシーケンス番号で未受信シーケンス番号最小値を上書きする。
【0033】
確認応答パケットを送信する際には、未受信シーケンス番号最小値から既受信シーケンス番号最大値の範囲で、受信管理表TO2からポインタ欄が空欄のものをピックアップすることで、図6に示される確認応答パケットの「受信されなかったパケットのシーケンス番号の列」36と「確認応答数」35とを作成することができる。また、図6中の「受信したシーケンス番号の最大値」33は、図7における既受信シーケンス番号最大値をそのまま使うことができる。
【0034】
図8は、図7で説明した確認応答手段実装のためのテーブルの例から生成された確認応答パケットの例である。確認応答パケットを送信する時点で、受信しているシーケンス番号の最大値は6、受信されていないシーケンス番号の数は2番と5番の2つである。
【0035】
図9〜図11は本発明によるデータ転送システムをコンテンツ配信システムに適用した種々の例を示す。図9に示すコンテンツ配信システムにおいて、パケット転送ネットワーク3に映像コンテンツサーバ40及び携帯端末41a〜41nを接続し、映像コンテンツサーバ40からパケット転送ネットワーク3を介して携帯端末41にコンテンツ配信を行う。本例では、映像コンテンツサーバ40に蓄積されている大容量のコンテンツを携帯電話等の携帯端末41へ高速で転送することができる。一般的に、携帯端末では、バッテリーの持続時間を延ばし、軽量化を図るためにダウンロードにかかる処理をできるだけ簡略化できることが求められる。この場合、本発明によれば、携帯端末のプロセッサに要求される性能を小さくすることができ、携帯端末の小型軽量化に資することができる。
【0036】
図10は、パケット転送ネットワーク3に映像コンテンツサーバ40及びパーソナルコンピュータ(PC)42a〜42nを接続し、映像コンテンツサーバ40に蓄積されている大容量のコンテンツをクライアントPCへ高速に転送するコンテンツ配信システムを示す。本例では、サーバやPCの送受信処理が効率的になるため、サーバでは従来よりも一層多くのクライアントPCに対して映像コンテンツを配信することができる。また、クライアントPCにおいても、従来よりも低コストな装置で同等の処理速度を得ることができる。
【0037】
図11はコンテンツサーバ間においてコンテンツを配信するコンテンツ配信システムを示す。パケット転送ネットワーク3を介して第1の大容量コンテンツサーバと第1のグループの端末装置43a〜43nを接続すると共に、同様にネットワーク3を介して第2の大容量コンテンツサーバ40bと第2のグループの端末装置44a〜44nとを接続する。そして、第1のコンテンツサーバ40aと第2のコンテンツサーバ40bとの間においてネットワーク3を介してコンテンツの配信を行う。本例において、コンテンツサーバ40a及び40bは共に図3に示す送信側端末装置1及び受信側端末装置2の両方の機能を具える。従って、コンテンツサーバ40aと40bとの間において最新のコンテンツを配信するために本発明によるデータ転送方法を適用することができる。映像コンテンツサーバでは、大容量のコンテンツの同期を取ったり、バックアップをとる作業を高速に行う必要があるが、従来のコンテンツ配信システムではこれらの処理を行うためにサーバに対して非常に高い性能が要求されていた。一方、本発明によれば、サーバに要求される性能を軽減することができ、或いは同一の性能のサーバを用いた場合より多くのコンテンツを短時間で送受信することが可能になる。
【0038】
図12は、本発明によるデータ転送システムの変形例を示す線図である。本例は、図3に示すデータ転送システムの変形例であり、図3で用いた部材と同一の構成要素には同一符号を付して説明する。図3に示す実施例では、フロー制御を送信側端末装置において実行したが、本例では、フロー制御を受信側端末装置において行う。受信側端末装置1において、データパケットの受信に応じてパケット受信速度やパケット損率を検出し、検出した受信速度情報を用いフロー制御手段15において送信側端末装置におけるデータパケットの送信速度情報を作成する。すなわち、フロー制御手段15では、必要に応じて受信データの帯域や送信帯域、パケットロス率等から、送信側端末装置が用いるべき最適な送信帯域を計算し、送信端末装置に通知する。尚、受信帯域の計算には時計手段14を用いることができる。例えば、時計手段により一定時間Tの間に受信したデータ量Dを計算し、D/Tにより受信帯域を計算することができる。また、送信帯域の計算精度を向上させるため、受信側端末装置から送信側端末装置へ宛てた送信帯域の指示に、それらの指示の1つ1つを識別するための指示識別子を一緒に送信し、かつ送信側端末装置から送信されるデータパケットに、前記指示識別子を埋め込むことにより、「どの時点送信速度の指示に基づいているか」を受信端末装置が知ることができる。従って、過去のある時点での送信帯域の指示に基づく確認応答パケットのみ取り出して、個別に受信帯域を測定することができる。或いは、送信側端末装置から送信されるデータパケットに、「現在の送信速度」に関する情報を埋め込むことにより、受信側端末装置では、受信したデータパケットを見るだけで、当該データパケットが送信された時点での帯域を正確に知ることができる。これを受信帯域と比較することにより、パケットロス率を正確に計算することができる。
【0039】
作成した送信速度情報は確認応答送信手段13に供給し、確認応答に含ませ、他の情報と共に送信側端末装置1に送信する。この場合、受信側端末装置から送信側端末装置に送信される確認応答に、「新しい送信帯域」を指示するフィールドを設け、当該フィールドにフロー制御手段で計算された送信速度情報を含めることができる。確認応答は送信側端末装置で受信され、送信速度情報がシェーピング手段11に供給され、シェーピング手段11は、送られてきた確認応答の「新しい送信帯域」フィールドに記された帯域に基づいてデータパケットの送信速度を設定する。このように、受信側端末装置においてフロー制御を行うことにより、送信側端末装置の負荷を軽減することができる。
【図面の簡単な説明】
【図1】従来のTCPによるデータ転送の時系列を示す図である。
本発明に従うデータ転送システムの構成例
【図2】本発明によるデータ転送の時系列の一例を示す図である。
【図3】本発明によるデータ転送システムの一例を示す線図である。
【図4】本発明のパケット処理におけるフィードバック処理を示す図である。
【図5】データパケットの一例を示す図である。
【図6】確認応答パケットの一例を示す図である。
【図7】本発明による確認応答ステップ実装のためのテーブルの一例を示す図である。
【図8】確認応答パケットの一例を示す図である。
【図9】本発明によるコンテンツ配信システムの一例を示す線図である。
【図10】本発明によるコンテンツ配信システムの別の実施例を示す線図である。
【図11】本発明によるコンテンツ配信システムの別の実施例を示す線図である。
【図12】本発明によるデータ転送システムの変形例を示す線図である。
【符号の説明】
1 送信側端末装置
2 受信側端末装置
3 パケット転送ネットワーク
10 パケット送信手段
11 シェーピング手段
12 蓄積手段
13 確認応答送信手段
14 計時手段
15 フロー制御手段
16 再送制御手段
P21 データパケット
P22 確認応答パケット
P31 データパケット
P32 確認応答パケット
Claims (26)
- パケット転送ネットワークを介して複数の端末装置が接続され、送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側の端末装置は、データパケットの受信に応じて送信側の端末装置に確認応答を送信するデータ転送方法において、
送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して前記ネットワークに送信するパケット送信ステップと、
データパケットの受信に応じて、確認応答を、データパケットの受信速度から独立した周期で送信側の端末装置に送信するステップと、
受信したデータパケットを主記憶装置に蓄積する蓄積ステップと、
少なくともデータパケットの受信速度情報を用いてデータパケットの送信速度を制御するフロー制御ステップと、
前記フロー制御ステップにおいて得られた送信速度情報に基づいてパケット送信速度を設定するシェーピングステップとを具えることを特徴とするデータ転送方法。 - 請求項1に記載のデータ転送方法において、前記受信側端末装置から送信側端末装置へ送信される確認応答が、データパケットの受信速度に関する受信速度情報を含み、送信側端末装置は、フロー制御ステップにおいて確認応答に含まれる受信速度情報と設定されている送信速度とに基づいてデータパケットの送信速度を制御することを特徴とするデータ転送方法。
- 請求項1に記載のデータ転送方法において、前記受信側端末装置がデータパケットの受信速度を検出する手段を有し、検出されたデータパケットの受信速度情報を用いてデータパケットの送信速度情報を作成し、当該送信速度情報を確認応答に含ませて送信側端末装置に送信し、前記シェーピングステップにおいて、送信されてきた送信速度情報を用いて前記パケット送信速度を設定することを特徴とするデータ転送方法。
- 請求項1又は2に記載のデータ転送方法において、前記受信側端末装置から送信側端末装置へ送信される確認応答が、受信端末装置で受信されなかったデータパケットに関する情報を含み、前記送信側端末装置は、受信した確認応答に基づいて受信側端末装置で受信されなかったデータパケットを特定し、当該データパケットを再送することを特徴とするデータ転送方法。
- 請求項1から4までのいずれか1項に記載のデータ転送方法において、さらに、ネットワークの利用可能帯域を検出するステップを具え、検出されたネットワークの利用可能帯域に基づいて確認応答の送信周期を動的に制御することを特徴とするデータ転送方法。
- パケット転送ネットワークを介して複数の端末装置が接続され、送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側の端末装置は、データパケットの受信に応じて送信側の端末装置に確認応答を送信するデータ転送システムに用いられるプログラムであって、コンピュータに、
送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して前記ネットワークに送信する手順と、
データパケットの受信に応じて、確認応答を、データパケットの受信速度から独立した周期で送信側の端末装置に送信する手順と、
受信したデータパケットを主記憶装置に蓄積する手順と、
少なくともデータパケットの受信速度情報を用いてデータパケットの送信速度を制御するフロー制御手順と、
パケット転送速度を、前記フロー制御された送信速度に設定するシェーピング手順とを実行させるためのプログラム。 - 請求項6に記載のプログラムにおいて、前記受信側端末装置から送信側端末装置へ送信される確認応答が、データパケットの受信速度に関する受信速度情報を含み、前記フロー制御手順において確認応答に含まれる受信速度情報と設定されている送信速度とに基づいてデータパケットの送信速度を制御するプログラム。
- 請求項6又は7に記載のプログラムにおいて、さらに、受信した確認応答に基づいて受信側端末装置で受信されなかったデータパケットを特定し、当該データパケットを再送する再送制御手順を含むプログラム。
- 請求項6から8までのいずれか1項に記載のプログラムが記録された記録媒体。
- パケット転送ネットワークを介して複数の端末装置が接続され、送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側の端末装置は、データパケットの受信に応じて送信側の端末装置に確認応答を送信するデータ転送システムにおいて、
送信側の端末装置は、送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して前記ネットワークに送信するパケット送信手段と、受信側の端末装置から送られてきた確認応答に基づいてデータパケットの送信速度を制御するフロー制御手段と、前記フロー制御手段からの出力に応じてパケット送信速度を設定するシェーピング手段とを具え、
受信側の端末装置は、受信したデータパケットを蓄積する主記憶装置と、データパケットの受信に応じて確認応答を送信側端末装置に送信する確認応答送信手段とを具え、
前記受信側端末装置の確認応答送信手段は、データパケットを受信した際、確認応答を、受信データパケットの受信速度から独立した周期で送信側端末装置に返送することを特徴とするデータ転送システム。 - パケット転送ネットワークを介して複数の端末装置が接続され、送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側の端末装置は、データパケットの受信に応じて送信側の端末装置に確認応答を送信するデータ転送システムにおいて、
送信側の端末装置は、送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して前記ネットワークに送信するパケット送信手段と、パケット送信速度を設定するシェーピング手段とを具え、
受信側の端末装置は、受信したデータパケットを蓄積する主記憶装置と、データパケットの受信に応じて確認応答を送信側端末装置に送信する確認応答送信手段と、データパケットの受信速度情報を用いて送信側端末装置におけるパケット送信速度を制御するフロー制御手段とを具え、
前記受信側端末装置の確認応答送信手段は、データパケットを受信した際、確認応答を、受信データパケットの受信速度から独立した周期で送信側端末装置に返送することを特徴とするデータ転送システム。 - 請求項10又は11に記載のデータ転送システムにおいて、前記確認応答送信手段は、受信した複数のデータパケットに対する応答を単一のパケットに収めて送信側端末装置に返送することを特徴とするデータ転送システム。
- 請求項10又は11に記載のデータ転送システムにおいて、前記受信帯域装置がデータパケットの受信速度を検出する手段を有し、前記受信側端末装置から送信側端末装置へ送信される確認応答が、受信側端末装置におけるパケット受信速度に関する受信速度情報を含み、前記送信側端末装置のフロー制御手段は、受信した確認応答に含まれる受信速度情報に基づいてパケット送信速度を調整することを特徴とするデータ転送システム。
- 請求項10、11、12又は13記載のデータ転送システムにおいて、送信側の端末装置が、受信した確認応答に基づいて、データパケットの再送を制御する再送制御手段を具えることを特徴とするデータ転送システム。
- 請求項10から14までのいずれか1項に記載のデータ転送システムにおいて、ネットワークの利用可能帯域情報を検出する手段を有し、検出されたネットワークの利用可能帯域情報に基づいて確認応答の送信周期を動的に制御することを特徴とするデータ転送システム。
- 請求項10から15までのいずれか1項に記載のデータ転送システムにおいて、前記データパケットが、少なくともIPヘッダ、UDPヘッダ、パケットのシーケンス番号、及びペイロードを含むことを特徴とするデータ転送システム。
- 請求項10から16までのいずれか1項に記載のデータ転送システムにおいて、前記確認応答が、少なくともIPヘッダ、UDPヘッダ、受信したシーケンス番号、受信速度、確認応答数、受信されなかったシーケンス番号の列を含むことを特徴とするデータ転送システム。
- 請求項10から17までのいずれか1項に記載のデータ転送システムにおいて、前記フロー制御手段は、受信した確認応答パケットに含まれる受信速度と設定されているパケット送信速度とからパケット損率を計算し、その計算結果に基づいてデータパケットの送信速度を調節することを特徴とするデータ転送システム。
- 請求項10から18までのいずれか1項に記載のデータ転送システムにおいて、前記再送制御手段は、受信した確認応答の受信したシーケンス番号と受信されなかったシーケンス番号の列とから再送が必要なパケットを特定することを特徴とするデータ転送システム。
- パケット転送ネットワークを介して、コンテンツ配信サーバと複数の端末装置とが接続され、コンテンツ配信サーバからパケット転送ネットワークを介して端末装置にデータパケットが送信され、データパケットを受信した端末装置は、データパケットの受信に応じてコンテンツ配信サーバに確認応答を送信するコンテンツ配信システムにおいて、
前記コンテンツ配信サーバは、送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して前記ネットワークに送信するパケット送信手段と、受信側の端末装置から送られてきた確認応答に基づいてデータパケットの送信速度を制御するフロー制御手段と、前記フロー制御手段からの出力に応じてパケット送信速度を設定するシェーピング手段とを具え、
前記端末装置は、受信したデータパケットを蓄積する主記憶装置と、データパケットの受信に応じて確認応答を送信側パケット送受信装置に送信する確認応答送信手段とを具え、
前記端末装置の確認応答送信手段は、データパケットを受信した際、確認応答を、受信データパケットの受信速度から独立した一定の周期で送信側のパケット送受信装置に返送することを特徴とするコンテンツ配信システム。 - 請求項20に記載のコンテンツ配信システムにおいて、前記端末装置から構成配信サーバに送られる確認応答が、当該端末装置におけるデータパケットの受信速度情報を含み、前記フロー制御手段は、受信した確認応答に含まれる受信速度情報に基づいてパケット送信速度を制御することを特徴とするコンテンツ配信システム。
- 請求項20又は21に記載のコンテンツ配信システムにおいて、前記コンテンツ配信サーバは、データパケットの再送を制御する再送制御手段を有し、当該再送制御手段は、受信した確認応答に含まれるデータパケットのシーケンス番号情報に基づいて再送すべきデータパケットを特定することを特徴とするコンテンツ配信システム。
- 請求項20、21又は22に記載のコンテンツ配信システムにおいて、前記端末装置を、携帯型情報端末装置、パーソナルコンピュータ、又は携帯電話としたことを特徴とするコンテンツ配信システム。
- 請求項20から23までのいずれか1項に記載のコンテンツ配信システムにおいて、前記パケット転送ネットワークに接続されている1つの端末装置を別のコンテンツ配信サーバとし、一方のコンテンツ配信サーバから他方のコンテンツ配信サーバにデータパケットが送信され、他方のコンテンツ配信サーバから前記一方のコンテンツ配信サーバに確認応答が送信されることを特徴とするコンテンツ配信システム。
- 送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側のパケット送受信装置は、データパケットの受信に応じて送信側のパケット送受信装置に確認応答を送信するパケット転送システムに用いられる端末装置であって、
送信すべきデータからデータパケットを作成し、当該データパケットをパケット単位のシーケンス番号を付加して送信するパケット送信手段と、
データパケットの受信に応じて、データパケットの受信速度から独立した周期で確認応答を送信する確認応答送信手段と、
データパケットの受信速度情報を用いてデータパケットの送信速度を制御するフロー制御手段と、
前記フロー制御手段からの出力に応じてパケット送信速度を設定するシェーピング手段と、
受信したデータパケットを蓄積する主記憶装置とを具えることを特徴とする端末装置。 - 送信側の端末装置からパケット転送ネットワークを介して受信側の端末装置にデータパケットが送信され、受信側のパケット送受信装置は、データパケットの受信に応じて送信側のパケット送受信装置に確認応答を送信するパケット転送システムに用いられる端末装置であって、
送信側端末装置から、パケット単位のシーケンス番号が付加されて送られてきたデータパケットを受信する手段と、
受信したデータパケットを記憶する記憶手段と、
受信したデータパケットからデータパケットの受信速度情報を作成し、当該受信速度情報を含む確認応答を作成する手段と、
前記作成した確認応答を、データパケットの受信速度から独立した一定の周期で送信側端末装置に送信する確認応答送信手段とを具えることを特徴とする端末装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002233363A JP2004080070A (ja) | 2002-08-09 | 2002-08-09 | データ転送方法及びデータ転送システム並びにコンテンツ配信システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002233363A JP2004080070A (ja) | 2002-08-09 | 2002-08-09 | データ転送方法及びデータ転送システム並びにコンテンツ配信システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004080070A true JP2004080070A (ja) | 2004-03-11 |
Family
ID=32018505
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002233363A Pending JP2004080070A (ja) | 2002-08-09 | 2002-08-09 | データ転送方法及びデータ転送システム並びにコンテンツ配信システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004080070A (ja) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007166281A (ja) * | 2005-12-14 | 2007-06-28 | Casio Hitachi Mobile Communications Co Ltd | データパケット転送装置、データパケット転送方法、及び、データパケット転送プログラム |
JP2008535080A (ja) * | 2005-03-31 | 2008-08-28 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 順不同で配信されるデータの保護 |
JP2008219170A (ja) * | 2007-02-28 | 2008-09-18 | Nippon Hoso Kyokai <Nhk> | ファイル送信装置およびファイル送信プログラム、ならびにファイル受信装置およびファイル受信プログラム |
JP2010263350A (ja) * | 2009-05-01 | 2010-11-18 | Nec Corp | 通信装置、擬似応答装置、送信レート制御方法およびプログラム |
WO2011033894A1 (ja) * | 2009-09-16 | 2011-03-24 | 株式会社日立製作所 | 端末間の通信を高速化する通信装置および通信システム |
JP2011071764A (ja) * | 2009-09-25 | 2011-04-07 | Nippon Hoso Kyokai <Nhk> | ファイル送受信システム、ファイル受信装置、ファイル送信装置、ファイル中継装置、ファイル差替え装置、ファイル合成装置及びプログラム |
WO2011048740A1 (ja) * | 2009-10-19 | 2011-04-28 | 日本電気株式会社 | データ伝送システム、送信速度制御方法、受信端末、送信端末 |
JPWO2010070699A1 (ja) * | 2008-12-15 | 2012-05-24 | 富士通株式会社 | データ送信方法 |
WO2012066824A1 (ja) | 2010-11-16 | 2012-05-24 | 株式会社日立製作所 | 通信装置および通信システム |
US8223766B2 (en) | 2007-02-28 | 2012-07-17 | Fujitsu Limited | Communication method for system including client device and plural server devices |
WO2019239541A1 (ja) * | 2018-06-14 | 2019-12-19 | 三菱電機株式会社 | 電気機器、通信システム、及び制御方法 |
CN116321250A (zh) * | 2023-05-23 | 2023-06-23 | 北京星河亮点技术股份有限公司 | 数据转发***及方法 |
JP7474078B2 (ja) | 2020-03-10 | 2024-04-24 | 日本放送協会 | 配信サーバ及びプログラム |
-
2002
- 2002-08-09 JP JP2002233363A patent/JP2004080070A/ja active Pending
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4903780B2 (ja) * | 2005-03-31 | 2012-03-28 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 順不同で配信されるデータの保護 |
JP2008535080A (ja) * | 2005-03-31 | 2008-08-28 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 順不同で配信されるデータの保護 |
US8352727B2 (en) | 2005-03-31 | 2013-01-08 | Telefonaktiebolaget L M Ericsson (Publ) | Protection of data delivered out-of-order |
JP2007166281A (ja) * | 2005-12-14 | 2007-06-28 | Casio Hitachi Mobile Communications Co Ltd | データパケット転送装置、データパケット転送方法、及び、データパケット転送プログラム |
JP4624252B2 (ja) * | 2005-12-14 | 2011-02-02 | Necカシオモバイルコミュニケーションズ株式会社 | データパケット転送装置、データパケット転送方法、及び、データパケット転送プログラム |
JP4714172B2 (ja) * | 2007-02-28 | 2011-06-29 | 日本放送協会 | ファイル受信装置およびファイル受信プログラム |
US8223766B2 (en) | 2007-02-28 | 2012-07-17 | Fujitsu Limited | Communication method for system including client device and plural server devices |
JP2008219170A (ja) * | 2007-02-28 | 2008-09-18 | Nippon Hoso Kyokai <Nhk> | ファイル送信装置およびファイル送信プログラム、ならびにファイル受信装置およびファイル受信プログラム |
JPWO2010070699A1 (ja) * | 2008-12-15 | 2012-05-24 | 富士通株式会社 | データ送信方法 |
JP2010263350A (ja) * | 2009-05-01 | 2010-11-18 | Nec Corp | 通信装置、擬似応答装置、送信レート制御方法およびプログラム |
WO2011033894A1 (ja) * | 2009-09-16 | 2011-03-24 | 株式会社日立製作所 | 端末間の通信を高速化する通信装置および通信システム |
JP5175982B2 (ja) * | 2009-09-16 | 2013-04-03 | 株式会社日立製作所 | 端末間の通信を高速化する通信装置および通信システム |
US9118609B2 (en) | 2009-09-16 | 2015-08-25 | Hitachi, Ltd. | Communication apparatus and communication system for enhancing speed of communication between terminals |
US8605745B2 (en) | 2009-09-16 | 2013-12-10 | Hitachi, Ltd. | Communication apparatus and communication system for enhancing speed of communications between terminals |
JP2011071764A (ja) * | 2009-09-25 | 2011-04-07 | Nippon Hoso Kyokai <Nhk> | ファイル送受信システム、ファイル受信装置、ファイル送信装置、ファイル中継装置、ファイル差替え装置、ファイル合成装置及びプログラム |
WO2011048740A1 (ja) * | 2009-10-19 | 2011-04-28 | 日本電気株式会社 | データ伝送システム、送信速度制御方法、受信端末、送信端末 |
WO2012066824A1 (ja) | 2010-11-16 | 2012-05-24 | 株式会社日立製作所 | 通信装置および通信システム |
US9124518B2 (en) | 2010-11-16 | 2015-09-01 | Hitachi, Ltd. | Communication device and communication system |
US9979658B2 (en) | 2010-11-16 | 2018-05-22 | Hitachi, Ltd. | Communication device and communication system |
WO2019239541A1 (ja) * | 2018-06-14 | 2019-12-19 | 三菱電機株式会社 | 電気機器、通信システム、及び制御方法 |
JPWO2019239541A1 (ja) * | 2018-06-14 | 2020-12-17 | 三菱電機株式会社 | 電気機器、通信システム、及び制御方法 |
JP7004815B2 (ja) | 2018-06-14 | 2022-01-21 | 三菱電機株式会社 | 空調機、通信システム、及び制御方法 |
JP7474078B2 (ja) | 2020-03-10 | 2024-04-24 | 日本放送協会 | 配信サーバ及びプログラム |
CN116321250A (zh) * | 2023-05-23 | 2023-06-23 | 北京星河亮点技术股份有限公司 | 数据转发***及方法 |
CN116321250B (zh) * | 2023-05-23 | 2023-09-19 | 北京星河亮点技术股份有限公司 | 数据转发***及方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4520032B2 (ja) | ヘッダ圧縮装置およびヘッダ圧縮方法 | |
US9043486B2 (en) | Data transfer method, system and protocol | |
JP4000905B2 (ja) | 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
US9413494B2 (en) | FEC-based reliable transport control protocols for multipath streaming | |
CN104836748B (zh) | 拥塞控制比特率算法 | |
KR101229768B1 (ko) | 무선 패킷 네트워크용 블록 확인응답 프로토콜 | |
US6141324A (en) | System and method for low latency communication | |
JP4016387B2 (ja) | データフロー制御方法 | |
JP4623616B2 (ja) | データ伝送方法および装置 | |
US20030023746A1 (en) | Method for reliable and efficient support of congestion control in nack-based protocols | |
CN110677221B (zh) | 重传控制方法、通信接口和电子设备 | |
US8306062B1 (en) | Method and apparatus of adaptive large receive offload | |
US20040246974A1 (en) | Storing and accessing TCP connection information | |
US20050135252A1 (en) | Transparent optimization for transmission control protocol flow control | |
JP2004080070A (ja) | データ転送方法及びデータ転送システム並びにコンテンツ配信システム | |
US20070291782A1 (en) | Acknowledgement filtering | |
WO2019144802A1 (zh) | 一种数据的传输方法及其相关设备 | |
US8578040B2 (en) | Method, system and article for client application control of network transmission loss tolerance | |
US20220368765A1 (en) | Universal Transport Framework For Heterogeneous Data Streams | |
US11811877B2 (en) | Universal transport framework for heterogeneous data streams | |
US20240154735A1 (en) | Method and apparatus for transmitting objects based on deadline-aware | |
CN117394953A (zh) | 一种quic自适应数据重传方法、装置及*** | |
He et al. | TCP/IP header compression scheme over lossy links |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050809 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050906 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060314 |