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

Abstract

ここで開示するものは、ネットワーク・データ通信に関するものである。いくつかの実施例においては、元情報源と最終目的地間のネットワーク接続を開始し、ネットワークを通して元情報源から最終目的地へデータのブロックを伝送し、逸失したブロックの再伝送を最終目的地から発信源へ要求し、逸失したブロックを元情報源から最終目的地へ再伝送する。このような実施例では、更に、再伝送の要求にかかったラウンド−トリップ時間、即ち最終目的地が再伝送の要求を送り出した時間から、元情報源からの再伝送後最終目的地がそれを受信した時間までのラウンド−トリップ時間、を計測し、このラウンド−トリップ時間をネットワーク接続のための最小の再伝送要求時間としてセットする。 この場合、前記ラウンド−トリップ時間とは、ネットワーク接続のためのレイテンシー、および元情報源ならびに最終目的地におけるデータ処理による遅れを含む。
【選択図】図１

Description

［関連出願]
本出願は、３５Ｕ．Ｓ．Ｃ．第１１９（ｅ）条に基づき、２００４年１２月２４日出願の米国仮特許出願第６０／６３８，８０６号、２００５年２月１日出願の米国仮特許出願第６０／６４９，１９８号、および２００５年２月１日出願の米国仮特許出願第６０／６４９，１９７号による特典を主張する。これら出願の全明細書がここに含まれている。

本発明の主題は、ネットワーク・データ通信に関するものであり、より具体的には、バルク・データ転送用プロトコルに関する。

ネットワークの帯域幅および世界的規模のインターネットを通してのユビキタスなユーザー同士間の相互接続が最近増大していること、そして、ビジネスにおいてまた消費者ユーザーによって処理されるデジタル・データの量が増大していることから、ネットワークを利用してのバルク・データ（ファイルおよびディレクトリー）の転送に対する要求がかってないほどに高まってきている。 特に、ユーザーは、より高い帯域幅のネットワークを通してより遠距離のネットワークへより大きなファイルを転送したいと望んでいる。

このようなデータ転送経路では、帯域幅に障害となるボトルネックが多く生ずると共に地理的距離によるラウンド・トリップ遅延が生ずるだけではなく、パケット損失の期間が生じ、且つ伝送媒体(例えば無線）そのものにより変化する遅れ、および変化するそして時として過剰なデータトラフィックの輻輳からくる遅れが生じていた。

伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：ＴＣＰ）に基づく従来のバルク・データ転送用プロトコルは、帯域幅と遅延時間の積が大きいネットワークにおいては、ＴＣＰの性能が劣ることから、標準的な地球規模のインターネット経路の深刻な性能制限によって悩まされていた。このため、帯域幅と遅延時間が共に大きいネットワークにおけるバルク・データの転送の性能（転送速度、および帯域幅の活用）を改良するための別の転送プロトコルの実現に関心が集中していた。しかしながら、現在進められている試みは、主としてインターネット・コアのリンクでの改良されたスループットおよび改良された帯域幅の活用を提供するもので、比較的低いビット・エラー・レート（ＢＥＲ）を有するとともに十分な帯域幅を有し、データ・トラフィック量の輻輳を避けることができる。しかしながら、ユーザーによるデータ転送の大部分は、ネットワークのエッジからエッジまでに広がっており、地理的距離に起因する大きなラウンド・トリップ遅延が生ずるばかりでなく、パッケット逸失期間および典型的な「エッジ」ネットワーク特有の可変遅延特性が生ずる。かかる典型的なエッジ・ネットワークにおいては、現在の手法では、帯域幅をフルに活用することができないし、輻輳が進むにつれて変化するスループットにより悩まされることになる。更に、かかる試みでは、時間が重要なビジネス処理や厳しい消費者ユーザーからの転送時間についての要求に対して十分な保証を提供することができない。更に、限られた例ではあるが、かかる試みによりスループットは確かに改良されるが、それは、別のネットワーク・アプリケーションとの帯域幅の公平な分け合いをないがしろにして行われており、かかる帯域幅の分け合いについてはユーザーには何らの権限も与えられていない。エンド・ユーザーは、性能的には劣るけれども「公平な」標準的ＴＣＰを採用するか、或いは帯域幅の公平さはないがしろにしても場合によっては改良されたスループットが提供される別の新しいプロトコルとするかという選択を迫られることになる。これは、インターネット・コアにおいては受け入れられるかもしれないが、データの転送はそのネットワークにおいて利用可能な帯域幅に限定されている「時として過剰加入者状態となるエッジ・ネットワーク」では受け入れられない。従って、 ＴＣＰプロトコルを現在或いは将来実施することも考慮した上で、上述した問題点に対処でき、且つ改良されたスループットと、ネットワークの距離もしくは輻輳度（そして関連する遅延時間およびパケット逸失）に関係なく予測可能な転送速度と、帯域幅が使われていないときにはその他のデータ・トラフィックと比例的に帯域幅を分かち合う能力とを提供できるようにした、データ転送のためのシステムが必要とされている。

上述した問題点およびここではっきりとは取り上げてはいないその他の問題点については、本発明の主題がその狙いとするところであるが、本明細書を読み且つ検討することにより理解されることなろう。

本発明の主題によれば、リライアブルなネットワーク・データ転送システムが提供される。このシステムは、ネットワークを通してデータを転送し、、ソフトウェア・データ転送アプリケーションを使用してネットワークのデータ転送レートに改善を施す目的のために有用なものである。

本システムのいくつかの実施例は、アプリケーション・レベル（カーネル・スペースではなくユーザー・スペース）のバルク・データ転送用プロトコルであって、（帯域幅、遅れ、および逸失レートが任意の）コモディティ・ネットワークを通して、固有の転送レート制御を可能とするに十分な転送効率で高バルク・データ転送速度をもたらすことのできるプロトコルを提供する。その結果、本システムは、世界共通のコモディティ・ネットワークにおいて、安定なしかも予測可能な特長を持ちながら、完全で設定可能な(configurable)転送レートをリアルタイムで制御できるアプリケーションを提供することができる。

本発明システムのいくつかの実施例は、大きな且つ成長しつつあるコモディティ・エッジ・ネットワークの領界向けのデータ転送を目的としている。いくつかの実施例は、また、コモディティ・ネットワークを利用した単一ストリーム・データ転送に高度な制御性と透明性とを与える。より具体的には、ネットワーク遅れとパケット逸失とに伝送効率と安定性が依存しないことの直接の結果として、本発明の実施例のシステムはそのレート制御からその信頼性アルゴリズムを切り離すことができ、ネットワークの状態に関係なく、アプリケーションに対する正確で遺漏のない転送レートのリアルタイムによる制御を提供する。このことは、予測し得る転送時間に対する絶対転送レートのプリセットと、リアル・タイム制御を含むと共に、ＴＣＰフロー（標準ＴＣＰおよび新興の新しいＴＣＰの両方）との１対１の公平性といった共有リンクでの他のデータ・トラフィック量に関係する帯域幅の利用の制御を含んでいる。それとは逆に、いくつかの実施例は、転送性能およびダイナミック・ネットワーク・パラメータについてリアルタイムの視認性を提供する。

別の実施例は、また、オペレーション・システムおよびファイル・システムに依存しない転送を必要とするアプリケーションにふさわしいプログラマティックなインターフェースを、一般化されたバルク・データ転送に提供する。これら実施例のサービス・レイヤーは、他のアプリケーションと関連して実行されるバックグラウンド・サービスとして、各種のコンピューティング装置へ内蔵して使用され、専用のコンピュータシステムを必要としない。データ転送に加え、前記サービス・レイヤーは、セキュリティ（安全性：認証および暗号化）、同じもしくは別のサーバーからの自動復旧転送、ネットワークの機能休止またはネットワークのローミング（例えば携帯電話から固定無線へ）の場合の自動再スタート、およびＵＲＬリンクのようなファイル・リファレンスからの起動等を含む現代の商業的アプリケーションによって要求される一般的なアプリケーション能力を提供する。

本発明システムのいくつかの実施例は、注入レートから転送経路上のパケット逸失レートを差引いた差に等しい有用なスループットを確かなものとする、高度に効率的な信頼性のあるメカニズムを提供する。このメカニズムを有する実施例は、従来の信頼できるＵＤＰ転送にはよくあったデータ伝送の重複（変わりやすいネットワーク遅延時間および無視できないパケット逸失レートの存在のもと）を防止することができる。いくつかの実施例は、また、信頼性メカニズムに依存しない注入レート制御を有している。信頼性メカニズムは、ネットワークの状態に依存せずに高効率を確かなものとするので、ときとして「輻輳コラプス」と言われる「低実用スループット」の原因となるプロトコルの性能劣化を防ぐことができる。更に別の実施例は、目標転送レートへの速やかな収束と平衡点における安定したスループットとを可能とする等式ベースのレート制御を含んでいる。かかる実施例のいくつかでは、システムは、ネットワークの輻輳をランダム・エラー（ＢＥＲ）によるパケット逸失と正確に区別するために、アプリケーションレベルのプロトコルにおけるネットワーク待機遅れを使用して輻輳を検出する。更に別の実施例は、目標転送レートを転送前および転送中にセットできる能力をシステムに提供している。レートは、固定されたものでもよいし、標準ＴＣＰ、或いは新たな新生ＴＣＰまたは他の転送実行手段に関連して設定可能なアグレッシブネスによってダイナミックに適応できるようにしてもよいし、優先順位ポリシーに従ってダイナミックに適応できるようにしてもよい。

本発明システムのこれらの要素およびその他の要素は、アプリケーション用のプログラマテッック管理インターフェースに具体化されており、同インターフェースは、システムの転送の完全な制御とモニタリングとを提供する。他の実施例は、独立型のアプリケーション、オペレーション・システムのプラグ・イン、ユティリティ・アプリケーション、ハードウェア・コンポーネント、その他ここに記述されているシステムのサービスを提供できるもの全ての別のタイプのソフトウェアおよびハードウェア構成を含む。

ここに記述された概要は、本出願の教示するところのいくつかを概説するものであり、本発明主題専用の且つ網羅的な扱いを意図したものではない。更に、本発明主題についての詳細は、発明の詳細な説明と添付された特許請求の範囲に見出すことができる。本発明のその他のアスペクトは、当業者であれば、以下の詳細な記述を読み且つ理解し、説明の一部である図面を見ることによって明らかであろう。本発明の範囲は、添付された特許請求の範囲およびそれらの法的同等物によって明確にされる。

以下の詳細な説明は、本明細書の一部である添付の図面を参照してなされるが、同図面には、発明の主題を実現化できる具体的な実施例が図解的に示されいる。これらの実施例は、当業者が実施できるように十分詳細に説明されているが、その他の実施例も利用可能であること、そして構成的な、論理的な、電気的な変更は、本発明の主題の範囲から逸脱することなくなされ得ることは理解される。それ故、以下の説明は、限定的に捉えるべきではなく、発明の主題の範囲は、ここに一体の特許請求の範囲およびそれらの法的同等物によって画定される。

ここに提示されているシステムは、異なる実施例において、ハードウェア、ソフトウェア、ファームウェア、およびハードウェアおよび／またはソフトウェアおよび／またはファームウェアの組合せによって実現できることが理解される。 種々の実施例において、本システムの機能は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せに導入されているモジュールに対応できることが理解される。 ここに提示されている例は、モジュールごとに一つもしくはそれ以上の機能を組み合わせることができるが、機能の別の組み合わせも本発明の主題の範囲を逸脱することなく実現化することができる。

種々の実施例において、ソフトウェア部は、デジタル信号プロセッサー、ＡＳＩＣ、マイクロプロセッサー、マイクロコントローラ、或いは別タイプのプロセッサーを含む（ただし、これらに限定されないが）装置を用いることにより実行される。本発明の主題を実施化できる環境には、ネットワーク装置を有するコンピュータ環境、例えばコンピュータ、サーバー、ルーター、ゲ−トウェイ、ＬＡＮ、ＷＡＮ，イントラネット、および／またはインターネット・パスウェイまたはその他のネットワーク接続装置など（ただし、これらに限定されないが）が含まれる。

いくつかの実施例は、モジュール間でまたはモジュールを介して通信される関連するコントロール（制御）とデータ信号とを有する二つもしくはそれ以上の特定の且つ相互接続されたハードウェア・モジュールまたは装置、あるいはアプリケーション固有の集積回路における機能を実現する。それ故、例示的なプロセスのフローはソフトウェア、ファームウェアおよびハードウェアの実行に適用可能である。

本出願は、２００４年１２月２４日出願の米国仮特許出願第６０／６３８，８０６号に関連しており、その全明細書がここに含まれている。
本発明の主題による種々の実施例がここに提示されている。第１図は、本発明の主題の一実施例にかかわるシステム１００の模式的ブロック図である。システム１００は、ネットワーク１２２により接続された第1ノード１０２と第２ノード１３２とを有している。

第１ノード１０２はプロセッサー１０４、メモリー１０６、バス１１４に連結されたネットワーク・インターフェース１１２とを有している。 第１ノード１０２は、任意ではあるが、例えばディスク１１０のような記憶装置、出力装置１１６、および入力装置１１８を有することができる。第２ノード１３２は、プロセッサー１３４、メモリー１３６、およびバス１４４に連結されたネットワーク・インターフェース１４２を備えている。第２ノード１３２は、任意ではあるが、例えばディスク１４０のような記憶装置、出力装置１４６、および入力装置１４８を有することができる。変形例において、第１ノード１０２および第２ノード１３２のメモリー１０６、１３６は、ソフトウェア１０８、１３８を有するものとして図示されている。かかるソフトウェアは、ネットワーク・インターフェースに対して少なくともデータを伝達するための機能を備えている。変形実施例および応用例においては、かかるソフトウェアは、記憶装置１１０、１４０を含む（ただしこれらに限定されないが）一つもしくはそれ以上のソースからメモリー１０８、１３８へロードされる。

種々の実施例において、ネットワーク１２２は、一つもしくはそれ以上のインターネット（ＩＮＴＥＲＮＥＴ）、ローカル・エリア・ネットワーク（「ＬＡＮ）、イントラネット、ワイド・エリア・ネットワーク（「ＷＡＮ」）、その他のタイプのネットワークを含んでいる。

ソフトウェア１０８、１３８は、ノード１０２、１３２がネットワーク１２２を通してデータを交換できるように、各ノード１０２、１３２のプロセッサー１０４、１３４上で動作する。ソフトウェア１０８、１３８は、ノード１０２、１３２に対して、データの交換に関連する種々のアクションを遂行させる。以下に例示されているように、かかるアクションには、種々の定期的確認方法によるデータの交換が含まれている。

ここで述べられているデータ転送とは、エンド・ツー・エンドの「転送」経路という言葉で表される。 転送経路は、ＩＰネットワークを介して例えば第１ノードのようなソース・ホストから、例えば第２ノード１３２のような目的地ホストまで伸びている。かかる転送経路はその特徴として、「ボトルネック帯域幅」、「ネットワーク・ラウンド・トリップ時間」、および経路ラウンド・トリップ時間を有している。

経路ボトルネック帯域幅というのは、転送経路全長にわたる最小転送容量（単位時間あたりのデータ単位）のことであって、第１ノード１０２および第２ノード１３２のような送信側ホストおよび受信側ホストのボトルネック容量と、一回もしくはそれ以上のネットワーク・ホップを含むネットワーク１２２のボトルネック容量とを含んでいる。 ノード１０２、１３２のボトルネック容量とは、データ転送に用いられる手段の最小データスループット（単位時間あたりのデータ）のことであって、そこには、記憶装置１１０、１４０もしくはメモリー１０６、１３６の読み出し／書き込み速度、ホスト・バス１１４、１４４の速度、プロセッサー１０４、１３４の速度、およびネットワーク・インターフェース１１２、１４２の速度が含まれる。 ネットワーク１２２のボトルネック容量とは、転送経路を備えたネットワーク・リンク個々の最小帯域幅である。

経路ラウンド・トリップ時間（「経路ＲＴＴ」）とは、一つのデータ・ユニットが、データ受信側からソース側へ送られまた元へ戻るまでに必要な時間のことである。例えば、経路ＲＴＴは、第２ノード１３２、記憶装置１４０もしくはメモリー１３６からのデータ・ユニットを読みだす時間、ネットワーク１２２を通して第１ノード１０２へデータ・ユニットを返送する時間、同データ・ユニットをメモリー１０６へ読み出す時間、および、データ・ユニットをネットワーク１２２を通して第２ノード１３２へ送り返して同データ・ユニットをメモリー１３６へ読み出す時間を含んでいる。一つの例では、 時間は、伝送の開始および最終的に受け取ったときの時間を示すパケット上のタイム・「ティック」を用いて計測される。

ネットワーク・ラウンド・トリップ時間（ネットワークＲＴＴ）とは、一つのデータ・ユニットが、受信側ホストによってネットワークへ送り出された時間から始まり、同データが送信側ホストへ到着し続いて受信側ホストへ戻ってくるまでの時間のことであり、時として「ネットワーク・レイテンシー」と言われるものである。

種々の実施例において、ネットワークＲＴＴは、目的地ホストで「通信スタック」を下る要求のための時間（ネットワーク・プロトコル・レイヤー−オペレーティング・システム内のネットワーク・スタック−物理的インターフェース）、送信側ホストへネットワークを上る要求のための時間、送信側ホストが再伝送要求を受信し、次に予定されたデータ・ユニットを送信するための時間（入力してくる再伝送要求を受信するために「スタックを上る」経路（物理的インターフェース−オペレーティング・システム内のネットワーク・スタック−システム・プロトコル・レイヤー）、及び次に予定されたデータ・ユニットを送信するために「スタックを下る」経路（システム・プロトコル・レイヤー−オペレーティング・システム上のネットワーク・スタック−物理的インターフェース）を含む）、その上、目的地ホストへネットワークを伝わるための時間を含む。

所定の転送経路における帯域幅と遅延時間の積（ＢＤＰ）は、その経路における総データ容量であり、ボトルネック帯域幅にラウンド・トリップ時間を乗じたものに等しい。ＢＤＰはネットワーク・ラウンド・トリップ時間と称されるが、非常に高い帯域幅のネットワークの場合、ボトルネック帯域幅およびＢＤＰは、実際には、ホストの帯域幅によって決定され得る。

データの転送は、「データ注入レート」、「受取りレート」、および「有用受取りレート(useful reception rate)」という言葉で定義づけられ、これらは「効率」を左右する。データ注入レート（「Ｒｉ（ｔ）」）とは、送信側がデータをネットワークへ注入するレート（例えば１秒当たりのビット数またはバイト数で計測される）のことであり、送信側は、送信アプリケーションのためにそのレートでデータをネットワークへ注入する。 データ受取りレート（「Ｒｒ（ｔ）」）とは、受信側がネットワーク１２２からデータを読み込むレートのことであり、受信側は、そのレートでネットワ−クからデータを読み込む。有用受取りレート（「Ｒｕ（ｔ）」）とは、受信側が「有用」なデータを受け取るレートのことであり、受信側は、そのレートで有用なデータを受取る。有用なデータには、その受取り時より前には受取られていなかったデータ（例えば、重複データ）が含まれる。

また、本説明の全般にわたって使われている言葉に「重複受信レート」と、「転送効率」という言葉がある。重複受取りレート（「Ｒｄ（ｔ）」）とは、受信側がそのレートで既に受取られているデータを受取るレートのことである。

転送効率とは、総受信レートに対する有用受信レートの比（Ｒｕ／Ｒｒ）である。最大転送効率（１００％）は、ＲｕがＲｒに接近し、重複・データが全く受取られていない場合である（即ち、プロトコルの冗長データ・オーバーヘッドは無視できることを意味している）。 即ち：

「完全に効率的な」プロトコルは、要求されたデータの全てを転送する。 このことは、転送経路上でのパケット逸失による逸失データが冗長な転送なく転送される必要があることを意味している。ここで、効率とは、帯域幅の利用と同じではない、ということに注意を要する。

種々の実施例による安定システム１００は、パケット逸失、ネットワーク遅延及び、パケット逸失とネットワーク遅延のバリエーションなどに直面しても動揺することのない安定した状態のスループットに集中する。このことにより、システム１０２のアプリケーション１０８は、システム１００の安定性を乱すことなく任意のデータ注入レートＲｉを選択することができる。もし、システム１００が固定した目的とするレートを用いたとすると、データはネットワーク１２２へ絶えず注入され、「バースト」が生ずることはない。いくつかの実施例においては、システム１００はダイナミックに適応できるレートを使用しており、そのレートは、高レートでの安定のために、現在の伝送レートではなく、平衡点からの距離に比例した平衡レートとなる。ダイナミックに適応できるレートを使用する安定したプロトコルは、転送経路に介在するルーター・バッファーを満杯にすることがなく、また、小さな「マイス」トラフィックを悪化させることもない。

いくつかの実施例では、システム１００の性能を計測するために使用されるパラメータを有している。同パラメータには、「予測可能性」、「帯域幅の公平さ」、および「独立したレート制御」が含まれる。 前記有用受信レート（Ｒｕ）は、もし転送スループットおよび時間が、例えば変化するラウンド・トリップ遅延であるとかパケット逸失などの変動予測不可能な経路状態以上に確定的であるならば、「予測可能」である。

もしもＴＣＰに競合する一つのフローが同等にアグレッシブでありかつ同等の割合で、即ち例えば各フローのレートがＮ個の競合するフローに対してＢＷ／Ｎであるであるように、ボトルネック帯域幅を分かち合うのであれば、そのプロトコルは標準ＴＣＰに対して「帯域幅−公平」（「ＴＰＣフレンドリーな」）と見なされる。コモディティ・ネットワークの高い性能と公平さについては、信頼できる転送プロトコルはＴＣＰと適正に共用ができて、且つ「最大−最小」の公平さを有する。あるＴＣＰのフローが完全に比例した割り当て分の帯域幅を使用していない場合、いくつかの実施例において、システム１００は、使われずに残っている帯域幅を使用する。

システム１００は、もしもデータの注入レートが、信頼性メカニズムと結びついていない場合、システム１００は、「独立レート制御」を提供する。そして、システム１００は、レート制御を操作するアプリケーションへのインターフェースを開示する。操作可能な種々の実施例におけるいくつかのパラメータは、目標レートまたは最大／最小範囲、相対的なアグレッシブネス、および優先順位ポリシーなどの独立したレート設定を含んでいる。いくつかの実施例において、システム１００は、アプリケーションに対して、インテリジェント・フィードバック、例えば、性能に関する統計、有効レート、転送される連続したバイト、およびラウンド・トリップ時間という形で計測されたネットワーク・インパクト、転送経路におけるパケット逸失、およびプロトコル・オーバーヘッドなど、も提供する。

上述したシステム１００の特性（パケット逸失、ネットワーク遅れ、いろいろな種類のパケット逸失およびネットワーク遅れ、効率Ｒｕ／Ｒｒ〜１および独立レート制御）を実行するために、本発明によるバルク・データ転送システムの実施例は、以下のプロセスを提供する。

ａ．ブロックが逸失したときは、再伝送の要求は受信側に記憶される
ｂ．再伝送要求のストレージは、以下のデータ構成特性を有している：
i．ストレージへの挿入時間は一定時間Ｏ（１）内になければならない
ii．要求されるべき検索もしくは再伝送は、一定時間Ｏ（１）内になければならない
iii．再伝送されたブロックが受信されたときに、待機している再伝送の要求を見つけ無効にすることは一定時間Ｏ（１）内になければならない
ｃ．送信側で受け取られた再伝送の要求は、送信側ストレージに記憶される。送信側ストレージは、パケット逸失が大きくなったときに大きくなってはならない。

i．受信側は、送信側が再伝送されたブロックを送ることのできるレートで再伝送の要求を送るだけであること、
ii．再伝送要求の送信側ストレージは、一定の挿入時間を考慮しなければならないが（ここに提案する実施例では、対数挿入時間Ｏ（ｌｏｇ（ｎ））を用いている）、送信側記憶装置は、パケット逸失が増大しても大きくならないので、挿入時間は実用上一定である。
iii．送信側は、ディスク読み取り性能を最適化するためにブロックを再伝送しなければならないので、記憶された最小再伝送インデックスを見つけ出すことも一定時間Ｏ（１）内になければならない。

ｄ．再伝送の要求は、送信側に遅滞なく到達しなければならない。受信側は再伝送の要求を、送る必要のある再伝送の要求の量とそれらが送られるときのレートとを考慮して、可能な限り最小のパケットとして送り出す。

ｅ．受信システムは、入力データを、それが受け取られたときのレートで処理しなければならない。もしもデータが受信システムのディスクに書き込まなければならない場合、それは適切に行われなければならない。

ｆ．もしも受信システムが、システム制限により、入力データをそれが受け取られたときのレートで処理できない場合、入力データはドロップされ、ドロップされたブロックは、再伝送メカニズムの目的のために逸失したものとみなされる。

第２図は、本発明の一実施例によるシステム２００のブロック図である。システム２００は送信システム２０１および受信システム２２６を有している。送信システム２０１および受信システム２２６は、ネットワーク２２４を通して接続されている。

システム２００で示された実施例の送信システム２０１は、一組のモジュ-ルを有している。これらモジュールには、転送開始モジュール２２２、データ・ファイル・システム・ソース・モジュール２１８、データ・アプリケーション・ソース・モジュール、ブロック・ハンドラー・モジュール２０６、およびオプショナルな暗号化モジュール２０８が含まれている。送信システム２０１は更に、ブロック排出モジュール２１０、フィードバック・リーダー・モジュール２１６、レート制御モジュール２１４、再伝送モジュール２１２、管理インターフェース・モジュール２０４、および転送開始モジュール２２２を含んでいる。

転送開始モジュール２２２は、受信システム２２６との制御チャンネルの確立を行う。 制御チャンネルは、信頼可能な或いは信頼不可能なベース・トランスポート（例えば、ＴＣＰもしくはＵＤＰ）を使用し得る。制御チャンネルは更に、セキュア・ソケット・レイヤー（「ＳＳＬ」）とかセキュア・シェル（「ＳＳＨ」）といった公開−秘密鍵法を使用することによってその安全が確保され得る。制御チャンネルを使用することによって、転送開始モジュール２２２は、受信システム２２６へ資格認定書を送り、送信アプリケーションの認証を行い、任意ではあるが、データの暗号化に使用されるパー・セッション対称暗号化キーを交換することができる。転送開始モジュール２２２は更に、例えばブロックの大きさ、目標とするレートなどといった転送パラメータについてのネゴシエーションを行い、目的地向けファイルを構成しかつ一部転送の再開のためにファイルもしくはディレクトリィ・メタデータを交換する。メタデータは、ファイル名とか、サイズとか、アクセス制御パラメータとか、チェックサムといった属性データを含んでいる。

データ・ファイル・システム・ソース・モジュール２１８は、送信システム２０１のファイル・システム２１８を介してディスク２２もしくは送信システム２０１にアクセス可能なディスク２２０即ちメモリーから転送するための一連のデータを提供する。この一続きのデータは、ファイル、ディレクトリー、ロウ・バイト・シーケンス、もしくは事実上その他どのようなデータ形式のものであってもよい。

データ・アプリケーション・ソース・モジュール２０３は、転送すべき一連のデータを送信アプリケーション２０２のメモリー・スペースへ提供する。
ブロック・ハンドラー・モジュール２０６は、伝送もしくは再伝送が必要になると、ファイル・システムからのもしくはユーザー・アプリケーション２０２のメモリー・スペース２０３からのデータブロックを読み、データを取り込む。

暗号化モジュール２０８は、送信システム２０１内においては任意の（必須ではない）モジュールである。暗号化モジュール２０８は、データブロックの暗号化を任意に行い、完全性証明のための認証ダイジェストを付け加える。

ブロック排出モジュール２１０は、データブロックをネットワーク２２４へ書き出す。
フィードバック・リーダー・モジュール２１６は、逸失したブロックの再伝送の要求、転送統計、およびダイナミック目標レートを含む制御フィードバック情報を、受信システム２２６から読みとる。フィードバック・リーダー・モジュール２１６は、メッセージのタイプを解析し、処理のために再伝送モジュール２１２とか、レート制御モジュール２１４とか管理インターフェース２０４などの適切なモジュールへ、ペイロードをパスする。

レート制御モジュール２１４は、目標とするレート（例えばビット・パー・セコンド）を遵守するために、ブロックを伝送予定に入れる。
再伝送モジュール２１２は、入力してくる再伝送の要求を記憶するが、この要求は、シーケンス・ナンバーによるソートを可能にするデータ構造となっている。再伝送モジュール２１２は更に、再伝送するべきブロックの数を発行する。

管理インターフェース・モジュール２０４は、監視および制御インターフェースを提供し、同インターフェースから制御コマンドが発せられ、転送統計が読み込まれる。
システム２００で示された実施例の受信システム２２６は、一組のモジュ-ルを有している。これらモジュールには、転送開始モジュール２２５、データ・ファイル・システム送信先モジュール２５０、データ・アプリケーション送信先モジュール２２７、ブロック・ハンドラー・モジュール２３０、およびオプショナルな暗号化モジュール２３２が含まれている。受信システム２２６は更に、ブロック取り込みモジュール２３６、フィードバック・ライター・モジュール２４８、レート制御モジュール２４２、再伝送モジュール２４６、管理インターフェース・モジュール２２８、および転送開始モジュール２２５を含んでいる。

転送開始モジュール２２５は、送信システム２０１との制御チャンネルを確立させるよう機能する。 制御チャンネルは、信頼可能な或いは信頼不可能なベース・トランスポート（例えば、ＴＣＰもしくはＵＤＰ）を使用し得る。制御チャンネルは更に、セキュア・ソケット・レイヤー（「ＳＳＬ」）とかセキュア・シェル（「ＳＳＨ」）といった公開−秘密鍵法を使用することによってその安全が確保され得る。制御チャンネルを使用することによって、転送開始モジュール２２５は、送信システム２０１へ資格認定書を送り、受信アプリケーション２２７の認証を行い、任意ではあるが、データの暗号化に使用されるパー・セッション対称暗号化キーを交換することができる。転送開始モジュール２２５は更に、例えばブロックの大きさ、目標とするレートなどといった転送パラメータについてのネゴシエーションを行い、目的地向けファイルを構成しかつ一部転送の再開のためにファイルもしくはディレクトリィ・メタデータを交換する。メタデータは、ファイル名とか、サイズとか、アクセス制御パラメータとか、チェックサムといった属性データを含んでいる。

ブロック取り込みモジュール２３６は、ネットワーク２２４からのデータブロックを読み込む。
暗号化モジュール２３２は、オプショナルなものである。暗号化モジュール２３２を有する実施例では、暗号化されたデータブロックを復号化して、完全性についての認証ダイジェストを検証する。

ブロック・ハンドラー・モジュール２３０は、入力してくるデータブロックを処理する。この処理は、ネットワーク・ラウンド・トリップ・タイムスタンプを抽出し、それをレート計算モジュールへパスし、且つ経路ラウンド・トリップ・タイムスタンプを抽出し、それをタイムアウト・予測モジュールへパスすることを含む。更にこの処理は、排出のために、ディスク・ライター・モジュール２３４へペイロードをコピーすることも含む。

ディスク・ライター・モジュール２３４は、ネットワーク読み取り動作とディスク書き込み動作とのインターロックを最小とすることによって、受信側入力／出力（「Ｉ／Ｏ」）速度を最大にするためのロジックを実現する。ディスク・ライター・モジュールは、多数のバッファーを使用しており、いつでも一つのバッファーにはネットワーク２２４の読み取り動作を、またもう一つのバッファーにはディスク２５２への書き込み動作を割り当てる。一旦、一つのバッファーがネットワーク・リーダーによって満たされると、それはディスク・ライター・モジュール２３４へパスされ、新たなバッファーが、ネットワーク・リーダーとして割り当てられる。

ファイル・キャッシュ・モジュール２３８は、シーケンス外の書き込みを最小にし且つ特定のファイル・システムに対して最適な大きさのブロックを書き込むことによって、ブロックがディスク２５２もしくはシステムのメモリーに書き込まれるときの速度を最大にするようロジックを実行する。

前記データ・ファイル・システム・目的地モジュール２５０は、受け取られたデータが書き込まれるファイル・システムを介してローカル・コンピュータにアクセス可能なディスク２５２もしくはシステム・メモリー上のファイルもしくはディレクトリーである。

データ・アプリケーション・目的地モジュール２２９は、受信システム２２６のアプリケーション２２７のメモリー・スペース２２９における一連のメモリーである。そこに受取られたデータが書き込まれる。

再伝送モジュール２４６は、インデックスにより逸失したデータを回復させるための逸失データブロックの情報を記憶する。この記憶されている情報は、シーケンス番号および逸失したデータが最初送られたのはいつであったかのタイムスタンプを含んでいる。

前記フィードバック・ライター・モジュール２４８は、送信システム２０１へフィードバック情報を送る。このフィードバック情報には、再伝送の要求、統計、計算された目標とするレート、およびその他送信システム２０１及び受信システム２２６間のデータの交換に関係するあらゆる情報を含ませることができる。

前記タイムアウト・プレディクター・モジュール２４０は、ラウンド−トリップの計測に基づいて経路ラウンド−トリップ時間を予測する再帰的推定アルゴリズムを使用することによって、逸失したブロックの再伝送を要求するまでの待ち時間（ＲＴＯ）を計算する。

前記レート制御モジュール２４２は、設定されたレート制御メカニズム即ち固定レート、もしくは計測されたネットワーク・ラウンド−トリップ時間の関数としてダイナミックに適用されるレートにしたがって、目標とする伝送レートを計算する。

前記タイマー・モジュール２４４は、再伝送の要求なされることになっている絶対時間に従って再伝送するためのブロックのシーケンス番号を記憶する。この絶対時間は、タイムアウト予測モジュールによって計算されたＲＴＯにより与えられる。タイマー・モジュールは、現時刻に再伝送されることになっているブロックのシーケンス番号を再伝送モジュールへ送る。

前記管理インターフェース・モジュール２２８は、モニター／制御インターフェースを提供するもので、このインターフェースからコマンドが発せられ、転送統計値が読みとられる。

ファイル・ディファレンシング・モジュール２５４は受信システム２２６に既にあるデータを評価して、同一のデータが既にあって転送は不要であるかどうかを判定するために、そのデータを送信システム２０１のデータと比較する。ある実施例では、かかる比較は、大きさとか、修正された時間とか、コンテンツ・チェックサムといった属性に基づき、送信側ファイルと同一の名前を有する受信側ファイルとの間でなされる。もしも比較したファイル同士が同一である場合、如何なるデータも転送されない。もしもファイルが部分的に転送されている場合、ファイル・ディファレンシング・モジュールは、伝送が開始すなわち再開されるべき補正点を決定する。

正確な機能、データがグループ化され相互に連結される方法、および個個に実行されるプロセスは、本発明の主題の範囲から逸脱することなく変化し得ることは理解される。
第３図は、一実施例によるプロセス３００のブロック図である。このプロセス３００には、ファイル或いはその他のデータ構成をソースシステムから目的地システムへ送るための、コンピュータにより実行可能な方法である。このプロセス３００には、ファイルもしくはその他のデータ構成３０２を目的地システムへ伝送するためのコマンドを受取り、目的地システム３０４への接続を確立し、同システムと制御データを交換し、ファイルもしくはその他のデータ構成を番号を付けたブロックに分けること、が含まれている。このプロセス３００は更に、再伝送の要求が受取られた保留状態にあるか（３０８）を判断し、その他のブロックを伝送する前に要求されたブロックを全て再伝送することを含む。プロセス３００は更に、伝送すべきブロックで残っているものがあるかどうかを判断し（３１２）、番号を付されたシーケンスにおける次のブロックを伝送する（３１０）ことを含む。もしも伝送すべき残りのブロックがない場合、プロセス３００は、目的地システムから最後のブロックが受取られたことを示すインディケーションが受取られたかどうかを判断する（３１６）。もしそのようなインディケーションが受取られていた場合プロセスは終了し（３２０）、そうでなければ、プロセスは最後のブロックを再伝送する（３１８）。

第４図は、本発明の一実施例による、ソースシステムからファイル或いはその他のデータ構成を目的地システムで受取るためのプロセス４００のブロック図である。プロセス４００は、ファイル、もしくはその他のデータ構成を受取るためのコマンドを受け取り（４０２）、接続を確立してソースシステムと制御データの交換をし（４０４）、記憶スペースを割り当てて受取られる多数のブロックに従い記憶スペースをブロックに分割する（４０６）ことを含んでいる。プロセス４００は更に、番号を付されたブロックを受取り（４０８）、そのブロックが以前に受取られていたかどうかを判断し（４１０）、もし以前に受取られていた場合にはそのブロックを切り捨てる（４１２）か或いは受取られたブロックの番号に対応する各記憶ブロックにそのブロックを書き込む（４１４）ことを含む。その後プロセス４００は、受取られたブロックにギャップがあるかどうかを判断する。もし、ギャップがあった場合、プロセスは逸失したブロックの再伝送の予定を立て（４１６）、その逸失したブロックが既に受取られていたかどうか判断し（４１８）、逸失したブロックの再伝送を要求する（４２０）。続いて、プロセスは、受取られたブロックが再伝送の要求をされたかどうかを判断する（４２４）。もしもブロックが再伝送されていた場合には、そのブロックは再伝送予定からは除去される。ついで、プロセス４００は、ブロックが最後のブロックであるかどうかを判断する（４２８）。それがもし最後のブロックであった場合、プロセス４００は終了する（４３０）。そうでなかった場合、プロセス４００は全てのブロックが受取られるまで以上の動作を反覆する。

プロセス・フローの変化および各処理手順の動作のバリエーションは、本発明の主題から逸脱することなく変え得ることが理解される。
第３図および第４図に示されたプロセス３００および４００についてのいくつかの実施例においては、コンピュータ・アプリケーションへ相互にデータブロックのシーケンスを安定して転送できる能力を与えている。いくつかの実施例においては、プロセス３００と４００は、単一のコンピュータ・アプリケーションに含まれていて、そのためシステムは、送信部にも受信部にもなり得る。

動作する場合、送信システムは、第３図に示したプロセス３００に従ってデータ構成をソースから受信システムの目的地へ、要求された目標レートもしくは経路ボトルネック帯域幅のいずれか小さい方で次々に転送する。受信システムは、第４図に図解されているプロセス４００に従って動作する。転送は、伝送前経路のラウンド−トリップ時間或いは伝送中のラウンド−トリップ・レイテンシーおよびパケット逸失の変動に関係なく高効率で行われる。

一定の目標とするレートが要求された場合、伝送レートは、輻輳状態となっても、一定に保たれ、パケット逸失レートは少なくなる。「帯域幅−公平」のモードが使われている場合、転送レートは、ネットワークの使用率が低い場合には利用可能な帯域幅を自動的に利用するように適応するべきだが、ネットワークが輻輳している場合（利用可能な帯域幅がない）には、「ＴＰＣ−公平レート」についてユーザーが設定した割合に適応する。

第５図および第６図は、本発明の主題の種々の実施例に含まれる種々の態様を示している。これらの図は、中でも、ラウンド−トリップ時間の計測、データ伝送、いくつかの例によるデータ注入レートの計算と最新化を詳細に示すものであるが、網羅的なもしくは限定的な図示を意図したものではない。

第５図は、一実施例によるシステム５００のデータ・フロー図である。システム５００は、最終データ・ソース５０２を有する送信部と、ネットワーク５０４と、最終データ目的地５０６を有する受信部とを備えている。伝送要求はタイムスタンプを有する受信部によって送られ、そしてそのタイムスタンプはリライアビリティ法（例えば経路ＲＴＴ）及び輻輳計測（例えばネットワークＲＴＴ）のため瞬間ラウンド・トリップ時間の計算に用いられる。各タイムスタンプには、タイプ別（ｎ＝ｎｅｔｗｏｒｋ ＲＴＴ，ｐ＝ｐａｔｈ ＲＴＴ）にフラグが付加されている。「ｎ」個の再伝送要求（Ｔｒｅｘ）は、一定の時間間隔で受信部から送信部へ送られる。もしも、「ｎ」の計測時に再伝送がない場合、空の再伝送要求が送られる。

第５図は、次の「Ｔ」参照信号を有する。同信号は以下の意味を有する。
Ｔ１： 受信部により再伝送要求が送られた時間
Ｔ２： 送信部に再伝送要求が到着した時間
Ｔ３（ｐ）： 再伝送要求を満足させるブロックが送信部により送られた時間
Ｔ３（ｎ）： 「ネットワークＲＴＴ」のフラグのついた再伝送要求の受信が受取られた後、最初のブロックが送られたときの時間
Ｔ４： このブロックが受信部に到達した時間
以下の計算は、種々の実施例において有用なものであり、計測された時間
Ｔ１、Ｔ２、Ｔ３（ｐ）、Ｔ３（ｎ）、およびＴ４を用いる。

第６図は、一実施例によるシステム５００のデータ・フロー図である。第６
図は、いくつかの実施例による伝送要求の生成とプロセスおよび時間の計測についてより詳細に図解している。

時間Ｔ１において、受信部は、再伝送のときが来た逸失ブロックを再伝送要求ＰＤＵへ付け加える。いくつかの実施例においては、時間が、現在推定されているＲＴＴと同じになり、ＲＴＯが経過したときをもって再伝送が行われる時間に「なった」とする。現在時刻は、再伝送要求ＰＤＵのヘッダーのタイムスタンプ・ティック（ＴＫ）に記録されており、ティック・タイプのフラグ（経路「Ｐ」もしくはネットワーク「Ｎ」）がセットされる。ネットワーク「Ｎ」のティックは、周期的な時間間隔で送られる。もしも「Ｎ」ティックを送る時間でない場合、ティック「Ｐ」がデフォルトで送られる。

時間Ｔ２のときに再伝送要求は送信部へ到着する。送信部は、ブロック番号で順番にソートされている待ち行列(queue )へ要求を挿入する。各ブロックは、ティック・タイムスタンプＴＫと共に記憶される。

再伝送要求がティック・タイプＴＫを含んで受けとられると、送られた次のデータＰＤＵ（再伝送もしくはオリジナル）は、ネットワーク時間を計測するためだけに送信部の処理時間にあわせられたティックＴＫを含む。即ち、ＴＫ＝ＴＫ＋（Ｔ３（ｐ）−Ｔ２）
送信部は、ブロックを、注入レートＲ_ｉで継続的に送リ出す。待ち行列に入れられている全てのブロックは、新たなデータが送られる前に順番どおりに送り出される。もしも待ち行列に入れられた再伝送がある場合、送信部は、一番若いブロック番号を選択し、その番号のブロックをディスクから読み出す。再伝送されたデータブロックと、そのタイムスタンプＴＫと、タイプ（Ｐ／Ｎ）は、ＰＤＵに封入される。

時間Ｔ４に受信部によってデータブロックが受け取られたときに、もしもそのブロックがティックを含んでいるとすると、受信部は、ネットワーク・ラウンド・トリップ時間もしくは経路−トリップ時間（ＲＴＯ）の予測推定を最新のものに更新する。受信部は、埋め込まれているティックからサンプル・ラウンド−トリップ時間
を計算し、サンプル化されたラウンド−トリップ時間を予測推定関数へ入力し、経路またはネットワークのためにＲＴＯが計算される。

第７図は、本発明の一実施例によるシステム５００のデータ・フロー図である。この図は、最大／最小レート、一定レートもしくは自動的に適用されるレートといった帯域幅共用ポリシー、ＴＣＰに対するアグレッシブネス等−これら全ては管理インターフェースを介してリアルタイムで提供される−の入力パラメータの関数として、受信部５０６による新しい注入レートの計算、および新たなレートの送信部への伝達の両方を示している。

転送されるべき一連のデータは、同じ大きさを持ったブロックに分割される。データブロックのサイズは、データ（ペイロード＋アップリケ−ション・ヘッダー＋封入されているパケット・ヘッダー）を持つプロトコル・データ・ユニットが、ネットワークの最大伝送ユニット（ＭＴＵ）を超えることがないように計算される。このＰＤＵは多分超えることになる。

前記システムは、全ブロックの伝送と目的地におけるソース・ファイルの再構成を保証するものである。ブロックは順番に番号付けされる。システム受信部は、逸失ブロックに気づき、システム送信部に対し全部ロックが受け取られ目的地フィルへ書き込まれるまで逸失したデータを再伝送するよう要求する。受け取られたブロックは、それらが受け取られている最中にディスクもしくはメモリーに書き込まれ、終了まで少しずつ書き入れられていく空きの多いファイルが形成される。

システム送信部は、ユーザーによって特定された目標レート（絶対値もしくは自動的に求められた帯域幅即ちキャパシティのいずれかとして）で、もしくは適応レート・メカニズムによって計算されたレートで、ブロックを順番どおりに送り出すことによって動作開始する。適応レート・モードにある場合、送信部は、任意ではあるが、スロー・スタート・メカニズムを使用することができる。このメカニズムによれば、最初の送り出しレートは、送り出しレートの何分の一かであって、適応レート・アルゴリズムは自動的に、２，３秒間の間に目標レートへと急成長する。各ブロックは、受信部でファイルを再構成するために用いられるブロック番号を有している。送信部は、受信部からのブロック再伝送の要求を受け取ることができる。その場合、送信部は、再伝送の要求を記憶し、ユーザーにより特定されたレート、または適応レート・メカニズムにより計算されたレートで、要求されたブロックを再送する。サーバーは、新しいブロック−それがどのようなものであれ−を送り出す前に再伝送が必要な全てのブロックを送り出す。再伝送すべきブロックがなくなったとき、または伝送するための新しいブロックがあるとき、サーバーは、終了状態に入り、受信部が全ファイルの受信を知らせるか或いは更なる再伝送の要求を送るまで、最後のファイル・ブロックを繰り返し送りつづける。

システムの受信部は、データブロックの受取を待ちつづける。ブロックを受け取ると同時に、受信部は、そのブロックがその前に受け取られていなかった場合、そのブロックをメモリーディスク・サブシステムまたはシステム・メモリーのようなメモリへパスする。もしもブロックシーケンス番号が、受け取られたブロックにギャップのあることを示すと、受信部は、直前に受け取られたブロックとこのブロックとの間のシーケンス番号を持つ逸失ブロックの全てを再伝送するための予定を立てる。

再伝送スケジューラーは、いつ再伝送の要求を送るかを決めるタイマーの機能として、逸失したブロックの再伝送を要求するように動作する。再伝送予定のタイマーは、経路ラウンド−トリップ時間の予測計測に基づいている。再伝送のバッチが予定時間になると、受信部はこれらブロックの再伝送要求を送信部へ送り出す。再伝送されたブロックが受け取られると、それらの登録は、保留中の再伝送スケジューラーから取り除かれる。ブロックは、メモリー、ディスク、もしくは適切なファイル・オフセット位置を有するその他の場所へパスされ、ファイルへ書き込まれる。最後のデータブロックが受け取られたとき、高速終了アルゴリズムによって、残っている再伝送があれば全て要求される。全てのブロックが受け取られると、受信部は終了メッセージを送信部へ送る。

その他種々の実施例は、高データ転送効率と、任意の高固定注入レートの場合のラウンド−トリップ遅延およびパケット逸失に関係のない予測可能な転送レートとを実現する方法を提供している。

そのような実施例のいくつかは、データ転送アプリケーション・ノンシーケンシャル・データアクセスを実現するブロック・ベースの転送を提供し、更に、データの信頼し得る受取から切り離された高度に正確な注入レートを提供する。

データ転送アプリケーション・ノンシーケンシャル・データアクセスを実現する実施例は、データ・ソース、例えばディスク・システム、メモリー、或いはアプリケーションといったデータ・ソースに、必ずしも順番どおりになっていなくともよい、不連続ブロックでデータを供給することを要求するブロック・ベース転送を含む。

これら実施例はデータ「ブロック」のサイズを画定し、アプリケーションに対して、ブロックを、個個にまたはまとめて提供するよう要求する。例えば、通常のファイル転送の場合、それら実施例はブロックを多数のバイトとして画定する。（大きさは、アプリケ−ションによって、或いは導入の際に予めコード化された固定値によって設定され得るし、或いは、転送経路のＭＴＵの大きさを探査することによって求めることができる。最大スループット効率を得るために、ブロック・サイズは、下位のＩＰレイヤーにおいて断片化されたパケットを再構築する際の不要なオーバーヘッドを避けるため、経路ＭＴＵを越えず且つパケットの断片化を生じさせない範囲で可能な限り大きくすべきである。）ファイルはブロックに分割され、最初のブロックは、ブロック番号１である。所定のブロックが要求される順序および回数については保証はない。所定のどの時間においても、アプリケーションには、要求するブロックの一番若いブロック番号が与えられる。このような情報に基づき、アプリケーションは、その前のブロックを切り捨て、メモリー内に大きなメモリー・バッファーを持つオーバーヘッドを避け且つ連続するデータを潜在的に並行して扱うことができようになる。

いくつかの実施例では、データ注入レートは、その信頼性メカニズムとは無関係である。そのような実施例の場合、注入レートは、データがうまく受け取られたかそしてレート制御アルゴリズムはアプリケーションによる明確な且つ独自の制御下にあるかどうかに依存していない。このことにより、ネットワーク遅延およびパケット逸失には関係のない転送性能を実現できると共に、アプリケーションには独立した転送レート制御を与えることができる。

これら実施例により動作するアプリケーションは、アプリケーションによって設定される（例えば、絶対値として、或いは設定されたまたは自動的に求められた帯域幅のキャパシティの割合として）か、或いは計算式を基礎としたアルゴリズムを用いて計算されるかのいずれかによる目標注入レートを使用し、通知ではなくタイミングを使って注入レートを制御している。かかるレート制御メカニズムによれば、相対精度をもった、システム負荷に依存しない、また他のアプリケーションに対してＣＰＵフレンドリーな目標レートを維持することができる。これら実施例は、新しいデータをネットワークへクロックするために伝送されたデータを順番に承認する必要がないので、データはアプリケーションからどのような順序ででも再要求されることができ、通知の受領まで伝送されたブロックを不必要に格納しておくことがなくなる。

これら実施例にかかわるアプリケーションは、「固定レート」モードにおいて一定の注入レートを維持し、或いは、「適応レート」制御アルゴリズムが使われる場合には、利用可能なネットワーク帯域幅についての進行中の計測と、アプリケーションへ明確に明らかにされ得るＴＣＰに関連する設定可能なアグレッシブネスとに従って目標レートを調整する。アプリケーションは、進行中にレート制御モード（例えば、固定もしくは適応モード）をセットすることができ、また、目標レート、最大および最小転送レート、および、帯域幅の公平さの基準倍率を含む境界パラメータをセットすることができる。（現行の実施手法では、標準（Ｒｅｎｏ）ＴＣＰに関する計算された目標レートについての基準倍率を表すのが最も有用であるかもしれないが、基準倍率は、ラウンド−トリップ時間およびパケット逸失といった測定可能なエンドツーエンド・ネットワーク・パラメータの関数として安定状態のスループットを有するあらゆるＴＣＰ互換の実施手法にも関連し得るものである。）

ネットワークの利用を最大化するいくつかの実施例においては、送信部システムは、データを要求された注入レート（計算されたまたは予め決められた）で、正確に出力することが重要である。このことを達成するために解決されなければならない問題は、第一に、オペレーティング・システムによりもたらされるタイミング・メカニズムに関係し、また第二には、システムの負荷に関係している。

第一に、マルチ‐プロセス型のオペレーティング・システムでは、プロセス・スイッチングの粒度は、高レートのネットワーク伝送で要求される「パケット間の時間」よりもずっと大ききい。一般的には、粒度は、１０から２０ミリ秒であり、このことは、ひとたびプロセスがＣＰＵをイールドすると、少なくとも１０−２０ミリ秒は再動作しないことを意味している。毎１０ミリ秒ごとに１５００バイトのデータ・パケット1個を送り出した場合、伝送レートは１．２Ｍｂｐｓだけしかイールドしない。スピニング（ＣＰＵをイールディングするのとは反対に）によれば、精度の高いタイミングが得られるが、マシーンがネットワーク・送信部専用でない限り実用的ではない。本発明主題のいくつかの実施例では、商品としてのマルチ・タスク・システムによるデータ転送を提供するものであり、ＣＰＵを独占する贅沢さを有するものではない。

第二に、ＣＰＵおよびディスクの利用といった点からみると、より高いシステム負荷は、注入レートの精度に悪影響を及ぼし、劣ったものにする。
本発明主題のいくつかの実施例に用いられている方法は、高精度の注入レートを提供する。これらの注入レートは、ＣＰＵフレンドリーであり十分な利用可能な処理パワーがある限りシステム負荷の変動によって影響を受けることはない。

パケットは、バッチにグループ分けされているため、注入レートはＣＰＵフレンドリーである。バッチの大きさは、パケット間遅延（「ＩＰＤ（Inter-packet delay）」）が、送信部にＣＰＵをイールドさせ且つ注入レートと折り合いをつけることなくプロセス・スイッチング遅れから回復させるに十分な大きさになるように計算される。

注入レートは、システム負荷の変動により影響を受けることはない。なぜなら、上記実施例では、一つのパケット、もしくはバッチの伝送を処理する時間を計測し、この処理時間にＣＰＵをイールディングするスイッチング処理に費やした時間をプラスした時間により生じたラグを補償するからである。実際のパケット間の遅延は、計測されたラグについて補償されるので、変動するシステム負荷が存在しても注入レートは一定に保たれる。

以下の擬似コードは、高精度ネットワーク転送レートを実現するためにネットワークへパケットを注入する際に使用されるアルゴリズムの例である。バッチの大きさの計算において最小パケット間遅延（「ＩＰＤ」）の制限５０００マイクロ秒（５ミリ秒）で、ＩＰＤは、プロセス・スイッチングにより引き起こされる遅れ（１０−２０ミリ秒）が、次の３から４のバッチから回復されるように選択される。

所定の注入レート（Ｒｉ）で、パケット間遅延およびバッチ・サイズを計算する。
送信部ループ
いくつかの実施例も、高注入レートによる経路遅延およびパケット逸失に関係なく高データ伝送効率を維持する方法を提供している。

肯定応答信頼性アルゴリズム（Positive-acknowledgement reliability algorithm）の伝送速度ボトルネックを避けるために、本発明主題によるいくつかの方法は、例えば、注入レートを絞ったり或いは逸失データの回復といったことを行わないユーザー・データグラム・プロトコル（「ＵＤＰ」：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）をなどのリライアブルでない伝送チャンネルを使用している。かかる方法は、逸失データの再伝送について独自のアルゴリズムを実行することによって信頼性(reliability )を得るようにしている。かかる伝送アルゴリズムは、データブロックが、遅れたりあるいは再注文されているのではなく、オリジナル・ソースと最終目的地間で本当に「逸失した」ときを正確に特定することにより、エッジからエッジまでのネットワーク遅延およびパケット逸失に関係のない安定した、高効率を高注入速度について達成できる。再伝送アルゴリズムは、高ラウンド−トリップ時間（例えば、長距離大陸間ネットワークなど）、高ランダム・パケット逸失（例えばいくつかの無線メディアにおける）、および変動するレイテンシーとパケット逸失レート（例えば重い負荷により輻輳している公共のインターネット・リンク）に対して不変の、高注入速度と有用なスループットとの組合せを可能とする。

再伝送アルゴリズムのいくつかの実施例は、「否定応答（negative acknowledgements）」を使用している。否定応答は、受信部が送信部へ逸失したブロックについてのみを通知しそれに従って送信部が再送信を行ったときになされる。

本発明主題のいくつかの実施例は、継続的に経路ラウンド・トリップ時間をサンプリングし、ラウンド・トリップ時間を正確に予測しいつ逸失したブロックが本当に失われたのかそしていつ再伝送されるべきかを決定するために、予測推定関数を使用する。再伝送の要求は、安定性を維持するために早すぎてもいけないし、効率をさげることになるので遅すぎてもいけない。高注入レートのための、有用な、受け取られたデータ・レートは、一定であって、注入レートから経路のパケット逸失レートを引いたものに等しい。それ故、逸失の大きいレイテンシーの変動するリンクであっても高速で高伝送効率と高帯域幅の利用とが実現される。

最適再伝送要求アルゴリズムの問題はモデル化可能である。例えば、経路注入レートＲｉ（ｔ）とし、効率的伝送をほぼ１００％とするには、有用データ・レートＲｕ（ｔ）はＲｉ（ｔ）からパケット逸失レートＰ（ｔ）とＲｉ（ｔ）の積を減じたものに等しくなるようにする：

任意の高速ネットワークの利用をほぼ１００％とするには、毎秒数キロビットから任意高速（毎秒１ギガビット以上）までの範囲にわたるＲｉについて上記式は保持されなければならない。

かかる実質的な最適なモデルを実現するために、逸失したブロックについての再伝送の要求は、遅れるかもしれない或いは再要求されるかもしれない送信中の一ブロックが受取られまでの十分な時間であって再伝送の要求を送信部へ送り、送信部の目標注入レートＲｉとして、要求に対する返事を受取る（までの）時間を超えない時間長さだけ、待つことになる。

正確な待ち時間は、決定されないが、継続的に経路ラウンド−トリップ時間を計測し且つ予測推定方程式の一種を用いることによって、高精度で推定され得る。かかる予測推定方程式とは、再帰的予測エラー傾斜関数もしく将来の経路ラウンド−トリップ時間を予測する確率論的傾斜関数として知られているものである。経路ラウンド−トリップ時間を正確に推定し、再伝送の要求を待つ時間を計算するために、本発明主題のいくつかの実施例は、ブロック・ベースのデータの伝送システムの中に上記のアプリケーションを有している。その結果、これら実施例は高伝送効率を実現している。

いくつかの実施例において、再伝送の予定は、経路ラウンド・トリップ時間の正確な予測、現在のラウンド・トリップ時間の正確なサンプリング、および予測される経路ラウンド・トリップ時間に基づく高性能再伝送スケジューラーが含まれている。

正確な再伝送タイムアウト（ＲＴＯ）のために、再伝送要求の送り出しと再伝送されたデータブロックの受取りに用いられる時間スケールで、経路ラウンド・トリップ時間の進展を正確に予測することが重要である。本発明主題の種々の実施例は、データブロックがネットワーク上を走行する時間に加え、ラウンド−トリップ時間を全転送経路についてサンプリングすることによってＲＴＴ予測を計算している。このラウンド−トリップ時間には、送信部の処理時間、例えば再伝送データ構成を検索し且つディスクからブロックを再読み出す時間が含まれている。かかる実施例においては、送信側の処理アルゴリズムは、再伝送要求の数に対して不変であり、従ってラウンド−トリップ予測に安全に考慮される。

更に、かかる実施例のいくつかは、サンプリングされたラウンド・トリップ時間から、推定平均経路ラウンド・トリップ時間（「平滑化ＲＴＴ」：“ｓｍｏｏｔｈ ＲＴＴ” もしくは「ＳＲＴＴ」）を計算し、また、ＲＴＴのサンプルおよび平滑化ＲＴＴ間の差から遅延の分散（「ＲＴＴ分散」）を導き出す。そして、予測されるネットワーク遅延は、平滑化ＲＴＴおよびＲＴＴ分散に基づいて計算される。

新たなＲＴＴサンプル（ＲＴＴｉ）の受取りおよび計算と同時に、平滑化ＲＴＴ（「ＳＲＴＴ」）の値が以下のように計算される。
γは、現在のＲＴＴサンプルが新しい平滑化されたＲＴＴの推定値の中でどのくらい重いかを決定するゲイン・ファクター（ａ ｇａｉｎ ｆａｃｔｏｒ）である。ＲＴＴｉとＳＲＴＴｉとの差は、その前の予測の際のエラーを示しており、このエラーは、経路における何らかのランダム・エラーおよびその前の不良推定ために生じた何らかのエラーから成っている。時間の経過と共に、ランダム・エラー成分はキャンセルされ、不良推定によるエラーは、推定値を「真の」平均値ヘ押し上げる。それ故、小さなゲイン・ファクターは、特定のＳＲＴＴがランダム・エラーによって多大な影響を受けないように機能する。一実施例は、ゲイン・ファクター「γ」として１／８を使用している。

ＳＲＴＴ推定値の真の平均値からの振れを考慮して、ＲＴＴ分散（ＶＲＴＴ）は、以下のように計算される。
ここで、ηは減衰ファクターである。一実施例では、減衰ファクター「η」として、1／４が使われている。

予測されるＲＴＴ（＝ＲＴＯ）は、以下のように計算される。
ＲＴＯ値は、標準的なネットワークにおける1回実行時の現実的ラウンド−トリップ・リミットに制限された範囲である。

ネットワークの遅れ予測におけるもう一つのファクターは、ＲＴＴのサンプリング周波数である。いくつかの実施例に使用されている転送レートの範囲（２０Ｋｂｐｓ−１Ｇｂｐｓ）に対して、サンプリング期間は、１０ミリ秒にセットされている。

予測されるＲＴＴ（＝ＲＴＯ）の精度は、サンプリングされたＲＴＴの精度にかかっている。受信部は、オペレーティング・システムによって提供される最良のクロック・メカニズムを使用して、正確な「クロック・ティック」を発生する。このティックは、再伝送の要求を送り出す直前に生成され、再伝送の要求ＰＤＵに埋め込まれる。再伝送要求はネットワークを通って送信部へ移送する。送信部が、要求に対応するブロックをいつでも転送できる状態になると、送信部はクロック・ティックをデータＰＤＵへ埋め込み、受信部へそれを送る。クロック・ティックを含むデータＰＤＵを受取ると同時に、受信部は、受取られたクロック・ティックを現在のクロックから差し引くことによって経路ＲＴＴを決定する。この方法は、オペレーティング・システムから得られる最高精度のクロック・メカニズムを使用しているため、正確である。

否定応答（「ＮＡＣＫ」）再転送要求の受信側は、ブロック再伝送のための要求を扱わなければならない。以下、ブロック再伝送要求、逸失ブロックの検出、逸失ブロックの再伝送要求、および、要求されたブロックが受取られたときに未処理の再伝送要求の取り消しを取り扱う実施例について説明する。

本発明主題によるいくつかの実施例は、データ・ソース内の各ブロックに1からＮまでの番号が順番に付されている。ここで、Ｎは、Ｎ＝ファイルのサイズ／ブロックのサイズである［ファイルの大きさ＞０の場合は＋１］。その他の実施例では、各ブロックを順番付けて特定するため種々の手段を使用している。

送信部は、各プロトコル・データ・ユニット（「ＰＤＵ」）のおけるペイロードに対してブロック・シーケンス番号を付加する。受信部は、想定される次のシーケンス番号よりも大きなシーケンス番号を持ったブロックを受取ると逸失ブロックを検出する。ブロックは順番を外れて受取られたので、受信部は直ちに逸失ブロックを要求せずに、一つのＲＴＯの後での再伝送のために最初の要求として予定に入れる。このことにより、再注文された実行中のブロックは、再伝送を早めに要請することによる伝送の重複を作り出すことなく、受取られることになる。

受信部は、再伝送の要求の全てを、予定される正確な絶対時間と共に記憶する。時間は、計算された余地時間が計測エラーによる理論的に正確な値よりも小さくならないようにするため、ＲＴＴ計測の精度で予定時刻値の端数を切り上げることにより計算される。

予定時間（ミリ秒）＝ 検出された時間ロス［ミリ秒］＋
検出された時間におけるＲＴＯ［ミリ秒］＋
ＲＴＴ計測精度［ミリ秒］

受信部から送信部へ再伝送の要求が送られると、再伝送についての続く要求は、同じ方法によって計算された予定時刻に予定に入れられる。従って、いったん逸失ブロックが検出されると、そのブロックが受取られるまで待機中の再伝送要求が常に存在するが、現在待機中の再伝送は取り消される。

正確な経路ラウンド・トリップ時間予測は、再伝送の要求の送り出しと処理におけるオーバーヘッドが再伝送の数に対して不変であることを必要とし、データの逸失を合成するものではない。困難なネットワーク状態を通しての高速度転送のため、再伝送の数は非常に大きくなり得る。種々の実施例は、たとえ再伝送の数が大きいとしても、送信部および受信部での処理時間が常にほぼ一定であるようにし、且つ再伝送の要求がうまく配送される確率を最大にする多数の要素（エレメント）を有している。

そのような実施例において、再伝送されたブロックが受取られると、再伝送のためのみ処理の要求はスケジューラーから取り戻されて取り消される。逸失が高い（再伝送の数が多い）場合、もしも取り戻し方法が再伝送の数に比例するとすると、これはお金のかかる動作となり得る。これら実施例に用いられている取り戻し方法は、高い逸失に直面しても、ほぼ最適な実用的なスループットのために一定のアクセス・タイムを得ることができる。一つのブロックが逸失したものとして最初に検出されると、そのブロックの再伝送要求が直線配列(linear array)で受信部に記憶される。それが記憶されているインデックスは再伝送の要求に送られる。送信側では、このインデックスは再伝送の要求と共に送信側に記憶される。送信部がブロックを再伝送すると、インデックスはブロックに付加されて、その結果受信部は、ブロックの総数に関係なく一定時間内に未処理の再伝送を調べる。

未処理の再伝送が累積するのを避けるために、本実施例の送信部は、新しいブロックを送り出す前に逸失した全てのブロックを常に再伝送する。そのようにしなければ、受信部は、更なる逸失を累積し、更に多くの再転送の要求を予定に入れることになろう。その結果、送信部の輻輳による破綻をまねき転送性能の低下をきたすことになる。ブロックを再伝送するために、送信部はソース・ファイルからブロックのデータを再度読み出さなければならない。この、「探して−戻って−読み出す」動作は高レート転送では高価なものとなり得るし、パケット逸失が大きく且つファイルのサイズが大きい場合には特に厄介である。受信部は、送信部が逸失したブロックを再送でき、送信側の未処理の再伝送の記憶量がほぼ一定の大きさ（ネットワーク逸失とともに大きくならない）になるようなレートに合うように、再伝送の要求を絞る。

半二重通信メディアでは、待機資源の小型化のために半二重通信動作となってしまうネットワーク装置の場合と同様に、受信部から送信部への逆方向経路上の大きなＩＰパケット逆経路は、送信部へたどり着かなくなることがあり得る。その結果、送信部は新しいブロックを送りつづけさせられるため、レートが加速され受信部にはそのレートによる損失が蓄積されて、ファイル転送性能が一気に悪くなる。

そのため、本実施例では以下の対抗策が講じられている。
（ａ）送信部が単位時間当たりに送らなければならない再伝送の要求の数と、送信部は送信レートよりも早くない速度で伝送可能であることとを考慮して、送信部は、再伝送要求ＰＤＵの中で再伝送対象ブロックを、送信部の目標レートと再送要求レートによって決定される、最小数だけ送る。

要求の間隔は一定であって、以下の特別な例を除いて、伝送タイマー分解能（現行では１０ミリ秒）に等しい。もしも送信部の目標レートが、最小の要求レートが毎秒１レックス（ｒｅｘ）よりも小さくイールドするくらい小さいとすると前記間隔は、１要求当たり１レックスに要求される最小間隔長まで伸張される。

（ｂ）伝送要求の最大サイズは、アプリケーションによって設定され、またデフォルトにより、最小の普通のネットワークＭＹＵ（１４９２バイト）よりも小さくセットされ得る。

ディスクの書き込み／読出しスループットに近いファイル伝送レートを有する実施例においては、ディスクのＩ／Ｏ性能は、ボトルネックになり得る。かかる実施例における送信部は、ファイルの始まりに一番近いブロックを常に最初に再送することによってディスクの探索負荷を軽減している。このことにより、送信部は、再送信するブロックを順次読み出すことができ、受信部は受取られたブロックを順次書き込むことができる。送信側には、予定されている再伝送が、ソートされたデータ構造で記憶される。即ち、番号でソートされた再伝送予定のためのシーケンス番号を記憶する改良レッド・ブラック・ツリーで記録される。レッド・ブラック・ツリーは、コンピュータ・サイエンス本に詳細に書かれている古典的な二進樹構造であるが、本明細書ではその説明を省略する。ブロック・シーケンス番号は、ツリーにおいては、ノード・キーである。

最小のブロック番号（最小のもの）だけが回復される必要があるという事実に基づき、レッド・ブラック・ツリーは、ほぼ一定時間の検索を提供するように、改良されている。挿入時間は、正規のレッド・ブラック・ツリーのものと同じである。

レッド・ブラック・ツリーは、下記の基本命令を備える。

レッド・ブラック・ツリーは、最小シーケンス番号を有するノードのトラックを保つ。これは、「現在の最小ノード」と言われる。挿入と同時に、最小モードのトラックを保つことは些細なことである。「現在の最小ノード」を知り、もし挿入するブロックが現在の「最小ノード」のシーケンス番号よりも小さかった場合には、それが「最小」となる。その他の場合は、現在の最小ノードは変更されない。

取り戻しと同時に、最小ノードはツリーから除去され、アプリケーションへ戻され、新しい「最小」が求められ記憶される。新しい最小ノードを求めるために用いられるアルゴリズムを支援して、下記のステートメントが真(true)となる。

−「現在の最小ノード」は、左側のデセンダントを持っていない（即ち、左側デセンダントは最小ノードのキーよりも小さなキーを有している）、
−「現在の最小ノード」は、そのペアレントの左側デセンダント（または、そのペアレントは最小ノードのキーよりも小さなキーを有することになる）
−「現在の最小ノード」の右側デセンダントから出ているサブ・ツリーは、「現在の最小ノード」のペアレントのキーおよびツリーの残りのキーよりも小さな全てのキーを有している。

「次」の「現在の最小ノード」がツリーから除去される前に「次」の最小ノードを求めるために、レッド・ブラック・ツリーは、以下のアルゴリズムを使用している。

種々の実施例において用いられている標準のレッド・ブラック・ツリーに対する修正は、以下に述べる。

本発明主題のいくつかの実施例は、ランダム・ディスク・アクセスと、要求された再伝送がある場合にファイルを頻繁に往復して探査することとを要求している。いくつかのオペレーティング・システムは、高性能のファイル・システム・ランダム・アクセスを提供しているが、その他のオペレーティング・システムでは、ランダム・アクセスを十分に扱っておらず、実質的なファクターによってディスクの読出し／書き込み速度は減じられている。かかる実施例における受信機側は、ディスクの書き込み動作はよりお金の掛かるものであるので、最も悪影響を受ける。

いくつかの実施例においては、受信部は、ランダム・ディスク・アクセスを最小にするために、ディスク書き込みキャッシュ・メカニズムを実施している。メモリー・キャッシュのサイズは、以下の計算を使用して、ファイル転送の目標レートに比例している。

ファイル・キャッシュの大きさはディスク書き込みサイズ・バッファー、
に比例している。ディスク書き込みサイズ・バッファーは、多様なサイズのディスク・クラスターであって、ファイル・システムにより、５１２バイト、１０２４バイト、４０９６バイト、８１９２バイト、或いはそれ以上であってもよい。いくつかの実施例では、６４Ｋバイトのディスク書き込みサイズを使用している。

ファイル・キャッシュは、受信部からデータブロックを受取り、ブロックをバッファーし、ディスクへいつ、どのデータを書き込むかを決定する。ファイル転送が終了すると、キャッシュはその内容をディスクへフラッシュする。ファイル・キャッシュは、以下の問題点を解決する。データの逸失が高い場合、キャッシュは、受信部が再伝送されたブロックを最大機会で受取れるようにするため、また、パケット逸失によりできたキャッシュ内のギャップを埋めるために、実際のディスクへの書き込みを可能な限り遅らせるべきである。理想的には、ディスクへの書き込みは、書き込みバッファー内の構成ブロックの全てが受取られてから行われるのがよい。データ逸失が低い場合、多数のデータをキャッシュすることなく、ファイル転送の終了時のフラッシュ時間を改良することができる。

高ディスク・キャッシング性能を実現する方法についてのいくつかの実施例は、ディスクへの書き込みに際して、高水準インディケーターを使用する手法を含んでいる。キャッシュへ書き込まれたデータが「高水準」を超えると、キャッシュは、キャッシュの最初から書き出しを行う。上述した高逸失対低逸失キャッシング・ポリシー（high-loss versus low-loss caching policies）は、受信部の再伝送テーブルのサイズの移動平均を計算することによって達成される。

移動平均は、その値が、受信部のテーブルの再伝送の数が増加したときにその数に追従し、その数が減少したときにはゆっくりと減少するように調整されるように計算される。それ故、受信部は、上昇傾向時には密着して従い、下降傾向時には遅れることになる。

「高水準」は、再伝送移動平均の対数ステップ関数として計算される。
「高水準」は、全てのディスク書き込みの後で再調整される。

定義： どの時間ポイントにおいても、ネットワーク経路は、「利用可能な帯域幅」または「利用できない帯域幅」を持ち得る。経路は、今現在経路を伝送されている全てのフローにより使用されている帯域幅の合計が経路のボトルネック帯域幅以下であって、且つ帯域幅の一部に未使用部分が残っている場合に、利用可能な帯域幅を持つ、ということになる。逆に、全てのフローのために必要な帯域幅の合計が経路のボトルネック帯域幅を超えていた場合に、経路は、利用可能な帯域幅を持っていないということになる。この場合、帯域幅に対する需要は供給を超えてしまうことになり、帯域幅はリンク上の種々のフローの間で分かち合われなければならなくなる。「帯域幅の公平」というのは、個個のフローにより消費される相対帯域幅と言える。

本発明主題の種々の実施例は、安定した効率的なデータ・スループット、及び、利用可能な帯域幅がある場合に、他のＩＰデータ・フローがある中でシェアされたリンク上の使用されていない帯域幅の十分な活用を実現する。利用可能な帯域幅のないネットワークの場合、かかる実施例は、伝送速度をＴＣＰと公平に帯域幅を共有するように伝送速度を自動的に適応させる。

かかる実施例では、ネットワークの待機遅れをネットワークの輻輳（或いは逆に、利用可能な帯域幅）を示す信号として使用する、適応レート制御モードを有している。利用可能な帯域幅を有するネットワークでは、待機遅れが低いとの信号があると、これら実施例は、計測された待機遅れの関数としてデータ注入レートを決定する。従来技術では、待機遅れは、ＴＣＰの伝送スループットを、利用可能な帯域幅をダイナミックに変更するモードに適応させるために、正確な輻輳信号として用いられ、高速ネットワークの帯域幅能力で安定した高ＴＣＰスループットを維持するために、待機遅れの関数として等式ベースのレート制御を適用していた。従来技術による安定した高スループットは、無視できるパケット逸失（パケット逸失の事態が生じたときはそれでもスループットを低下させる）が存在し、且つ高スループットのネットワークの場合（低速度ネットワークの帯域幅は利用しない）だけに限って適用できるのであって、その場合他のＴＣＰのフローに対して帯域幅の公平さを犠牲にすることになる。利用可能な帯域幅を持つネットワークにおいては、ここに提案する実施例は、ランダムに逸失が生じてもスループットを低下させることがなく（遅延ベースの手法をパケット逸失許容の信頼できるＵＤＰ支援に適用する）、それ故、たとえ高パケット逸失レートを持つメディアであったとしても高スループットを保つことができる。提案されている実施例は更に、改良されたスケーリング・パラメータを使用して、全ての実用的ネットワークにおいて帯域幅の利用を１００％に近づけることができる（毎秒数キロビットからギガビットまで：単に高速かつパケット逸失のごく少ないネットワークでなく）。更に、提案されている実施例は、利用可能な帯域幅のないネットワークでは、ＴＤＰフレンドリーなレートを自動的に使用することになる。

現在利用可能な帯域幅のないネットワークでは、提案されている実施例は、計算された注入レートを、同一のネットワークの下で動作しているＴＣＰのフローの数に比例した数に合致させることにより、他のＴＣＰのフローに対して帯域幅−公平なスループットを提供することができる。従来の技術は、同等の動作条件の下で、等式ベースのレート制御がＵＤＰ転送の注入レートをＴＣＰ等価レートへ合致させるために使用することができ、ＴＣＰ−帯域幅の公平を実現できるが、安定性、スループット、および帯域幅利用を犠牲にしている。提案されている実施例は、利用可能な帯域幅があるときには安定性、高帯域幅、およびＴＣＰ公平を維持しながら、利用可能な帯域幅がいつなくなるのかを正確に決定することができ、またＴＣＰ公平を実現することができる。

従来技術のおいては、すべてのＴＣＰ処理系の通信の輻輳ウィンドウ／送信レートｘ（ｔ）は以下の等式により導出することが示されている。

ｋｉ（ｘｉ，Ｔｉ）は、ゲイン関数であり、レートの安定性や応答性のようなダイナミック特性を決定するが、平衡特性には影響しない。

ｕｉ（ｘｉ，Ｔｉ）は、平衡レート割り当て及び公平のような平衡特性をセットする限界効用関数である。

ｐｉ（ｔ）は、逸失確率もしくは待機遅れによる輻輳度の指標である。

Ｔｉ（ｔ）は、ラウンド・トリップ時間である。

利用可能な帯域幅を持つネットワークに対する送信レートを適用するために、いくつかの実施例は、従来例に見られるような、ＴＣＰに対する遅れベースの解決手法を適用している。この、遅れをベースとした解決手法は、限界効用関数：即ち

および、推奨されるゲイン関数：
ki＝γ^＊αi(t)及び輻輳度指標、pi、ベース・ラウンド・トリップ時間brttiと現在のラウンド・トリップ時間srttiとの差

いくつかの実施例では、brttiは、転送中に計測される最小ラウンド・トリップ時間である。srttiについては、これら実施例は、経路ラウンド・トリップ遅延ではなく、ネットワーク・ラウンド・トリップ遅延を計測し、以下に説明されているように、再伝送用ＲＴＯの計算に使用されるものと同じ再帰的予測推定関数を用いて、平滑化されたラウンド・トリップ時間を計算する。

ＴＣＰ用として従来例にも示されているように、信頼できるＵＤＰ転送のための安定した平衡レートを実現するために、この手法は時間がたてば送信レートの変化が０（零）に収束するように努める。これは、レートのサイズを変更し、効用関数に対する輻輳度の指標の比（ｐｉ／ｕｉ）が１に収束するように、そしてその結果、式１におけるｘ（ｔ＋１）−ｘ（ｔ）が０に収束するように方向を変更することによって達成される。

γ＝１／２としてｕｉとｋｉについて式１を説明すれば、レート更新の一般式は：
BaseAvgは、brttおよびsrttが小さいときには強制的に１にされ、brttがＲＴＴ計測の精度とおおよそ同じくらいの精度であるくらいに小さい場合のケースを処理する。

いくつかの実施例においては、αは、帯域幅および調整可能なアグレッシブネスの幅広い範囲にわたる、収束を目的とする目標レートの一次関数の適応ファクターである。従来技術で示されているように、αファクターは、レートｘｉでのソースからの送り出しが平衡点に到着するように、転送経路の待機行列へバッファーされるべきパケットの数を表しており、レート制御アルゴリズムの「アグレッシブネス」を表している。αと同一の値を有するフローは公平に帯域幅を有し、より高いα値を有するフローはより多くの帯域幅を比例的に取る。

これら実施例において、従来例と違っているのは、αが、全ての実用的ネットワークの帯域幅（１００Ｋｂｐｓから１Ｇｂｐｓまでの）範囲に対して安定した目標レートへ収束されるように、その目標レートの一次関数として調整されるということである。

効果的な再伝送タイムアウト（ＲＴＯ：retransmission timeout）を決定する場合に、正確に経路ラウンド−トリップ時間を見積もることが有用であるのと全く同じように、待機遅れを正確に計算するためにはラウンド−トリップ時間の正確な計測が有用である。待機遅れは、転送経路のネットワーク部分だけに適用するので、種々の実施例では、再伝送のための最終ホストにおける処理時間を含まない、二回目のラウンド−トリップ時間と、ネットワークＲＴＴとを計測する。再伝送のためのＲＴＯを計算するために使われる再帰的推定関数と同じ関数を使って、これら実施例ではネットワークＲＴＴの平滑化された加重平均を計算し、この値を、レート更新関数に使われるベースＲＴＴに対する現在のネットワークのＲＴＴの比を計算するために使用する。

ネットワーク遅れを計算するために、いくつかの実施例は、ＲＴＯのために経路ラウンド−トリップ時間を計測する方法と同じ方法を用いている。これら実施例においては，受信部は、各オペレーティング・システムにより提供される最良のクロック・メカニズムを用いて、正確な「クロック・ティックを発生させる。受信部は、再伝送の要求を送り出す直前にこの「ティック」を発生させ、再伝送要求に埋め込む。もしも再伝送要求の再伝送が不必要な場合（例えば、順方向チャンネルに何らの逸失も存在しない場合）には、受信部は、再伝送「なし（empty ）」を発生させ、これが、例えば毎１０ｍｓごとに最小周波数で送り出される。クロック・ティックは再伝送要求ＰＤＵに埋め込まれ、受信部から送信部へネットワーク上を走行する。受信部は、再伝送要求を処理するために用いられる正確な時間計算を行い、再伝送要求ＰＤＵに受取られたクロック・ティックにこの時間を加え、効果的に処理時間を差引く。受信部は、続いて、クロック・ティックをデータＰＤＵに埋め込み、それを受信部へ送る。クロック・ティックを含むデータＰＤＵが受取られると、受信部は、受取られたクロック・ティックを現在時刻から差引くことにより、経路遅れを決定する。この方法は、受信部がオペレーティング・システムから得られる最高精度のクロック・メカニズムを使用し、送信部が要求を処理する時間が明らかにされているので、精度の高いものである。

いくつかの実施例は更に、帯域幅を、利用できる帯域幅のない輻輳するネットワーク上で、いかなるＴＣＰ処理とも公平に、即ち比例的なアグレッシブネスで、分かち合う能力を有している。これら実施例は、計測された（例えば、ネットワーク遅延および／またはパケット逸失の関数として）ネットワークの諸条件のもとで一つのＴＣＰのフローの安定状態のレートを計測することによって、いかなるＴＣＰ互換の処理（例えば、既に紹介した式１により導入したあらゆるプロトコル）とも同等に、もしくは設定された比率で帯域幅を分かち合う。これら実施例は、待機遅れを利用可能な帯域幅がないことを示す信号として使用し、現在利用できる帯域幅がないリンク上での設定可能な公平さを保ちながら、利用可能な帯域幅があるリンクでの全帯域幅の利用を犠牲にしない。

公知技術に示されているように、すべてのＴＣＰ処理の送信レートは式１（上述）によって展開されることを用いて：

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

ＴＣＰ処理に基づく全ての逸失及び遅延についての平衡レートの式は、pi(t)/ui(t)=１と設定することにより得られる。

提案されている実施例は、式３に示されている遅れベースの輻輳度アルゴリズムを使用している。

公知技術に示されているように、最も多く一般に展開されているＴＣＰ方式(ＴＣＰ Ｒｅｎｏ）の平衡レートは、式４で示される。

いくつかの提案された実施例では、二つの平衡レートは、式５において、待機遅れおよび特定のＴＣＰ通信用平衡レート関数についての適応パラメータαを導き出すために同等に扱われている。
導き出されたαは、その後帯域幅−公平レート（式３を用いて）を計算するために使用される。これは、現在計測されたネットワーク・パラメータ（例えば、ラウンド−トリップ時間および／またはパケット逸失）用のＴＣＰレートに等しいことを意味している。ラウンド−トリップ時間を正確に計測するための方法については既に説明されている。パケット逸失レートは、いろいろな方法、例えば、推定加重移動平均法などを使用して、計測される。

ＴＣＰは、例えば「高速ＴＣＰ」とか、「スケーラブルＴＣＰ」とかというように発展するので、同じ方法が、ＴＣＰの平衡レートを異なる応答関数に適合させるために利用できる。例えば高速ＴＣＰまたはスケーラブルＴＣＰ：

本発明主題のいくつかの実施例によるレート制御機能は、二つの大きな要素を有している。即ち、「輻輳」があるとき（即ち、利用可能な帯域幅がないとき）に、帯域幅の公平さのために、待機遅れ、パケット逸失、およびラウンド−トリップ時間に関するＴＣＰレートにレートをイールドするためのαファクターを求めること、および、ＴＣＰフレンドリーな状態に入るための信号を出すべき輻輳がいつあるかについて正確に判断すること、である。これら実施例は、本発明主題による「適応ｘ−モード」（帯域幅が利用可能であるときに使用されていない帯域幅を利用する）と、「ＴＤＰモード」（利用可能な帯域幅がないときの公平さのため）とにおいて動作する、二つの状態を持つマシーン（二状態マシーン）を使用することにより、ＴＣＰフレンドリーのレートを使用すべき輻輳状態を判断する。

これら実施例は、輻輳があった場合にのみＴＣＰフレンドリー・モードへ入り、そのＴＣＰフレンドリー・モードを、輻輳は終了したと知るまでそのままにておく。これら実施例は、モードをいつ切り換えるかを判断するためにヒステリシス・モデルを使用している。もしもラウンド−トリップ時間が増加し、且つ待機遅れがベースｒｔｔよりも十分に大きくなり重要なものになると、ＴＣＰモードに入れられる。一旦ＴＣＰモードに入ると、システムは、ｒｔｔが減少し、待機遅れが十分前記ベースｒｔｔに近づいて待機状態は終わったことを示すまで、ＴＣＰモードに留まっている。

いくつかの実施例において使われている特定のパラメータは、実験的に決定される。

この方法は、異なるネットワーク状態において並列フロー・シナリオにはよい結果をもたらす。

レート制御モデルのパラメータは、アプリケーションに対し調整可能な「制御ノブ」を与えている。設定可能なパラメータとして、αを明らかにすることにより、転送が進行中に目標レート即ちアグレッシブネスの変更が可能になる。

アプリケーションは、例えば一つの標準ＴＣＰのフロー、或いは他の二つのＴＣＰのフローにレート等価な多数の（またはタイプの）ＴＣＰのフロー関してそのアグレッシブネスをセットできる。更に、アプリケーションは、特定のモード、例えば「トリックル（trickle ）」モードを選択できる。この「トリックル」モードにおいては、フローはＴＣＰとの共有の場合には完全に最小の閾値に後退するが、単独で進行中には全帯域幅を使うように急成長する。

いくつかの実施例は、非常に効率的なトリックル転送を紹介している。
データの転送において他のネットワーク活動がない限り全回線容量を利用でき、ネットワーク活動が検出されたときには非常に低いレートにバックアップするようにしている。非輻輳モードで進行するときには、適応レートモードで転送を進めアグレッシブネス・ファクターを非常に低くセットすることによって、フローは利用できる帯域幅の全てを利用し、輻輳モードに入ったときには完全に後退する。上記に関連して、転送アプリケーションは、配送時間を保証するために、このときの転送用として最小のレート・閾値をセットすることができる。トリックル・アプリケーションのユーザーは、転送する時間のネットワークの帯域幅をトレーディングすることによってオンザフライで（on-the-fly）最小閾値を変更することができる。

いくつかの実施例は、任意ではあるが暗号化要素を有していて、オンザフライでデータブロックを暗号化し、復号化する。
転送の始めに、ＳＳＨ或いはＳＳＬ／ＴＬＳといった確立された方法を用いて、セキュアＴＣＰチャンネルがリモート・エンド−ポイントにセットアップされる。そのような実施例における受信部は、ユーザーが設定可能な暗号（暗号化アルゴリズム）を与えられたランダム対称暗号化キーを発生させ、セキュア・チャンネルを使用している送信部と同キーを交換する。いくつかの実施例においては、前記エンド−ポイントは、前記暗号化キーを周期的に変更し、前記セキュア・チャンネルを介して新しいキーを交換するように決定できる。送信部は、データの秘密性を確かなものにするために各データブロックを暗号化し、データの認証を確かなものにするためにメッセージ認証コードを付け加える。この方法は、アプリケーション−レベルのデータ転送アプリケーションなどと同じように、種々の実施例において任意なものとして備えられている。この方法は、インターネットのような、公共のセキュアでないネットワークであっても、データを安全に転送できる手段をアプリケーションに対して提供することになる。

いくつかの実施例は、ファイルの転送を制御し且つモニターする能力も提供している。これら実施例では、管理用としてＴＣＰソケットインターフェースを提案している。同インターフェースによれば、管理用アプリケーションは、管理される転送エンド−ポイントと同じもしくは別のコンピュータ上で走ることができる。このインターフェースによれば、転送を開始および停止させ、オンザフライで転送レートを修正し、転送を一時停止または再開させ、またオンザフライで転送パラメータを変更するといった、制御およびモニター動作が可能となる。転送パラメータの変更には、適応レート・モードをイネーブルまたはディスエーブルさせ且つアグレッシブネスを変更するといった動作が含まれる。前記制御およびモニター動作には、基本的な転送統計を読み出し、プログレッシブ・ダウンロードに必要な転送統計を読み出し、且つＦＡＳＰ固有統計、例えば再伝送データの構造パラメータ、ディスク書き込み統計および適応レートパラメータ等、を読み出す能力といった動作も含まれる。このインターフェースは、種々の転送実施エレメントをアプリケーションに一体化するためのメカニズムである。前記インターフェースは、優先順位および帯域幅の利用の管理といった転送ポリシーをアプリケーションに実行させる。

いくつかの実施例は、アプリケーションレベルのリライアブルなＵＤＰプロトコルにより、アプリケーションが進行中の転送の転送レートを変更できるようにしている。管理インターフェースを使用することにより、転送マネージャは、データ転送における二つのエンド−ポイントの一方を制御する。送信部および受信部の両方は、同一の転送マネージャによりに制御されるときには、データ処理用スレッドとは関係なく、モニターおよび制御メッセージを転送マネージャと取り交わすことのできる専用の処理スレッドを有している。オンザフライでレート変更といった制御コマンドを受取るときに、送信部および受信部の専用管理スレッドは、新たな値および主たるデータ処理スレッドの問い合わせを記憶し、周期的に新たな値を取り出す。

もしも前記マネージャが受信部を制御しているとすると、マネージャは受信部に対して所望の最小または最大レート・閾値をパスする。受信部は、適応レート・モードで要求される目標レートを計算するに際しこの新たな値を使用し、また、固定レート・モードで動いている場合には目標レートを最大閾値にセットする。受信部は、目標レート（計算されたものであれ、セットされたものであれ）を周期的統計メッセージと共に送信部へ送り、送信部はそれに従う。

前記マネージャが送信部を制御している場合、マネージャは、送信部に対して所望の最小または最大レート閾値をパスする。もし固定レート・モードで動作していると、送信部はその固定レートとして新たなレートを使用し、統計メッセージの中で受信部が要求している目標レートを無視する。もし、適応レート・モードで動作中であると、送信部は、マネージャによってセットされた最小および最大レートを記憶し、それらを、受信部が要求している目標レートと比較する。もしも受信部により要求されている目標レートが最大レート閾値よりも大きいと、送信部はその目標レートを最大レート閾値にセットする。もしも受信部により要求されている目標レートが最小レート閾値よりも小さいと、送信部はその目標レートを最小閾値にセットする。それ以外では、送信部はその目標レートを、受信部により要求されている目標レートとする。

本発明主題の種々の実施例によるデータ転送は、予測能力を持つという性質から、ユーザーは、転送レートではなく、転送する時間をセットすることを選択できる。アプリケーションの一実施例によれば、ユーザーは、転送する時間もしくは到着推定時間をセットでき、それに合致させるように要求される目標レートを計算することができる。転送マネージャは、上述したように、オンザフライで目標レートをセットすることができる。

進行中の転送を一時停止するというのは、オンザフライで目標レートをセットするという特別のケース（レートを０（零）にセットする）であって、送信部および受信部の両方に、データ送り出しとデータ受取りの試みとの完全な停止を要求するものである。この特長は、帯域幅の優先順位について何の予定もないときには有用である。一時停止するには、転送マネージャが、目標レートを、適応−レート・モードの場合には最大レート閾値を、０（零）にセットする。送信部は、転送マネージャから、もしくは統計メッセージを介して受信部から、新たなレート値について知る。送信部が一旦この特別なケースを検出すると、送信部はデータの送り出しを停止し、転送マネージャが０よりも大きい値の目標レートをセットしてくれるのを待つ。もしも受信部が転送マネージャに制御されているとすると、受信部は０という新たなレートがセットされたことを直接知ることになる。桃霜送信部が転送マネージャに制御されているとすると、送信部は、制御目メッセージを受信部に送り、「一時停止」状態に入ったことを受信部に知らせる。いくつかの実施例において、受信部が「一時停止」状態に気づいているということは、データ受取りタイムアウトを引き起こしてしまわないようにするために重要なことである。

転送マネージャは、管理インターフェースにより、レート制御モードのセッッティング（固定レート、適応レート、および帯域幅アグレッシブネスを送信部もしくは受信部へパスする。もしも受信部が転送マネージャに制御されていると、受信部は、新たな制御モードを記憶し且つ実行する。受信部は、統計メッセージまたは制御メッセージを介して、固定または計算された目標レートを送信部へ送る。もしも送信部が転送マネージャーにより制御されているとすると、送信部は新たなセッティングを記憶し、それを制御メッセージを介して受信部へ送る。一実施例において、帯域幅アグレッシブネスは、多数の標準ＴＣＰアグレッシブネスという言葉で表現できる。いくつかの実施例は、標準ＴＣＰおよびその他のＴＣＰに関して、アグレッシブネスの連続してスライドするスケールをサポートする能力を有する。これは、フロータイプに関連するアグレッシブネス値を「ダイアルする」ため、連続インデックスとのフロータイプ互換性として管理インターフェースを介してエンド・ユーザに明らかにされるようにしてもよい。

ＯＳＩプロトコル・スタックについて、本発明主題のいくつかの実施例は統合データ転送レイヤー、セッション・レイヤー、およびサービス・レイヤー・プロトコルを提供している。

種々の実施例は、ＳＳＨおよびＳＣＰといったファイル転送のフレームワークをオペレーティング・システム内において統合することを含んでいる。ＳＳＨは、ユーザーに対して認証およびキーの交換についてのフレームワークを提供している。いくつかの実施例は、任意のセキュア・モードで動作する際の暗号化キーをつくるために、この枠組みを使っている。ＳＣＰは、リモート・ファイル・コピー用の事実上のユーザー・インターフェースを提供する。いくつかの実施例は、ＴＣＰへの別の高性能のデータ経路として、ＳＣＰとの統合を有している。

いくつかの実施例は、転送されたデータの消費なく或いは最小の消費でファイル転送における再開性（resumability）を可能とする転送メタ・データを記憶する。転送は、同一のファイルを記憶している送信部であればどのような送信部からでも再開され、必ずしも同一の送信部である必要はない。これにより、システムを余分に配備する必要がなくなり、アプリケーションは、送信部システムもしくはそこへの接続の不具合が生じた後、バックアップ用の送信部もしくは接続ルートが利用可能となったときに再開される。かかる再開性のサービスは、完全性のチェック、完全性の保証の平衡、及び検証時間（検証時間はエッジからエッジまでの転送速度を再度計数する）についての数レイヤーを提供する。

ここに示されたブロックベースの転送システム、方法、およびソフトウェアの目標レートベースの本質は、等式ベースのレート制御と共に、転送ポリシーを有する実施例を提供する。かかる転送ポリシーのいくつかは、帯域幅の割り当て、優先順位、およびファイル転送の手動コントロールに関係している。

ａ）帯域幅割り当てポリシー
多数のロケーションとそれらロケーション間を結ぶネットワーク・リンクの容量による構成の場合、管理者もしくは帯域幅管理アプリケーションは異なるファイル転送アプリケーション間のネットワーク容量の割り当てを決定することができる。各フローの最大転送レートはファイル転送アプリケーションへパスされて実施される。転送レートの上限は、ファイルの転送が開始される前に、もしくは転送の進行中にパスされる。

時間方式帯域幅割り当てについて、ファイルの転送が或る転送時間に合致しなければならないとき、一つの実施例では、最小転送レートをセットすることができる。フローは、輻輳のある中で公平に動作するが、最小転送レートを超えてスローダウンすることはない。このことにより、不公平にその他のトラフィックの全てに対し残りの帯域幅について競合させることを代償にして最小の配信時間が保証される。
ｂ）優先順位ポリシー
いくつかの実施例は、優先レベルを、レートを制御するアグレッシブネスファクターに関連付けることができる。それ故、優先度の高いトラフィック（高優先トラフィック）は、ダイナミックに且つ優先度の低いトラフィック（低優先トラフィック）より多くの帯域幅が割り当てられる。優先順位についての極端な場合として、低優先トラフィックは、高優先トラフィックと競合したときに、完全に停止するように設定できる。このことは、トリックル・トラフィックについても言え、トリックル・トラフィック優先を最低レベルにセットすることにより、他のトラフィックに対して影響を与えないトリックル転送即ち他のトラフィックが存在するときには停止するトリックル・トラフィックとすることができる。
ｃ）ファイル転送の手動制御ポリシー
いくつかの実施例において用いられている管理インターフェースにより、ユーザーまたは管理者は、オンザフライで転送パラメータを変更することができる。これは、他の転送がより早く実行できるように転送を一時停止し、また同様に、進行中の転送の速度を落し或いは速度を速めるということを含んでいる。

いくつかの実施例は、アプリケーションに対して以下のパラメータを明らかにしている。即ち、目標レート（適応レート制御の場合の最大レート）、最小レート（適応レート制御の場合の）、および適応ファクターである。これらパラメータは、転送の開始前もしくは転送が進行中にセットされることができる。これらパラメーターに基づき、アプリケーションは、以下をするためにファイル転送をインテリジェントに制御する。
・固定レート制御を特定し且つ目標レートを供給して固定レートでファイル転送を行うこと、
・適応レート制御を特定し且つリンクのキャパシティよりも高いもしくと同じ最大レートを供給することによって、競合するトラフィックが存在しても公平に適応するリンクキャパシティでファイル転送を行うこと、
・所定のレートでファイルを転送すること、但し、輻輳が存在する場合には適応レート制御を特定し且つ最小レートを供給することによって最小レートとする。フローは、競合するトラフィックとリンクを分かち合うように適応するが、そのレートは特定された最小値を下回ることはなく、従って配送時間が保証される、
・リンク・キャパシティでファイルを転送すること、但し、適応レート制御を特定し且つ適応ファクターとして最小値を供給することによって、競合するどのようなトラフィックに対しても影響を与えないこと。フローは、リンクのキャパシティで走るが、競合するトラフィックが存在すると停止し、その結果、通常のネートワークの働きには一切影響しない。これは効果的なトリックル転送に使用できる。
転送が行われている最中に、アプリケーションが、転送レートを変更することができるので、アプリケーションは目標レートをゼロにすることにより転送を一時停止させ、またゼロではない値へ戻すことによって、転送を再開させることができる。

いくつかの実施例は、インテリジェントなブロック・ベースのキャッシングサービスを提供する。このサービスにより、これら実施例は、ファイルのセグメントが既に受信部システムへ転送されたかどうかを判断し、それをネットワークを通して転送する替わりにキャッシュされているデータを再使用する。このキャッシング・サービスは、完全性のチェックの数レイヤーを提供する。完全性チェックのタイプは、アプリケーションによって特定されるか、或いは最適化機能を使用してＦＡＳＰによって自動的に決定される。最適化機能は、ネットワーク・キャパシティおよび転送待機列に対するキャッシュ完全性検証時間を考慮する。もしも転送が、ローカルの完全性検証よりも早い場合、前記キャッシングサービスは、データの再転送を選択する。それ以外では、ローカルにキャッシュされたデータは再使用される。

いくつかの別の実施例は、アプリケーションが両面パイプライン型データ転送を実行できるようにするために必要な全てのモニター・サービスと制御サービスとを提供する。このデータ転送は、プログレッシブ・ダウンロードとも称される。両面データ転送は、データを受け取ると同時にそのデータを第三の転送エンド−ポイントへ送り出すか或いは消費する一つのエンド・ポイントを有している。両面パイプライン型データ転送の例は、メディア・ファイルをダウンロードし同時にそれをメディア・プレーヤへ供給するアプリケーションを有するか、或いは、ユーザーに代わってファイルをダウンロードし、ファイルをキャッシュへ記憶する一方同時にユーザーへそれを配送するアプリケーションを有している。

そのような実施例の一例は、ＡからＢへのデータ転送を所望のレートで開始し、Ｂにおいて、ファイルの先頭から始めて、実効受取りレート、逸失レート、受取られた連続データの量を明らかにすることによって、パイプライン型データ転送を実現する方法を備えている。この方法はさらに、Ｂで明らかにされたデータとＢからＣへの所望の転送レートとに基づいて、ＢからＣへの転送を開始する時間を決定することも含んでいる。この方法はまた、ＢからＣへの転送の実効レートおよび送られるデータの量をＢで明らかにすることも含んでいる。かかる情報に基づき、この方法は、パイプラインが正しく機能しているかどうかを決定することができる。ＢからＣへの転送が、ＡからＢへの転送よりも先行する場合、この方法は、ＢからＣへの転送を遅くし、或いは一時的に停止することさえもできる。更に、この方法は、要求許可されたＢからＣへの転送の最小ブロック数を明らかにすることを含んでいる。これにより、この方法は、Ｂにおいてそのポイントまでのデータを廃棄することができ、ストレージが制限されている場合には有用である。

いくつかの実施例は、リファレンスを用いてファイルを特定すること、およびファイル転送することを含んでいる。伝送エンドポイントは、特定のリファレンスに基づいてファイルもしくはディレクトリーをダウンロードまたはアップロードできる。種々の実施例においてこれらリファレンスは、リモート・ファイルもしくはディレクトリーの識別番号、転送レート、適応レート制御、および暗号化といった転送パラメータを含んでいる。

基準のフォーマットの一例は以下の通りである：

種々の実施例において、以下のオプションのうちの一つまたはそれ以上をリファレンスとして利用できる。
ｘｆｅｒ＝アップ｜ダウン アップは、アップロードを表しており、その場合、 径路は目標ディレクトリを表す。
ａｕｔｈ＝イエス｜ノー もしイエスにセットされると、ダウンロードを強制 的に暗号化し、もしノーとセットされると、強制的 に復号化する。もし、ノー又は、なしにセットされ ると、ユーザーが暗号化するかしないかを選択す る。
ｍａｘｒａｔｅ＝＜ｖａｌ＞ 許容される最大レートを＜ｖａｌ＞Ｋｂｐｓとセッ トする。ユーザーは転送レートをこの値まで選択で きる。
ｄｅｆｒａｔｅ＝＜ｖａｌ＞ デフォルトの転送レートを＜ｖａｌ＞Ｋｂｐｓに セットする。ユーザーは、もう一つのレートを許容 される最大のものまでの間で選択する。
ａｄａｐｔ＝イエス｜ノー もしイエスにセットされると、適応レート制御を使 用する。
ｐｏｒｔ＝＜ｖａｌ＞ ＵＤＰポートを＜ｖａｌ＞ にセットする。
ｓｉｇｎ＝＜ｖａｌ＞ 参照ストリングの署名、完全性に保険をかけるため の安全措置として。

リファレンス・サービスにより転送を提供することによって、ＦＡＳＰは、アップリケ−ションへ簡単に統合できる。アプリケーションは、例えばウェブ・ダウンロードやアップロード、ＦＡＳＰのダウンロードのためのリファレンスとのイーメール添付置換(email attachment replacement)、アセット管理システム・チェックイン及びチェックアウトである。本発明主題のいくつかの実施例は、ブロック・データのペイロードを繰り上げするためにＵＤＰを利用している。しかしながら、事実上、どのような転送またはネットワーク・レイヤー・メカニズムであっても同じ目的を達成することができる。例えば、別の転送およびネットワーク・レイヤーは、ユーザーによって定義づけられた転送プロトコルをエンドポイントにおけるＩＰもしくは修正ＴＣＰスタックに含んでいる。エンドポイントにおけるＴＣＰスタックは、ＵＤＰのように動作するように修正（例えばフロー制御とか再伝送とかがないといった）することができる。ブロックは、ファイア・ウォールの設定を確立できるネットワークを通してＴＣＰパケットとして送られる。その結果、特殊なファイアウォールおよび侵入検出の設定をＵＤＰに対してしなくても済む。その他の別のトランスポートは、ＩＰと同様のサービスを提供できる非−ＩＰネットワークを含む。前記サービスとは、即ち、「ベスト・エフォート」・コネクションレス・ルーティングおよび、データ転送動作に含まれる２またはそれ以上のエンドポイント間におけるパケットの配送である。かかるネットワークには、衛星、パケットラジオ、二地点間または一斉通信ネットワーク、およびＡＴＭが含まれる。

いくつかの実施例のアーキテクチュアは、二重構造となっている。かかる実施例における第一の階層は、アプリケーションに対してブロック・ベースのファイル転送サービスを提供するプロトコルを提供するものである。第二の階層は、プロトコルの上に構築される最小ファイル転送アプリケーションである。

しかしながら、このアーキテクチュアの変形例は、ドライバー、カーネル・モジュールまたはモノリシック・オペレーティング・システムの単なる一部として、オペレーティング・システムの一部であるシステムおよび方法を実行すること、を含むことができる。その他の変形例は、本発明主題をモノリシック・データ・転送アプリケーションへ実施すること（例えば、単一階層による手法）を含む。

その他の実施例は、既存のＴＣＰトラフィックを遮断しここに説明されている種々の要素によってネットワークを通してそれをリモート・エンドのプロクシへ伝送するためにインターセプション・プロクシ（透明性が歩かないかに関係なく）を使用することを含み、ＴＣＰを用いてデータをＴＣＰアプリケーションのリモート・エンドへパスする。このインターセプション・プロクシは、ファイルまたはアプリケーション・サーバー・マシーンで動作するソフトウェア・ピース、またはネットワークに接続されたハードウェア装置である。更に別の実施例では、ネットワーク・ファイル・システム内に本発明の主題を含んでいる。また別の実施例では、効率的なバルク転送のために、無線または衛星ネットワーク用の特別なアプリケーション・ゲートウェイを有している。

いくつかの実施例は、信頼性、性能、安全性、および管理可能性を、プロトコル・パラメータの調整により達成できる方法とアルゴリズムとを提供する。これらパラメータの値は、ネットワークおよびオペレーティング・システムの環境に従ってセットされる。信頼性、性能、安全性、および管理可能性は、これらのパラメータを操作することによって、またはそれらが計算されたやり方によって、達成される。これらパラメータには以下のものが含まれる。

・ブロックの大きさ（サイズ）
・再伝送タイムアウトパラメータγおよびη
・ファイル・キャッシュのサイズ
・ファイル・キャッシュ低、高の水準
・レート制御用ＦＡＳＰおよびＴＣＰ互換モード・パラメータα
・レート制御用ベース・平均ステップ関数・パラメータ
・レート制御用パラメータＣ
・ＦＡＳＰおよびＴＣＰモード間の状態を切換えるレート制御用パラメータ・ファクター
「要約」は、技術的開示内容の性質と要点とを読者が速やかに確かめることができるようにするために［発明の概要」を求めている３７Ｃ．Ｆ．Ｒ．第１．７２（ｂ）条の規定に従い用意されたものであることを強調する。同「発明の概要」は、特許請求の範囲の範囲もしくは意味を解釈または限定するために使用されないとの理解のもとに提出されたものである。

当業者であれば本発明の主題の性質を説明するために記述され且つ図解された詳細、材料、部品の配列、方法の段階の配列は、添付されている特許請求の範囲に表明された本発明主題およびそれらの法的同等物の範囲を逸脱することなく、種々のその他の変更をなし得ることは直ちに理解されよう。

添付されている図は、本システムに関するいくつかの態様と例とを示すためのものであるが、本発明の主題を専用的に表すもしくは余すところなく表すべく意図されたものではない。
一実施例によるシステムを示す模式的なブロック図である。 一実施例による送信／受信システムを示すブロック図である。 一実施例によるデータ送信プロセスを示すブロック図である。 一実施例によるデータ受信プロセスを示すブロック図である。 一実施例によるシステムのデータ・フロー図である。 一実施例によるシステムのデータ・フロー図である。 一実施例によるシステム７００のデータ・フロー図である。

Claims (54)

1. 送信部と受信部とを備え、ネットワークを通して前記送信部および前記受信部間で、安定した、予測可能な、効率的なデータの転送をするためのデータ転送システムであって、
   注入レートを受取るための注入レート用入力と、
   前記注入レートでデータを効率的に転送するための信頼性手段とを備え、
   前記信頼性手段は、データをブロックに分割し、各ブロックは、連続する順序番号を有し、また前記信頼性手段はブロックの順序外れの配送を許容し、更に前記信頼性手段は再伝送手段を有し逸失したブロックを特定しそれを再伝送するための再伝送手段を有しており、
   前記信頼性手段は、注入レートに対する受取りレートに実質的に等しく、且つ伝播遅れおよびデータ逸失を招き得るネットワークの状態およびエンドポイントの状態に関係のない実用的なスループットを実現するデータ転送システム。
2. 請求項１のデータ転送システムにおいて、前記注入レート用入力は、固定された注入レートを受取るシステム。
3. 請求項１のデータ転送システムにおいて、前記注入レート入力は可変注入レートを受取るシステム。
4. 請求項１のデータ転送システムにおいて、前記注入レート入力は、前記送信部および前記受信部間のネットワークの輻輳の計測に基づいて決定される注入レートを受取るシステム。
5. 請求項４のデータ転送システムにおいて、前記レート制御プロセスは、レート制御プロセスのアグレッシブネスを判断するためのネットワーク・ラウンド・トリップ時間を決定する待機遅れ計測手段を有しているシステム。
6. 請求項５のデータ転送システムにおいて、前記レート制御プロセスは、待機遅れがネットワークの輻輳を示した際に、ＴＣＰ互換のフローに実質的に同等のレートで安定するようになっているシステム。
7. 請求項１のデータ転送システムにおいて、逸失ブロックを特定するためのラウンド・トリップ時間を正確に予測するための経路ラウンド・トリップ時間予測装置を有するシステム。
8. 請求項７のデータ転送システムにおいて、前記経路ラウンド・トリップ予測装置は、予測されるラウンド−トリップ時間についてヴァン・ヤコブソン予測を行うようになっているシステム。
9. 請求項１のデータ転送システムにおいて、実質的に一定時間で検索する機能を有する修正されたレッド・ブラック・ツリーが、番号でソートされた再伝送用のシーケンス番号を記憶する前記再伝送手段によって使用されているシステム。
10. 請求項１のデータ転送システムは更に、ディスクに対するランダム・アクセスを最小とするためのディスク書込みキャッシュ・メカニズムを有しており、前記メカニズムは、再伝送テーブルの大きさの移動平均(running average )として計算された高水準を使用している。
11. データ・ソースとコミュニケーションをとり合っている送信部と、受信部との間におけるデータ転送の方法であって、
    前記データ・ソースからのデータを一つもしくはそれ以上のブロックに分割し、
    前記一つもしくはそれ以上のブロックの各ブロックに連続する識別番号を関連付け、
    データブロックの伝送のために注入レートを受取り、
    一つもしくはそれ以上の逸失ブロックを特定した再伝送要求を前記受信部から受取り、前記再伝送要求は、逸失したブロックを特定するための予測経路ラウンド−トリップ・タイムアウトに基づいており、再伝送要求が重複してなされないように、そして、注入レートに整合するレートで前記受信部から伝送され、
    データは、一つもしくはそれ以上の残りのブロックの前に前記再伝送要求に特定された逸失ブロックを有するデータを前記注入レートで伝送し、前記伝送は、順番通りではないデータブロックでの伝送を可能とし、
    前記方法は、注入レートに関係なく実質的に受取りレートに等しく、また伝播遅れおよびデータ逸失をもたらし得るネットワーク状態およびエンドポイントの状態に無関係な、有用なスループットを実現できるようにする。
12. 請求項１１の方法において、前記注入レートの受取りには、固定注入レートを受取ることを含む方法。
13. 請求項１１の方法において、前記注入レートの受取りには、可変注入レートを受取ることを含む方法。
14. 請求項１１の方法において、前記注入レートの受取りには、前記送信部および前記受信部間のネットワーク経路の輻輳の計測に基づいたレート制御プロセスによって決定される注入レートを受取ることを含む方法。
15. 請求項１４の方法において、レート制御プロセスのアグレッシブネスを決定するためにネットワーク・ラウンド−トリップ時間を計測することを含み、前記レート制御プロセスによって決定される注入レートを受取ることを含む方法。
16. 請求項１５の方法において、前記レート制御プロセスは、ネットワークが輻輳しているときには、ＴＣＰ互換フローのレートに実質的に等しいレートで安定するようになっている方法。
17. 請求項１１の方法は更に、番号でソートされた再伝送の実質的一定時間の検索を有する修正されたレッド・ブラック・ツリーに複数個の識別番号を記憶させることを備えた方法。
18. データ・ソースとコミュニケーションをとり合っている送信部から、受信部によってデータを受取る方法であって、
    前記送信部および前記受信部間のネットワークにおける伝送の予測経路ラウンド−トリップ時間を計測し、
    前記送信部からのデータブロックを受取るために注入レートを取得し、
    各々識別番号を含む一つもしくはそれ以上のデータブロックを受取り、
    受取られた識別番号に基づいて逸失したデータブロックと、経路ラウンド−トリップ時間の関数として予測受取り時間とを検出し、
    一つもしくはそれ以上の逸失ブロックを特定する前記受信部により再伝送要求を発生させ、
    再伝送要求は、逸失したブロックを特定するための予測経路ラウンド−トリップ時間に基づいており、且つ注入レートに相応するレートで送られる方法。
19. 請求項１８の方法は更に、経路ラウンド−トリップ時間の予測にヴァン・ヤコブスン法を実施することを備えてている。
20. 請求項１８の方法は更に、直線配列で再伝送されるべきブロックの識別番号を記憶することを備え、各ブロックのリニア・インデックスは再伝送要求と共に送信部へ走行し、データブロック自身と共に戻るようにした方法。
21. 請求項１８の方法において、再伝送要求は、前記注入レートに対して可能な限り最小のサイズのパケットで走行する。
22. 請求項１８の方法は更に、ディスクに対するランダム・アクセスを最小とするため、ディスク書込みキャッシュ・プロセスにおける再伝送要求の再伝送テーブルの移動平均サイズとして計算される水準(watermark )を備えている。
23. ネットワークを通して送信部から受信部へデータを伝送する方法であって、
    前記送信部および前記受信部間のネットワークの現在利用可能な未使用の帯域幅を、パケット逸失とは無関係に検出し、
    もし未使用の帯域幅が現在利用可能である場合、全ての利用可能なネットワーク帯域幅に対して、パケット逸失とは無関係に、今使用されていない帯域幅に実質的に等しい目標注入レートを発生する帯域幅利用モードに入り、
    もし、未使用の帯域幅が現在利用可能でない場合、その他の進行中のフローにより消費される帯域幅の設定可能な割合の目標注入レートを発生する帯域幅共有モードに入り、
    実質的に前記目標注入レートでデータを伝送し、
    前記目標注入レートを更新するために、前記検出を繰り返すことを備えた方法。
24. 請求項２３の方法であって、前記目標注入レートは、前記送信部および前記受信部間のネットワーク経路の計測可能なエンド・ツー・エンド・パラメータの関数である目標フロータイプの安定状態レートに等しい方法。
25. 請求項２４の方法であって、前記計測可能なエンド・ツー・エンド・パラメータは、待機遅れを含んでいる方法。
26. 請求項２４の方法であって、前記計測可能なエンド・ツー・エンド・パラメータは、ラウンド−トリップ時間を含んでいる方法。
27. 請求項２４の方法であって、前記計測可能なエンド・ツー・エンド・パラメータは、パケット逸失を含んでいる方法。
28. 請求項２３の方法において、前記その他の進行中のフローはＴＣＰを含んでいる方法。
29. 請求項２３の方法において、前記その他の進行中のＴＣＰ互換のものが含まれている方法。
30. 請求項２３の方法において、未使用の帯域幅を検出することは、デフォルトの帯域幅利用モードになり、帯域幅共有モードに入るかどうかを決めるためにネットワーク待機遅れにおける変化の絶対値及び方向を計測するヒステリシス・モデルを使用することを含む方法。
31. 請求項３０の方法は更に、
    前記送信部および前記受信部間の転送経路のラウンド−トリップ時間を計測し、
    前記転送経路のベース・ラウンド−トリップ時間を計測し、
    待機遅れを、ベース・ラウンド−トリップ時間と測定されたラウンド−トリップ時間との間の差として計算することを備える方法。
32. 請求項２３の方法は更に、自動帯域幅キャパシティ検出を使用して、少なくとも最初に前記目標レートを確立することを備える方法。
33. 請求項２３の方法は更に、利用可能な帯域幅がない場合には設定された最小値へ戻った目標注入レートを与え、帯域幅が利用可能となった場合には未使用の帯域幅を十分に利用できるように急成長する目標注入レートを与えることを備える方法。
34. 請求項２３の方法は更に、ユーザーもしくはアプリケーションが、進行中のフローとのスケーラブルな可能なプロトコル間帯域幅共有のために目標注入レートを決定するポリシーを選択できるようにするインターフェースを提供することを備え、目標プロトコルのタイプ、目標プロトコルのフローの数に乗算する一定のまたは相対的ファクター、および目標注入レートを制約する最大もしくは最小レートを任意に選択することを含む方法。
35. 通信プロトコルのために注入レートを計算する方法であって、パケット逸失とは無関係に、現在の目標レートの関数（Ｆ）である最新の注入レートと、目標プロトコルに対するプロトコルのアグレッシブネスを制御する適応ファクター（α）とを計算することを含み、
    前記最新注入レートは、
    として特徴付けられ、
    前記適応ファクターは、目標プロトコルの平衡レート（Ｘｉ）であり、Ｘｉは計測された一つもしくはそれ以上のネットワーク・パラメータ、即ち一つもしくはそれ以上のラウンド・トリップ遅延、パケット逸失の確率もしくは待機遅れなどの関数である方法。
36. 請求項３５の方法であって、前記ＸｉはＴＣＰ Ｒｅｎｏの平衡レートであって、
    と定義され、ここにおいてｒｔｔｉは、現在のネットワーク・ラウンド・トリップ時間であり、ｐｉはパケット逸失の確率であり、Ｃは、ネットワークＭＴＵに依存する定数である方法。
37. 請求項３５の方法であって、前記Ｘｉは、どのようなＴＣＰ互換のフローに対しても平衡レートである方法。
38. ネットワークを通して送信部および受信部間の通信を行う装置であって、
    前記受信部において逸失ブロックを特定する手段と、
    前記受信部によって前記逸失ブロックの受信のために逸失ブロックの再伝送を効率的に要求する手段とを備えた装置。
39. ネットワークを通して送信部および受信部間の通信を行う装置であって、
    注入レートを入力する手段と、
    逸失ブロックを再伝送する手段を有し、前記注入レートで効率的に且つ確実にデータを伝送する手段とを備える装置。
40. ネットワークを通して送信部および受信部間の通信を行う方法であって、
    前記受信部において逸失したブロックを特定し、
    前記受信部によって前記逸失ブロックを受信するために逸失ブロックの再伝送を効率的に要求する方法。
41. ネットワークを通して送信部および受信部間の通信を行う方法であって、
    逸失ブロックを再伝送することを含み、注入レートで効率的に且つ確実にデータを伝送する方法。
42. ネットワークを通して送信部および受信部間の通信を行う装置であって、
    ネットワークの活動を検出する手段と、
    ネットワークの活動を検出するための手段からの情報に基づいて伝送されるブロックの注入レートを調整するレート制御手段とを備える装置。
43. 請求項４２の装置は更に、収束および調整可能なアグレッシブネスを制御するための適応ファクターを決定する手段を備えている。
44. 請求項４２の装置は更に、ＴＣＰ互換のフローに対する帯域幅の公平性を制御する手段を備えている。
45. ネットワークを通して送信部および受信部間の通信を行う装置であって、
    ネットワ−クの活動を決定する手段と、
    帯域幅有効トリックル・データ転送のための手段とを備える装置。
46. ネットワークの活動を検出し、
    効率的なデータ転送システムのレートを制御することを備える方法。
47. ネットワークの活動を検出し、
    収束および調整可能なアグレッシブネスを制御するための適応ファクターを決定することを備える方法。
48. ネットワークの活動を検出し、
    効率的データ転送システムを使用してＴＣＰもしくはＴＣＰ互換のフローに対する公平性を制御することを備える方法。
49. ネットワークの活動を検出し、
    効率的なトリックル・データ転送を制御することを備える方法。
50. ネットワークを通して送信部および受信部間の通信を行うシステムであって、
    暗号化キーを発生する手段と、
    効率的データ転送システムのための暗号化および認証手段を備えるシステム。
51. ネットワークを通して送信部および受信部間の通信を行うためのインターフェースであって、
    確実且つ効率的なデータ転送のための管理インターフェースを備えるインターフェース。
52. 添付の図面を参照して本明細書に実質的に記述されているデータ転送のための装置。
53. 添付の図面を参照して本明細書に実質的に記述されているデータ転送のための方法。
54. 添付の図面を参照して本明細書に実質的に記述されている、コンピュータの実行可能な指示を含むコンピュータによる読取り可能なメディア。