JP4848425B2 - 適応型帯域幅制御を行う方法、装置、及びコンピュータ使用可能なコード（適応型帯域幅制御） - Google Patents

Description

本発明は一般に改良型データ処理システムに関するものであり、特に、データ転送を行うコンピュータ実装方法及び装置に関するものである。

より詳細には、本発明は、データ転送に使用される帯域幅を適応的に制御するコンピュータ実装方法、装置、及びコンピュータ使用可能なプログラム・コードに関するものである。

ネットワーク及びインターネットの普及は、商用通信に大きな変革をもたらしている。一般に、ネットワークはデータ転送に使用される。多くの分散型アプリケーションでは、サービス品質を高めるためにバックグラウンド転送が利用されている。これらのタイプのバックグラウンド転送を用いると、ユーザはバックグラウンド転送の完了を待たずに他のアクションを実行することが可能となる。バックグラウンド転送は、例えばデータ・バックアップ、プリフェッチ、エンタープライズ・データ配信、インターネット・コンテンツ配信、及びピア・ツー・ピア・ストレージを含めた様々なアプリケーション及びサービスで利用されている。上記及び他のタイプのアプリケーションでは、ネットワーク帯域幅の消費量が増加している。こうしたサービスの中には、帯域幅が増加するほどサービス品質が向上し得ることから帯域幅需要が際限なく増加するものもある。
Ｖｅｎｋａｔａｒａｍａｎｉ等の「ＴＣＰ Ｎｉｃｅ： Ａ Ｍｅｃｈａｎｉｓｍ ｆｏｒ Ｂａｃｋｇｒｏｕｎｄ Ｔｒａｎｓｆｅｒｓ」、ＡＣＭ ＳＩＧＯＰＳ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｒｅｖｉｅｗ、Ｖｏｌ．３６、Ｉｓｓｕｅ ＳＩ Ｗｉｎｔｅｒ ２００２、１〜１５頁

これらのタイプのアプリケーションに関しては、大部分のネットワークにおいてデータ転送に使用可能な帯域幅が限られているという問題がある。アプリケーションの中には重要な機能を実行するものもあればそうでないものもある。典型的には、バックグラウンド転送は重要な機能に入らないが、これによって使用可能な全ての帯域幅が使用されれば、重要なネットワーク・トラフィックの遅延を招く恐れがある。

ネットワーク状態を自動的に適応させてネットワークへの影響を少なくするために、適応型帯域幅制御が利用されている。現在、様々なアプリケーションで使用される帯域幅量を制御して輻輳を回避する様々な適応型帯域幅制御処理及びアルゴリズムが利用されている。現時点で使用可能な適応型帯域幅制御処理では、サーバ又はクライアント・コンピュータ上のローカル・インターフェース・レベルのネットワーク状態が加味されるが、データ転送時に存在し得る他の状態が加味されることはない。

したがって、データ転送時の帯域幅使用率を適応的に制御するように改良されたコンピュータ実装方法、装置、及びコンピュータ使用可能なプログラム・コードを有することが有利なはずである。

本発明は、選択された優先度を使用してソースから配信（ｄｉｓｔｒｉｂｕｔｉｏｎ）されるデータを複数のゲートウェイにおいて受信するコンピュータ実装方法、装置、及びコンピュータ使用可能なプログラム・コードを提供する。前記データは、前記選択された優先度を使用して前記複数のゲートウェイから複数の受信機に送信される。前記複数のゲートウェイは全て、適応型帯域幅制御処理と、前記データが前記選択された優先度で送信されるように前記適応型帯域幅制御処理を制御する各パラメータ・セットと、を有する。前記選択された優先度で行われる各ゲートウェイからの前記データの送信は、前記複数のゲートウェイのうちの異なるゲートウェイに関する前記パラメータ・セットについて異なる値が設定されている場合には、前記異なるゲートウェイの他のトラフィックに異なる影響を与えることになる。

前記パラメータ・セットは、閾値と、βと、最大待ち時間と、を含むことができる。前記複数のゲートウェイのうちの特定のゲートウェイに関するパラメータ・セットを構成することができ、前記特定のゲートウェイに関する前記パラメータ・セットは、前記複数のゲートウェイのうちの別のゲートウェイに関する前記パラメータ・セットとは異なるものとすることができる。前記適応型帯域幅制御処理では、前記複数のゲートウェイのうちのあるゲートウェイから前記配信の受信機までの経路に沿った輻輳が加味される。前記各パラメータ・セットは、前記複数のゲートウェイのうちの各ゲートウェイ毎に異なるものとすることができる。各実例において、前記データは、データ・ファイル、アプリケーション・アップデート、及びウイルス・パッチのうちの１つを含む。

ここでは単なる例示として、本発明の実施形態（単数又は複数）を添付図面を参照しながら説明する。

図１及び図２はそれぞれ、本発明の諸実施形態を実施することが可能なデータ処理環境を例示する図である。図１及び図２は例示的なものに過ぎず、本発明の諸態様又は諸実施形態を実施することが可能な環境を限定することを主張するものではなく、そのように暗示することも意図しているわけではないことを理解していただきたい。図示の環境には、本発明の趣旨及び範囲から逸脱しない限り様々な修正を施すことができる。

ここで添付図面を参照すると、図１には本発明の諸態様を実施することが可能な複数のデータ処理システムから成るネットワークが示されている。ネットワーク・データ処理システム１００は、本発明の諸実施形態を実施することが可能な複数のコンピュータから成るネットワークである。ネットワーク・データ処理システム１００はネットワーク１０２を含んでおり、ネットワーク１０２は、ネットワーク・データ処理システム１００内で互いに接続された様々なデバイスとコンピュータとの間の通信リンクを提供するのに使用される媒体である。ネットワーク１０２は、有線通信リンク、無線通信リンク、光ファイバ・ケーブル等の接続を含むことができる。

図示の例において、ネットワーク１０２には、サーバ１０４及びサーバ１０６ならびに記憶ユニット１０８が接続されている。また、ネットワーク１０２には、クライアント１１０、１１２、及び１１４も接続されている。これらのクライアント１１０、１１２、及び１１４は、例えばパーソナル・コンピュータであってもネットワーク・コンピュータであってもよい。図示の例において、サーバ１０４は、ブート・ファイルのようなデータ、オペレーティング・システム・イメージ、及び各種アプリケーションをクライアント１１０、１１２、及び１１４に提供する。本例において、クライアント１１０、１１２、及び１１４は、サーバ１０４のクライアントに相当する。ネットワーク・データ処理システム１００は、図示されていない追加的なサーバ、クライアント、及び他のデバイスを含むこともできる。

図示の例において、ネットワーク・データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）プロトコル・スイートを使用して互いに通信し合う世界中のネットワーク及びゲートウェイの集合体を表す、ネットワーク１０２を有するインターネットである。当該インターネットの中心には、データ及びメッセージを送る数千もの民間用、政府用、教育機関用他のコンピュータ・システムから成る、主要なノード又はホスト・コンピュータ間の高速データ通信回線の基幹回線が存在する。言うまでもなく、ネットワーク・データ処理システム１００は、例えばイントラネットや、ローカル・エリア・ネットワーク（ＬＡＮ）や、広域ネットワーク（ＷＡＮ）等のいくつかの異なるタイプのネットワークとして実施することもできる。図１は一例として意図されたものであり、本発明の様々な実施形態に関するアーキテクチャ上の限定として意図されたものではない。

ここで図２を参照すると、本発明の諸態様を実施することが可能なデータ処理システムのブロック図が示されている。データ処理システム２００は、本発明の諸実施形態に関する処理を実行するコンピュータ使用可能なコード又は命令を設置することができる、図１のサーバ１０４やクライアント１１０等のコンピュータの一例である。

図示の例において、データ処理システム２００は、ノース・ブリッジ及びメモリ・コントローラ・ハブ（ＭＣＨ）２０２と、サウス・ブリッジ及び入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＩＣＨ）２０４とを含むハブ・アーキテクチャを利用している。プロセッサ２０６、メイン・メモリ２０８、及びグラフィックス・プロセッサ２１０は、ノース・ブリッジ及びメモリ・コントローラ・ハブ２０２に連結されている。グラフィックス・プロセッサ２１０は、高速グラフィックス・ポート（ＡＧＰ）を介してノース・ブリッジ及びメモリ・コントローラ・ハブ２０２に連結することができる。

図示の例において、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２は、サウス・ブリッジ及びＩ／Ｏコントローラ・ハブ２０４に連結されている。オーディオ・アダプタ２１６、キーボード及びマウス・アダプタ２２０、モデム２２２、読取り専用メモリ（ＲＯＭ）２２４、ユニバーサル・シリアル・バス（ＵＳＢ）ポート及び他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４は、バス２３８を介してサウス・ブリッジ及びＩ／Ｏコントローラ・ハブ２０４に連結されており、ハード・ディスク・ドライブ（ＨＤＤ）２２６及びＣＤ−ＲＯＭドライブ２３０は、バス２４０を介してサウス・ブリッジ及びＩ／Ｏコントローラ・ハブ２０４に連結されている。ＰＣＩ／ＰＣＩｅデバイスとしては、例えばイーサネット・アダプタ、アドイン・カード、及びノート型コンピュータ用のＰＣカード等を挙げることができる。ＰＣＩはカード・バス・コントローラを使用する一方、ＰＣＩｅはこれを使用しない。ＲＯＭ２２４は、例えばフラッシュ・バイナリ入力／出力システム（ＢＩＯＳ）等であってもよい。

ハード・ディスク・ドライブ２２６及びＣＤ−ＲＯＭドライブ２３０は、バス２３０を介してサウス・ブリッジ及びＩ／Ｏコントローラ・ハブ２０４に連結されている。ハード・ディスク・ドライブ２２６及びＣＤ−ＲＯＭドライブ２３０は、例えば統合ドライブ・エレクトロニクス（ＩＤＥ）やシリアル・アドバンスト・テクノロジー・アタッチメント（ＳＡＴＡ）・インターフェース等を使用することができる。スーパーＩ／Ｏ（ＳＩＯ）デバイス２３６は、サウス・ブリッジ及びＩ／Ｏコントローラ・ハブ２０４に連結させることができる。オペレーティング・システムは、プロセッサ２０６上で作動して、図２のデ−タ処理システム２００内の様々なコンポーネントの制御を調整し実行するものである。クライアントとしてのオペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）ＸＰのような市販のオペレーティング・システムであってもよい（「Ｍｉｃｒｏｓｏｆｔ」及び「Ｗｉｎｄｏｗｓ」は、マイクロソフト・コーポレーションの米国その他の国、又はその両方における商標である）。Ｊａｖａ（ＴＭ）プログラミング・システムのようなオブジェクト指向のプログラミング・システムは、上記オペレーティング・システムと連動して作動することができ、データ処理システム２００上で実行されているＪａｖａプログラム又はアプリケーションから当該オペレーティング・システムへのコールを行うものである（「Ｊａｖａ」は、サン・マイクロシステムズの米国その他の国、又はその両方における商標である）。

サーバとしてのデータ処理システム２００は、例えば拡張対話式エグゼクティブ（Ａｄｖａｎｃｅｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｅｘｅｃｕｔｉｖｅ：ＡＩＸ（Ｒ））オペレーティング・システム又はＬＩＮＵＸオペレーティング・システムを実行するＩＢＭ ｅＳｅｒｖｅｒ（ＴＭ）ｐＳｅｒｉｅｓ（Ｒ）コンピュータ・システムであってもよい（「ｅＳｅｒｖｅｒ」、「ｐＳｅｒｉｅｓ」、及び「ＡＩＸ」は、インターナショナル・ビジネス・マシーンズ・コーポレーションの米国その他の国、又はその両方における商標であり、「Ｌｉｎｕｘ」は、Ｌｉｎｕｓ Ｔｏｒｖａｌｄｓ氏の米国その他の国、又はその両方における商標である）。データ処理システム２００は、複数のプロセッサを処理ユニット２０６内に含む対称型マルチプロセッサ（ＳＭＰ）システムであってもよい。別法として、シングル・プロセッサ・システムを採用することもできる。

上記オペレーティング・システムに対する命令、上記オブジェクト指向のプログラミング・システム、及びアプリケーション又はプログラムは、ハード・ディスク・ドライブ２２６のような記憶装置上に設置され、処理ユニット２０６による実行のためにメイン・メモリ２０８にロードすることができる。本発明の諸実施形態に関する各処理は、例えばメイン・メモリ２０８や読取り専用メモリ２２４等のメモリ内に設置することも、１つ又は複数の周辺デバイス２２６及び２３０内に設置することもできるコンピュータ使用可能なプログラム・コードを使用して、処理ユニット２０６によって実行される。

図１及び図２のハードウェアは実装形態に応じて変更され得ることが当業者には理解されるだろう。図１及び図２に示されるハードウェアに加えて又はその代わりに、フラッシュ・メモリ又は同等の不揮発性メモリ又は光ディスク・ドライブ等、他の内部ハードウェア又は周辺デバイスを使用することもできる。また、本発明の上記処理は、マルチプロセッサ・データ処理システムにも適用することができる。

いくつかの実例において、データ処理システム２００は、オペレーティング・システム・ファイル又はユーザ生成データあるいはその両方を記憶する不揮発性メモリを提供するフラッシュ・メモリが組み込まれた携帯情報端末（ＰＤＡ）であってもよい。バス・システムは、図２に示されるバス２３８やバス２４０のような１つ又は複数のバスから構成されることもある。言うまでもなく、上記バス・システムは、任意のタイプの通信ファブリック又はアーキテクチャであって、当該ファブリック又はアーキテクチャに取り付けられた様々なコンポーネント又はデバイス間でデータの転送を実施する通信ファブリック又はアーキテクチャを使用して実装することができる。通信ユニットは、図２のモデム２２２やネットワーク・アダプタ２１２等、データの送受信に使用される１つ又は複数のデバイスを含むことができる。メモリは、例えば図２のノース・ブリッジ及びメモリ・コントローラ・ハブ２０２内で見受けられるようなメイン・メモリ２０８、読取り専用メモリ２２４、キャッシュ等であってもよい。図１及び図２に示される例及び上述の実例は、アーキテクチャ上の限定を暗示することを意図しているわけではない。例えば、データ処理システム２００は、ＰＤＡの形式をとることに加えて、タブレット・コンピュータ、ラップトップ・コンピュータ、あるいは電話デバイスであってもよい。

本発明は、データ転送時の使用帯域幅を適応的に制御するコンピュータ実装方法、装置、及びコンピュータ使用可能なプログラム・コードを提供する。本発明の諸態様は、現在使用されている適応型帯域幅制御処理がクライアント側以外のネットワーク状態を加味することができない点を認識している。本発明の諸態様は、様々なネットワークが様々な特性を有することがデータ転送に影響を及ぼす可能性がある点を認識している。本発明の諸態様は、そのようなタイプの要因が加味された様々な機構を提供する。本発明の諸態様は、個々のデータ・パケットを適応型帯域幅制御に使用されるネットワーク上にどのように送出するかを制御するパラメータを設定する能力を提供する。

本発明の諸態様は、現在使用可能なデータ転送システムではバックグラウンド・モードでの実行速度が非常に低速となるため、実行の完了に非常に長い時間を要する可能性があることを認識している。また、本発明の諸態様は、顧客が適応型機能を所望する一方で配信に長い時間を掛けたくない場合が多いことも認識している。例えば、アプリケーションのアップデートに関しては、ウイルス・パッチ又はウイルス・アップデートの配信が非常に重要なものと見なされている。そのため、本発明の諸態様は、配信単位で優先度を設定する能力を提供する。これらの実例では、「高（ｈｉｇｈ）」、「中（ｍｅｄｉｕｍ）」、「低（ｌｏｗ）」の３種類の優先度が設定される。各実例の優先度は、例えば「高」のような選択された優先度に応じて適応型帯域幅制御処理の挙動が変化する、適応型優先度（ａｄａｐｔｉｖｅ ｐｒｉｏｒｉｔｙ）である。例えば、ソフトウェア・アップデートを「低」優先度として送信し、その後ウイルス・パッチを「高」優先度で送信することができる。したがって、該当する配信物（ｄｉｓｔｒｉｂｕｔｉｏｎ）の重要度に基づいて様々な配信物に様々な優先度を与えることが可能となる。配信物毎に優先度が異なるようにすることで、適応型帯域幅制御処理の異なるパラメータ・セットが提供され、当該処理の挙動が選択された特定の優先度に応じて変化することになる。

また、優先度はゲートウェイ単位で様々な形で設定することができる。これらの実例において、ゲートウェイは、１組のデバイスのコンジットとして働くデバイス又はデータ処理システムである。例えば、ゲートウェイは、ローカル・エリア・ネットワーク又は広域ネットワークのポータル又は入口の働きをすることができる。また、ゲートウェイは、無線ネットワークとの間の接続の働きをすることもできる。ゲートウェイは、１組のクライアントを管理するものとして言及されることもある。

各実例はいずれも適応型帯域幅制御を対象としているが、本発明の諸態様は、１つ又は複数のターゲット・データ処理システムへの任意のタイプのバルク・データ転送に適用されてもよい。

ここで図３を参照すると、本発明の例示的な一実施形態に従って様々な優先度を使用して配信を行うことが可能となる例示的なネットワーク・データ処理システムが示されている。本例において、ネットワーク・データ処理システム３００は、ゲートウェイ３０４、３０６、及び３０８に接続されたソース３０２を含む。ゲートウェイ３０４は、ルータ３１８を介したクライアント３１０、３１２、３１４、及び３１６との間の接続を提供する。ゲートウェイ３０６は、衛星ルータ３２８を介したクライアント３２０、３２２、３２４、及び３２６との間の接続を提供する。ゲートウェイ３０８は、クライアント３３０、３３２、３３４、及び３３６との間の接続を提供する。これらの実例において、各クライアントは、無線接続、ダイヤル・アップ接続、ケーブル・モデム、これらに類する他の何らかの接続システム等、様々な手段を介してゲートウェイ３０８に接続される移動ラップトップ・コンピュータである。

ネットワーク３００は、図１のネットワーク・データ処理システム１００内に含まれるネットワークの一例に過ぎない。特に、図２のデータ処理システム２００と同様のデータ処理システムを使用して様々なクライアント及びゲートウェイを実装することが可能である。

本例において、ゲートウェイ３０４は、安全性の高いローカル・エリア・ネットワーク・サーバを管理する。言い換えれば、クライアント３１０、３１２、３１４、及び３１６は、サーバ・データ処理システムである。ゲートウェイ３０６は、様々な支店に所在するＰＯＳ（ｐｏｉｎｔ−ｏｆ−ｓａｌｅ：販売時点）システムを管理する。ゲートウェイ３０８は、移動ラップトップの形をとる各クライアントを管理する。

管理者３３８は、様々な設定を使用して配信物を送信することができる。これらの実例において、配信（ｄｉｓｔｒｉｂｕｔｉｏｎ）とは、任意の種類のデータを１つ又は複数のエンドポイント又は受信機に送信することを指す。そのような配信物は、例えばアプリケーション・アップデート、ダイナミック・リンク・ライブラリ・アップデート、ウイルス・パッチ又はウイルス定義アップデート、あるいはデータ・ファイルであることもある。図３の例において、配信物は３種類の優先度レベル、即ち、「高」、「中」、「低」のうちの１つを使用して送信することができる。言うまでもなく、特定の実装形態に応じてこれ以外の数の優先度レベルを実装することもできる。３つの異なる優先度レベルは、本発明の一実施形態を例示するために採用したものである。

したがって、管理者３３８は、例えばクライアントに配信される１つの配信物に対して「高」のような１つの優先度を付与した上で、当該配信物をゲートウェイ３０４、３０６、及び３０８に送信することができる。次に、管理者３３８は、例えば「中」のような異なる優先度を後続の配信物に付与した上で、当該配信物をゲートウェイ３０４、３０６、及び３０８に送信することができる。このようにして、特定の配信物に関連する重要度に基づいて、受信機への転送に関する様々な優先度を様々な配信物に与えることができる。したがって、重要度の高い配信物ほどクライアント側に到達するタイミングを早めることができるが、このようなタイプの配信では使用する帯域幅が多くなる。優先度の低い配信物ほど使用する帯域幅が少なくなるが、このようなタイプの配信では配信に要する時間が長くなる。

更に、本発明の諸態様は、選択された優先度レベルに応じてゲートウェイ毎に異なる量の帯域幅を使用する能力を、選択される優先度毎に提供する。言い換えれば、２つのゲートウェイが同一のネットワーク状態にあると考えた場合に、それらのゲートウェイは、選択された優先度レベル毎に異なる量の帯域幅を使用してデータ転送を行うことができる。これらの実例では、様々なクライアントに対する配信物の送信を行うゲートウェイ上で実行される適応型帯域幅制御処理のパラメータを調整することによって、選択される優先度レベルの様々な効果がゲートウェイ単位で調整される。

例えば、ゲートウェイ３０４が「高」優先度の配信物をクライアント３１０、３１２、３１４、及び３１６に送信する際は、帯域幅の７０％を使用することができる。ゲートウェイ３０６が「高」優先度の同一の配信物をクライアント３２０、３２２、３２４、及び３２６に転送する際は、帯域幅の５０％を使用することができる。ゲートウェイ３０８が「高」優先度の同一の配信物をクライアント３３０、３３２、３３４、及び３３６に送信する際は、帯域幅の３０％まで使用することができる。

ゲートウェイからアクセスされる特定のネットワーク内の帯域幅使用率に対する実際の影響は、当該ゲートウェイ上で実行される適応型帯域幅制御処理のパラメータを調整することによって調整される。各ゲートウェイは、それらが最初にセット・アップされる時点で事前構成することができる。また、上記の各パラメータは、管理者３３８によって特定されたネットワーク内の変更あるいは他の変更に基づいて変更することもできる。これらの変更は、後述するユーザ定義設定を介して管理することができる。

ここで図４を参照すると、本発明の例示的な一実施形態に係る適応型帯域幅制御で使用される各コンポーネントが示されている。この例では、適応型送信機（ａｄａｐｔｉｖｅ ｓｅｎｄｅｒ）４００がデータを受信機４０２、４０４、及び４０６に送信する。図４の例において、適応型送信機４００は、図３のゲートウェイ３０４のようなゲートウェイとすることができる。特に、適応型送信機４００は、図２のデータ処理システム２００内で見受けられるようなハードウェアを使用する図１のサーバ１０６として実装することができる。受信機４０２、４０４、及び４０６は、図３のクライアント３１０、３１２、３１４のようなクライアントとすることができる。これらの受信機は、図２のデータ処理システム２００のようなデータ処理システムを使用して実装することもできる。データ送信は、パケット４０８をルータ４１０のようなルーティング機構に送信することによって行われる。ルータ４１０は、パケット４０８内で発見された経路指定データに基づいてパケット４０８を該当する受信機に経路指定し又は送信する働きをするデバイスである。ルータ４１０が過剰な数のパケットの処理を強いられる場合、そのようなルータ４１０をバックログ・ルータと呼ぶ。言い換えれば、バックログ・ルータとは、それ自体のキューに所在するパケットのうちで最も負荷の大きいパケット、即ち最大数のパケットを有するルータを指す。送信機と受信機との間にルータが介在する場合もあれば介在しない場合もある。送信機はパケットの送信元であり、受信機は肯定応答の送信元である。各受信機はパケット４０８を受信すると、肯定応答４１２を適応型送信機４００に返す。本例において、肯定応答はＴＣＰ／ＩＰ通信の一部となる。

これらの実例では、適応型送信機４００を図１のサーバ１０４のようなデータ処理システム内の一処理として実施することができる。受信機４０２、４０４、及び４０６は、図１のクライアント１０８、１１０、１１２のような受信デバイス上で実行することが可能な処理である。特に、これらの様々な処理は、図２のデータ処理システム２００のようなデータ処理システム上で実施することができる。

適応型送信機４００は、各受信機に送信されたパケット４０８を追跡する。また、肯定応答４１２の受信も追跡され、この情報はラウンド・トリップ時間等のパラメータを特定するのに使用される。ラウンド・トリップ時間とは、パケットが送信されてから肯定応答が受信されるまでの時間を指す。本例において、ラウンド・トリップ時間は適応型送信機４００の見通しに基づいている。また、この情報はブロックを特定する際にも使用される。ブロックは任意のパケットが送信される時点を開始点とし、例えば、あるブロック内の全てのパケットに関する統計データは、当該ブロックの開始点となった最初のパケットに対する肯定応答が受信機から返されるまで保持される。任意のパケットに対する肯定応答が返されたときに、適応型送信機４００は、複数のパケットから成る当該ブロックを対象とする統計値を計算する。言い換えれば、当該ブロックの開始点に位置する任意のパケットに対する肯定応答が返されるまでにパケットがいくつ送信されたかに応じて、１つ又は複数のパケットをブロック内に所在させることができる。また、適応型送信機４００はウィンドウの特定も行う。ウィンドウとは、肯定応答が受信されるまでにネットワーク内で送信されたパケット数を指す。

更に、適応型送信機４００は、ルータ４１０内に所在するパケット数の推定も行う。当該情報は現在のラウンド・トリップ時間を使用して判定され、これにより、肯定応答が返されないことが予想されたパケット数と、肯定応答が実際に返されなかったパケット数との差が計算される。例えば、現在のラウンド・トリップ時間に照らしてネットワーク上に５つのパケットが存在することが考えられる場合に、８つのパケットの肯定応答が返されていないことが特定された場合、適応型送信機４００は、ルータ４１０上に３つのパケットが所在するものと推定することができる。

適応型送信機４００は、ルータ４１０上の選択されたパケット数を維持しようと試みながら、予想されるウィンドウ・サイズを増減することによって速度を制御する。ウィンドウが大きくなるほどルータ４１０が他のネットワーク・トラフィックの処理よりも適応型パケットの処理に費やす時間が増加するため、大きいウィンドウの方がアグレッシブ（ａｇｇｒｅｓｓｉｖｅ）である。このようにして、適応型送信機４００は、ルータ４１０に関するαパラメータ及びβパラメータを調整することができる。αは、その数に達した時点でウィンドウが１パケット分拡大される、ルータ４１０内の接続単位の最大パケット数を示す整数である。βは、その数に達した時点でウィンドウが１パケット分縮小される、バックログ・ルータ内の接続単位の最大パケット数を示す整数である。これらのパラメータを用いると、ウィンドウをα及びβに基づいて調整することにより速度増減幅を小さくすることが可能となる。別のパラメータ及び閾値を用いると、ブロック内の半数のパケットが当該閾値の条件を満たした時点で速度を減少させることが可能となる。本例において、閾値は、ベース・ラウンド・トリップ時間から最大ラウンド・トリップ時間までの時間に関して構成可能な時間率である。

ここで図５を参照すると、本発明の例示的な一実施形態に係る伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）及び同様のプロトコルが示されている。ＴＣＰ／ＩＰ及び同様のプロトコルは、通信アーキテクチャ５００によって利用される。本例において、通信アーキテクチャ５００は、４レイヤ・システムである。当該アーキテクチャは、アプリケーション・レイヤ５０２と、トランポート・レイヤ５０４と、ネットワーク・レイヤ５０６と、リンク・レイヤ５０８と、を含む。各レイヤは、様々な通信タスクの処理を担当する。リンク・レイヤ５０８は、データ・リンク・レイヤ又はネットワーク・インターフェース・レイヤとも呼ばれ、通常、デバイス・ドライバをオペレーティング・システム内に含み、対応するネットワーク・インターフェースをコンピュータ内に含んでいる。当該レイヤは、使用されている光ケーブルやイーサネット・ケーブル等のネットワーク媒体との物理インターフェースに関する全てのハードウェア詳細を取り扱うレイヤである。

ネットワーク・レイヤ５０６は、インターネット・レイヤとも呼ばれ、ネットワーク中のデータ・パケットの移動を処理するレイヤである。例えば、ネットワーク・レイヤ５０６は、当該ネットワークを介して転送される様々なデータ・パケットの経路指定を処理する。ＴＣＰ／ＩＰスイートのネットワーク・レイヤ５０６は、インターネット・プロトコル（ＩＰ）、インターネット制御メッセージ・プロトコル（ＩＣＭＰ）、及びインターネット・グループ管理プロトコル（ＩＧＭＰ）を含めたいくつかのプロトコルから構成される。

次に、トランポート・レイヤ５０４は、２つのホスト・コンピュータ間のデータ転送を容易にする、ネットワーク・レイヤ５０６とアプリケーション・レイヤ５０２との間のインターフェースを提供する。トランポート・レイヤ５０４は、例えばアプリケーションからそれ自体に渡されたデータを下位のネットワーク・レイヤに適したサイズのチャンクに分割することや、受信パケットの肯定応答を返すこと、送信されたパケットを相手方が受け取ったことを確認するためのタイムアウトを設定すること、等に関与するレイヤである。ＴＣＰ／ＩＰプロトコル・スイートには、明確に異なる２つのトランスポート・プロトコル、即ち、ＴＣＰと、ユーザ・データグラム・プロトコル（ＵＤＰ）とが存在する。ＴＣＰは、ドロップアウト検出及び再送信サービスを含めた信頼性サービスを提供することにより、データが２つのホスト間で適切に伝送されることを保証するものである。

これとは逆に、ＵＤＰは、データが適切に転送されることを保証する機構を何ら提供することなく、単に一方のホストから他方のホストにデータグラムと呼ばれるデータ・パケットを送信するだけという、ＴＣＰよりもずっと単純なサービスをアプリケーション・レイヤに提供するものである。ＵＤＰが使用される場合には、アプリケーション・レイヤは信頼性機能を実行しなければならない。

アプリケーション・レイヤ５０２は、特定のアプリケーションの詳細を取り扱う。ほぼ全ての実装形態に関して、リモート・ログイン向けのＴｅｌｎｅｔ、ファイル転送プロトコル（ＦＴＰ）、電子メール向けの簡易メール転送プロトコル（ＳＭＴＰ）、及び簡易ネットワーク管理プロトコル（ＳＮＭＰ）を含めた多くの一般的なＴＣＰ／ＩＰの応用例が存在する。

本発明の諸態様はアプリケーション・レイヤ５０２において実装され、これにより、ユーザがユーザ設定を入力することができるようにデータ転送を適応的に制御することが可能となる。このようにして、ユーザは様々な設定を変更することにより、適応型帯域幅制御で使用されるネットワーク上にパケットをどのように送出するかを制御することができる。ユーザ設定をアプリケーション・レベルから入力できるようにすることで、ユーザは、様々なタイプのネットワークに変更を施すことができ、また、典型的には適応型帯域幅制御処理で加味されることがない様々なネットワーク状態に変更を施すこともできる。このようにして、クライアント側以外の状態をも加味することが可能となる。例えば、本発明の諸態様を用いると、ユーザは、受信機までの経路内のホップ数や、受信機までの経路内のリンクのうち、トラフィック量が多いリンク又は輻輳状態に陥っているリンク等の各種要因を特定することに基づいて設定を変更することが可能となる。

本発明の各実例はアプリケーション・レベルで実装されているが、他のレイヤに様々な処理を実装することもできる。例えば、本発明の諸態様は、特定の実装形態に応じてトランポート・レイヤ５０４内に実装することもネットワーク・レイヤ５０６内に実装することもできる。

ここで図６を参照すると、本発明の例示的な一実施形態に係る適応型帯域幅制御を実現する際に使用される各ソフトウェア処理及びコンポーネントが示されている。本例において、適応型送信機６００は、図４の適応型送信機４００内の処理を詳細に示したものである。図６の例において、適応型送信機６００は３つのスレッドを含む。送信（ｓｅｎｄ）スレッド６０２、輻輳制御（ｃｏｎｇｅｓｔｉｏｎ ｃｏｎｔｒｏｌ）スレッド６０４、及びパケット・スニッフィング・スレッド（ｐａｃｋｅｔ ｓｎｉｆｆｉｎｇ）６０６はそれぞれ、データを１つ又は複数の受信機に適応的に送信するのに使用されるコンポーネントである。送信スレッド６０２は、ソケット・コールを介してデータを送信するのに使用される。ソケットとは、ＴＣＰ／ＩＰスタック内のＴＣＰ／ＩＰプロトコル等のネットワーク・プロトコルにアプリケーションを接続するソフトウェア・オブジェクトを指す。

送信スレッド６０２は、要求６０８を輻輳制御スレッド６０４に送信して、送信スレッド６０２によって送信可能なデータ量を問い合わせる。輻輳制御スレッド６０４は、応答６１０を返すことによって送信可能なデータ量を知らせる。送信スレッド６０２は、応答６１０を使用して送信対象のパケット６１２を送信する。これらの各パケットは、バックログ・ルータによってそれぞれの宛先に経路指定されるまでバックログ・ルータ・キュー６１４に格納される。バックログ・ルータ・キュー６１４は、図４のルータ４１０のようなバックログ・ルータ上に所在する。各パケットが受信されたときは肯定応答６１６が適応型送信機６００に返される。

輻輳制御スレッド６０４は、適応型帯域幅制御処理を実行することによって送信すべきデータ量を特定する。これらの実例において、輻輳制御スレッド６０４は、ネットワーク状態の変化に応じて適応型帯域幅制御処理を使用して、ネットワークを介したデータ・パケット伝送の伝送レートを適応的に特定する。これらのネットワーク状態としては、例えば適応型送信機によって処理されているデータ送信ならびに他の様々なデータ送信に起因する、ネットワーク上の輻輳量が挙げられる。言い換えれば、データ送信を行うことが可能な転送速度は、ネットワーク状態に応じて変化する。輻輳制御スレッド６０４は、ユーザによって設定される様々なパラメータに基づいて、ネットワークへの影響を最小限に抑えるために加減される様々な転送速度を特定する。

以下ではネットワーク状態の一例を図７を使用して説明する。ＦＴＰサーバ７５２がデータをＦＴＰクライアント７５４に送信する前は、ルータ７４６はアイドル状態にある。この状況下では、適応型送信機７００が非常に高い転送速度で受信機又はエンドポイントへの送信を行うことが可能である。しかしながら、ＦＴＰサーバ７５２がＦＴＰクライアント７５４へのデータ送信を開始するとすぐに、ルータ７４６がデータで氾濫してしまう。その後、適応型帯域幅制御処理では、データの優先度に応じてこの状況に対処する。「低」優先度の場合には、適応型帯域幅制御処理の速度は殆ど送信を行うことができない程度まで低下し、これによってＦＴＰ配信への影響が最小限に抑えられる。「高」優先度の場合には、適応型帯域幅制御処理の速度が大幅に増加するが、それによってＦＴＰ配信の速度は低下することになる。

以下では、適応型配信（ａｄａｐｔｉｖｅ ｄｉｓｔｒｉｂｕｔｉｏｎ）によってネットワーク状態に対処するための別の手法を例示する。ある銀行は、当該銀行内の１０個のシステムを対象としたネットワーク接続を管理する単一のルータを含んでいる。当該銀行は、当該ルータを介してセントラル・サイト（全国の３００店の銀行を管理する）に接続されている。午前６時（当該銀行の営業開始時間前）の時点では銀行内に誰もおらず、ネットワーク（特に当該銀行の単一のルータ）はアイドル状態にある。この時間に、セントラル・サイトからは大容量の適応型配信物が「低」優先度で送信される。この配信物のトラフィックは当該銀行のルータ上に限られるため、配信速度はルータの帯域幅の１００％まで高められる。この配信は、顧客が当該銀行のＡＴＭ及び融資業務システム（ｌｏａｎ ｐｒｏｃｅｓｓｉｎｇ ｓｙｓｔｅｍ）の使用を開始することに伴って単一のルータとのネットワーク共有が発生することになる午前８時まで続けられる。適応型配信では、低速リンク（このシナリオでは当該銀行のルータ）を横切る追加的なトラフィックの存在が直ちに認識される。本例の適応型配信は「低」優先度で行われているため、適応型配信の速度をルータの非常に少ないパーセンテージだけを使用するように低下させることで、ＡＴＭ及び融資業務トラフィックへの影響が最小限に抑えられる。本例の適応型配信は午後５時の時点でもまだ続けられる。融資業務トラフィックは当該銀行の営業終了と同時に減少する。本例の適応型配信でネットワーク負荷の減少が感知されると、より多くの帯域幅が使用可能となることから配信速度も増加することになる。

再び図６を参照すると、上記の処理はキュー６１８内に所在する情報を使用して行われる。特に、パケット・スニッフィング・スレッド６０６は、ネットワークからのパケット及び肯定応答をグラブし、パケット情報６２０及び肯定応答情報６２２をキュー６１８に入れる。パケット・スニッフィング・スレッド６０６は、パケット及び肯定応答のフィルタリングを行って輻輳制御スレッド６０４から必要とされている適切なデータをキュー６１８に入れる。別法として、輻輳制御スレッド６０４による処理のために全てのパケット及び肯定応答をキュー６１８に入れることもできる。キュー６１８内の情報は、パケットが送信されてから当該パケットの肯定応答が受信されるまでのラウンド・トリップ時間のようなパラメータを特定するために輻輳制御スレッド６０４によって使用される。キュー６１８内の情報から輻輳制御スレッド６０４によって特定され維持され得る他のパラメータとしては、ブロック、ウィンドウ、及びバックログ・ルータ内のパケットが挙げられる。

更に、本発明の諸態様は、ユーザ定義パラメータ６２６を設定するのに使用され得るユーザ・インターフェース６２４も含む。ユーザ・インターフェース６２４は、パラメータ・スレッド６２８によって提供される。典型的には、各パラメータのセット・アップは、適応型処理がシステム上で最初にセット・アップされるときに行われる。これらのパラメータは、ユーザ・インターフェース６２４及びパラメータ・スレッド６２８を介して変更することができる。ユーザ定義パラメータ６２６は、ディスク等の不揮発性メモリに記憶される。当該パラメータは、後に適応型帯域幅処理が開始されるときに読み出すことができる。図６の例において、当該パラメータは、優先度毎に値が異なるパラメータ・セットを含む。これらの実例において、配信物の優先度レベルに基づいて変更される各パラメータ・セットは、閾値、データ、及び最大待ち時間である。ユーザは優先度レベル毎に異なる値を入力することができるが、適応型送信機６００によって使用されるパラメータを直接設定することもできる。ユーザ・インターフェース６２４を用いると、ユーザは、適応型帯域幅制御処理を実行する際に輻輳制御スレッド６０４によって使用される様々なパラメータを選択し、入力することが可能となる。

これらの実例において、本発明の諸態様は、５つのパラメータの値を入力又は選択することを可能にする。これらの５つのパラメータは、閾値、ラウンド・トリップ時間の最大変化（ｒｏｕｎｄ ｔｒｉｐ ｔｉｍｅ ｍａｘｉｍｕｍ ｃｈａｎｇｅ）、β、ラウンド・トリップ時間の平滑化（ｒｏｕｎｄ ｔｒｉｐ ｔｉｍｅ ｓｍｏｏｔｈｉｎｇ）、及び最大待ち時間に関するパラメータを含む。ラウンド・トリップ時間の最大変化は、事前に測定されたラウンド・トリップ時間と比較して、現時点で測定されるラウンド・トリップ時間の変化量を制限するのに使用されるパラメータである。この処理では、現在のラウンド・トリップ時間、最大ラウンド・トリップ時間、及びベース・ラウンド・トリップ時間が追跡される。

輻輳制御スレッド６０４は、ラウンド・トリップ時間をソケット単位で連続的に追跡する。１つ目のパケットのラウンド・トリップ時間を「１０」とし、２つ目のパケットのラウンド・トリップ時間を「２０」とした場合、当該２つ目のパケットのラウンド・トリップ時間は、ラウンド・トリップ時間の最大変化の値「１．５」によって制限される。実際のラウンド・トリップ時間が「２０」であっても、ラウンド・トリップ時間の値は「１５」（１０×１．５）として記録される。その後、後続のパケットのラウンド・トリップ時間は、最大で１．５×１５（第２のパケットに関して記録されたラウンド・トリップ時間）となる。

ネットワークは、典型的にはある程度のランダム性を有する。当該パラメータを用いると、過剰に大きい又は過剰に小さいラウンド・トリップ時間を適応型帯域幅制御処理で無視することが可能となる一方で、大きいラウンド・トリップ時間が十分に高い頻度で発生する場合には、それらを許容することも可能となる。当該パラメータを用いると、ユーザは許容される変更の程度を構成することが可能となる。

これらの実例におけるラウンド・トリップ時間の平滑化パラメータは、ラウンド・トリップ時間の測定値を指数関数的減衰によってどの程度平滑化すべきかを示す上で使用される整数である。指数関数的減衰は、事前測定値の平均をとることによって実行される。当該パラメータは、ラウンド・トリップ時間の変動の過補償によって適応型帯域幅制御処理が不規則な挙動を示す場合に役立つ可能性がある。平滑化は、典型的には最大変更パラメータが加味される前に行われる。

最大待ち時間は、接続を断念して再設定を行う前に当該接続が送信待機状態におかれるラウンド・トリップ時間が、最大ラウンド・トリップ時間の何倍に相当するかを示すパラメータである。肯定応答はネットワーク上で失われることがあり、それによって送信機が追加的なデータを送信するまでに長時間待たされることもある。リセット値は、データが送信されるまでに時間が掛かりすぎた場合に適応型帯域幅制御処理をリセットする値である。その閾値パラメータに関しては、パケットのラウンド・トリップ時間がソケット上に送信される場合、当該ラウンド・トリップ時間は選択された範囲内に収まる傾向がある。この状況は特にネットワークがアイドル状態にあるときにあてはまる。

当該閾値は、最小ラウンド・トリップ時間と最大ラウンド・トリップ時間との差のパーセンテージである。例えば、閾値が２０パーセントであれば、当該閾値によって、ベース・ラウンド・トリップ時間と最大ラウンド・トリップ時間との差が２０パーセントであることが示される。ラウンド・トリップ時間は、ネットワークのタイプに応じて変動が大きくなることも小さくなることもある。典型的には、様々な変動によって様々な閾値の値が必要となる。例えば、良好な挙動のローカル・エリア・ネットワークのラウンド・トリップ時間の変動は非常に小さく、その結果閾値の値を低くすることが可能となる。これに比べ、広域ネットワークのラウンド・トリップ時間の変動は大きい。このタイプのネットワークでは、より高い閾値が必要とされる。このような特定のパラメータは、データ送信の際に遭遇する可能性がある様々なタイプのネットワークを加味するようにユーザ構成可能なパラメータである。その閾値パラメータに関しては、パケットのラウンド・トリップ時間がソケット上に送信される場合、当該ラウンド・トリップ時間は選択された範囲内に収まる傾向がある。この状況は特にネットワークがアイドル状態にあるときにあてはまる。

パケットのラウンド・トリップ時間が閾値の値よりも低速である場合には、当該パケットは低速と見なされる。ブロック内のパケットの５０％が低速と見なされた場合には、ウィンドウを半分に分割することによって配信速度を大幅に減少させることができる。したがって、上記の閾値の値に関するユーザ構成を可能にすることによって、様々なネットワーク・タイプ及びネットワーク状態を加味することが可能となる。

本発明の諸態様は、各実例の３つのパラメータを修正することによって優先度を変更する。各実例において、優先度毎に修正されるパラメータは、閾値、β、及び最大待ち時間である。

ここで図７を参照すると、本発明の例示的な一実施形態に係る優先度を使用して、配信物を適応型送信機から受信機に送信するネットワークが示されている。本例において、適応型送信機７００は、ネットワーク７０２を介してクライアント７０４、７０６、７０８、７１０、７１２、７１４、７１６、７１８、７２０、７２２、７２４、７２６、７２８、７３０、７３２、７３４、７３６、７３８、７４０、及び７４２に配信物を送信する。７５０、７４８、７４６、及び７４４はルータであり、７４６はバックログ・ルータである。上記の各クライアントはルータ７４４に接続され、ルータ７４４はルータ７４６に接続されている。ルータ７４６はルータ７４８に接続されている。適応型送信機７００は、サーバ７５０を介してネットワーク７０２に接続されている。本例において、ネットワーク７０２は２０回のホップを含む。ファイル転送プロトコル（ＦＴＰ）サーバ７５２は、配信物と共にデータをＦＴＰクライアント７５４に送信することもできる。本例において、ＦＴＰサーバ７５２は、配信物が適応型送信機７００から各クライアントに送信されている間に、データをＦＴＰクライアント７５４に送信する。本実例では、ＦＴＰサーバによって高需要のトラフィックが生成され、その結果、ルータ７４６のリンクが氾濫することになる。優先度を設定することにより、適応型送信機７００は、配信物を各クライアントに送信する際に様々な帯域幅量を使用することができるようになる。

ここで図８を参照すると、本発明の例示的な一実施形態に係るネットワーク内の帯域幅使用率が示されている。図８のグラフは、図７に示されるようなネットワークのデータ転送で使用されるネットワーク帯域幅のパーセンテージを示している。本例において、線８０２は、様々なタイプの配信に使用される帯域幅量を示している。セクション８０４では、図７のＦＴＰサーバ７５２からＦＴＰクライアント７５４へのＦＴＰ転送だけが示されている。この配信では帯域幅の１００％が使用されている。図７の適応型送信機７００から各クライアントへの配信に関して「低」優先度設定が用いられる場合には、図７のルータ７４４は、セクション８０６に示されるように帯域幅の約８０％をＦＴＰ転送用に割り当てる。「中」優先度が用いられる場合には、セクション８０８に示されるように帯域幅の約５０％がＦＴＰ転送に使用される。図示のとおり、優先度が高くなるほど適応型送信機による配信に対して割り当てられる帯域幅が増加するため、ＦＴＰ転送に割り当てられる帯域幅は減少する。セクション８１０では、各クライアントへの配信に「高」優先度が与えられる。図示のとおり、ここでのＦＴＰ転送は、帯域幅の３０％前後のレベルにまで落ち込んでいる。セクション８１２では、適応型帯域幅制御処理が使用されていない。したがって、この特定のセクションでは本明細書に記載の輻輳制御が使用されないことになる。

ここで図９を参照すると、本発明の例示的な一実施形態に従ってパラメータに関するユーザ設定を構成する処理のフローチャートが示されている。図９に示される処理は、図６のパラメータ・スレッド６２８において実行することができる。この処理を使用すると、ユーザは、適応型帯域幅制御で使用されるパラメータを定義又は変更することが可能となる。これらの実例において、パラメータは、閾値、ラウンド・トリップ時間の最大変化、ラウンド・トリップ時間の平滑化、最大待ち時間、及びβである。特に、図９に示される処理は、「高」、「中」、「低」等の様々な優先度レベルで使用される様々なゲートウェイに関するパラメータを設定するのに使用することができる。これらの実例において、「高」優先度ではβを「７」に、閾値を「９９」に、最大待ち時間を「２０」に設定することができる。「中」優先度ではベータを「５」に、閾値を「４０」に、最大待ち時間を「３０」に設定することができる。「低」優先度ではβを「３」に、閾値を「２５」に、最大待ち時間を「４０」に設定することができる。これらの特定の設定は、それぞれの優先度レベルに応じて使用される。各設定は、提供されるユーザ・インターフェースを介して設定することができる。

更に、本発明の諸態様では、各実例におけるいずれかのルータ又はサーバあるいはゲートウェイからエンドポイントに対する影響も加味される。このような能力は、適応型帯域幅制御処理でラウンド・トリップ時間を使用することによって実現される。

図９の処理は、ユーザ設定を提示することから開始する（ステップ９００）。これらの設定は、図６のユーザ・インターフェース６２４のようなユーザ・インターフェース内で提示することができる。その後、ユーザ入力が受信され（ステップ９０２）、当該ユーザ入力によってパラメータ設定が変更されたかどうかが判定される（ステップ９０４）。当該ユーザ入力によって設定が変更されている場合には、古い設定が新しい設定に置き換えられる（ステップ９０６）。その後、ステップ９００に戻って各設定がユーザに提示される。

再びステップ９０４を参照すると、ユーザ入力によって設定が変更されていない場合には、当該ユーザ入力がユーザ設定の変更処理を終了するものであるかどうかが判定される（ステップ９０８）。当該ユーザ入力が変更処理を終了するものである場合には、ステップ９００に戻る。そうでない場合には、各ユーザ設定が保存された後（ステップ９１０）、図９の処理は終了する。これらの実例において、各設定は図６のユーザ定義パラメータ６２６として保存される。

次に図１０を参照すると、本発明の例示的な一実施形態に係る送信スレッドの処理に関するフローチャートが示されている。図１０に示される処理は、図６の送信スレッド６０２のような送信スレッドにおいて実行することができる。

図１０の処理は、輻輳制御スレッド６０４に送信可能なデータ量の確認要求を送信することから開始する（ステップ１０００）。その後、応答が受信される（ステップ１００２）。当該応答は、輻輳制御スレッドによって実行される適応型帯域幅制御処理の結果として送信可能なデータ量を含む。当該応答が受信されたことに応じて、許容可能なデータ量だけを送信するよう求めるコールがソケットに対して送信される（ステップ１００４）。その後、送信すべきデータがそれ以上存在するかどうかが判定される（ステップ１００６）。データが存在する場合には、ステップ１０００に戻る。データが存在しない場合には、図１０の処理は終了する。

次に図１１を参照すると、本発明の例示的な一実施形態に係るパケット・スニッフィング・スレッドの処理に関するフローチャートが示されている。図１１に示される処理は、図６のパケット・スニッフィング・スレッド６０６において実行することができる。

図１１の処理は、パケットが検出されたかどうかを判定することから開始する（ステップ１１００）。パケットが検出された場合には、当該パケットからパケット識別子及びタイムスタンプが抽出される（ステップ１１０２）。その後、当該データがキューに格納される（ステップ１１０４）。当該キューは、輻輳制御スレッドがラウンド・トリップ時間を判定し適応型帯域幅制御処理を実行する際に上記データを使用することができるように、輻輳制御スレッドからアクセス可能な状態になっている。

再びステップ１１００を参照すると、パケットが検出されない場合には、肯定応答が検出されたかどうかが判定される（ステップ１１０６）。肯定応答が検出されない場合には、ステップ１１００に戻る。ステップ１１０６で肯定応答が検出された場合には、当該肯定応答のパケット識別子及びタイムスタンプが抽出される（ステップ１１０８）。その後、上述のステップ１１０４に進む。

ここで図１２を参照すると、本発明の例示的な一実施形態に係る輻輳制御スレッドの処理に関するフローチャートが示されている。本例において、図１２に示される処理は、図６の輻輳制御スレッド６０４において実行することができる。図１２の処理は、送信スレッドから要求を受信することから開始する（ステップ１２００）。これらの実例において、輻輳制御スレッドによって使用される適応制御処理は、ゲートウェイ内に所在する。各ゲートウェイは個別に、各優先度について使用される様々なパラメータの値を有する。送信スレッドは配信物の送信を開始する際、各値と共に現在の配信優先度を輻輳制御スレッドに引き渡す。輻輳制御スレッドは、現在の配信優先度に対応する値を使用する。この情報は、配信物の送信要求が最初に行われるステップ１２００で受信することができる。当該要求は、送信可能なデータ量の特定を要求するものである。その後、データがキューからプルされる（ステップ１２０２）。このデータには到達時間及びパケット識別子が含まれる。その後、キュー内のデータからラウンド・トリップ時間が特定される（ステップ１２０４）。次に、配信の優先度に基づいてパラメータが取得される（ステップ１２０６）。これらのパラメータは、図６のユーザ定義パラメータ６２６に由来するものである。特に、ユーザ定義パラメータは、選択された優先度に関連する特定のパラメータ・セットに関するパラメータである。これらの実例において、優先度毎に様々な設定を有するパラメータは、β、閾値、及び最大待ち時間である。その後、適応型帯域幅制御処理が実行される（ステップ１２０８）。この処理は、例えば輻輳制御スレッドに含まれるステップとしてもよい。別法として、輻輳制御スレッドは、ステップ１２０８で関数又は外部プロセスをコールすることもできる。その後、結果が取得され（ステップ１２１０）、送信可能なデータ量と共に応答が返された後（ステップ１２１２）、図１２の処理は終了する。

次に図１３を参照すると、本発明の例示的な一実施形態に係る適応型帯域幅制御を実行する処理のフローチャートが示されている。図１３に示される処理は、図１２のステップ１２０８をより詳細に説明するものである。

図１３の処理は、最小ラウンド・トリップ時間及び最大ラウンド・トリップ時間を特定することから開始する（ステップ１３００）。その後、ウィンドウが特定される（ステップ１３０２）。その後、閾値を上回るパケット数及び閾値を下回るパケット数が肯定応答単位で特定される（ステップ１３０４）。次に、ブロック内のパケットの５０％が閾値を上回るかどうかが判定される（ステップ１３０６）。ブロック内のパケットの５０％が閾値を上回っていない場合には、予想スループットが計算される（ステップ１３０８）。ステップ１３０８において、予想スループットは以下のように計算される。
Ｅ ← Ｗ／ｍｉｎＲＴＴ

Ｅは予想スループット、Ｗはウィンドウであり、ｍｉｎＲＴＴは、当該キューから取得されるラウンド・トリップ時間から見た最小ラウンド・トリップ時間である。その後、実際のスループットが特定される（ステップ１３１０）。実際のスループットは以下の式を使用して特定される。
Ａ ← Ｗ／ｏｂｓｅｒｖｅｄＲＴＴ

Ａは実際のスループット、Ｗはウィンドウであり、ｏｂｓｅｒｖｅｄＲＴＴは、パケットが送信された時点と肯定応答が受信された時点との時間差を使用して測定される値である。したがって、アイドル状態のネットワークでは最小ラウンド・トリップ時間が常にパケットの送信結果となることが予想されるため、予想スループットは最小ラウンド・トリップ時間に基づくものとなる。実際のスループットは、現在ラウンド・トリップ時間が最小ラウンド・トリップ時間よりも大きくなる現在のネットワーク状態に基づくものとなる。これらの実例において、最小ラウンド・トリップ時間は、ベース・ラウンド・トリップ時間と同一である。次に、バックログ・ルータ上のパケット数が計算される（ステップ１３１２）。実際のパケット数は以下の式を使用して推定される。
Ｄｉｆｆ ←（Ｅ−Ａ）●ｍｉｎＲＴＴ

Ｄｉｆｆはバックログ・ルータ上のパケット数、Ｅは予想スループット、Ａは実際のスループット、ｍｉｎＲＴＴは認められる最小ラウンド・トリップ時間である。

次に、バックログ・ルータ上のパケット数がαよりも小さいかどうかが判定される（ステップ１３１４）。上述のように、αは、ウィンドウがパケット１つ分増加する前にバックログ・ルータ内に存在するはずの、接続単位のパケット数を示す整数である。バックログ・ルータ上のパケット数がαよりも小さい場合には、ウィンドウが１つ増分される（ステップ１３２２）。その後、ウィンドウ・サイズを上限としてデータ送信が可能であることが指示され（ステップ１３１８）、その後処理は終了する。

再びステップ１３１４を参照し、バックログ・ルータ上のパケット数がα以上である場合には、パケット数がβよりも大きいかどうかが判定される（ステップ１３１６）。パケット数がβよりも大きい場合には、ウィンドウ・サイズが１つ減分される（ステップ１３２４）。その後上述のステップ１３１８に進む。パケット数がβを超えていない場合には、ウィンドウ・サイズの変更を行わずにステップ１３１８に進む。

ステップ１３０６に戻り、ブロック内のパケットの５０％が閾値を上回っている場合には、ウィンドウ・サイズが半分に縮小される（ステップ１３２０）。その後上述のステップ１３１８に進む。

図１３に示した上記の処理は、Ｖｅｎｋａｔａｒａｍａｎｉ等の「ＴＣＰ Ｎｉｃｅ： Ａ Ｍｅｃｈａｎｉｓｍ ｆｏｒ Ｂａｃｋｇｒｏｕｎｄ Ｔｒａｎｓｆｅｒｓ」、ＡＣＭ ＳＩＧＯＰＳ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｒｅｖｉｅｗ、Ｖｏｌ．３６、Ｉｓｓｕｅ ＳＩ Ｗｉｎｔｅｒ ２００２、１〜１５頁に記載されているＮｉｃｅアルゴリズム等、現在利用可能な各種帯域幅制御アルゴリズムの修正版に基づいている。

本発明の諸態様では、図１３に記載される適応型帯域幅制御処理の実行に関与するいくつかのパラメータが特定されている。各パラメータとそれらに関する説明とを以下に列挙する。

ＮＩＣＥ＿ＡＬＰＨＡ：ウィンドウが増加する前の、バックログ・ルータ内の接続単位の最小パケット数を示す整数。デフォルトは「１」である。
ＮＩＣＥ＿ＢＡＳＥ＿ＤＩＳＣＡＲＤ：接続単位で廃棄を行うべき当初ベースＲＴＴ測定数を示す整数。これは、配信が最初に開始された時点でネットワークがまだ飽和状態にない場合には、当初過剰に低いベースＲＴＴ測定値が発生し得ることに依拠する。デフォルトは「３」である。

ＮＩＣＥ＿ＢＡＳＥ＿ＳＣＡＬＥ：Ｎｉｃｅによって維持されるグローバル最小ＲＴＴ（ｖ＿ｂａｓｅＲＴＴ）に適用される倍率を指定する浮動小数点数である。このパラメータを１．１のような小さい正数に設定すると、ネットワークが非定型の短いＲＴＴを許可する場合に役立つ可能性がある。デフォルトは「０．０」である。

ＮＩＣＥ＿ＢＥＬＯＷ＿ＯＮＥ：低いウィンドウについて接続をアイドル状態にすることが可能な最大ＲＴＴ数に相当するｖ＿ｃｗｎｄ＿ｂｅｌｏｗ＿ｏｎｅの下限を示す整数。デフォルトは「４８」である。

ＮＩＣＥ＿ＢＥＴＡ：ウィンドウが減少する前の、バックログ・ルータ内の接続単位の最大パケット数を示す整数。この値はβのデフォルト値である。デフォルトは優先度に基づく。

ＮＩＣＥ＿ＣＬＡＭＰ：このパラメータが設定されると、ウィンドウ・サイズのクランプ（ｓｎｄ＿ｃｗｎｄ）は、現時点でネットワーク内に所在するパケット数よりも大きいパケット数の「４」を超えないように制限される。デフォルトは設定済みである。

ＮＩＣＥ＿ＣＯＮＤ：このパラメータが設定されると、送信スレッドは、任意の時間待機する代わりに、ａｃｋスレッドによってシグナリングされる状態で待機する。デフォルトは未設定である。

ＮＩＣＥ＿ＣＯＮＧ＿ＲＴＸ＿Ｑ：このパラメータが設定されると、ｃｏｎｇ拡張スレッドは、各発信パケットの推定値をｒｔｘ＿ｑに更新する。ｒｔｘ＿ｑは、ＲＴＴの計算に使用される。ｃｏｎｇスレッドには、発信時間の推定が正確であるという利点があるが、パケットをドロップする可能性がある。デフォルトは設定済みである。

ＮＩＣＥ＿ＤＹＮＡＭＩＣ＿ＭＳＳ：このパラメータが設定されると、適応型帯域幅制御処理は、低いＭＳＳ値から開始され、より大きいＭＳＳを有する発信パケットのスニッフィングが行われるたびに、当該ＭＳＳ値を増分させる。このようにして、ＭＳＳは、接続に使用されるＭＳＳに急速に近付くことになる。デフォルトは設定済みである。

ＮＩＣＥ＿ＦＡＳＴ：各適応型帯域幅制御処理ソケットが高速始動フェーズに入るミリ秒数を指定する整数。高速始動フェーズが長くなるほど、ｍａｘＲＴＴの推定値は正確になる。ただし、このパラメータを大きい値に設定すると、その期間の間適応型帯域幅制御処理が効果的にディセーブルされることになる。デフォルトは「５０００」即ち「５秒」である。

ＮＩＣＥ＿ＦＡＳＴ＿ＲＥＴＵＲＮ：このパラメータが設定されると、高速始動フェーズは、ＥＷＯＵＬＤＢＬＯＣＫエラーによってｓｅｎｄ（）が最初に失敗したときに終了する。これによって、ソケットの発信キューが非常に早い段階で一杯になることからゲートウェイの足かせとなる高速始動モードに費やされる時間が、最小限に抑えられることになる。デフォルトは設定済みである。

ＮＩＣＥ＿ＩＮＴＥＲＦＡＣＥ：Ｎｉｃｅによって使用されることになるインターフェース（ネットワーク・カード識別子）である。適応型帯域幅制御処理では、この時点で正しいインターフェースを動的に判定することはできない。したがって、インターフェースが最初のアクティブ・インターフェースでない場合には、インターフェースを手動で設定する必要がある。典型的には、このインターフェースは「ｅｔｈ１」等に設定されることになる。デフォルトは未設定である。

ＮＩＣＥ＿ＭＡＸ＿ＭＵＬＴ：ｍａｘＲＴＴの最小値をベースＲＴＴの倍数として指定する浮動小数点数である。この浮動小数点数が設定されると、ｍａｘＲＴＴ値が過剰に低くなることを防止するとともに、それに付随して生じる傾向がある低スループットの発生を防止するにも役立つ。デフォルトは「０．０」である。

ＮＩＣＥ＿ＭＩＮ＿ＭＳＳ：使用すべき最小ＭＳＳを示す整数。効率化のために、オペレーティング・システムから提供される値のうちこのパラメータよりも低くなる値は、ＮＩＣＥ＿ＤＥＦＡＵＬＴ＿ＭＳＳを優先して無視される。デフォルトは「１０００」である。

ＮＩＣＥ＿ＭＩＮ＿ＰＡＣＫＥＴ：一度に送信すべき最小データ量を指定する整数。このパラメータは、ｏｋ＿ｔｏ＿ｓｅｎｄが指定値よりも小さい場合はそれ自体が０に設定される点でＮＩＣＥ＿ＭＩＮ＿ＳＥＮＤと異なる。これは、輻輳制御スレッドが送信スレッドに対して１バイトのような非常に小さい値を送信するよう指令し続けるような状況を回避するためである。この値を１０に設定すれば、輻輳制御スレッドは、少なくとも１０バイトが送信可能な状態になるまで待機する（計算結果が１０になるまで０を返す）ことになる。デフォルトは「０」である。

ＮＩＣＥ＿ＭＩＮ＿ＳＥＮＤ：ｏｋ＿ｔｏ＿ｓｅｎｄの最小値を指定する整数。つまり、輻輳制御スレッドは常に、送信スレッドに対して少なくともこのパラメータのデータ量を送信するように指令する。このパラメータを１０に設定すれば、適応型計算によって３が指定されている場合でも、輻輳制御スレッドからは１０が返されることになる。デフォルトは「０」である。

ＮＩＣＥ＿ＮＡＮＯ＿ＦＩＸＥＤ：内部コールバック関数、即ちｓｅｌｅｃｔ＿ｄｅｌａｙ（）の使用時に当該関数をスリープ状態にすべきマイクロ秒数を指定する整数。

ＮＩＣＥ＿ＮＡＮＯ＿ＦＩＸＥＤは、コールバックがｓｅｌｅｃｔ＿ｄｅｌａｙ（）以外のものに設定されたときは無効となる。このパラメータが設定されない場合には、最終ブロックのスループットによって示される（最終ブロックにおける最速パケットのＲＴＴ及び当該ブロックのサイズによって判定される）、パケットを送信するのに十分なスペースが設けられるまでにどれほどの時間が掛かるかに基づいて、遅延が動的に計算される。このパラメータが１２３４に設定された場合には、ｎａｎｏｓｌｅｅｐ（）のコールは行われない。このパラメータが設定されない場合には、遅延が動的に計算される。このパラメータが０に設定された場合には、ｎａｎｏｓｌｅｅｐ（）が０の値でコールされ、いくつかのシステム上で１０ミリ秒程度の遅延が存在する可能性がある。このパラメータが１２３４に設定された場合には、ｎａｎｏｓｌｅｅｐ（）のコールは行わない。その他の場合には、指定のマイクロ秒数（デフォルト＝０）でｎａｎｏｓｌｅｅｐ（）をコールする。

ＮＩＣＥ＿ＰＣＡＰ＿ＴＩＭＥＯＵＴ：収集されたパケットのリストが取得されるまでオペレーティング・システムが待機する時間を示す整数。Ｌｉｎｕｘシステムは待機時間に関わらず１つのパケットが使用可能になるまで待機するだけであるため、この変数はＬｉｎｕｘシステムでは効果がない。この変数が有効となるＳｏｌａｒｉｓのようなシステムでは、タイムアウトが低く設定されたときは正確なＲＴＴが得られるが、ネットワークがアイドル状態にあるときはＣＰＵ時間が浪費されるというトレード・オフが存在する。デフォルトは「１０ミリ秒」（Ｓｏｌａｒｉｓでサポートされる最小値）である。

ＮＩＣＥ＿ＱＵＥＵＥ＿ＬＩＭＩＴ：ｃｏｎｇスレッドから読み出されたスニッフィング・スレッドによって書き込まれるパケット・キューの最大長を指定する整数である。キューが長くなるほど当該キュー内のパケットの移動時間が長くなり、それによってｃｏｎｇスレッドの処理対象となる情報の到着に遅延が生じるため、Ｎｉｃｅの応答性は低くなる。デフォルトは「１０」である。

ＮＩＣＥ＿ＲＴＴ＿ＭＡＸ＿ＣＨＡＮＧＥ：ベースＲＴＴ及び最大ＲＴＴについて、それぞれの事前値に対して変更を行うことが可能な最大量を示す整数。このパラメータが設定されると、適応型帯域幅制御処理におけるスプリアス性の極端なＲＴＴ値に対する耐性が向上することになる。デフォルトは「１．５」である。

ＮＩＣＥ＿ＲＴＴ＿ＭＩＮ＿ＳＴＤＳ：ベースＲＴＴを上回る最小標準偏差数を示す整数。ＲＴＴは、ベースＲＴＴを上回るものと見なされる必要がある。デフォルトは「０」である。

ＮＩＣＥ＿ＲＴＴ＿ＳＭＯＯＴＨＩＮＧ：ＲＴＴ（ラウンド・トリップ時間）測定を指数関数的減衰によってどの程度平滑化すべきかを示す整数。指数関数的減衰は、事前測定値の平均をとることによって行われる。このパラメータを設定すると、ＲＴＴの各変動の過補償によってＮｉｃｅが不規則な挙動を示す場合に役立つ可能性がある。デフォルトは「５０」である。

ＮＩＣＥ＿ＲＴＴ＿ＳＴＤ＿ＳＭＯＯＴＨ：ＮＩＣＥ＿ＲＴＴ＿ＳＭＯＯＴＨＩＮＧと同様であるが、標準偏差に関する整数である。標準偏差は、最近の（ｒｅｃｅｎｔ）ＲＴＴ測定値の加重平均値に基づくものとなる。デフォルトは「０」である。

ＮＩＣＥ＿ＳＥＮＤ＿ＲＴＸ＿Ｑ：このパラメータが設定されると、送信スレッドは、各発信パケットの推定値を追加し、又は当該推定値をＲＴＴの計算に使用されるｒｔｘ＿ｑに更新する。送信スレッドにはパケットがドロップされないという利点があるが、当該スレッドによる発信時間の推定値が不正確となる可能性がある。デフォルトは設定済みである。

ＮＩＣＥ＿ＴＨＲＯＵＧＨＰＵＴ＿ＡＶＧ：最新の（ｍｏｓｔ ｒｅｃｅｎｔ）パケットをスループット計算にいくつ含めるべきかを示す整数。この値を大きくするほどスループット計算の正確さが向上するが、その代償として応答性が低下することになる。デフォルトは「２０」である。

ＮＩＣＥ＿ＴＨＲＯＵＧＨＰＵＴ＿ＳＴＡＲＴ：スループット計算が開始される前に送信しなければならない最小パケット数を示す整数。このパラメータでは当初空状態にあった低速リンク・キューが加味される故に、ソケットの開始部分におけるスループットは当該ソケットの典型的なスループットとならない可能性があり、そのようなスループットは無視されることになる。デフォルトは「１００」である。

ＮＩＣＥ＿ＷＡＩＴ＿ＢＡＳＥ：ある接続で送信を断念してｓｎｄ＿ｎｘｔ及びｓｎｄ＿ｕｎａをリセットするまでの送信待機時間が、ｖ＿ｂａｓｅＲＴＴ（グローバル最小ＲＴＴ）の何倍に相当するかを示す整数。このように計算されたタイムアウトがＮＩＣＥ＿ＷＡＩＴ＿ＭＡＸのタイムアウトに加算される。デフォルトは「０」である。

ＮＩＣＥ＿ＷＡＩＴ＿ＭＡＸ：ある接続で送信を断念してリセットを行うまでの送信待機時間が、ｖ＿ｍａｘＲＴＴ（グローバル最小ＲＴＴ）の何倍に相当するかを示す整数。デフォルトは優先度に基づく。

次に図１４を参照すると、本発明の例示的な一実施形態に従って配信物の送信をカスタマイズする処理のフローチャートが示されている。図１４に示される処理は、各自のネットワーク内でカスタマイズされた配信システムを所望する顧客に解決策を提供するのに使用される処理である。

図１４の処理は、顧客要求を受信することから開始する（ステップ１４００）。当該要求は、上記の解決策を実現するのに必要な情報を含む。例えば、当該要求には、顧客ネットワーク内のゲートウェイＩＤが含まれる。また、ゲートウェイを介してアクセスされる様々なクライアントの特性を含めることもできる。更に、図示の例にはクライアントによって行われる様々なタイプの配信物の送信要求も含まれる。当該要求が受信されたことに応じて、配信物を各エンドポイントに送信するためにクライアント・パラメータの分析が行われる（ステップ１４０２）。

この分析では、様々な優先度で使用される各パラメータの設定が特定される（ステップ１４０４）。これらの実例において、優先度は、閾値、β、及び最大待ち時間である。このように特定される各パラメータは、様々な優先度レベルとすることができる。例えば、図示の例では、「高」、「中」、及び「低」の３つの優先度レベルが使用されている。顧客要求に応じて図示の例とは異なる数の優先度レベル、例えば２つあるいは４つの優先度レベルを使用することもできる。特定の優先度レベルで生成されるパラメータは、クライアントの要求とゲートウェイが所在するネットワーク特性とに応じて、各ゲートウェイ毎に異なる可能性がある。

その後、適応型帯域幅制御用のコードが各ゲートウェイ毎に生成される（ステップ１４０６）。当該コードは、それ自体を特定のゲートウェイにインストールすることができるようにパッケージ化される。当該コードは、特定のゲートウェイを対象とする適応型帯域幅制御処理及び各種パラメータを含む。当該コードは、ゲートウェイ上の適応型帯域幅制御処理のインストール及びセット・アップに必要な実行可能ファイルも含むことができる。その後、当該コードは配信対象の顧客に送信される（ステップ１４０８）。このようにして、顧客は、カスタマイズされた配信システムを要求に応じて企業又は他のプロバイダから受け取ることができる。

かくして、本発明の諸態様は、データ転送速度を調整するコンピュータ実装方法、装置、及びコンピュータ使用可能なプログラム・コードを提供する。本発明の諸態様は、ユーザ入力を受信してアプリケーション・レベルでパラメータの各値を選択する。これらのユーザ定義パラメータは、適応型帯域幅制御処理においてネットワークを介して宛先に送信可能なパケット数を特定するのに利用される。本発明の諸態様によれば、ユーザは、様々なネットワーク状態及びネットワーク特性に基づいて各パラメータを定義することが可能となる。このように、本発明の諸態様によれば、様々なタイプのネットワーク及びネットワーク状態に基づいてデータを適応的に送信することが可能となる。

本発明の諸実施形態は全体としてハードウェアの実施形態の形をとることも、全体としてソフトウェアの実施形態の形をとることもでき、ハードウェア要素とソフトウェア要素の両方を含む一実施形態とすることもできる。好ましい一実施形態では、本発明は、必ずしもそれだけに限定されるわけではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含むソフトウェアの形で実施される。

更に、本発明は、コンピュータ又は任意の命令実行システムによって使用され又はそれらと共に使用されるプログラム・コードを備えるコンピュータ使用可能な又はコンピュータに読み込み可能な媒体からアクセス可能なコンピュータ・プログラムの形をとることもできる。本明細書では、コンピュータ使用可能な又はコンピュータに読み込み可能な媒体は、上記命令実行システム、装置、又はデバイスによって使用され又はそれらと共に使用される上記プログラムを収容し、記憶し、通信し、伝搬し、又は移送することが可能な任意の装置であってもよい。

上記媒体は、電子系、磁気系、光学系、電磁気系、赤外線系、又は半導体系（すなわち装置又はデバイス）であっても、伝搬媒体であってもよい。コンピュータに読み込み可能な媒体の例としては、半導体又は固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、固定磁気ディスク、及び光ディスクが挙げられる。光ディスクの現行例としては、コンパクト・ディスク−読取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−読出し／書込み（ＣＤ−Ｒ／Ｗ）、及びＤＶＤが挙げられる。

プログラム・コードを記憶し又は実行しあるいはその両方を行うのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接又は間接的に連結される少なくとも１つのプロセッサを含む。上記メモリ要素は、上記プログラム・コードの実際の実行中に利用されるローカル・メモリ、バルク記憶装置、及び実行中にバルク記憶装置からコードを検索しなければならない回数を少なくするために、少なくともいくつかのプログラム・コードを一時的に記憶するキャッシュ・メモリを含むことができる。

入力／出力すなわちＩ／Ｏデバイス（必ずしもそれだけに限定されるわけではないが、キーボード、ディスプレイ、ポインティング・デバイス等を含む）は、上記システムに直接又はＩ／Ｏコントローラを介して、連結することもできる。

介在する私設ネットワーク又は公共ネットワークを通して他のデータ処理システムあるいは遠隔プリンタ又は記憶装置に、上記データ処理システムが連結できるようにするために、上記システムにネットワーク・アダプタを連結することもできる。モデム、ケーブル・モデム及びイーサネット・カードは、現時点で使用可能なタイプのネットワーク・アダプタのほんのいくつかに過ぎない。

本発明の記載は、例示及び説明のために提示されるものであり、本発明を余すところのないものとし、又は開示の形態に限定することは、本出願人の意図するところではない。当業者には多くの修正形態及び変更形態が明らかとなるであろう。上記実施形態は、本発明の諸原理及び実際の適用形態が最良の形で説明されるように、また、想定される特定の使用に適するように様々な修正が施された様々な実施形態について当業者が本発明を理解することが可能となるように選択され説明されている。

本発明の諸態様を実施することが可能な複数のデータ処理システムから成るネットワークを示す図である。 本発明の諸態様を実施することが可能なデータ処理システムのブロック図である。 本発明の例示的な一実施形態に従って、様々なプロパティを使用して配信を行うことが可能な例示的なネットワーク・データ処理システムを示す図である。 本発明の例示的な一実施形態に係る適応型帯域幅制御で使用される各コンポーネントを示す図である。 本発明の例示的な一実施形態に係る伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）及び同様のプロトコルを示す図である。 本発明の例示的な一実施形態に係る適応型帯域幅制御を実現する際に使用される各ソフトウェア処理及びコンポーネントを示す図である。 本発明の例示的な一実施形態に係る優先度を使用して、配信物を適応型送信機から受信機に送信するネットワークを示す図である。 本発明の例示的な一実施形態に係るネットワーク内の帯域幅使用率を示す図である。 本発明の例示的な一実施形態に従ってパラメータに関するユーザ設定を構成する処理を示すフローチャートである。 本発明の例示的な一実施形態に係る送信スレッドに関する処理を示すフローチャートである。 本発明の例示的な一実施形態に係るパケット・スニッフィング・スレッドの処理を示すフローチャートである。 本発明の例示的な一実施形態に係る輻輳制御スレッドの処理を示すフローチャートである。 本発明の例示的な一実施形態に係る適応型帯域幅制御を実行する処理を示すフローチャートである。 本発明の例示的な一実施形態に従って顧客の受信機への配信物の送信をカスタマイズする処理を示すフローチャートである。

Claims (10)

1. データ転送を適応的に制御するコンピュータ実装方法であって、
   選択された優先度を使用してソースから配信されるデータを複数のゲートウェイにおいて受信するステップと、
   前記選択された優先度を使用して、前記データを前記複数のゲートウェイから複数の受信機に送信するステップと、を含み、
   前記複数のゲートウェイは全て、適応型帯域幅制御処理と、前記データが前記選択された優先度で送信されるように前記適応型帯域幅制御処理を制御する各パラメータ・セットと、を有し、
   前記選択された優先度で行われる各ゲートウェイからの前記データの送信は、前記複数のゲートウェイのうちの異なるゲートウェイに関する前記パラメータ・セットについて異なる値が設定されている場合には、前記異なるゲートウェイの他のトラフィックに異なる影響を与えることになる、
   コンピュータ実装方法。
2. 前記パラメータ・セットは、閾値と、βと、最大待ち時間と、を含む、請求項１に記載のコンピュータ実装方法。
3. 前記複数のゲートウェイのうちの特定のゲートウェイに関するパラメータ・セットを構成するステップを更に含み、前記特定のゲートウェイに関する前記パラメータ・セットは、前記複数のゲートウェイのうちの別のゲートウェイに関する前記パラメータ・セットとは異なる、
   請求項１に記載のコンピュータ実装方法。
4. 前記適応型帯域幅制御処理では、前記複数のゲートウェイのうちのあるゲートウェイから前記配信の受信機までの経路に沿った輻輳が加味される、請求項１に記載のコンピュータ実装方法。
5. 前記各パラメータ・セットは、前記複数のゲートウェイのうちの各ゲートウェイ毎に異なる、請求項１に記載のコンピュータ実装方法。
6. 前記データは、データ・ファイル、アプリケーション・アップデート、及びウイルス・パッチのうちの１つを含む、請求項１に記載のコンピュータ実装方法。
7. 請求項１乃至６のいずれか一項に記載の方法の各ステップをコンピュータに実行させるコンピュータ・プログラム。
8. データ処理システムであって、
   バスと、
   前記バスに接続された通信ユニットと、
   前記バスに接続され、１組のコンピュータ使用可能なプログラム・コードを含む記憶デバイスと、
   前記バスに接続され、前記１組のコンピュータ使用可能なプログラム・コードを実行して請求項１乃至６のいずれか一項に記載の各ステップを実施する処理ユニットと、
   を備えるデータ処理システム。
9. カスタマイズ・データ転送をクライアントに提供する方法であって、
   ネットワーク特性及びゲートウェイＩＤを含むカスタマイズ・データ転送要求を前記クライアントから受信するステップと、
   それぞれ前記ゲートウェイＩＤ及び前記ネットワーク特性に基づいてゲートウェイに割り当てられるカスタム・パラメータ・セットを生成するステップと、
   選択された優先度を使用してソースから配信されるデータを複数のゲートウェイにおいて受信するために、コンピュータ使用可能なプログラム・コードと共に使用される前記カスタム・パラメータ・セットを前記クライアントに送信するステップと、
   前記選択された優先度を使用して、前記データを前記複数のゲートウェイから複数の受信機に送信するステップと、を含み、
   前記複数のゲートウェイは全て、適応型帯域幅制御処理と、前記データが前記選択された優先度で送信されるように前記適応型帯域幅制御処理を制御する各パラメータ・セットと、を有し、
   前記選択された優先度で行われる各ゲートウェイからの前記データの送信は、前記複数のゲートウェイのうちの異なるゲートウェイに関する前記パラメータ・セットについて異なる値が設定されている場合には、前記異なるゲートウェイの他のトラフィックに異なる影響を与えることになる、
   方法。
10. 前記送信するステップは、前記コンピュータ使用可能なプログラム・コードと共に前記カスタム・パラメータ・セットを送信するステップを更に含む、請求項９に記載の方法。

Images