JP4589406B2 - バルク・データ転送 - Google Patents

バルク・データ転送 Download PDF

Info

Publication number
JP4589406B2
JP4589406B2 JP2007548581A JP2007548581A JP4589406B2 JP 4589406 B2 JP4589406 B2 JP 4589406B2 JP 2007548581 A JP2007548581 A JP 2007548581A JP 2007548581 A JP2007548581 A JP 2007548581A JP 4589406 B2 JP4589406 B2 JP 4589406B2
Authority
JP
Japan
Prior art keywords
data
rate
injection rate
block
time
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.)
Active
Application number
JP2007548581A
Other languages
English (en)
Other versions
JP2008526132A (ja
Inventor
マンソン,マイケル,シー.
シム,サーバン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aspera Inc
Original Assignee
Aspera Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Aspera Inc filed Critical Aspera Inc
Publication of JP2008526132A publication Critical patent/JP2008526132A/ja
Application granted granted Critical
Publication of JP4589406B2 publication Critical patent/JP4589406B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/18End to end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Optical Communication System (AREA)
  • Traffic Control Systems (AREA)
  • Medicines Containing Plant Substances (AREA)
  • Mechanical Pencils And Projecting And Retracting Systems Therefor, And Multi-System Writing Instruments (AREA)

Description

[関連出願]
本出願は、35U.S.C.第119(e)条に基づき、2004年12月24日出願の米国仮特許出願第60/638,806号、2005年2月1日出願の米国仮特許出願第60/649,198号、および2005年2月1日出願の米国仮特許出願第60/649,197号による特典を主張する。これら出願の全明細書がここに含まれている。
本発明の主題は、ネットワーク・データ通信に関するものであり、より具体的には、バルク・データ転送用プロトコルに関する。
ネットワークの帯域幅および世界的規模のインターネットを通してのユビキタスなユーザー同士間の相互接続が最近増大していること、そして、ビジネスにおいてまた消費者ユーザーによって処理されるデジタル・データの量が増大していることから、ネットワークを利用してのバルク・データ(ファイルおよびディレクトリー)の転送に対する要求がかってないほどに高まってきている。 特に、ユーザーは、より高い帯域幅のネットワークを通してより遠距離のネットワークへより大きなファイルを転送したいと望んでいる。
このようなデータ転送経路では、帯域幅に障害となるボトルネックが多く生ずると共に地理的距離によるラウンド・トリップ遅延が生ずるだけではなく、パケット損失の期間が生じ、且つ伝送媒体(例えば無線)そのものにより変化する遅れ、および変化するそして時として過剰なデータトラフィックの輻輳からくる遅れが生じていた。
伝送制御プロトコル(Transmission Control Protocol:TCP)に基づく従来のバルク・データ転送用プロトコルは、帯域幅と遅延時間の積が大きいネットワークにおいては、TCPの性能が劣ることから、標準的な地球規模のインターネット経路の深刻な性能制限によって悩まされていた。このため、帯域幅と遅延時間が共に大きいネットワークにおけるバルク・データの転送の性能(転送速度、および帯域幅の活用)を改良するための別の転送プロトコルの実現に関心が集中していた。しかしながら、現在進められている試みは、主としてインターネット・コアのリンクでの改良されたスループットおよび改良された帯域幅の活用を提供するもので、比較的低いビット・エラー・レート(BER)を有するとともに十分な帯域幅を有し、データ・トラフィック量の輻輳を避けることができる。しかしながら、ユーザーによるデータ転送の大部分は、ネットワークのエッジからエッジまでに広がっており、地理的距離に起因する大きなラウンド・トリップ遅延が生ずるばかりでなく、パッケット逸失期間および典型的な「エッジ」ネットワーク特有の可変遅延特性が生ずる。かかる典型的なエッジ・ネットワークにおいては、現在の手法では、帯域幅をフルに活用することができないし、輻輳が進むにつれて変化するスループットにより悩まされることになる。更に、かかる試みでは、時間が重要なビジネス処理や厳しい消費者ユーザーからの転送時間についての要求に対して十分な保証を提供することができない。更に、限られた例ではあるが、かかる試みによりスループットは確かに改良されるが、それは、別のネットワーク・アプリケーションとの帯域幅の公平な分け合いをないがしろにして行われており、かかる帯域幅の分け合いについてはユーザーには何らの権限も与えられていない。エンド・ユーザーは、性能的には劣るけれども「公平な」標準的TCPを採用するか、或いは帯域幅の公平さはないがしろにしても場合によっては改良されたスループットが提供される別の新しいプロトコルとするかという選択を迫られることになる。これは、インターネット・コアにおいては受け入れられるかもしれないが、データの転送はそのネットワークにおいて利用可能な帯域幅に限定されている「時として過剰加入者状態となるエッジ・ネットワーク」では受け入れられない。従って、 TCPプロトコルを現在或いは将来実施することも考慮した上で、上述した問題点に対処でき、且つ改良されたスループットと、ネットワークの距離もしくは輻輳度(そして関連する遅延時間およびパケット逸失)に関係なく予測可能な転送速度と、帯域幅が使われていないときにはその他のデータ・トラフィックと比例的に帯域幅を分かち合う能力とを提供できるようにした、データ転送のためのシステムが必要とされている。
上述した問題点およびここではっきりとは取り上げてはいないその他の問題点については、本発明の主題がその狙いとするところであるが、本明細書を読み且つ検討することにより理解されることなろう。
本発明の主題によれば、リライアブルなネットワーク・データ転送システムが提供される。このシステムは、ネットワークを通してデータを転送し、、ソフトウェア・データ転送アプリケーションを使用してネットワークのデータ転送レートに改善を施す目的のために有用なものである。
本システムのいくつかの実施例は、アプリケーション・レベル(カーネル・スペースではなくユーザー・スペース)のバルク・データ転送用プロトコルであって、(帯域幅、遅れ、および逸失レートが任意の)コモディティ・ネットワークを通して、固有の転送レート制御を可能とするに十分な転送効率で高バルク・データ転送速度をもたらすことのできるプロトコルを提供する。その結果、本システムは、世界共通のコモディティ・ネットワークにおいて、安定なしかも予測可能な特長を持ちながら、完全で設定可能な(configurable)転送レートをリアルタイムで制御できるアプリケーションを提供することができる。
本発明システムのいくつかの実施例は、大きな且つ成長しつつあるコモディティ・エッジ・ネットワークの領界向けのデータ転送を目的としている。いくつかの実施例は、また、コモディティ・ネットワークを利用した単一ストリーム・データ転送に高度な制御性と透明性とを与える。より具体的には、ネットワーク遅れとパケット逸失とに伝送効率と安定性が依存しないことの直接の結果として、本発明の実施例のシステムはそのレート制御からその信頼性アルゴリズムを切り離すことができ、ネットワークの状態に関係なく、アプリケーションに対する正確で遺漏のない転送レートのリアルタイムによる制御を提供する。このことは、予測し得る転送時間に対する絶対転送レートのプリセットと、リアル・タイム制御を含むと共に、TCPフロー(標準TCPおよび新興の新しいTCPの両方)との1対1の公平性といった共有リンクでの他のデータ・トラフィック量に関係する帯域幅の利用の制御を含んでいる。それとは逆に、いくつかの実施例は、転送性能およびダイナミック・ネットワーク・パラメータについてリアルタイムの視認性を提供する。
別の実施例は、また、オペレーション・システムおよびファイル・システムに依存しない転送を必要とするアプリケーションにふさわしいプログラマティックなインターフェースを、一般化されたバルク・データ転送に提供する。これら実施例のサービス・レイヤーは、他のアプリケーションと関連して実行されるバックグラウンド・サービスとして、各種のコンピューティング装置へ内蔵して使用され、専用のコンピュータシステムを必要としない。データ転送に加え、前記サービス・レイヤーは、セキュリティ(安全性:認証および暗号化)、同じもしくは別のサーバーからの自動復旧転送、ネットワークの機能休止またはネットワークのローミング(例えば携帯電話から固定無線へ)の場合の自動再スタート、およびURLリンクのようなファイル・リファレンスからの起動等を含む現代の商業的アプリケーションによって要求される一般的なアプリケーション能力を提供する。
本発明システムのいくつかの実施例は、注入レートから転送経路上のパケット逸失レートを差引いた差に等しい有用なスループットを確かなものとする、高度に効率的な信頼性のあるメカニズムを提供する。このメカニズムを有する実施例は、従来の信頼できるUDP転送にはよくあったデータ伝送の重複(変わりやすいネットワーク遅延時間および無視できないパケット逸失レートの存在のもと)を防止することができる。いくつかの実施例は、また、信頼性メカニズムに依存しない注入レート制御を有している。信頼性メカニズムは、ネットワークの状態に依存せずに高効率を確かなものとするので、ときとして「輻輳コラプス」と言われる「低実用スループット」の原因となるプロトコルの性能劣化を防ぐことができる。更に別の実施例は、目標転送レートへの速やかな収束と平衡点における安定したスループットとを可能とする等式ベースのレート制御を含んでいる。かかる実施例のいくつかでは、システムは、ネットワークの輻輳をランダム・エラー(BER)によるパケット逸失と正確に区別するために、アプリケーションレベルのプロトコルにおけるネットワーク待機遅れを使用して輻輳を検出する。更に別の実施例は、目標転送レートを転送前および転送中にセットできる能力をシステムに提供している。レートは、固定されたものでもよいし、標準TCP、或いは新たな新生TCPまたは他の転送実行手段に関連して設定可能なアグレッシブネスによってダイナミックに適応できるようにしてもよいし、優先順位ポリシーに従ってダイナミックに適応できるようにしてもよい。
本発明システムのこれらの要素およびその他の要素は、アプリケーション用のプログラマテッック管理インターフェースに具体化されており、同インターフェースは、システムの転送の完全な制御とモニタリングとを提供する。他の実施例は、独立型のアプリケーション、オペレーション・システムのプラグ・イン、ユティリティ・アプリケーション、ハードウェア・コンポーネント、その他ここに記述されているシステムのサービスを提供できるもの全ての別のタイプのソフトウェアおよびハードウェア構成を含む。
ここに記述された概要は、本出願の教示するところのいくつかを概説するものであり、本発明主題専用の且つ網羅的な扱いを意図したものではない。更に、本発明主題についての詳細は、発明の詳細な説明と添付された特許請求の範囲に見出すことができる。本発明のその他のアスペクトは、当業者であれば、以下の詳細な記述を読み且つ理解し、説明の一部である図面を見ることによって明らかであろう。本発明の範囲は、添付された特許請求の範囲およびそれらの法的同等物によって明確にされる。
以下の詳細な説明は、本明細書の一部である添付の図面を参照してなされるが、同図面には、発明の主題を実現化できる具体的な実施例が図解的に示されいる。これらの実施例は、当業者が実施できるように十分詳細に説明されているが、その他の実施例も利用可能であること、そして構成的な、論理的な、電気的な変更は、本発明の主題の範囲から逸脱することなくなされ得ることは理解される。それ故、以下の説明は、限定的に捉えるべきではなく、発明の主題の範囲は、ここに一体の特許請求の範囲およびそれらの法的同等物によって画定される。
ここに提示されているシステムは、異なる実施例において、ハードウェア、ソフトウェア、ファームウェア、およびハードウェアおよび/またはソフトウェアおよび/またはファームウェアの組合せによって実現できることが理解される。 種々の実施例において、本システムの機能は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せに導入されているモジュールに対応できることが理解される。 ここに提示されている例は、モジュールごとに一つもしくはそれ以上の機能を組み合わせることができるが、機能の別の組み合わせも本発明の主題の範囲を逸脱することなく実現化することができる。
種々の実施例において、ソフトウェア部は、デジタル信号プロセッサー、ASIC、マイクロプロセッサー、マイクロコントローラ、或いは別タイプのプロセッサーを含む(ただし、これらに限定されないが)装置を用いることにより実行される。本発明の主題を実施化できる環境には、ネットワーク装置を有するコンピュータ環境、例えばコンピュータ、サーバー、ルーター、ゲ−トウェイ、LAN、WAN,イントラネット、および/またはインターネット・パスウェイまたはその他のネットワーク接続装置など(ただし、これらに限定されないが)が含まれる。
いくつかの実施例は、モジュール間でまたはモジュールを介して通信される関連するコントロール(制御)とデータ信号とを有する二つもしくはそれ以上の特定の且つ相互接続されたハードウェア・モジュールまたは装置、あるいはアプリケーション固有の集積回路における機能を実現する。それ故、例示的なプロセスのフローはソフトウェア、ファームウェアおよびハードウェアの実行に適用可能である。
本出願は、2004年12月24日出願の米国仮特許出願第60/638,806号に関連しており、その全明細書がここに含まれている。
本発明の主題による種々の実施例がここに提示されている。第1図は、本発明の主題の一実施例にかかわるシステム100の模式的ブロック図である。システム100は、ネットワーク122により接続された第1ノード102と第2ノード132とを有している。
第1ノード102はプロセッサー104、メモリー106、バス114に連結されたネットワーク・インターフェース112とを有している。 第1ノード102は、任意ではあるが、例えばディスク110のような記憶装置、出力装置116、および入力装置118を有することができる。第2ノード132は、プロセッサー134、メモリー136、およびバス144に連結されたネットワーク・インターフェース142を備えている。第2ノード132は、任意ではあるが、例えばディスク140のような記憶装置、出力装置146、および入力装置148を有することができる。変形例において、第1ノード102および第2ノード132のメモリー106、136は、ソフトウェア108、138を有するものとして図示されている。かかるソフトウェアは、ネットワーク・インターフェースに対して少なくともデータを伝達するための機能を備えている。変形実施例および応用例においては、かかるソフトウェアは、記憶装置110、140を含む(ただしこれらに限定されないが)一つもしくはそれ以上のソースからメモリー108、138へロードされる。
種々の実施例において、ネットワーク122は、一つもしくはそれ以上のインターネット(INTERNET)、ローカル・エリア・ネットワーク(「LAN)、イントラネット、ワイド・エリア・ネットワーク(「WAN」)、その他のタイプのネットワークを含んでいる。
ソフトウェア108、138は、ノード102、132がネットワーク122を通してデータを交換できるように、各ノード102、132のプロセッサー104、134上で動作する。ソフトウェア108、138は、ノード102、132に対して、データの交換に関連する種々のアクションを遂行させる。以下に例示されているように、かかるアクションには、種々の定期的確認方法によるデータの交換が含まれている。
ここで述べられているデータ転送とは、エンド・ツー・エンドの「転送」経路という言葉で表される。 転送経路は、IPネットワークを介して例えば第1ノードのようなソース・ホストから、例えば第2ノード132のような目的地ホストまで伸びている。かかる転送経路はその特徴として、「ボトルネック帯域幅」、「ネットワーク・ラウンド・トリップ時間」、および経路ラウンド・トリップ時間を有している。
経路ボトルネック帯域幅というのは、転送経路全長にわたる最小転送容量(単位時間あたりのデータ単位)のことであって、第1ノード102および第2ノード132のような送信側ホストおよび受信側ホストのボトルネック容量と、一回もしくはそれ以上のネットワーク・ホップを含むネットワーク122のボトルネック容量とを含んでいる。 ノード102、132のボトルネック容量とは、データ転送に用いられる手段の最小データスループット(単位時間あたりのデータ)のことであって、そこには、記憶装置110、140もしくはメモリー106、136の読み出し/書き込み速度、ホスト・バス114、144の速度、プロセッサー104、134の速度、およびネットワーク・インターフェース112、142の速度が含まれる。 ネットワーク122のボトルネック容量とは、転送経路を備えたネットワーク・リンク個々の最小帯域幅である。
経路ラウンド・トリップ時間(「経路RTT」)とは、一つのデータ・ユニットが、データ受信側からソース側へ送られまた元へ戻るまでに必要な時間のことである。例えば、経路RTTは、第2ノード132、記憶装置140もしくはメモリー136からのデータ・ユニットを読みだす時間、ネットワーク122を通して第1ノード102へデータ・ユニットを返送する時間、同データ・ユニットをメモリー106へ読み出す時間、および、データ・ユニットをネットワーク122を通して第2ノード132へ送り返して同データ・ユニットをメモリー136へ読み出す時間を含んでいる。一つの例では、 時間は、伝送の開始および最終的に受け取ったときの時間を示すパケット上のタイム・「ティック」を用いて計測される。
ネットワーク・ラウンド・トリップ時間(ネットワークRTT)とは、一つのデータ・ユニットが、受信側ホストによってネットワークへ送り出された時間から始まり、同データが送信側ホストへ到着し続いて受信側ホストへ戻ってくるまでの時間のことであり、時として「ネットワーク・レイテンシー」と言われるものである。
種々の実施例において、ネットワークRTTは、目的地ホストで「通信スタック」を下る要求のための時間(ネットワーク・プロトコル・レイヤー−オペレーティング・システム内のネットワーク・スタック−物理的インターフェース)、送信側ホストへネットワークを上る要求のための時間、送信側ホストが再伝送要求を受信し、次に予定されたデータ・ユニットを送信するための時間(入力してくる再伝送要求を受信するために「スタックを上る」経路(物理的インターフェース−オペレーティング・システム内のネットワーク・スタック−システム・プロトコル・レイヤー)、及び次に予定されたデータ・ユニットを送信するために「スタックを下る」経路(システム・プロトコル・レイヤー−オペレーティング・システム上のネットワーク・スタック−物理的インターフェース)を含む)、その上、目的地ホストへネットワークを伝わるための時間を含む。
所定の転送経路における帯域幅と遅延時間の積(BDP)は、その経路における総データ容量であり、ボトルネック帯域幅にラウンド・トリップ時間を乗じたものに等しい。BDPはネットワーク・ラウンド・トリップ時間と称されるが、非常に高い帯域幅のネットワークの場合、ボトルネック帯域幅およびBDPは、実際には、ホストの帯域幅によって決定され得る。
データの転送は、「データ注入レート」、「受取りレート」、および「有用受取りレート(useful reception rate)」という言葉で定義づけられ、これらは「効率」を左右する。データ注入レート(「Ri(t)」)とは、送信側がデータをネットワークへ注入するレート(例えば1秒当たりのビット数またはバイト数で計測される)のことであり、送信側は、送信アプリケーションのためにそのレートでデータをネットワークへ注入する。 データ受取りレート(「Rr(t)」)とは、受信側がネットワーク122からデータを読み込むレートのことであり、受信側は、そのレートでネットワ−クからデータを読み込む。有用受取りレート(「Ru(t)」)とは、受信側が「有用」なデータを受け取るレートのことであり、受信側は、そのレートで有用なデータを受取る。有用なデータには、その受取り時より前には受取られていなかったデータ(例えば、重複データ)が含まれる。
また、本説明の全般にわたって使われている言葉に「重複受信レート」と、「転送効率」という言葉がある。重複受取りレート(「Rd(t)」)とは、受信側がそのレートで既に受取られているデータを受取るレートのことである。
転送効率とは、総受信レートに対する有用受信レートの比(Ru/Rr)である。最大転送効率(100%)は、RuがRrに接近し、重複・データが全く受取られていない場合である(即ち、プロトコルの冗長データ・オーバーヘッドは無視できることを意味している)。 即ち:

「完全に効率的な」プロトコルは、要求されたデータの全てを転送する。 このことは、転送経路上でのパケット逸失による逸失データが冗長な転送なく転送される必要があることを意味している。ここで、効率とは、帯域幅の利用と同じではない、ということに注意を要する。
種々の実施例による安定システム100は、パケット逸失、ネットワーク遅延及び、パケット逸失とネットワーク遅延のバリエーションなどに直面しても動揺することのない安定した状態のスループットに集中する。このことにより、システム102のアプリケーション108は、システム100の安定性を乱すことなく任意のデータ注入レートRiを選択することができる。もし、システム100が固定した目的とするレートを用いたとすると、データはネットワーク122へ絶えず注入され、「バースト」が生ずることはない。いくつかの実施例においては、システム100はダイナミックに適応できるレートを使用しており、そのレートは、高レートでの安定のために、現在の伝送レートではなく、平衡点からの距離に比例した平衡レートとなる。ダイナミックに適応できるレートを使用する安定したプロトコルは、転送経路に介在するルーター・バッファーを満杯にすることがなく、また、小さな「マイス」トラフィックを悪化させることもない。
いくつかの実施例では、システム100の性能を計測するために使用されるパラメータを有している。同パラメータには、「予測可能性」、「帯域幅の公平さ」、および「独立したレート制御」が含まれる。 前記有用受信レート(Ru)は、もし転送スループットおよび時間が、例えば変化するラウンド・トリップ遅延であるとかパケット逸失などの変動予測不可能な経路状態以上に確定的であるならば、「予測可能」である。
もしもTCPに競合する一つのフローが同等にアグレッシブでありかつ同等の割合で、即ち例えば各フローのレートがN個の競合するフローに対してBW/Nであるであるように、ボトルネック帯域幅を分かち合うのであれば、そのプロトコルは標準TCPに対して「帯域幅−公平」(「TPCフレンドリーな」)と見なされる。コモディティ・ネットワークの高い性能と公平さについては、信頼できる転送プロトコルはTCPと適正に共用ができて、且つ「最大−最小」の公平さを有する。あるTCPのフローが完全に比例した割り当て分の帯域幅を使用していない場合、いくつかの実施例において、システム100は、使われずに残っている帯域幅を使用する。
システム100は、もしもデータの注入レートが、信頼性メカニズムと結びついていない場合、システム100は、「独立レート制御」を提供する。そして、システム100は、レート制御を操作するアプリケーションへのインターフェースを開示する。操作可能な種々の実施例におけるいくつかのパラメータは、目標レートまたは最大/最小範囲、相対的なアグレッシブネス、および優先順位ポリシーなどの独立したレート設定を含んでいる。いくつかの実施例において、システム100は、アプリケーションに対して、インテリジェント・フィードバック、例えば、性能に関する統計、有効レート、転送される連続したバイト、およびラウンド・トリップ時間という形で計測されたネットワーク・インパクト、転送経路におけるパケット逸失、およびプロトコル・オーバーヘッドなど、も提供する。
上述したシステム100の特性(パケット逸失、ネットワーク遅れ、いろいろな種類のパケット逸失およびネットワーク遅れ、効率Ru/Rr〜1および独立レート制御)を実行するために、本発明によるバルク・データ転送システムの実施例は、以下のプロセスを提供する。
a.ブロックが逸失したときは、再伝送の要求は受信側に記憶される
b.再伝送要求のストレージは、以下のデータ構成特性を有している:
i.ストレージへの挿入時間は一定時間O(1)内になければならない
ii.要求されるべき検索もしくは再伝送は、一定時間O(1)内になければならない
iii.再伝送されたブロックが受信されたときに、待機している再伝送の要求を見つけ無効にすることは一定時間O(1)内になければならない
c.送信側で受け取られた再伝送の要求は、送信側ストレージに記憶される。送信側ストレージは、パケット逸失が大きくなったときに大きくなってはならない。
i.受信側は、送信側が再伝送されたブロックを送ることのできるレートで再伝送の要求を送るだけであること、
ii.再伝送要求の送信側ストレージは、一定の挿入時間を考慮しなければならないが(ここに提案する実施例では、対数挿入時間O(log(n))を用いている)、送信側記憶装置は、パケット逸失が増大しても大きくならないので、挿入時間は実用上一定である。
iii.送信側は、ディスク読み取り性能を最適化するためにブロックを再伝送しなければならないので、記憶された最小再伝送インデックスを見つけ出すことも一定時間O(1)内になければならない。
d.再伝送の要求は、送信側に遅滞なく到達しなければならない。受信側は再伝送の要求を、送る必要のある再伝送の要求の量とそれらが送られるときのレートとを考慮して、可能な限り最小のパケットとして送り出す。
e.受信システムは、入力データを、それが受け取られたときのレートで処理しなければならない。もしもデータが受信システムのディスクに書き込まなければならない場合、それは適切に行われなければならない。
f.もしも受信システムが、システム制限により、入力データをそれが受け取られたときのレートで処理できない場合、入力データはドロップされ、ドロップされたブロックは、再伝送メカニズムの目的のために逸失したものとみなされる。
第2図は、本発明の一実施例によるシステム200のブロック図である。システム200は送信システム201および受信システム226を有している。送信システム201および受信システム226は、ネットワーク224を通して接続されている。
システム200で示された実施例の送信システム201は、一組のモジュ-ルを有している。これらモジュールには、転送開始モジュール222、データ・ファイル・システム・ソース・モジュール218、データ・アプリケーション・ソース・モジュール、ブロック・ハンドラー・モジュール206、およびオプショナルな暗号化モジュール208が含まれている。送信システム201は更に、ブロック排出モジュール210、フィードバック・リーダー・モジュール216、レート制御モジュール214、再伝送モジュール212、管理インターフェース・モジュール204、および転送開始モジュール222を含んでいる。
転送開始モジュール222は、受信システム226との制御チャンネルの確立を行う。 制御チャンネルは、信頼可能な或いは信頼不可能なベース・トランスポート(例えば、TCPもしくはUDP)を使用し得る。制御チャンネルは更に、セキュア・ソケット・レイヤー(「SSL」)とかセキュア・シェル(「SSH」)といった公開−秘密鍵法を使用することによってその安全が確保され得る。制御チャンネルを使用することによって、転送開始モジュール222は、受信システム226へ資格認定書を送り、送信アプリケーションの認証を行い、任意ではあるが、データの暗号化に使用されるパー・セッション対称暗号化キーを交換することができる。転送開始モジュール222は更に、例えばブロックの大きさ、目標とするレートなどといった転送パラメータについてのネゴシエーションを行い、目的地向けファイルを構成しかつ一部転送の再開のためにファイルもしくはディレクトリィ・メタデータを交換する。メタデータは、ファイル名とか、サイズとか、アクセス制御パラメータとか、チェックサムといった属性データを含んでいる。
データ・ファイル・システム・ソース・モジュール218は、送信システム201のファイル・システム218を介してディスク22もしくは送信システム201にアクセス可能なディスク220即ちメモリーから転送するための一連のデータを提供する。この一続きのデータは、ファイル、ディレクトリー、ロウ・バイト・シーケンス、もしくは事実上その他どのようなデータ形式のものであってもよい。
データ・アプリケーション・ソース・モジュール203は、転送すべき一連のデータを送信アプリケーション202のメモリー・スペースへ提供する。
ブロック・ハンドラー・モジュール206は、伝送もしくは再伝送が必要になると、ファイル・システムからのもしくはユーザー・アプリケーション202のメモリー・スペース203からのデータブロックを読み、データを取り込む。
暗号化モジュール208は、送信システム201内においては任意の(必須ではない)モジュールである。暗号化モジュール208は、データブロックの暗号化を任意に行い、完全性証明のための認証ダイジェストを付け加える。
ブロック排出モジュール210は、データブロックをネットワーク224へ書き出す。
フィードバック・リーダー・モジュール216は、逸失したブロックの再伝送の要求、転送統計、およびダイナミック目標レートを含む制御フィードバック情報を、受信システム226から読みとる。フィードバック・リーダー・モジュール216は、メッセージのタイプを解析し、処理のために再伝送モジュール212とか、レート制御モジュール214とか管理インターフェース204などの適切なモジュールへ、ペイロードをパスする。
レート制御モジュール214は、目標とするレート(例えばビット・パー・セコンド)を遵守するために、ブロックを伝送予定に入れる。
再伝送モジュール212は、入力してくる再伝送の要求を記憶するが、この要求は、シーケンス・ナンバーによるソートを可能にするデータ構造となっている。再伝送モジュール212は更に、再伝送するべきブロックの数を発行する。
管理インターフェース・モジュール204は、監視および制御インターフェースを提供し、同インターフェースから制御コマンドが発せられ、転送統計が読み込まれる。
システム200で示された実施例の受信システム226は、一組のモジュ-ルを有している。これらモジュールには、転送開始モジュール225、データ・ファイル・システム送信先モジュール250、データ・アプリケーション送信先モジュール227、ブロック・ハンドラー・モジュール230、およびオプショナルな暗号化モジュール232が含まれている。受信システム226は更に、ブロック取り込みモジュール236、フィードバック・ライター・モジュール248、レート制御モジュール242、再伝送モジュール246、管理インターフェース・モジュール228、および転送開始モジュール225を含んでいる。
転送開始モジュール225は、送信システム201との制御チャンネルを確立させるよう機能する。 制御チャンネルは、信頼可能な或いは信頼不可能なベース・トランスポート(例えば、TCPもしくはUDP)を使用し得る。制御チャンネルは更に、セキュア・ソケット・レイヤー(「SSL」)とかセキュア・シェル(「SSH」)といった公開−秘密鍵法を使用することによってその安全が確保され得る。制御チャンネルを使用することによって、転送開始モジュール225は、送信システム201へ資格認定書を送り、受信アプリケーション227の認証を行い、任意ではあるが、データの暗号化に使用されるパー・セッション対称暗号化キーを交換することができる。転送開始モジュール225は更に、例えばブロックの大きさ、目標とするレートなどといった転送パラメータについてのネゴシエーションを行い、目的地向けファイルを構成しかつ一部転送の再開のためにファイルもしくはディレクトリィ・メタデータを交換する。メタデータは、ファイル名とか、サイズとか、アクセス制御パラメータとか、チェックサムといった属性データを含んでいる。
ブロック取り込みモジュール236は、ネットワーク224からのデータブロックを読み込む。
暗号化モジュール232は、オプショナルなものである。暗号化モジュール232を有する実施例では、暗号化されたデータブロックを復号化して、完全性についての認証ダイジェストを検証する。
ブロック・ハンドラー・モジュール230は、入力してくるデータブロックを処理する。この処理は、ネットワーク・ラウンド・トリップ・タイムスタンプを抽出し、それをレート計算モジュールへパスし、且つ経路ラウンド・トリップ・タイムスタンプを抽出し、それをタイムアウト・予測モジュールへパスすることを含む。更にこの処理は、排出のために、ディスク・ライター・モジュール234へペイロードをコピーすることも含む。
ディスク・ライター・モジュール234は、ネットワーク読み取り動作とディスク書き込み動作とのインターロックを最小とすることによって、受信側入力/出力(「I/O」)速度を最大にするためのロジックを実現する。ディスク・ライター・モジュールは、多数のバッファーを使用しており、いつでも一つのバッファーにはネットワーク224の読み取り動作を、またもう一つのバッファーにはディスク252への書き込み動作を割り当てる。一旦、一つのバッファーがネットワーク・リーダーによって満たされると、それはディスク・ライター・モジュール234へパスされ、新たなバッファーが、ネットワーク・リーダーとして割り当てられる。
ファイル・キャッシュ・モジュール238は、シーケンス外の書き込みを最小にし且つ特定のファイル・システムに対して最適な大きさのブロックを書き込むことによって、ブロックがディスク252もしくはシステムのメモリーに書き込まれるときの速度を最大にするようロジックを実行する。
前記データ・ファイル・システム・目的地モジュール250は、受け取られたデータが書き込まれるファイル・システムを介してローカル・コンピュータにアクセス可能なディスク252もしくはシステム・メモリー上のファイルもしくはディレクトリーである。
データ・アプリケーション・目的地モジュール229は、受信システム226のアプリケーション227のメモリー・スペース229における一連のメモリーである。そこに受取られたデータが書き込まれる。
再伝送モジュール246は、インデックスにより逸失したデータを回復させるための逸失データブロックの情報を記憶する。この記憶されている情報は、シーケンス番号および逸失したデータが最初送られたのはいつであったかのタイムスタンプを含んでいる。
前記フィードバック・ライター・モジュール248は、送信システム201へフィードバック情報を送る。このフィードバック情報には、再伝送の要求、統計、計算された目標とするレート、およびその他送信システム201及び受信システム226間のデータの交換に関係するあらゆる情報を含ませることができる。
前記タイムアウト・プレディクター・モジュール240は、ラウンド−トリップの計測に基づいて経路ラウンド−トリップ時間を予測する再帰的推定アルゴリズムを使用することによって、逸失したブロックの再伝送を要求するまでの待ち時間(RTO)を計算する。
前記レート制御モジュール242は、設定されたレート制御メカニズム即ち固定レート、もしくは計測されたネットワーク・ラウンド−トリップ時間の関数としてダイナミックに適用されるレートにしたがって、目標とする伝送レートを計算する。
前記タイマー・モジュール244は、再伝送の要求なされることになっている絶対時間に従って再伝送するためのブロックのシーケンス番号を記憶する。この絶対時間は、タイムアウト予測モジュールによって計算されたRTOにより与えられる。タイマー・モジュールは、現時刻に再伝送されることになっているブロックのシーケンス番号を再伝送モジュールへ送る。
前記管理インターフェース・モジュール228は、モニター/制御インターフェースを提供するもので、このインターフェースからコマンドが発せられ、転送統計値が読みとられる。
ファイル・ディファレンシング・モジュール254は受信システム226に既にあるデータを評価して、同一のデータが既にあって転送は不要であるかどうかを判定するために、そのデータを送信システム201のデータと比較する。ある実施例では、かかる比較は、大きさとか、修正された時間とか、コンテンツ・チェックサムといった属性に基づき、送信側ファイルと同一の名前を有する受信側ファイルとの間でなされる。もしも比較したファイル同士が同一である場合、如何なるデータも転送されない。もしもファイルが部分的に転送されている場合、ファイル・ディファレンシング・モジュールは、伝送が開始すなわち再開されるべき補正点を決定する。
正確な機能、データがグループ化され相互に連結される方法、および個個に実行されるプロセスは、本発明の主題の範囲から逸脱することなく変化し得ることは理解される。
第3図は、一実施例によるプロセス300のブロック図である。このプロセス300には、ファイル或いはその他のデータ構成をソースシステムから目的地システムへ送るための、コンピュータにより実行可能な方法である。このプロセス300には、ファイルもしくはその他のデータ構成302を目的地システムへ伝送するためのコマンドを受取り、目的地システム304への接続を確立し、同システムと制御データを交換し、ファイルもしくはその他のデータ構成を番号を付けたブロックに分けること、が含まれている。このプロセス300は更に、再伝送の要求が受取られた保留状態にあるか(308)を判断し、その他のブロックを伝送する前に要求されたブロックを全て再伝送することを含む。プロセス300は更に、伝送すべきブロックで残っているものがあるかどうかを判断し(312)、番号を付されたシーケンスにおける次のブロックを伝送する(310)ことを含む。もしも伝送すべき残りのブロックがない場合、プロセス300は、目的地システムから最後のブロックが受取られたことを示すインディケーションが受取られたかどうかを判断する(316)。もしそのようなインディケーションが受取られていた場合プロセスは終了し(320)、そうでなければ、プロセスは最後のブロックを再伝送する(318)。
第4図は、本発明の一実施例による、ソースシステムからファイル或いはその他のデータ構成を目的地システムで受取るためのプロセス400のブロック図である。プロセス400は、ファイル、もしくはその他のデータ構成を受取るためのコマンドを受け取り(402)、接続を確立してソースシステムと制御データの交換をし(404)、記憶スペースを割り当てて受取られる多数のブロックに従い記憶スペースをブロックに分割する(406)ことを含んでいる。プロセス400は更に、番号を付されたブロックを受取り(408)、そのブロックが以前に受取られていたかどうかを判断し(410)、もし以前に受取られていた場合にはそのブロックを切り捨てる(412)か或いは受取られたブロックの番号に対応する各記憶ブロックにそのブロックを書き込む(414)ことを含む。その後プロセス400は、受取られたブロックにギャップがあるかどうかを判断する。もし、ギャップがあった場合、プロセスは逸失したブロックの再伝送の予定を立て(416)、その逸失したブロックが既に受取られていたかどうか判断し(418)、逸失したブロックの再伝送を要求する(420)。続いて、プロセスは、受取られたブロックが再伝送の要求をされたかどうかを判断する(424)。もしもブロックが再伝送されていた場合には、そのブロックは再伝送予定からは除去される。ついで、プロセス400は、ブロックが最後のブロックであるかどうかを判断する(428)。それがもし最後のブロックであった場合、プロセス400は終了する(430)。そうでなかった場合、プロセス400は全てのブロックが受取られるまで以上の動作を反覆する。
プロセス・フローの変化および各処理手順の動作のバリエーションは、本発明の主題から逸脱することなく変え得ることが理解される。
第3図および第4図に示されたプロセス300および400についてのいくつかの実施例においては、コンピュータ・アプリケーションへ相互にデータブロックのシーケンスを安定して転送できる能力を与えている。いくつかの実施例においては、プロセス300と400は、単一のコンピュータ・アプリケーションに含まれていて、そのためシステムは、送信部にも受信部にもなり得る。
動作する場合、送信システムは、第3図に示したプロセス300に従ってデータ構成をソースから受信システムの目的地へ、要求された目標レートもしくは経路ボトルネック帯域幅のいずれか小さい方で次々に転送する。受信システムは、第4図に図解されているプロセス400に従って動作する。転送は、伝送前経路のラウンド−トリップ時間或いは伝送中のラウンド−トリップ・レイテンシーおよびパケット逸失の変動に関係なく高効率で行われる。
一定の目標とするレートが要求された場合、伝送レートは、輻輳状態となっても、一定に保たれ、パケット逸失レートは少なくなる。「帯域幅−公平」のモードが使われている場合、転送レートは、ネットワークの使用率が低い場合には利用可能な帯域幅を自動的に利用するように適応するべきだが、ネットワークが輻輳している場合(利用可能な帯域幅がない)には、「TPC−公平レート」についてユーザーが設定した割合に適応する。
第5図および第6図は、本発明の主題の種々の実施例に含まれる種々の態様を示している。これらの図は、中でも、ラウンド−トリップ時間の計測、データ伝送、いくつかの例によるデータ注入レートの計算と最新化を詳細に示すものであるが、網羅的なもしくは限定的な図示を意図したものではない。
第5図は、一実施例によるシステム500のデータ・フロー図である。システム500は、最終データ・ソース502を有する送信部と、ネットワーク504と、最終データ目的地506を有する受信部とを備えている。伝送要求はタイムスタンプを有する受信部によって送られ、そしてそのタイムスタンプはリライアビリティ法(例えば経路RTT)及び輻輳計測(例えばネットワークRTT)のため瞬間ラウンド・トリップ時間の計算に用いられる。各タイムスタンプには、タイプ別(n=network RTT,p=path RTT)にフラグが付加されている。「n」個の再伝送要求(Trex)は、一定の時間間隔で受信部から送信部へ送られる。もしも、「n」の計測時に再伝送がない場合、空の再伝送要求が送られる。
第5図は、次の「T」参照信号を有する。同信号は以下の意味を有する。
T1: 受信部により再伝送要求が送られた時間
T2: 送信部に再伝送要求が到着した時間
T3(p): 再伝送要求を満足させるブロックが送信部により送られた時間
T3(n): 「ネットワークRTT」のフラグのついた再伝送要求の受信が受取られた後、最初のブロックが送られたときの時間
T4: このブロックが受信部に到達した時間
以下の計算は、種々の実施例において有用なものであり、計測された時間
T1、T2、T3(p)、T3(n)、およびT4を用いる。
第6図は、一実施例によるシステム500のデータ・フロー図である。第6
図は、いくつかの実施例による伝送要求の生成とプロセスおよび時間の計測についてより詳細に図解している。
時間T1において、受信部は、再伝送のときが来た逸失ブロックを再伝送要求PDUへ付け加える。いくつかの実施例においては、時間が、現在推定されているRTTと同じになり、RTOが経過したときをもって再伝送が行われる時間に「なった」とする。現在時刻は、再伝送要求PDUのヘッダーのタイムスタンプ・ティック(TK)に記録されており、ティック・タイプのフラグ(経路「P」もしくはネットワーク「N」)がセットされる。ネットワーク「N」のティックは、周期的な時間間隔で送られる。もしも「N」ティックを送る時間でない場合、ティック「P」がデフォルトで送られる。
時間T2のときに再伝送要求は送信部へ到着する。送信部は、ブロック番号で順番にソートされている待ち行列(queue )へ要求を挿入する。各ブロックは、ティック・タイムスタンプTKと共に記憶される。
再伝送要求がティック・タイプTKを含んで受けとられると、送られた次のデータPDU(再伝送もしくはオリジナル)は、ネットワーク時間を計測するためだけに送信部の処理時間にあわせられたティックTKを含む。即ち、TK=TK+(T3(p)−T2)
送信部は、ブロックを、注入レートRで継続的に送リ出す。待ち行列に入れられている全てのブロックは、新たなデータが送られる前に順番どおりに送り出される。もしも待ち行列に入れられた再伝送がある場合、送信部は、一番若いブロック番号を選択し、その番号のブロックをディスクから読み出す。再伝送されたデータブロックと、そのタイムスタンプTKと、タイプ(P/N)は、PDUに封入される。
時間T4に受信部によってデータブロックが受け取られたときに、もしもそのブロックがティックを含んでいるとすると、受信部は、ネットワーク・ラウンド・トリップ時間もしくは経路−トリップ時間(RTO)の予測推定を最新のものに更新する。受信部は、埋め込まれているティックからサンプル・ラウンド−トリップ時間
を計算し、サンプル化されたラウンド−トリップ時間を予測推定関数へ入力し、経路またはネットワークのためにRTOが計算される。
第7図は、本発明の一実施例によるシステム500のデータ・フロー図である。この図は、最大/最小レート、一定レートもしくは自動的に適用されるレートといった帯域幅共用ポリシー、TCPに対するアグレッシブネス等−これら全ては管理インターフェースを介してリアルタイムで提供される−の入力パラメータの関数として、受信部506による新しい注入レートの計算、および新たなレートの送信部への伝達の両方を示している。
転送されるべき一連のデータは、同じ大きさを持ったブロックに分割される。データブロックのサイズは、データ(ペイロード+アップリケ−ション・ヘッダー+封入されているパケット・ヘッダー)を持つプロトコル・データ・ユニットが、ネットワークの最大伝送ユニット(MTU)を超えることがないように計算される。このPDUは多分超えることになる。
前記システムは、全ブロックの伝送と目的地におけるソース・ファイルの再構成を保証するものである。ブロックは順番に番号付けされる。システム受信部は、逸失ブロックに気づき、システム送信部に対し全部ロックが受け取られ目的地フィルへ書き込まれるまで逸失したデータを再伝送するよう要求する。受け取られたブロックは、それらが受け取られている最中にディスクもしくはメモリーに書き込まれ、終了まで少しずつ書き入れられていく空きの多いファイルが形成される。
システム送信部は、ユーザーによって特定された目標レート(絶対値もしくは自動的に求められた帯域幅即ちキャパシティのいずれかとして)で、もしくは適応レート・メカニズムによって計算されたレートで、ブロックを順番どおりに送り出すことによって動作開始する。適応レート・モードにある場合、送信部は、任意ではあるが、スロー・スタート・メカニズムを使用することができる。このメカニズムによれば、最初の送り出しレートは、送り出しレートの何分の一かであって、適応レート・アルゴリズムは自動的に、2,3秒間の間に目標レートへと急成長する。各ブロックは、受信部でファイルを再構成するために用いられるブロック番号を有している。送信部は、受信部からのブロック再伝送の要求を受け取ることができる。その場合、送信部は、再伝送の要求を記憶し、ユーザーにより特定されたレート、または適応レート・メカニズムにより計算されたレートで、要求されたブロックを再送する。サーバーは、新しいブロック−それがどのようなものであれ−を送り出す前に再伝送が必要な全てのブロックを送り出す。再伝送すべきブロックがなくなったとき、または伝送するための新しいブロックがあるとき、サーバーは、終了状態に入り、受信部が全ファイルの受信を知らせるか或いは更なる再伝送の要求を送るまで、最後のファイル・ブロックを繰り返し送りつづける。
システムの受信部は、データブロックの受取を待ちつづける。ブロックを受け取ると同時に、受信部は、そのブロックがその前に受け取られていなかった場合、そのブロックをメモリーディスク・サブシステムまたはシステム・メモリーのようなメモリへパスする。もしもブロックシーケンス番号が、受け取られたブロックにギャップのあることを示すと、受信部は、直前に受け取られたブロックとこのブロックとの間のシーケンス番号を持つ逸失ブロックの全てを再伝送するための予定を立てる。
再伝送スケジューラーは、いつ再伝送の要求を送るかを決めるタイマーの機能として、逸失したブロックの再伝送を要求するように動作する。再伝送予定のタイマーは、経路ラウンド−トリップ時間の予測計測に基づいている。再伝送のバッチが予定時間になると、受信部はこれらブロックの再伝送要求を送信部へ送り出す。再伝送されたブロックが受け取られると、それらの登録は、保留中の再伝送スケジューラーから取り除かれる。ブロックは、メモリー、ディスク、もしくは適切なファイル・オフセット位置を有するその他の場所へパスされ、ファイルへ書き込まれる。最後のデータブロックが受け取られたとき、高速終了アルゴリズムによって、残っている再伝送があれば全て要求される。全てのブロックが受け取られると、受信部は終了メッセージを送信部へ送る。
その他種々の実施例は、高データ転送効率と、任意の高固定注入レートの場合のラウンド−トリップ遅延およびパケット逸失に関係のない予測可能な転送レートとを実現する方法を提供している。
そのような実施例のいくつかは、データ転送アプリケーション・ノンシーケンシャル・データアクセスを実現するブロック・ベースの転送を提供し、更に、データの信頼し得る受取から切り離された高度に正確な注入レートを提供する。
データ転送アプリケーション・ノンシーケンシャル・データアクセスを実現する実施例は、データ・ソース、例えばディスク・システム、メモリー、或いはアプリケーションといったデータ・ソースに、必ずしも順番どおりになっていなくともよい、不連続ブロックでデータを供給することを要求するブロック・ベース転送を含む。
これら実施例はデータ「ブロック」のサイズを画定し、アプリケーションに対して、ブロックを、個個にまたはまとめて提供するよう要求する。例えば、通常のファイル転送の場合、それら実施例はブロックを多数のバイトとして画定する。(大きさは、アプリケ−ションによって、或いは導入の際に予めコード化された固定値によって設定され得るし、或いは、転送経路のMTUの大きさを探査することによって求めることができる。最大スループット効率を得るために、ブロック・サイズは、下位のIPレイヤーにおいて断片化されたパケットを再構築する際の不要なオーバーヘッドを避けるため、経路MTUを越えず且つパケットの断片化を生じさせない範囲で可能な限り大きくすべきである。)ファイルはブロックに分割され、最初のブロックは、ブロック番号1である。所定のブロックが要求される順序および回数については保証はない。所定のどの時間においても、アプリケーションには、要求するブロックの一番若いブロック番号が与えられる。このような情報に基づき、アプリケーションは、その前のブロックを切り捨て、メモリー内に大きなメモリー・バッファーを持つオーバーヘッドを避け且つ連続するデータを潜在的に並行して扱うことができようになる。
いくつかの実施例では、データ注入レートは、その信頼性メカニズムとは無関係である。そのような実施例の場合、注入レートは、データがうまく受け取られたかそしてレート制御アルゴリズムはアプリケーションによる明確な且つ独自の制御下にあるかどうかに依存していない。このことにより、ネットワーク遅延およびパケット逸失には関係のない転送性能を実現できると共に、アプリケーションには独立した転送レート制御を与えることができる。
これら実施例により動作するアプリケーションは、アプリケーションによって設定される(例えば、絶対値として、或いは設定されたまたは自動的に求められた帯域幅のキャパシティの割合として)か、或いは計算式を基礎としたアルゴリズムを用いて計算されるかのいずれかによる目標注入レートを使用し、通知ではなくタイミングを使って注入レートを制御している。かかるレート制御メカニズムによれば、相対精度をもった、システム負荷に依存しない、また他のアプリケーションに対してCPUフレンドリーな目標レートを維持することができる。これら実施例は、新しいデータをネットワークへクロックするために伝送されたデータを順番に承認する必要がないので、データはアプリケーションからどのような順序ででも再要求されることができ、通知の受領まで伝送されたブロックを不必要に格納しておくことがなくなる。
これら実施例にかかわるアプリケーションは、「固定レート」モードにおいて一定の注入レートを維持し、或いは、「適応レート」制御アルゴリズムが使われる場合には、利用可能なネットワーク帯域幅についての進行中の計測と、アプリケーションへ明確に明らかにされ得るTCPに関連する設定可能なアグレッシブネスとに従って目標レートを調整する。アプリケーションは、進行中にレート制御モード(例えば、固定もしくは適応モード)をセットすることができ、また、目標レート、最大および最小転送レート、および、帯域幅の公平さの基準倍率を含む境界パラメータをセットすることができる。(現行の実施手法では、標準(Reno)TCPに関する計算された目標レートについての基準倍率を表すのが最も有用であるかもしれないが、基準倍率は、ラウンド−トリップ時間およびパケット逸失といった測定可能なエンドツーエンド・ネットワーク・パラメータの関数として安定状態のスループットを有するあらゆるTCP互換の実施手法にも関連し得るものである。)
ネットワークの利用を最大化するいくつかの実施例においては、送信部システムは、データを要求された注入レート(計算されたまたは予め決められた)で、正確に出力することが重要である。このことを達成するために解決されなければならない問題は、第一に、オペレーティング・システムによりもたらされるタイミング・メカニズムに関係し、また第二には、システムの負荷に関係している。
第一に、マルチ‐プロセス型のオペレーティング・システムでは、プロセス・スイッチングの粒度は、高レートのネットワーク伝送で要求される「パケット間の時間」よりもずっと大ききい。一般的には、粒度は、10から20ミリ秒であり、このことは、ひとたびプロセスがCPUをイールドすると、少なくとも10−20ミリ秒は再動作しないことを意味している。毎10ミリ秒ごとに1500バイトのデータ・パケット1個を送り出した場合、伝送レートは1.2Mbpsだけしかイールドしない。スピニング(CPUをイールディングするのとは反対に)によれば、精度の高いタイミングが得られるが、マシーンがネットワーク・送信部専用でない限り実用的ではない。本発明主題のいくつかの実施例では、商品としてのマルチ・タスク・システムによるデータ転送を提供するものであり、CPUを独占する贅沢さを有するものではない。
第二に、CPUおよびディスクの利用といった点からみると、より高いシステム負荷は、注入レートの精度に悪影響を及ぼし、劣ったものにする。
本発明主題のいくつかの実施例に用いられている方法は、高精度の注入レートを提供する。これらの注入レートは、CPUフレンドリーであり十分な利用可能な処理パワーがある限りシステム負荷の変動によって影響を受けることはない。
パケットは、バッチにグループ分けされているため、注入レートはCPUフレンドリーである。バッチの大きさは、パケット間遅延(「IPD(Inter-packet delay)」)が、送信部にCPUをイールドさせ且つ注入レートと折り合いをつけることなくプロセス・スイッチング遅れから回復させるに十分な大きさになるように計算される。
注入レートは、システム負荷の変動により影響を受けることはない。なぜなら、上記実施例では、一つのパケット、もしくはバッチの伝送を処理する時間を計測し、この処理時間にCPUをイールディングするスイッチング処理に費やした時間をプラスした時間により生じたラグを補償するからである。実際のパケット間の遅延は、計測されたラグについて補償されるので、変動するシステム負荷が存在しても注入レートは一定に保たれる。
以下の擬似コードは、高精度ネットワーク転送レートを実現するためにネットワークへパケットを注入する際に使用されるアルゴリズムの例である。バッチの大きさの計算において最小パケット間遅延(「IPD」)の制限5000マイクロ秒(5ミリ秒)で、IPDは、プロセス・スイッチングにより引き起こされる遅れ(10−20ミリ秒)が、次の3から4のバッチから回復されるように選択される。
所定の注入レート(Ri)で、パケット間遅延およびバッチ・サイズを計算する。
送信部ループ
いくつかの実施例も、高注入レートによる経路遅延およびパケット逸失に関係なく高データ伝送効率を維持する方法を提供している。
肯定応答信頼性アルゴリズム(Positive-acknowledgement reliability algorithm)の伝送速度ボトルネックを避けるために、本発明主題によるいくつかの方法は、例えば、注入レートを絞ったり或いは逸失データの回復といったことを行わないユーザー・データグラム・プロトコル(「UDP」:User Datagram Protocol)をなどのリライアブルでない伝送チャンネルを使用している。かかる方法は、逸失データの再伝送について独自のアルゴリズムを実行することによって信頼性(reliability )を得るようにしている。かかる伝送アルゴリズムは、データブロックが、遅れたりあるいは再注文されているのではなく、オリジナル・ソースと最終目的地間で本当に「逸失した」ときを正確に特定することにより、エッジからエッジまでのネットワーク遅延およびパケット逸失に関係のない安定した、高効率を高注入速度について達成できる。再伝送アルゴリズムは、高ラウンド−トリップ時間(例えば、長距離大陸間ネットワークなど)、高ランダム・パケット逸失(例えばいくつかの無線メディアにおける)、および変動するレイテンシーとパケット逸失レート(例えば重い負荷により輻輳している公共のインターネット・リンク)に対して不変の、高注入速度と有用なスループットとの組合せを可能とする。
再伝送アルゴリズムのいくつかの実施例は、「否定応答(negative acknowledgements)」を使用している。否定応答は、受信部が送信部へ逸失したブロックについてのみを通知しそれに従って送信部が再送信を行ったときになされる。
本発明主題のいくつかの実施例は、継続的に経路ラウンド・トリップ時間をサンプリングし、ラウンド・トリップ時間を正確に予測しいつ逸失したブロックが本当に失われたのかそしていつ再伝送されるべきかを決定するために、予測推定関数を使用する。再伝送の要求は、安定性を維持するために早すぎてもいけないし、効率をさげることになるので遅すぎてもいけない。高注入レートのための、有用な、受け取られたデータ・レートは、一定であって、注入レートから経路のパケット逸失レートを引いたものに等しい。それ故、逸失の大きいレイテンシーの変動するリンクであっても高速で高伝送効率と高帯域幅の利用とが実現される。
最適再伝送要求アルゴリズムの問題はモデル化可能である。例えば、経路注入レートRi(t)とし、効率的伝送をほぼ100%とするには、有用データ・レートRu(t)はRi(t)からパケット逸失レートP(t)とRi(t)の積を減じたものに等しくなるようにする:
任意の高速ネットワークの利用をほぼ100%とするには、毎秒数キロビットから任意高速(毎秒1ギガビット以上)までの範囲にわたるRiについて上記式は保持されなければならない。
かかる実質的な最適なモデルを実現するために、逸失したブロックについての再伝送の要求は、遅れるかもしれない或いは再要求されるかもしれない送信中の一ブロックが受取られまでの十分な時間であって再伝送の要求を送信部へ送り、送信部の目標注入レートRiとして、要求に対する返事を受取る(までの)時間を超えない時間長さだけ、待つことになる。
正確な待ち時間は、決定されないが、継続的に経路ラウンド−トリップ時間を計測し且つ予測推定方程式の一種を用いることによって、高精度で推定され得る。かかる予測推定方程式とは、再帰的予測エラー傾斜関数もしく将来の経路ラウンド−トリップ時間を予測する確率論的傾斜関数として知られているものである。経路ラウンド−トリップ時間を正確に推定し、再伝送の要求を待つ時間を計算するために、本発明主題のいくつかの実施例は、ブロック・ベースのデータの伝送システムの中に上記のアプリケーションを有している。その結果、これら実施例は高伝送効率を実現している。
いくつかの実施例において、再伝送の予定は、経路ラウンド・トリップ時間の正確な予測、現在のラウンド・トリップ時間の正確なサンプリング、および予測される経路ラウンド・トリップ時間に基づく高性能再伝送スケジューラーが含まれている。
正確な再伝送タイムアウト(RTO)のために、再伝送要求の送り出しと再伝送されたデータブロックの受取りに用いられる時間スケールで、経路ラウンド・トリップ時間の進展を正確に予測することが重要である。本発明主題の種々の実施例は、データブロックがネットワーク上を走行する時間に加え、ラウンド−トリップ時間を全転送経路についてサンプリングすることによってRTT予測を計算している。このラウンド−トリップ時間には、送信部の処理時間、例えば再伝送データ構成を検索し且つディスクからブロックを再読み出す時間が含まれている。かかる実施例においては、送信側の処理アルゴリズムは、再伝送要求の数に対して不変であり、従ってラウンド−トリップ予測に安全に考慮される。
更に、かかる実施例のいくつかは、サンプリングされたラウンド・トリップ時間から、推定平均経路ラウンド・トリップ時間(「平滑化RTT」:“smooth RTT” もしくは「SRTT」)を計算し、また、RTTのサンプルおよび平滑化RTT間の差から遅延の分散(「RTT分散」)を導き出す。そして、予測されるネットワーク遅延は、平滑化RTTおよびRTT分散に基づいて計算される。
新たなRTTサンプル(RTTi)の受取りおよび計算と同時に、平滑化RTT(「SRTT」)の値が以下のように計算される。
γは、現在のRTTサンプルが新しい平滑化されたRTTの推定値の中でどのくらい重いかを決定するゲイン・ファクター(a gain factor)である。RTTiとSRTTiとの差は、その前の予測の際のエラーを示しており、このエラーは、経路における何らかのランダム・エラーおよびその前の不良推定ために生じた何らかのエラーから成っている。時間の経過と共に、ランダム・エラー成分はキャンセルされ、不良推定によるエラーは、推定値を「真の」平均値ヘ押し上げる。それ故、小さなゲイン・ファクターは、特定のSRTTがランダム・エラーによって多大な影響を受けないように機能する。一実施例は、ゲイン・ファクター「γ」として1/8を使用している。
SRTT推定値の真の平均値からの振れを考慮して、RTT分散(VRTT)は、以下のように計算される。
ここで、ηは減衰ファクターである。一実施例では、減衰ファクター「η」として、1/4が使われている。
予測されるRTT(=RTO)は、以下のように計算される。
RTO値は、標準的なネットワークにおける1回実行時の現実的ラウンド−トリップ・リミットに制限された範囲である。
ネットワークの遅れ予測におけるもう一つのファクターは、RTTのサンプリング周波数である。いくつかの実施例に使用されている転送レートの範囲(20Kbps−1Gbps)に対して、サンプリング期間は、10ミリ秒にセットされている。
予測されるRTT(=RTO)の精度は、サンプリングされたRTTの精度にかかっている。受信部は、オペレーティング・システムによって提供される最良のクロック・メカニズムを使用して、正確な「クロック・ティック」を発生する。このティックは、再伝送の要求を送り出す直前に生成され、再伝送の要求PDUに埋め込まれる。再伝送要求はネットワークを通って送信部へ移送する。送信部が、要求に対応するブロックをいつでも転送できる状態になると、送信部はクロック・ティックをデータPDUへ埋め込み、受信部へそれを送る。クロック・ティックを含むデータPDUを受取ると同時に、受信部は、受取られたクロック・ティックを現在のクロックから差し引くことによって経路RTTを決定する。この方法は、オペレーティング・システムから得られる最高精度のクロック・メカニズムを使用しているため、正確である。
否定応答(「NACK」)再転送要求の受信側は、ブロック再伝送のための要求を扱わなければならない。以下、ブロック再伝送要求、逸失ブロックの検出、逸失ブロックの再伝送要求、および、要求されたブロックが受取られたときに未処理の再伝送要求の取り消しを取り扱う実施例について説明する。
本発明主題によるいくつかの実施例は、データ・ソース内の各ブロックに1からNまでの番号が順番に付されている。ここで、Nは、N=ファイルのサイズ/ブロックのサイズである[ファイルの大きさ>0の場合は+1]。その他の実施例では、各ブロックを順番付けて特定するため種々の手段を使用している。
送信部は、各プロトコル・データ・ユニット(「PDU」)のおけるペイロードに対してブロック・シーケンス番号を付加する。受信部は、想定される次のシーケンス番号よりも大きなシーケンス番号を持ったブロックを受取ると逸失ブロックを検出する。ブロックは順番を外れて受取られたので、受信部は直ちに逸失ブロックを要求せずに、一つのRTOの後での再伝送のために最初の要求として予定に入れる。このことにより、再注文された実行中のブロックは、再伝送を早めに要請することによる伝送の重複を作り出すことなく、受取られることになる。
受信部は、再伝送の要求の全てを、予定される正確な絶対時間と共に記憶する。時間は、計算された余地時間が計測エラーによる理論的に正確な値よりも小さくならないようにするため、RTT計測の精度で予定時刻値の端数を切り上げることにより計算される。
予定時間(ミリ秒)= 検出された時間ロス[ミリ秒]+
検出された時間におけるRTO[ミリ秒]+
RTT計測精度[ミリ秒]
受信部から送信部へ再伝送の要求が送られると、再伝送についての続く要求は、同じ方法によって計算された予定時刻に予定に入れられる。従って、いったん逸失ブロックが検出されると、そのブロックが受取られるまで待機中の再伝送要求が常に存在するが、現在待機中の再伝送は取り消される。
正確な経路ラウンド・トリップ時間予測は、再伝送の要求の送り出しと処理におけるオーバーヘッドが再伝送の数に対して不変であることを必要とし、データの逸失を合成するものではない。困難なネットワーク状態を通しての高速度転送のため、再伝送の数は非常に大きくなり得る。種々の実施例は、たとえ再伝送の数が大きいとしても、送信部および受信部での処理時間が常にほぼ一定であるようにし、且つ再伝送の要求がうまく配送される確率を最大にする多数の要素(エレメント)を有している。
そのような実施例において、再伝送されたブロックが受取られると、再伝送のためのみ処理の要求はスケジューラーから取り戻されて取り消される。逸失が高い(再伝送の数が多い)場合、もしも取り戻し方法が再伝送の数に比例するとすると、これはお金のかかる動作となり得る。これら実施例に用いられている取り戻し方法は、高い逸失に直面しても、ほぼ最適な実用的なスループットのために一定のアクセス・タイムを得ることができる。一つのブロックが逸失したものとして最初に検出されると、そのブロックの再伝送要求が直線配列(linear array)で受信部に記憶される。それが記憶されているインデックスは再伝送の要求に送られる。送信側では、このインデックスは再伝送の要求と共に送信側に記憶される。送信部がブロックを再伝送すると、インデックスはブロックに付加されて、その結果受信部は、ブロックの総数に関係なく一定時間内に未処理の再伝送を調べる。
未処理の再伝送が累積するのを避けるために、本実施例の送信部は、新しいブロックを送り出す前に逸失した全てのブロックを常に再伝送する。そのようにしなければ、受信部は、更なる逸失を累積し、更に多くの再転送の要求を予定に入れることになろう。その結果、送信部の輻輳による破綻をまねき転送性能の低下をきたすことになる。ブロックを再伝送するために、送信部はソース・ファイルからブロックのデータを再度読み出さなければならない。この、「探して−戻って−読み出す」動作は高レート転送では高価なものとなり得るし、パケット逸失が大きく且つファイルのサイズが大きい場合には特に厄介である。受信部は、送信部が逸失したブロックを再送でき、送信側の未処理の再伝送の記憶量がほぼ一定の大きさ(ネットワーク逸失とともに大きくならない)になるようなレートに合うように、再伝送の要求を絞る。
半二重通信メディアでは、待機資源の小型化のために半二重通信動作となってしまうネットワーク装置の場合と同様に、受信部から送信部への逆方向経路上の大きなIPパケット逆経路は、送信部へたどり着かなくなることがあり得る。その結果、送信部は新しいブロックを送りつづけさせられるため、レートが加速され受信部にはそのレートによる損失が蓄積されて、ファイル転送性能が一気に悪くなる。
そのため、本実施例では以下の対抗策が講じられている。
(a)送信部が単位時間当たりに送らなければならない再伝送の要求の数と、送信部は送信レートよりも早くない速度で伝送可能であることとを考慮して、送信部は、再伝送要求PDUの中で再伝送対象ブロックを、送信部の目標レートと再送要求レートによって決定される、最小数だけ送る。
要求の間隔は一定であって、以下の特別な例を除いて、伝送タイマー分解能(現行では10ミリ秒)に等しい。もしも送信部の目標レートが、最小の要求レートが毎秒1レックス(rex)よりも小さくイールドするくらい小さいとすると前記間隔は、1要求当たり1レックスに要求される最小間隔長まで伸張される。
(b)伝送要求の最大サイズは、アプリケーションによって設定され、またデフォルトにより、最小の普通のネットワークMYU(1492バイト)よりも小さくセットされ得る。
ディスクの書き込み/読出しスループットに近いファイル伝送レートを有する実施例においては、ディスクのI/O性能は、ボトルネックになり得る。かかる実施例における送信部は、ファイルの始まりに一番近いブロックを常に最初に再送することによってディスクの探索負荷を軽減している。このことにより、送信部は、再送信するブロックを順次読み出すことができ、受信部は受取られたブロックを順次書き込むことができる。送信側には、予定されている再伝送が、ソートされたデータ構造で記憶される。即ち、番号でソートされた再伝送予定のためのシーケンス番号を記憶する改良レッド・ブラック・ツリーで記録される。レッド・ブラック・ツリーは、コンピュータ・サイエンス本に詳細に書かれている古典的な二進樹構造であるが、本明細書ではその説明を省略する。ブロック・シーケンス番号は、ツリーにおいては、ノード・キーである。
最小のブロック番号(最小のもの)だけが回復される必要があるという事実に基づき、レッド・ブラック・ツリーは、ほぼ一定時間の検索を提供するように、改良されている。挿入時間は、正規のレッド・ブラック・ツリーのものと同じである。
レッド・ブラック・ツリーは、下記の基本命令を備える。
レッド・ブラック・ツリーは、最小シーケンス番号を有するノードのトラックを保つ。これは、「現在の最小ノード」と言われる。挿入と同時に、最小モードのトラックを保つことは些細なことである。「現在の最小ノード」を知り、もし挿入するブロックが現在の「最小ノード」のシーケンス番号よりも小さかった場合には、それが「最小」となる。その他の場合は、現在の最小ノードは変更されない。
取り戻しと同時に、最小ノードはツリーから除去され、アプリケーションへ戻され、新しい「最小」が求められ記憶される。新しい最小ノードを求めるために用いられるアルゴリズムを支援して、下記のステートメントが真(true)となる。
−「現在の最小ノード」は、左側のデセンダントを持っていない(即ち、左側デセンダントは最小ノードのキーよりも小さなキーを有している)、
−「現在の最小ノード」は、そのペアレントの左側デセンダント(または、そのペアレントは最小ノードのキーよりも小さなキーを有することになる)
−「現在の最小ノード」の右側デセンダントから出ているサブ・ツリーは、「現在の最小ノード」のペアレントのキーおよびツリーの残りのキーよりも小さな全てのキーを有している。
「次」の「現在の最小ノード」がツリーから除去される前に「次」の最小ノードを求めるために、レッド・ブラック・ツリーは、以下のアルゴリズムを使用している。
種々の実施例において用いられている標準のレッド・ブラック・ツリーに対する修正は、以下に述べる。
本発明主題のいくつかの実施例は、ランダム・ディスク・アクセスと、要求された再伝送がある場合にファイルを頻繁に往復して探査することとを要求している。いくつかのオペレーティング・システムは、高性能のファイル・システム・ランダム・アクセスを提供しているが、その他のオペレーティング・システムでは、ランダム・アクセスを十分に扱っておらず、実質的なファクターによってディスクの読出し/書き込み速度は減じられている。かかる実施例における受信機側は、ディスクの書き込み動作はよりお金の掛かるものであるので、最も悪影響を受ける。
いくつかの実施例においては、受信部は、ランダム・ディスク・アクセスを最小にするために、ディスク書き込みキャッシュ・メカニズムを実施している。メモリー・キャッシュのサイズは、以下の計算を使用して、ファイル転送の目標レートに比例している。

ファイル・キャッシュの大きさはディスク書き込みサイズ・バッファー、
に比例している。ディスク書き込みサイズ・バッファーは、多様なサイズのディスク・クラスターであって、ファイル・システムにより、512バイト、1024バイト、4096バイト、8192バイト、或いはそれ以上であってもよい。いくつかの実施例では、64Kバイトのディスク書き込みサイズを使用している。
ファイル・キャッシュは、受信部からデータブロックを受取り、ブロックをバッファーし、ディスクへいつ、どのデータを書き込むかを決定する。ファイル転送が終了すると、キャッシュはその内容をディスクへフラッシュする。ファイル・キャッシュは、以下の問題点を解決する。データの逸失が高い場合、キャッシュは、受信部が再伝送されたブロックを最大機会で受取れるようにするため、また、パケット逸失によりできたキャッシュ内のギャップを埋めるために、実際のディスクへの書き込みを可能な限り遅らせるべきである。理想的には、ディスクへの書き込みは、書き込みバッファー内の構成ブロックの全てが受取られてから行われるのがよい。データ逸失が低い場合、多数のデータをキャッシュすることなく、ファイル転送の終了時のフラッシュ時間を改良することができる。
高ディスク・キャッシング性能を実現する方法についてのいくつかの実施例は、ディスクへの書き込みに際して、高水準インディケーターを使用する手法を含んでいる。キャッシュへ書き込まれたデータが「高水準」を超えると、キャッシュは、キャッシュの最初から書き出しを行う。上述した高逸失対低逸失キャッシング・ポリシー(high-loss versus low-loss caching policies)は、受信部の再伝送テーブルのサイズの移動平均を計算することによって達成される。
移動平均は、その値が、受信部のテーブルの再伝送の数が増加したときにその数に追従し、その数が減少したときにはゆっくりと減少するように調整されるように計算される。それ故、受信部は、上昇傾向時には密着して従い、下降傾向時には遅れることになる。
「高水準」は、再伝送移動平均の対数ステップ関数として計算される。
「高水準」は、全てのディスク書き込みの後で再調整される。
定義: どの時間ポイントにおいても、ネットワーク経路は、「利用可能な帯域幅」または「利用できない帯域幅」を持ち得る。経路は、今現在経路を伝送されている全てのフローにより使用されている帯域幅の合計が経路のボトルネック帯域幅以下であって、且つ帯域幅の一部に未使用部分が残っている場合に、利用可能な帯域幅を持つ、ということになる。逆に、全てのフローのために必要な帯域幅の合計が経路のボトルネック帯域幅を超えていた場合に、経路は、利用可能な帯域幅を持っていないということになる。この場合、帯域幅に対する需要は供給を超えてしまうことになり、帯域幅はリンク上の種々のフローの間で分かち合われなければならなくなる。「帯域幅の公平」というのは、個個のフローにより消費される相対帯域幅と言える。
本発明主題の種々の実施例は、安定した効率的なデータ・スループット、及び、利用可能な帯域幅がある場合に、他のIPデータ・フローがある中でシェアされたリンク上の使用されていない帯域幅の十分な活用を実現する。利用可能な帯域幅のないネットワークの場合、かかる実施例は、伝送速度をTCPと公平に帯域幅を共有するように伝送速度を自動的に適応させる。
かかる実施例では、ネットワークの待機遅れをネットワークの輻輳(或いは逆に、利用可能な帯域幅)を示す信号として使用する、適応レート制御モードを有している。利用可能な帯域幅を有するネットワークでは、待機遅れが低いとの信号があると、これら実施例は、計測された待機遅れの関数としてデータ注入レートを決定する。従来技術では、待機遅れは、TCPの伝送スループットを、利用可能な帯域幅をダイナミックに変更するモードに適応させるために、正確な輻輳信号として用いられ、高速ネットワークの帯域幅能力で安定した高TCPスループットを維持するために、待機遅れの関数として等式ベースのレート制御を適用していた。従来技術による安定した高スループットは、無視できるパケット逸失(パケット逸失の事態が生じたときはそれでもスループットを低下させる)が存在し、且つ高スループットのネットワークの場合(低速度ネットワークの帯域幅は利用しない)だけに限って適用できるのであって、その場合他のTCPのフローに対して帯域幅の公平さを犠牲にすることになる。利用可能な帯域幅を持つネットワークにおいては、ここに提案する実施例は、ランダムに逸失が生じてもスループットを低下させることがなく(遅延ベースの手法をパケット逸失許容の信頼できるUDP支援に適用する)、それ故、たとえ高パケット逸失レートを持つメディアであったとしても高スループットを保つことができる。提案されている実施例は更に、改良されたスケーリング・パラメータを使用して、全ての実用的ネットワークにおいて帯域幅の利用を100%に近づけることができる(毎秒数キロビットからギガビットまで:単に高速かつパケット逸失のごく少ないネットワークでなく)。更に、提案されている実施例は、利用可能な帯域幅のないネットワークでは、TDPフレンドリーなレートを自動的に使用することになる。
現在利用可能な帯域幅のないネットワークでは、提案されている実施例は、計算された注入レートを、同一のネットワークの下で動作しているTCPのフローの数に比例した数に合致させることにより、他のTCPのフローに対して帯域幅−公平なスループットを提供することができる。従来の技術は、同等の動作条件の下で、等式ベースのレート制御がUDP転送の注入レートをTCP等価レートへ合致させるために使用することができ、TCP−帯域幅の公平を実現できるが、安定性、スループット、および帯域幅利用を犠牲にしている。提案されている実施例は、利用可能な帯域幅があるときには安定性、高帯域幅、およびTCP公平を維持しながら、利用可能な帯域幅がいつなくなるのかを正確に決定することができ、またTCP公平を実現することができる。
従来技術のおいては、すべてのTCP処理系の通信の輻輳ウィンドウ/送信レートx(t)は以下の等式により導出することが示されている。
ki(xi,Ti)は、ゲイン関数であり、レートの安定性や応答性のようなダイナミック特性を決定するが、平衡特性には影響しない。
ui(xi,Ti)は、平衡レート割り当て及び公平のような平衡特性をセットする限界効用関数である。
pi(t)は、逸失確率もしくは待機遅れによる輻輳度の指標である。
Ti(t)は、ラウンド・トリップ時間である。
利用可能な帯域幅を持つネットワークに対する送信レートを適用するために、いくつかの実施例は、従来例に見られるような、TCPに対する遅れベースの解決手法を適用している。この、遅れをベースとした解決手法は、限界効用関数:即ち
および、推奨されるゲイン関数:
ki=γαi(t)及び輻輳度指標、pi、ベース・ラウンド・トリップ時間brttiと現在のラウンド・トリップ時間srttiとの差
いくつかの実施例では、brttiは、転送中に計測される最小ラウンド・トリップ時間である。srttiについては、これら実施例は、経路ラウンド・トリップ遅延ではなく、ネットワーク・ラウンド・トリップ遅延を計測し、以下に説明されているように、再伝送用RTOの計算に使用されるものと同じ再帰的予測推定関数を用いて、平滑化されたラウンド・トリップ時間を計算する。
TCP用として従来例にも示されているように、信頼できるUDP転送のための安定した平衡レートを実現するために、この手法は時間がたてば送信レートの変化が0(零)に収束するように努める。これは、レートのサイズを変更し、効用関数に対する輻輳度の指標の比(pi/ui)が1に収束するように、そしてその結果、式1におけるx(t+1)−x(t)が0に収束するように方向を変更することによって達成される。
γ=1/2としてuiとkiについて式1を説明すれば、レート更新の一般式は:
BaseAvgは、brttおよびsrttが小さいときには強制的に1にされ、brttがRTT計測の精度とおおよそ同じくらいの精度であるくらいに小さい場合のケースを処理する。
いくつかの実施例においては、αは、帯域幅および調整可能なアグレッシブネスの幅広い範囲にわたる、収束を目的とする目標レートの一次関数の適応ファクターである。従来技術で示されているように、αファクターは、レートxiでのソースからの送り出しが平衡点に到着するように、転送経路の待機行列へバッファーされるべきパケットの数を表しており、レート制御アルゴリズムの「アグレッシブネス」を表している。αと同一の値を有するフローは公平に帯域幅を有し、より高いα値を有するフローはより多くの帯域幅を比例的に取る。
これら実施例において、従来例と違っているのは、αが、全ての実用的ネットワークの帯域幅(100Kbpsから1Gbpsまでの)範囲に対して安定した目標レートへ収束されるように、その目標レートの一次関数として調整されるということである。
効果的な再伝送タイムアウト(RTO:retransmission timeout)を決定する場合に、正確に経路ラウンド−トリップ時間を見積もることが有用であるのと全く同じように、待機遅れを正確に計算するためにはラウンド−トリップ時間の正確な計測が有用である。待機遅れは、転送経路のネットワーク部分だけに適用するので、種々の実施例では、再伝送のための最終ホストにおける処理時間を含まない、二回目のラウンド−トリップ時間と、ネットワークRTTとを計測する。再伝送のためのRTOを計算するために使われる再帰的推定関数と同じ関数を使って、これら実施例ではネットワークRTTの平滑化された加重平均を計算し、この値を、レート更新関数に使われるベースRTTに対する現在のネットワークのRTTの比を計算するために使用する。
ネットワーク遅れを計算するために、いくつかの実施例は、RTOのために経路ラウンド−トリップ時間を計測する方法と同じ方法を用いている。これら実施例においては,受信部は、各オペレーティング・システムにより提供される最良のクロック・メカニズムを用いて、正確な「クロック・ティックを発生させる。受信部は、再伝送の要求を送り出す直前にこの「ティック」を発生させ、再伝送要求に埋め込む。もしも再伝送要求の再伝送が不必要な場合(例えば、順方向チャンネルに何らの逸失も存在しない場合)には、受信部は、再伝送「なし(empty )」を発生させ、これが、例えば毎10msごとに最小周波数で送り出される。クロック・ティックは再伝送要求PDUに埋め込まれ、受信部から送信部へネットワーク上を走行する。受信部は、再伝送要求を処理するために用いられる正確な時間計算を行い、再伝送要求PDUに受取られたクロック・ティックにこの時間を加え、効果的に処理時間を差引く。受信部は、続いて、クロック・ティックをデータPDUに埋め込み、それを受信部へ送る。クロック・ティックを含むデータPDUが受取られると、受信部は、受取られたクロック・ティックを現在時刻から差引くことにより、経路遅れを決定する。この方法は、受信部がオペレーティング・システムから得られる最高精度のクロック・メカニズムを使用し、送信部が要求を処理する時間が明らかにされているので、精度の高いものである。
いくつかの実施例は更に、帯域幅を、利用できる帯域幅のない輻輳するネットワーク上で、いかなるTCP処理とも公平に、即ち比例的なアグレッシブネスで、分かち合う能力を有している。これら実施例は、計測された(例えば、ネットワーク遅延および/またはパケット逸失の関数として)ネットワークの諸条件のもとで一つのTCPのフローの安定状態のレートを計測することによって、いかなるTCP互換の処理(例えば、既に紹介した式1により導入したあらゆるプロトコル)とも同等に、もしくは設定された比率で帯域幅を分かち合う。これら実施例は、待機遅れを利用可能な帯域幅がないことを示す信号として使用し、現在利用できる帯域幅がないリンク上での設定可能な公平さを保ちながら、利用可能な帯域幅があるリンクでの全帯域幅の利用を犠牲にしない。
公知技術に示されているように、すべてのTCP処理の送信レートは式1(上述)によって展開されることを用いて:

x(t+1)-x(t) = ki(t)(1-pi(t)/ui(t)) (式1)

TCP処理に基づく全ての逸失及び遅延についての平衡レートの式は、pi(t)/ui(t)=1と設定することにより得られる。
提案されている実施例は、式3に示されている遅れベースの輻輳度アルゴリズムを使用している。
公知技術に示されているように、最も多く一般に展開されているTCP方式(TCP Reno)の平衡レートは、式4で示される。
いくつかの提案された実施例では、二つの平衡レートは、式5において、待機遅れおよび特定のTCP通信用平衡レート関数についての適応パラメータαを導き出すために同等に扱われている。
導き出されたαは、その後帯域幅−公平レート(式3を用いて)を計算するために使用される。これは、現在計測されたネットワーク・パラメータ(例えば、ラウンド−トリップ時間および/またはパケット逸失)用のTCPレートに等しいことを意味している。ラウンド−トリップ時間を正確に計測するための方法については既に説明されている。パケット逸失レートは、いろいろな方法、例えば、推定加重移動平均法などを使用して、計測される。
TCPは、例えば「高速TCP」とか、「スケーラブルTCP」とかというように発展するので、同じ方法が、TCPの平衡レートを異なる応答関数に適合させるために利用できる。例えば高速TCPまたはスケーラブルTCP:
本発明主題のいくつかの実施例によるレート制御機能は、二つの大きな要素を有している。即ち、「輻輳」があるとき(即ち、利用可能な帯域幅がないとき)に、帯域幅の公平さのために、待機遅れ、パケット逸失、およびラウンド−トリップ時間に関するTCPレートにレートをイールドするためのαファクターを求めること、および、TCPフレンドリーな状態に入るための信号を出すべき輻輳がいつあるかについて正確に判断すること、である。これら実施例は、本発明主題による「適応x−モード」(帯域幅が利用可能であるときに使用されていない帯域幅を利用する)と、「TDPモード」(利用可能な帯域幅がないときの公平さのため)とにおいて動作する、二つの状態を持つマシーン(二状態マシーン)を使用することにより、TCPフレンドリーのレートを使用すべき輻輳状態を判断する。
これら実施例は、輻輳があった場合にのみTCPフレンドリー・モードへ入り、そのTCPフレンドリー・モードを、輻輳は終了したと知るまでそのままにておく。これら実施例は、モードをいつ切り換えるかを判断するためにヒステリシス・モデルを使用している。もしもラウンド−トリップ時間が増加し、且つ待機遅れがベースrttよりも十分に大きくなり重要なものになると、TCPモードに入れられる。一旦TCPモードに入ると、システムは、rttが減少し、待機遅れが十分前記ベースrttに近づいて待機状態は終わったことを示すまで、TCPモードに留まっている。
いくつかの実施例において使われている特定のパラメータは、実験的に決定される。
この方法は、異なるネットワーク状態において並列フロー・シナリオにはよい結果をもたらす。
レート制御モデルのパラメータは、アプリケーションに対し調整可能な「制御ノブ」を与えている。設定可能なパラメータとして、αを明らかにすることにより、転送が進行中に目標レート即ちアグレッシブネスの変更が可能になる。
アプリケーションは、例えば一つの標準TCPのフロー、或いは他の二つのTCPのフローにレート等価な多数の(またはタイプの)TCPのフロー関してそのアグレッシブネスをセットできる。更に、アプリケーションは、特定のモード、例えば「トリックル(trickle )」モードを選択できる。この「トリックル」モードにおいては、フローはTCPとの共有の場合には完全に最小の閾値に後退するが、単独で進行中には全帯域幅を使うように急成長する。
いくつかの実施例は、非常に効率的なトリックル転送を紹介している。
データの転送において他のネットワーク活動がない限り全回線容量を利用でき、ネットワーク活動が検出されたときには非常に低いレートにバックアップするようにしている。非輻輳モードで進行するときには、適応レートモードで転送を進めアグレッシブネス・ファクターを非常に低くセットすることによって、フローは利用できる帯域幅の全てを利用し、輻輳モードに入ったときには完全に後退する。上記に関連して、転送アプリケーションは、配送時間を保証するために、このときの転送用として最小のレート・閾値をセットすることができる。トリックル・アプリケーションのユーザーは、転送する時間のネットワークの帯域幅をトレーディングすることによってオンザフライで(on-the-fly)最小閾値を変更することができる。
いくつかの実施例は、任意ではあるが暗号化要素を有していて、オンザフライでデータブロックを暗号化し、復号化する。
転送の始めに、SSH或いはSSL/TLSといった確立された方法を用いて、セキュアTCPチャンネルがリモート・エンド−ポイントにセットアップされる。そのような実施例における受信部は、ユーザーが設定可能な暗号(暗号化アルゴリズム)を与えられたランダム対称暗号化キーを発生させ、セキュア・チャンネルを使用している送信部と同キーを交換する。いくつかの実施例においては、前記エンド−ポイントは、前記暗号化キーを周期的に変更し、前記セキュア・チャンネルを介して新しいキーを交換するように決定できる。送信部は、データの秘密性を確かなものにするために各データブロックを暗号化し、データの認証を確かなものにするためにメッセージ認証コードを付け加える。この方法は、アプリケーション−レベルのデータ転送アプリケーションなどと同じように、種々の実施例において任意なものとして備えられている。この方法は、インターネットのような、公共のセキュアでないネットワークであっても、データを安全に転送できる手段をアプリケーションに対して提供することになる。
いくつかの実施例は、ファイルの転送を制御し且つモニターする能力も提供している。これら実施例では、管理用としてTCPソケットインターフェースを提案している。同インターフェースによれば、管理用アプリケーションは、管理される転送エンド−ポイントと同じもしくは別のコンピュータ上で走ることができる。このインターフェースによれば、転送を開始および停止させ、オンザフライで転送レートを修正し、転送を一時停止または再開させ、またオンザフライで転送パラメータを変更するといった、制御およびモニター動作が可能となる。転送パラメータの変更には、適応レート・モードをイネーブルまたはディスエーブルさせ且つアグレッシブネスを変更するといった動作が含まれる。前記制御およびモニター動作には、基本的な転送統計を読み出し、プログレッシブ・ダウンロードに必要な転送統計を読み出し、且つFASP固有統計、例えば再伝送データの構造パラメータ、ディスク書き込み統計および適応レートパラメータ等、を読み出す能力といった動作も含まれる。このインターフェースは、種々の転送実施エレメントをアプリケーションに一体化するためのメカニズムである。前記インターフェースは、優先順位および帯域幅の利用の管理といった転送ポリシーをアプリケーションに実行させる。
いくつかの実施例は、アプリケーションレベルのリライアブルなUDPプロトコルにより、アプリケーションが進行中の転送の転送レートを変更できるようにしている。管理インターフェースを使用することにより、転送マネージャは、データ転送における二つのエンド−ポイントの一方を制御する。送信部および受信部の両方は、同一の転送マネージャによりに制御されるときには、データ処理用スレッドとは関係なく、モニターおよび制御メッセージを転送マネージャと取り交わすことのできる専用の処理スレッドを有している。オンザフライでレート変更といった制御コマンドを受取るときに、送信部および受信部の専用管理スレッドは、新たな値および主たるデータ処理スレッドの問い合わせを記憶し、周期的に新たな値を取り出す。
もしも前記マネージャが受信部を制御しているとすると、マネージャは受信部に対して所望の最小または最大レート・閾値をパスする。受信部は、適応レート・モードで要求される目標レートを計算するに際しこの新たな値を使用し、また、固定レート・モードで動いている場合には目標レートを最大閾値にセットする。受信部は、目標レート(計算されたものであれ、セットされたものであれ)を周期的統計メッセージと共に送信部へ送り、送信部はそれに従う。
前記マネージャが送信部を制御している場合、マネージャは、送信部に対して所望の最小または最大レート閾値をパスする。もし固定レート・モードで動作していると、送信部はその固定レートとして新たなレートを使用し、統計メッセージの中で受信部が要求している目標レートを無視する。もし、適応レート・モードで動作中であると、送信部は、マネージャによってセットされた最小および最大レートを記憶し、それらを、受信部が要求している目標レートと比較する。もしも受信部により要求されている目標レートが最大レート閾値よりも大きいと、送信部はその目標レートを最大レート閾値にセットする。もしも受信部により要求されている目標レートが最小レート閾値よりも小さいと、送信部はその目標レートを最小閾値にセットする。それ以外では、送信部はその目標レートを、受信部により要求されている目標レートとする。
本発明主題の種々の実施例によるデータ転送は、予測能力を持つという性質から、ユーザーは、転送レートではなく、転送する時間をセットすることを選択できる。アプリケーションの一実施例によれば、ユーザーは、転送する時間もしくは到着推定時間をセットでき、それに合致させるように要求される目標レートを計算することができる。転送マネージャは、上述したように、オンザフライで目標レートをセットすることができる。
進行中の転送を一時停止するというのは、オンザフライで目標レートをセットするという特別のケース(レートを0(零)にセットする)であって、送信部および受信部の両方に、データ送り出しとデータ受取りの試みとの完全な停止を要求するものである。この特長は、帯域幅の優先順位について何の予定もないときには有用である。一時停止するには、転送マネージャが、目標レートを、適応−レート・モードの場合には最大レート閾値を、0(零)にセットする。送信部は、転送マネージャから、もしくは統計メッセージを介して受信部から、新たなレート値について知る。送信部が一旦この特別なケースを検出すると、送信部はデータの送り出しを停止し、転送マネージャが0よりも大きい値の目標レートをセットしてくれるのを待つ。もしも受信部が転送マネージャに制御されているとすると、受信部は0という新たなレートがセットされたことを直接知ることになる。桃霜送信部が転送マネージャに制御されているとすると、送信部は、制御目メッセージを受信部に送り、「一時停止」状態に入ったことを受信部に知らせる。いくつかの実施例において、受信部が「一時停止」状態に気づいているということは、データ受取りタイムアウトを引き起こしてしまわないようにするために重要なことである。
転送マネージャは、管理インターフェースにより、レート制御モードのセッッティング(固定レート、適応レート、および帯域幅アグレッシブネスを送信部もしくは受信部へパスする。もしも受信部が転送マネージャに制御されていると、受信部は、新たな制御モードを記憶し且つ実行する。受信部は、統計メッセージまたは制御メッセージを介して、固定または計算された目標レートを送信部へ送る。もしも送信部が転送マネージャーにより制御されているとすると、送信部は新たなセッティングを記憶し、それを制御メッセージを介して受信部へ送る。一実施例において、帯域幅アグレッシブネスは、多数の標準TCPアグレッシブネスという言葉で表現できる。いくつかの実施例は、標準TCPおよびその他のTCPに関して、アグレッシブネスの連続してスライドするスケールをサポートする能力を有する。これは、フロータイプに関連するアグレッシブネス値を「ダイアルする」ため、連続インデックスとのフロータイプ互換性として管理インターフェースを介してエンド・ユーザに明らかにされるようにしてもよい。
OSIプロトコル・スタックについて、本発明主題のいくつかの実施例は統合データ転送レイヤー、セッション・レイヤー、およびサービス・レイヤー・プロトコルを提供している。
種々の実施例は、SSHおよびSCPといったファイル転送のフレームワークをオペレーティング・システム内において統合することを含んでいる。SSHは、ユーザーに対して認証およびキーの交換についてのフレームワークを提供している。いくつかの実施例は、任意のセキュア・モードで動作する際の暗号化キーをつくるために、この枠組みを使っている。SCPは、リモート・ファイル・コピー用の事実上のユーザー・インターフェースを提供する。いくつかの実施例は、TCPへの別の高性能のデータ経路として、SCPとの統合を有している。
いくつかの実施例は、転送されたデータの消費なく或いは最小の消費でファイル転送における再開性(resumability)を可能とする転送メタ・データを記憶する。転送は、同一のファイルを記憶している送信部であればどのような送信部からでも再開され、必ずしも同一の送信部である必要はない。これにより、システムを余分に配備する必要がなくなり、アプリケーションは、送信部システムもしくはそこへの接続の不具合が生じた後、バックアップ用の送信部もしくは接続ルートが利用可能となったときに再開される。かかる再開性のサービスは、完全性のチェック、完全性の保証の平衡、及び検証時間(検証時間はエッジからエッジまでの転送速度を再度計数する)についての数レイヤーを提供する。
ここに示されたブロックベースの転送システム、方法、およびソフトウェアの目標レートベースの本質は、等式ベースのレート制御と共に、転送ポリシーを有する実施例を提供する。かかる転送ポリシーのいくつかは、帯域幅の割り当て、優先順位、およびファイル転送の手動コントロールに関係している。
a)帯域幅割り当てポリシー
多数のロケーションとそれらロケーション間を結ぶネットワーク・リンクの容量による構成の場合、管理者もしくは帯域幅管理アプリケーションは異なるファイル転送アプリケーション間のネットワーク容量の割り当てを決定することができる。各フローの最大転送レートはファイル転送アプリケーションへパスされて実施される。転送レートの上限は、ファイルの転送が開始される前に、もしくは転送の進行中にパスされる。
時間方式帯域幅割り当てについて、ファイルの転送が或る転送時間に合致しなければならないとき、一つの実施例では、最小転送レートをセットすることができる。フローは、輻輳のある中で公平に動作するが、最小転送レートを超えてスローダウンすることはない。このことにより、不公平にその他のトラフィックの全てに対し残りの帯域幅について競合させることを代償にして最小の配信時間が保証される。
b)優先順位ポリシー
いくつかの実施例は、優先レベルを、レートを制御するアグレッシブネスファクターに関連付けることができる。それ故、優先度の高いトラフィック(高優先トラフィック)は、ダイナミックに且つ優先度の低いトラフィック(低優先トラフィック)より多くの帯域幅が割り当てられる。優先順位についての極端な場合として、低優先トラフィックは、高優先トラフィックと競合したときに、完全に停止するように設定できる。このことは、トリックル・トラフィックについても言え、トリックル・トラフィック優先を最低レベルにセットすることにより、他のトラフィックに対して影響を与えないトリックル転送即ち他のトラフィックが存在するときには停止するトリックル・トラフィックとすることができる。
c)ファイル転送の手動制御ポリシー
いくつかの実施例において用いられている管理インターフェースにより、ユーザーまたは管理者は、オンザフライで転送パラメータを変更することができる。これは、他の転送がより早く実行できるように転送を一時停止し、また同様に、進行中の転送の速度を落し或いは速度を速めるということを含んでいる。
いくつかの実施例は、アプリケーションに対して以下のパラメータを明らかにしている。即ち、目標レート(適応レート制御の場合の最大レート)、最小レート(適応レート制御の場合の)、および適応ファクターである。これらパラメータは、転送の開始前もしくは転送が進行中にセットされることができる。これらパラメーターに基づき、アプリケーションは、以下をするためにファイル転送をインテリジェントに制御する。
・固定レート制御を特定し且つ目標レートを供給して固定レートでファイル転送を行うこと、
・適応レート制御を特定し且つリンクのキャパシティよりも高いもしくと同じ最大レートを供給することによって、競合するトラフィックが存在しても公平に適応するリンクキャパシティでファイル転送を行うこと、
・所定のレートでファイルを転送すること、但し、輻輳が存在する場合には適応レート制御を特定し且つ最小レートを供給することによって最小レートとする。フローは、競合するトラフィックとリンクを分かち合うように適応するが、そのレートは特定された最小値を下回ることはなく、従って配送時間が保証される、
・リンク・キャパシティでファイルを転送すること、但し、適応レート制御を特定し且つ適応ファクターとして最小値を供給することによって、競合するどのようなトラフィックに対しても影響を与えないこと。フローは、リンクのキャパシティで走るが、競合するトラフィックが存在すると停止し、その結果、通常のネートワークの働きには一切影響しない。これは効果的なトリックル転送に使用できる。
転送が行われている最中に、アプリケーションが、転送レートを変更することができるので、アプリケーションは目標レートをゼロにすることにより転送を一時停止させ、またゼロではない値へ戻すことによって、転送を再開させることができる。
いくつかの実施例は、インテリジェントなブロック・ベースのキャッシングサービスを提供する。このサービスにより、これら実施例は、ファイルのセグメントが既に受信部システムへ転送されたかどうかを判断し、それをネットワークを通して転送する替わりにキャッシュされているデータを再使用する。このキャッシング・サービスは、完全性のチェックの数レイヤーを提供する。完全性チェックのタイプは、アプリケーションによって特定されるか、或いは最適化機能を使用してFASPによって自動的に決定される。最適化機能は、ネットワーク・キャパシティおよび転送待機列に対するキャッシュ完全性検証時間を考慮する。もしも転送が、ローカルの完全性検証よりも早い場合、前記キャッシングサービスは、データの再転送を選択する。それ以外では、ローカルにキャッシュされたデータは再使用される。
いくつかの別の実施例は、アプリケーションが両面パイプライン型データ転送を実行できるようにするために必要な全てのモニター・サービスと制御サービスとを提供する。このデータ転送は、プログレッシブ・ダウンロードとも称される。両面データ転送は、データを受け取ると同時にそのデータを第三の転送エンド−ポイントへ送り出すか或いは消費する一つのエンド・ポイントを有している。両面パイプライン型データ転送の例は、メディア・ファイルをダウンロードし同時にそれをメディア・プレーヤへ供給するアプリケーションを有するか、或いは、ユーザーに代わってファイルをダウンロードし、ファイルをキャッシュへ記憶する一方同時にユーザーへそれを配送するアプリケーションを有している。
そのような実施例の一例は、AからBへのデータ転送を所望のレートで開始し、Bにおいて、ファイルの先頭から始めて、実効受取りレート、逸失レート、受取られた連続データの量を明らかにすることによって、パイプライン型データ転送を実現する方法を備えている。この方法はさらに、Bで明らかにされたデータとBからCへの所望の転送レートとに基づいて、BからCへの転送を開始する時間を決定することも含んでいる。この方法はまた、BからCへの転送の実効レートおよび送られるデータの量をBで明らかにすることも含んでいる。かかる情報に基づき、この方法は、パイプラインが正しく機能しているかどうかを決定することができる。BからCへの転送が、AからBへの転送よりも先行する場合、この方法は、BからCへの転送を遅くし、或いは一時的に停止することさえもできる。更に、この方法は、要求許可されたBからCへの転送の最小ブロック数を明らかにすることを含んでいる。これにより、この方法は、Bにおいてそのポイントまでのデータを廃棄することができ、ストレージが制限されている場合には有用である。
いくつかの実施例は、リファレンスを用いてファイルを特定すること、およびファイル転送することを含んでいる。伝送エンドポイントは、特定のリファレンスに基づいてファイルもしくはディレクトリーをダウンロードまたはアップロードできる。種々の実施例においてこれらリファレンスは、リモート・ファイルもしくはディレクトリーの識別番号、転送レート、適応レート制御、および暗号化といった転送パラメータを含んでいる。
基準のフォーマットの一例は以下の通りである:
種々の実施例において、以下のオプションのうちの一つまたはそれ以上をリファレンスとして利用できる。
xfer=アップ|ダウン アップは、アップロードを表しており、その場合、 径路は目標ディレクトリを表す。
auth=イエス|ノー もしイエスにセットされると、ダウンロードを強制 的に暗号化し、もしノーとセットされると、強制的 に復号化する。もし、ノー又は、なしにセットされ ると、ユーザーが暗号化するかしないかを選択す る。
maxrate=<val> 許容される最大レートを<val>Kbpsとセッ トする。ユーザーは転送レートをこの値まで選択で きる。
defrate=<val> デフォルトの転送レートを<val>Kbpsに セットする。ユーザーは、もう一つのレートを許容 される最大のものまでの間で選択する。
adapt=イエス|ノー もしイエスにセットされると、適応レート制御を使 用する。
port=<val> UDPポートを<val> にセットする。
sign=<val> 参照ストリングの署名、完全性に保険をかけるため の安全措置として。
リファレンス・サービスにより転送を提供することによって、FASPは、アップリケ−ションへ簡単に統合できる。アプリケーションは、例えばウェブ・ダウンロードやアップロード、FASPのダウンロードのためのリファレンスとのイーメール添付置換(email attachment replacement)、アセット管理システム・チェックイン及びチェックアウトである。本発明主題のいくつかの実施例は、ブロック・データのペイロードを繰り上げするためにUDPを利用している。しかしながら、事実上、どのような転送またはネットワーク・レイヤー・メカニズムであっても同じ目的を達成することができる。例えば、別の転送およびネットワーク・レイヤーは、ユーザーによって定義づけられた転送プロトコルをエンドポイントにおけるIPもしくは修正TCPスタックに含んでいる。エンドポイントにおけるTCPスタックは、UDPのように動作するように修正(例えばフロー制御とか再伝送とかがないといった)することができる。ブロックは、ファイア・ウォールの設定を確立できるネットワークを通してTCPパケットとして送られる。その結果、特殊なファイアウォールおよび侵入検出の設定をUDPに対してしなくても済む。その他の別のトランスポートは、IPと同様のサービスを提供できる非−IPネットワークを含む。前記サービスとは、即ち、「ベスト・エフォート」・コネクションレス・ルーティングおよび、データ転送動作に含まれる2またはそれ以上のエンドポイント間におけるパケットの配送である。かかるネットワークには、衛星、パケットラジオ、二地点間または一斉通信ネットワーク、およびATMが含まれる。
いくつかの実施例のアーキテクチュアは、二重構造となっている。かかる実施例における第一の階層は、アプリケーションに対してブロック・ベースのファイル転送サービスを提供するプロトコルを提供するものである。第二の階層は、プロトコルの上に構築される最小ファイル転送アプリケーションである。
しかしながら、このアーキテクチュアの変形例は、ドライバー、カーネル・モジュールまたはモノリシック・オペレーティング・システムの単なる一部として、オペレーティング・システムの一部であるシステムおよび方法を実行すること、を含むことができる。その他の変形例は、本発明主題をモノリシック・データ・転送アプリケーションへ実施すること(例えば、単一階層による手法)を含む。
その他の実施例は、既存のTCPトラフィックを遮断しここに説明されている種々の要素によってネットワークを通してそれをリモート・エンドのプロクシへ伝送するためにインターセプション・プロクシ(透明性が歩かないかに関係なく)を使用することを含み、TCPを用いてデータをTCPアプリケーションのリモート・エンドへパスする。このインターセプション・プロクシは、ファイルまたはアプリケーション・サーバー・マシーンで動作するソフトウェア・ピース、またはネットワークに接続されたハードウェア装置である。更に別の実施例では、ネットワーク・ファイル・システム内に本発明の主題を含んでいる。また別の実施例では、効率的なバルク転送のために、無線または衛星ネットワーク用の特別なアプリケーション・ゲートウェイを有している。
いくつかの実施例は、信頼性、性能、安全性、および管理可能性を、プロトコル・パラメータの調整により達成できる方法とアルゴリズムとを提供する。これらパラメータの値は、ネットワークおよびオペレーティング・システムの環境に従ってセットされる。信頼性、性能、安全性、および管理可能性は、これらのパラメータを操作することによって、またはそれらが計算されたやり方によって、達成される。これらパラメータには以下のものが含まれる。
・ブロックの大きさ(サイズ)
・再伝送タイムアウトパラメータγおよびη
・ファイル・キャッシュのサイズ
・ファイル・キャッシュ低、高の水準
・レート制御用FASPおよびTCP互換モード・パラメータα
・レート制御用ベース・平均ステップ関数・パラメータ
・レート制御用パラメータC
・FASPおよびTCPモード間の状態を切換えるレート制御用パラメータ・ファクター
「要約」は、技術的開示内容の性質と要点とを読者が速やかに確かめることができるようにするために[発明の概要」を求めている37C.F.R.第1.72(b)条の規定に従い用意されたものであることを強調する。同「発明の概要」は、特許請求の範囲の範囲もしくは意味を解釈または限定するために使用されないとの理解のもとに提出されたものである。
当業者であれば本発明の主題の性質を説明するために記述され且つ図解された詳細、材料、部品の配列、方法の段階の配列は、添付されている特許請求の範囲に表明された本発明主題およびそれらの法的同等物の範囲を逸脱することなく、種々のその他の変更をなし得ることは直ちに理解されよう。
添付されている図は、本システムに関するいくつかの態様と例とを示すためのものであるが、本発明の主題を専用的に表すもしくは余すところなく表すべく意図されたものではない。
一実施例によるシステムを示す模式的なブロック図である。 一実施例による送信/受信システムを示すブロック図である。 一実施例によるデータ送信プロセスを示すブロック図である。 一実施例によるデータ受信プロセスを示すブロック図である。 一実施例によるシステムのデータ・フロー図である。 一実施例によるシステムのデータ・フロー図である。 一実施例によるシステム700のデータ・フロー図である。

Claims (39)

  1. 伝送中のデータの任意の高遅延、逸失又はリオーダーのため、及び、任意の高伝送速度のため、逸失データを再送するためのタイム・オーバーヘッドが一定に維持される、リライアブルでないネットワークを介する送信部と受信部の間のリライアブルなデータ転送方法であって、
    前記送信部からデータ・ブロック伝送の注入レートを取得し、
    前記送信部から前記受信部に前記注入レートで順番にデータ・ブロックを送信し、
    それぞれ識別番号を有する1以上のデータ・ブロックを前記受信部で受信し、
    受信した識別番号に基づいて失われたオリジナルデータ・ブロックを検出し、
    前記予測経路ラウンド−トリップ時間の関数として受信推定時間に基づいて失われた再伝送データ・ブロックを検出し、
    前記受信部から前記送信部へ再伝送要求を送信し、前記送信部で対応するデータ・ブロックをデータ・ソースから検索し、前記データ・ブロックを前記受信部に伝送する時間の予測推定を経て、経路ラウンド−トリップ時間を検出し、
    逸失ブロックの数が増加して、データIDを加える又はストレージから検索する時間が悪化しないように、前記受信部で逸失したデータ・ブロックの1以上の識別番号を格納し、
    伝送が遅れているだけで、いずれは前記受信部に到着するデータ・ブロックだけを早すぎて再伝送することなく、データの連続受信を最大化するように、できるだけ早く前記送信部が逸失データを再伝送できるように、前記予測経路ラウンド−トリップ時間に基づくタイマーで前記受信部から前記送信部へ再伝送要求を送信し、
    再伝送要求の数が増加して、再伝送すべきブロックの前記ブロックIDを加える又は検索する時間が悪化しないように、失われたデータ・ブロックの再伝送要求を前記送信部に格納し、
    前記送信部での再伝送要求のストレージを最小化するように前記注入レートと同等のレートで再伝送されたデータを前記送信部で送信し、
    複合したデータ逸失を避けるために、まだ送信されていないデータを送信する前に、全ての未済の再伝送要求についてのデータを最初に送信する、
    ことを含む方法。
  2. 経路ラウンド−トリップ時間を予測するヴァン・ヤコブソン法を実行する、
    ことをさらに含む請求項1記載の方法。
  3. 直線配列(linear array)で再伝送すべきブロックの識別番号を前記受信部で格納することをさらに含み、
    各ブロックの線形インデックス(linear index)は前記送信部への再伝送要求とともに送信され、前記データ・ブロック自身とともに返送される、請求項1又は2記載の方法。
  4. 数字でソートされたブロックIDの実質的に一定時間の検索を有する、改良レッド・ブラック・ツリーで再伝送する必要がある複数の識別番号を前記送信部で格納する、
    ことをさらに含む請求項1乃至3いずれかに記載の方法。
  5. 前記受信部から前記送信部へ再伝送要求を伝送するための時間を最短にするように、前記注入レートで可能な限り最も小さなパケットで再伝送要求は送信される、
    請求項1乃至4いずれかに記載の方法。
  6. キャッシュ・ヒット率を最大化するように、ディスク書き込みキャッシュ・プロセスでの逸失ブロックの数の移動平均(running average )の対数関数に従って計算された高水準を用いる(このように、ディスクへのランダムアクセスを最小化する)、
    ことをさらに含む請求項1乃至5いずれかに記載の方法。
  7. 前記送信部はデータ・ブロックを不連続に(out-of-sequence )伝送する、請求項1乃至6いずれかに記載の方法。
  8. 前記送信部は前記データ・ブロックの伝送のための注入レートを取得する、
    ことをさらに含む請求項1乃至7いずれかに記載の方法。
  9. 前記注入レートの取得は、固定された注入レートの取得を含む、請求項1乃至8いずれかに記載の方法。
  10. 前記注入レートの取得は、可変注入レートの取得を含む、
    請求項1乃至8いずれかに記載の方法。
  11. 同時に同一ネットワーク経路を伝わる異なるデータ伝送に関して前記伝送速度に優先順位をつけるために、前記注入レートは繰り返し再計算され、前記注入レートは、同時に前記同一ネットワーク経路を伝わる前記異なるデータによって使用される対象プロトコルの1つのフローについての安定状態での伝送レートの比率によって計算され、
    a)ユーザ・アプリケーションから、対象プロトコル・タイプ、最小注入レート、最大注入レート及び優先順位付け要素を取得し、
    b)定期的に新しい注入レートを再計算し、
    c)前記新しいレートを前記優先順位付け要素と乗算することによって前記優先順位付け要素に基づく前記注入レートを計算し、最小又は最大注入レート制限を適用する、
    ことをさらに含み、
    前記b)新しい注入レートの再計算は、
    伝送前に及び転送中に瞬間ネットワーク・ラウンド−トリップ時間を測定し、ベース・ラウンド・トリップ時間brttiとして測定された最小値を記録し、
    転送中に前記瞬間ネットワーク・ラウンド−トリップ時間を測定し、平滑化された平均ラウンド−トリップ時間srttiを計算し、
    失われたデータ・ブロックを検出し、平均パケット逸失確率piを計算する、
    ことを含み、
    各時間間隔(i+1)で、以下を用いて新しいレートを計算する、
    ここで、
    brtti+1 <5 且つ srtti+1 <20 の場合
    BaseAvg i+1 =1
    それ以外の場合 BaseAvg i+1 =brtti+1/srtti+1
    である請求項1乃至8いずれかに記載の方法。
  12. 前記異なるデータ転送は、請求項11にかかわるレート更新を持つプロトコルを用い、以下によって定義される安定状態レートを持ち、
    Rate(安定状態)=α/(srtti−brtti)
    ここで、αは、ユーザー・アプリケーションによって要求された要求伝送レートの定数倍である、
    請求項11に記載の方法。
  13. 前記異なるデータ転送は、
    全てのレート、又は、ウィンドウ・ベースTCPプロトコルの伝送レートを含み、
    前記TCPプロトコルの伝送レートは、
    絶対ラウンド−トリップ遅延、ラウンド−トリップ遅延の変化、パケット逸失のうち1以上のパラメータの関数として、時間が経過すると展開され、且つ、
    安定状態の伝送レートは1以上のこれらのパラメータの関数として既知であり、
    ここで、
    αは、請求項11に記載の方法の前記安定状態レートと、絶対ラウンド−トリップ遅延、ラウンド−トリップ遅延の変化又はパケット逸失について示された前記目標TCPプロトコルの前記安定状態レートとを、等式化することによって導出される、
    請求項11に記載の方法。
  14. α値は、
    Ratei=Rate i+1=Rate(安定状態)と設定して、
    Rate(安定状態)=α/(srtti −brtti)
    上式によって求められる請求項11の方法に関する前記安定状態レートと、
    ここで、Cは転送についての前記経路MTUに依存する定数であり、
    Rttiは前記平滑化されたラウンド−トリップ時間であり、
    piは前記パケット逸失確率であり、
    上式によって求められるTCP Renoの前記既知の安定状態レートを等式化することによって、
    結果として、
    上式によって生成される、請求項13に記載の方法。
  15. 前記プロトコル・タイプ、最大及び最小レート、及び優先順位付け要素は、前記転送が実行中に、前記ユーザー又はユーザー・プログラムから取得される、
    請求項11に記載の方法。
  16. パラメータは管理インターフェースによって取得される、
    請求項15に記載の方法。
  17. 前記計算された注入レートは、前記送信部と受信部の間の前記ネットワーク経路が、同一のネットワーク経路上で他のデータ転送が現在実行中であることを示す「輻輳」している場合のみ適用され、
    a)前記ベース・ラウンド−トリップ時間brtti を測定し、
    b)前記平滑化されたラウンド−トリップ時間srtti を測定し、
    c)ヒステリシス・モデルを用いて前記平滑化されたrtt 及び前記ベースrttとの差異(ネットワーク待ち遅れ)、及び前記差異の変化の向きを以下のように計測することにより、「輻輳」及び「非輻輳」モードを決定し、
    drtti =srtti −brtti −10とし、
    −初期状態は非輻輳(NC)モードであり、
    −NCモードで:srtti が最後のサンプルから増加し、
    且つ、drtti >0.2である場合、
    輻輳(C)モードにスイッチし、
    それ以外ではNCモードを維持し、
    −Cモードで :srtti が最後のサンプルから減少し、
    且つ、drtti <0.5である場合、
    非輻輳(NC)モードにスイッチし、
    それ以外ではCモードを維持し、
    d)「輻輳」モードでのみ前記計算された注入レートを使用し、それ以外では前記デフォルト注入レートを使用する、
    ことを含む請求項11乃至16いずれかに記載の方法。
  18. 前記「輻輳モード」の場合、前記優先順位付け倍率は、前記目標プロトコルの小部分に設定し、前記伝送レートを前記目標プロトコルの前記安定状態レートの小さな割合と等しくなるようにする、
    請求項17記載の方法。
  19. 前記転送経路の前記総帯域幅容量の自動検出を用いて、少なくとも最初に前記注入レートを確立する、
    ことをさらに含む、請求項1乃至18いずれかに記載の方法。
  20. 前記注入レートを決定するポリシーを選択するインターフェースを、ユーザー又はアプリケーションに与え、
    任意に、目標プロトコル・タイプ、前記目標プロトコルの前記安定状態レートに乗算する一定係数、及び前記目標注入レートを制限する最大又は最小レートを任意に選択することを含む、
    ことをさらに含む、請求項1乃至19いずれかに記載の方法。
  21. データ・ソースと通信する送信部から受信部によってデータを受信する方法であって、
    前記送信部及び前記受信部間のネットワーク上の伝送の予測経路ラウンド−トリップ時間を決定し、
    前記送信部からデータ・ブロックを受信する注入レートを取得し、
    各々識別番号を含む、1以上のデータ・ブロックを受信し、
    受信した識別番号、及び、経路ラウンド−トリップ時間の関数である予測受信時間に基づいて失ったデータ・ブロックを検出し、
    前記受信部によって、1以上の失ったブロックを識別する再伝送要求を生成することを含み、
    前記再伝送要求は失ったブロックを識別するために予測経路ラウンド−トリップ・タイムアウトに基づいており、前記再伝送要求は、前記注入レートに同等のレートで送信される、
    方法。
  22. 経路ラウンド−トリップ時間を予測するヴァン・ヤコブソン法を実行する、
    ことをさらに含む請求項21に記載の方法。
  23. 直線配列で再伝送すべきブロックの識別番号を格納することをさらに含み、
    各ブロックの線形インデックスは、再伝送要求とともに前記送信部へ伝送し、前記データ・ブロック自身とともに返送する、
    請求項21又は22に記載の方法。
  24. 再伝送要求は、前記注入レートに対して可能な限り最小のサイズのパケットで伝送する、
    請求項21乃至23いずれか記載の方法。
  25. ディスクに対するランダム・アクセスを最小とするため、ディスク書込みキャッシュ・プロセスにおける再伝送要求の再伝送テーブルの移動平均サイズとして計算される高水準(watermark )を備える、
    請求項21乃至24いずれかに記載の方法。
  26. 前記送信部は、データ・ブロックを順番どおりでなく(out-of-sequence )伝送する、
    請求項21乃至25いずれかに記載の方法。
  27. 前記送信部は、前記データ・ブロックの伝送のための注入レートを取得する、
    ことをさらに含む、請求項21乃至26いずれかに記載の方法。
  28. 前記注入レートの取得は、固定注入レートの取得を含む、
    請求項21乃至27いずれかに記載の方法。
  29. 前記注入レートの取得は、可変注入レートの取得を含む、
    請求項21乃至28いずれかに記載の方法。
  30. 送信部と受信部の間のネットワークを介したデータの転送のためのデータ転送システムであって、
    前記送信部からデータ・ブロックの伝送のための注入レートを取得する手段と、
    前記送信部から前記受信部に前記注入レートで順番にデータ・ブロックを送信する手段と、
    各々識別番号を有する1以上のデータ・ブロックを前記受信部で受信する手段と、
    受信した識別番号に基づいて失われたオリジナルデータ・ブロックを検出する手段と、
    前記予測経路ラウンド−トリップ時間の関数である受信推定時間に基づいて失われた再伝送データ・ブロックを検出する手段と、
    前記受信部から前記送信部へ再伝送要求を送信し、前記送信部で対応するデータ・ブロックをデータ・ソースから検索し、前記データ・ブロックを前記受信部に伝送する時間の予測推定を経て、経路ラウンド−トリップ時間を決定する手段と、
    逸失ブロックの数が増加して、ブロックIDを加える又はストレージから検索する時間が悪化しないように、前記受信部で逸失したデータ・ブロックの1以上の識別番号を格納する手段と、
    伝送が遅れているだけで、いずれは前記受信部に到着するデータ・ブロックだけを早すぎて再伝送することなく、データの連続受信を最大化するように、できるだけ早く前記送信部が逸失データを再伝送できるように、前記予測経路ラウンド−トリップ時間に基づくタイマーで前記受信部から前記送信部へ再伝送要求を送信する手段と、
    再伝送要求の数が増加して、再伝送すべきブロックの前記ブロックIDを加える又は検索する時間が悪化しないように、失われたデータ・ブロックの再伝送要求を前記送信部に格納する手段と、
    前記送信部での再伝送要求のストレージを最小化するように前記注入レートと同等のレートで再伝送されたデータを前記送信部で送信する手段と、
    複合したデータ逸失を避けるために、まだ送信されていないデータを送信する前に、全ての未済の再伝送要求についてのデータを最初に送信する手段と、
    を備えるデータ転送システム。
  31. 逸失ブロックを特定するためにラウンド−トリップ時間を正確に予測する経路ラウンド−トリップ時間予測装置、
    をさらに備える請求項30に記載のデータ転送システム。
  32. 前記経路ラウンド−トリップ時間予測装置はヴァン・ヤコブソン法を実行するように調整されている、
    請求項31記載のデータ転送システム。
  33. 番号によってソートされた再伝送用のシーケンス番号を格納するために、実質的な一定時間検索を有する改良レッド・ブラック・ツリーが前記再伝送手段によって使用されている、
    請求項30乃至32いずれかに記載のデータ転送システム。
  34. ディスクに対するランダム・アクセスを最小とするディスク書込みキャッシュ機構をさらに備え、
    前記機構は、再伝送テーブルのサイズの移動平均として計算される高水準(watermark )を用いる、
    請求項30乃至33いずれかに記載のデータ転送システム。
  35. リライアブルで効率的なデータ転送のための管理インターフェース、
    をさらに備える請求項30乃至34いずれかに記載のデータ転送システム。
  36. データ・ソースと通信する送信部と受信部の間のデータ転送方法であって、
    前記データ・ソースからのデータを1以上のブロックに分割し、
    前記1以上のブロックの各ブロックに連続した識別番号を付し、
    前記データ・ブロックの伝送のための注入レートを受信し、
    前記受信部から前記注入レートと同等に伝送された、失ったブロックを識別するための予測経路ラウンド−トリップ・タイムアウトに基づいて、1以上の失ったブロックを識別する再伝送要求を前記受信部から受信し、
    前記再伝送要求で識別された失ったブロックと、前記1以上のブロックのうちの残りのブロックとを備えるデータを前記注入レートで伝送し、前記伝送はデータ・ブロックの連続でない(non-sequential)伝送が可能である、
    ことを含む方法。
  37. 前記注入レートの受信は固定注入レートの受信を含む、
    請求項36記載の方法。
  38. 前記注入レートの受信は可変注入レートの受信を含む、
    請求項36記載の方法。
  39. 数字でソートされた再伝送の実質的に一定時間の検索を持つ、改良レッド・ブラック・ツリーで再伝送する必要がある複数の識別番号を前記送信部で格納する、
    ことをさらに含む請求項36乃至38いずれかに記載の方法。
JP2007548581A 2004-12-24 2005-12-23 バルク・データ転送 Active JP4589406B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63880604P 2004-12-24 2004-12-24
US64919705P 2005-02-01 2005-02-01
US64919805P 2005-02-01 2005-02-01
PCT/US2005/047076 WO2006071866A2 (en) 2004-12-24 2005-12-23 Bulk data transfer

Publications (2)

Publication Number Publication Date
JP2008526132A JP2008526132A (ja) 2008-07-17
JP4589406B2 true JP4589406B2 (ja) 2010-12-01

Family

ID=36216937

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007548581A Active JP4589406B2 (ja) 2004-12-24 2005-12-23 バルク・データ転送

Country Status (14)

Country Link
US (1) US8085781B2 (ja)
EP (2) EP1867110B1 (ja)
JP (1) JP4589406B2 (ja)
CN (2) CN101133599B (ja)
AT (1) ATE457577T1 (ja)
AU (1) AU2005322044A1 (ja)
CA (1) CA2590965C (ja)
DE (1) DE602005019332D1 (ja)
DK (1) DK1867110T3 (ja)
ES (1) ES2399491T3 (ja)
HK (2) HK1111015A1 (ja)
PL (1) PL2148479T3 (ja)
PT (1) PT2148479E (ja)
WO (1) WO2006071866A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102298719B1 (ko) * 2020-11-10 2021-09-07 더본테크 주식회사 현장 수집 입력 데이터에 기초한 데이터 재가공 시스템

Families Citing this family (94)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996705B2 (en) 2000-04-17 2015-03-31 Circadence Corporation Optimization of enhanced network links
US20110128972A1 (en) 2000-04-17 2011-06-02 Randy Thornton Peer to peer dynamic network link acceleration
US8024481B2 (en) * 2000-04-17 2011-09-20 Circadence Corporation System and method for reducing traffic and congestion on distributed interactive simulation networks
US8898340B2 (en) 2000-04-17 2014-11-25 Circadence Corporation Dynamic network link acceleration for network including wireless communication devices
US8510468B2 (en) 2000-04-17 2013-08-13 Ciradence Corporation Route aware network link acceleration
US8195823B2 (en) 2000-04-17 2012-06-05 Circadence Corporation Dynamic network link acceleration
US7043563B2 (en) 2000-04-17 2006-05-09 Circadence Corporation Method and system for redirection to arbitrary front-ends in a communication system
US8065399B2 (en) 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US8214707B2 (en) 2007-06-26 2012-07-03 Aspera, Inc. Method and system for reliable data transfer
ES2399491T3 (es) 2004-12-24 2013-04-01 Aspera, Inc. Transferencia de datos masiva
US8589508B2 (en) * 2005-04-07 2013-11-19 Opanga Networks, Inc. System and method for flow control in an adaptive file delivery system
US7500010B2 (en) * 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method
US20070002736A1 (en) * 2005-06-16 2007-01-04 Cisco Technology, Inc. System and method for improving network resource utilization
US7729240B1 (en) * 2005-06-30 2010-06-01 Opnet Technologies, Inc. Method and system for identifying duplicate packets in flow-based network monitoring system
US7630307B1 (en) * 2005-08-18 2009-12-08 At&T Intellectual Property Ii, Lp Arrangement for minimizing data overflow by managing data buffer occupancy, especially suitable for fibre channel environments
US7653778B2 (en) 2006-05-08 2010-01-26 Siliconsystems, Inc. Systems and methods for measuring the useful life of solid-state storage devices
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
CN100454903C (zh) * 2006-08-17 2009-01-21 华为技术有限公司 一种对iub接口进行流量控制的方法
JP5016279B2 (ja) * 2006-09-06 2012-09-05 ソニー株式会社 データ通信システム、データ送信装置およびデータ送信方法
US8549236B2 (en) 2006-12-15 2013-10-01 Siliconsystems, Inc. Storage subsystem with multiple non-volatile memory arrays to protect against data losses
US7596643B2 (en) * 2007-02-07 2009-09-29 Siliconsystems, Inc. Storage subsystem with configurable buffer
US8310920B2 (en) * 2007-03-02 2012-11-13 Saratoga Data Systems, Inc. Method and system for accelerating transmission of data between network devices
JP5102356B2 (ja) 2007-06-19 2012-12-19 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 電気通信システムにおける資源スケジューリングの方法とシステム
US9667545B2 (en) 2007-09-04 2017-05-30 International Business Machines Corporation Method and system for aggregate bandwidth control
US20090164657A1 (en) * 2007-12-20 2009-06-25 Microsoft Corporation Application aware rate control
US8386667B2 (en) * 2008-08-26 2013-02-26 Sun Management, Llc Techniques for managing the transmission and reception of data fragments
US8631149B2 (en) * 2008-11-25 2014-01-14 Citrix Systems, Inc. Systems and methods for object rate limiting
US8009560B2 (en) * 2008-12-31 2011-08-30 Microsoft Corporation Detecting and managing congestion on a shared network link
US8228800B2 (en) * 2009-02-03 2012-07-24 Microsoft Corporation Optimized transport protocol for delay-sensitive data
CA2754362C (en) 2009-03-06 2014-09-23 Aspera, Inc. Method and system for i/o driven rate adaptation
CN101520805B (zh) * 2009-03-25 2011-05-11 中兴通讯股份有限公司 一种分布式文件系统及其文件处理方法
US20110128921A1 (en) * 2009-05-22 2011-06-02 Qualcomm Incorporated Utility maximization scheduler for broadband wireless communication systems
CN101924603B (zh) 2009-06-09 2014-08-20 华为技术有限公司 数据传输速率的自适应调整方法、装置及系统
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
GB2477515B (en) 2010-02-03 2012-09-26 Orbital Multi Media Holdings Corp Data flow control method and apparatus
EP2564557B1 (en) * 2010-04-26 2018-12-12 Telefonaktiebolaget LM Ericsson (publ) Method for setting and adjusting a parameter dependent on a round trip time
US20120036366A1 (en) * 2010-08-09 2012-02-09 Microsoft Corporation Secure and verifiable data handling
US9516357B2 (en) * 2010-09-10 2016-12-06 Verizon Patent And Licensing Inc. Recording variable-quality content stream
JP5580706B2 (ja) 2010-09-29 2014-08-27 Kddi株式会社 再送制御プロトコルを用いるデータ転送装置、プログラム及び方法
EP2439905B1 (en) * 2010-10-05 2013-06-05 Research In Motion Limited Data channel set up latency reduction
US8824288B2 (en) * 2010-12-06 2014-09-02 Intel Corporation Communications techniques for bursty noise environments
US8566336B2 (en) 2011-03-30 2013-10-22 Splunk Inc. File identification management and tracking
US8548961B2 (en) * 2011-03-30 2013-10-01 Splunk Inc. System and method for fast file tracking and change monitoring
US9185043B2 (en) * 2011-04-08 2015-11-10 Saratoga Data Systems, Inc. Telecommunications protocol with PID control of data transmission rate
US8990416B2 (en) * 2011-05-06 2015-03-24 Oracle International Corporation Support for a new insert stream (ISTREAM) operation in complex event processing (CEP)
JP2012257010A (ja) * 2011-06-08 2012-12-27 Hitachi Ltd 通信装置、通信方法及び遠隔監視システム
US8478890B2 (en) * 2011-07-15 2013-07-02 Damaka, Inc. System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US20130265874A1 (en) * 2011-09-30 2013-10-10 Jing Zhu Link-aware application source-rate control technique
US9571406B2 (en) * 2011-10-25 2017-02-14 Vmware, Inc. Network congestion management based on communication delay
KR101243502B1 (ko) * 2011-10-31 2013-03-20 삼성에스디에스 주식회사 데이터 수신 방법 및 장치
WO2013078558A1 (en) * 2011-11-28 2013-06-06 Jigsee Inc. Method of determining transport parameters for efficient data transport across a network
EP2661138A1 (en) 2012-05-04 2013-11-06 Panasonic Corporation Threshold-based and power-efficient scheduling request procedure
CN103581045A (zh) * 2012-07-20 2014-02-12 华为技术有限公司 网络文件系统的数据处理方法、装置及系统
TWI505699B (zh) * 2012-11-23 2015-10-21 Inst Information Industry 資料串流傳輸方法
US9977596B2 (en) * 2012-12-27 2018-05-22 Dropbox, Inc. Predictive models of file access patterns by application and file type
US9596182B2 (en) * 2013-02-12 2017-03-14 Adara Networks, Inc. Controlling non-congestion controlled flows
US20150026130A1 (en) * 2013-07-17 2015-01-22 LiveQoS Inc. Method for efficient management of email attachments
KR20150071621A (ko) * 2013-12-18 2015-06-26 삼성전자주식회사 컨텐츠 중심 네트워크에서 라운드 트립 시간을 예측하는 방법
CN104348680B (zh) * 2013-08-08 2019-11-12 腾讯科技(深圳)有限公司 网速检测的方法及装置
WO2015026746A1 (en) * 2013-08-19 2015-02-26 Q Factor Communications Corp. Method & implementation of zero overhead rate controlled (zorc) information transmission via digital communication link
CN105683920A (zh) * 2013-10-28 2016-06-15 隆沙有限公司 文件的最新版本的即时流式传输
CN103986744B (zh) * 2013-11-18 2017-02-08 四川大学 基于吞吐量的文件并行传输方法
WO2015160953A2 (en) 2014-04-16 2015-10-22 Pixia Corp. Method and system of transmitting data over a network using a communication protocol
US10089307B2 (en) 2014-12-31 2018-10-02 International Business Machines Corporation Scalable distributed data store
CN104967497B (zh) * 2015-06-09 2019-04-12 武汉数字派特科技有限公司 一种基于网络通信协议的数据可靠传输方法及升级方法
CN105930731B (zh) * 2015-12-21 2018-12-28 中国银联股份有限公司 一种安全应用ta交互的方法及装置
US10154317B2 (en) * 2016-07-05 2018-12-11 BoxCast, LLC System, method, and protocol for transmission of video and audio data
US20180025170A1 (en) * 2016-07-21 2018-01-25 Zyptonite, Inc. File transfer using an in-browser staging database
KR102568436B1 (ko) * 2016-07-28 2023-08-21 삼성전자 주식회사 무선 통신 시스템에서 데이터의 전송 방법 및 장치
US10511864B2 (en) 2016-08-31 2019-12-17 Living As One, Llc System and method for transcoding media stream
US11412272B2 (en) 2016-08-31 2022-08-09 Resi Media Llc System and method for converting adaptive stream to downloadable media
CN109218847B (zh) * 2017-06-30 2022-03-04 中兴通讯股份有限公司 一种下载控制方法、装置以及多媒体终端
EP3673622B1 (en) * 2017-08-22 2024-05-01 Dejero Labs Inc. System and method for assessing communication resources
CN109510690B (zh) 2017-09-14 2020-07-28 华为技术有限公司 传输报文的方法、网络组件和计算机可读存储介质
CN107783847A (zh) * 2017-09-22 2018-03-09 平安科技(深圳)有限公司 数据发送方法及终端设备
US20190104169A1 (en) * 2017-10-03 2019-04-04 Synology Inc. Methods and computer program products for transceiving files through networks and apparatuses using the same
US10439940B2 (en) 2017-10-19 2019-10-08 Cisco Technology, Inc. Latency correction between transport layer host and deterministic interface circuit
CN107948010A (zh) * 2017-11-09 2018-04-20 郑州云海信息技术有限公司 一种网络抓包实现方法、系统及网络设备
CN108809514B (zh) 2018-04-23 2021-01-12 华为技术有限公司 一种数据传输方法及相关设备
US10637788B2 (en) 2018-06-26 2020-04-28 International Business Machines Corporation Stability of delay-based congestion control in a computer network using an alpha-beta filter and round-trip-time predictor
US11252097B2 (en) * 2018-12-13 2022-02-15 Amazon Technologies, Inc. Continuous calibration of network metrics
US11050675B2 (en) 2019-05-31 2021-06-29 Bae Systems Information And Electronic Systems Integration Inc. Scheduler for coordination and synchronization of data across low-bandwidth links and method thereof
CN110471771A (zh) * 2019-08-16 2019-11-19 佳源科技有限公司 一种配电实时操作系统
US11122019B2 (en) * 2019-09-13 2021-09-14 Oracle International Corporation Systems and methods for client collaborated migration of live TLS connection
US11140060B2 (en) * 2019-11-12 2021-10-05 Hulu, LLC Dynamic variation of media segment durations for optimization of network round trip times
US11218413B2 (en) * 2019-11-14 2022-01-04 Mellanox Technologies, Ltd. Congestion control management method derived from packets at a network adapter
WO2021235965A1 (en) * 2020-05-19 2021-11-25 Huawei Technologies Co., Ltd. Apparatuses and methods for measuring a transmission channel
CN112653635B (zh) * 2020-12-23 2024-08-02 百果园技术(新加坡)有限公司 一种拥塞控制算法的改进方法、装置、设备及存储介质
CN113411228B (zh) * 2021-06-04 2023-04-07 网宿科技股份有限公司 一种网络状况的确定方法及服务器
CN115022084B (zh) * 2022-07-18 2022-11-25 深圳市城市交通规划设计研究中心股份有限公司 一种网络隔离网闸数据交换方法及其应用
WO2024173666A1 (en) * 2023-02-15 2024-08-22 Guardant Health, Inc. Network bandwidth architecture for computational systems
CN116405442B (zh) * 2023-03-06 2024-04-26 中国电信股份有限公司卫星通信分公司 网络传输速率控制方法、装置及系统
CN117459188B (zh) * 2023-12-25 2024-04-05 吉林省吉能电力通信有限公司 基于北斗通信技术的电力北斗通信系统及通信方法
CN117555829B (zh) * 2024-01-12 2024-03-22 中诚华隆计算机技术有限公司 一种实现usb设备网络共享的usb重定向系统及方法

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4422171A (en) 1980-12-29 1983-12-20 Allied Corporation, Law Department Method and system for data communication
US5001628A (en) * 1987-02-13 1991-03-19 International Business Machines Corporation Single system image uniquely defining an environment for each user in a data processing system
US5805920A (en) 1995-11-13 1998-09-08 Tandem Computers Incorporated Direct bulk data transfers
US6078564A (en) * 1996-08-30 2000-06-20 Lucent Technologies, Inc. System for improving data throughput of a TCP/IP network connection with slow return channel
US6404739B1 (en) * 1997-04-30 2002-06-11 Sony Corporation Transmitter and transmitting method, receiver and receiving method, and transceiver and transmitting/receiving method
US6110382A (en) * 1997-07-25 2000-08-29 Ultra Fine, Inc. Automated effluence conditioning and treatment
AU3188800A (en) * 1999-03-15 2000-10-04 Vocaltec Communications Ltd. Flow control method and apparatus
KR100424654B1 (ko) * 1999-08-02 2004-03-24 삼성전자주식회사 이동 통신시스템에서 라디오링크프로토콜에 따른 데이터 재전송 장치 및 방법
US6629285B1 (en) * 2000-01-04 2003-09-30 Nokia Corporation Data transmission
CN1200368C (zh) * 2000-08-18 2005-05-04 清华大学 一种将tcp用于不可靠传输网络的局域重传方法
US7058085B2 (en) * 2001-03-14 2006-06-06 Nortel Networks Limited Method and apparatus for transmitting data over a network within a specified time limit
US6961539B2 (en) * 2001-08-09 2005-11-01 Hughes Electronics Corporation Low latency handling of transmission control protocol messages in a broadband satellite communications system
US7352761B2 (en) * 2002-06-04 2008-04-01 Lucent Technologies Inc. Distributing unused allocated bandwidth using a borrow vector
US20030231661A1 (en) * 2002-06-18 2003-12-18 General Instrument Corporation Optimized broadband download for large content
US7706378B2 (en) * 2003-03-13 2010-04-27 Sri International Method and apparatus for processing network packets
WO2005002120A2 (en) 2003-06-12 2005-01-06 California Institute Of Technology Method and apparatus for network congestion control
JP4651364B2 (ja) 2004-11-17 2011-03-16 富士通株式会社 位相調整方法及び装置
ES2399491T3 (es) 2004-12-24 2013-04-01 Aspera, Inc. Transferencia de datos masiva
US8214707B2 (en) 2007-06-26 2012-07-03 Aspera, Inc. Method and system for reliable data transfer

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102298719B1 (ko) * 2020-11-10 2021-09-07 더본테크 주식회사 현장 수집 입력 데이터에 기초한 데이터 재가공 시스템

Also Published As

Publication number Publication date
ATE457577T1 (de) 2010-02-15
EP2148479A1 (en) 2010-01-27
ES2399491T3 (es) 2013-04-01
JP2008526132A (ja) 2008-07-17
HK1140875A1 (en) 2010-10-22
WO2006071866A3 (en) 2006-09-08
EP1867110A2 (en) 2007-12-19
CN101133599B (zh) 2011-04-20
CN101133599A (zh) 2008-02-27
HK1111015A1 (en) 2008-07-25
AU2005322044A1 (en) 2006-07-06
CN102201977A (zh) 2011-09-28
EP2148479B1 (en) 2012-11-21
CN102201977B (zh) 2015-01-21
US8085781B2 (en) 2011-12-27
US20060159098A1 (en) 2006-07-20
DK1867110T3 (da) 2010-05-31
PT2148479E (pt) 2013-02-20
PL2148479T3 (pl) 2013-04-30
CA2590965A1 (en) 2006-07-06
EP1867110B1 (en) 2010-02-10
WO2006071866A2 (en) 2006-07-06
CA2590965C (en) 2016-05-03
DE602005019332D1 (de) 2010-03-25

Similar Documents

Publication Publication Date Title
JP4589406B2 (ja) バルク・データ転送
US8996945B2 (en) Bulk data transfer
JP4848425B2 (ja) 適応型帯域幅制御を行う方法、装置、及びコンピュータ使用可能なコード(適応型帯域幅制御)
JP5059976B2 (ja) 通信装置及び通信方法
JP4791322B2 (ja) 帯域幅保証を伴う適応性帯域幅制御のための方法及び装置
US20100020689A1 (en) Immediate ready implementation of virtually congestion free guaranteed service capable network : nextgentcp/ftp/udp intermediate buffer cyclical sack re-use
US20090268747A1 (en) Communication apparatus
US20220294727A1 (en) Systems and methods for managing data packet communications
Natarajan et al. Non-renegable selective acknowledgments (NR-SACKs) for SCTP
AU2014200413B2 (en) Bulk data transfer
Abdullah et al. Improving the TCP Newreno Congestion Avoidance Algorithm on 5G Networks.
JP2008536339A (ja) 事実上輻輳のないギャランティードサービス対応ネットワーク:外部インターネットNextGenTCP(方形波形)TCPフレンドリSANの即座の準備のできた実施
Li Improving the Efficiency of Multipath Transport Protocols
Kinnear WindowTree: Explicit congestion notification and route labeling for congestion control in content centric networks
Welzl et al. Survey of Transport Protocols Other than Standard Tcp
Shivarudraiah STCP: A new transport protocol for high-speed networks
Primet A Survey of Transport Protocols other than Standard TCP

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081218

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100810

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100909

R150 Certificate of patent or registration of utility model

Ref document number: 4589406

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130917

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350