(57)【特許請求の範囲】
【請求項１】
クライアント装置上でパケットスケジューリングを管理するための、コンピュータにより実行される方法であって、
送信されるパケットを受信することと、
ネットワークスタックレベルの待ち行列内に前記パケットをエンキューすることと、
パケットスケジューリングが、現在、ドライバレベルで実行されているか、又はネットワーキングスタックレベルで実行されているかを判定することと、
スケジューリングが、現在、前記ネットワークスタックレベルで実行されている場合には、前記ネットワークスタックレベルの前記待ち行列から、前記送信のためのパケットを選択することと、
スケジューリングが、現在、前記ドライバレベルで実行されている場合には、前記ドライバレベルの前記待ち行列から、前記送信のためのパケットを選択することと、
前記ネットワーキングスタックにインターフェースを接続することと、
応答して、インターフェースのタイプ及び前記インターフェースに関して、パケットスケジューリングが、前記ネットワークスタックレベル又は前記ドライバレベルのいずれかで実行されるべきかについての指示を、宣言することと、
を含む、コンピュータにより実行される方法。
【請求項２】
パケットスケジューリングが、特定のＷｉ−Ｆｉネットワークインターフェースに関しては、前記ドライバレベルで実行されるが、全ての他の媒体アクセス制御（ＭＡＣ）インターフェースに関しては、前記ネットワーキングスタックレベルで実行される、請求項１に記載の方法。
【請求項３】
前記他のＭＡＣインターフェースが、イーサネットインターフェース及び無線セルラーインターフェースを含む、請求項２に記載の方法。
【請求項４】
パケットスケジューリングが、８０２．１１ｎデータトラフィックに関しては、前記ドライバレベルで実行されるが、８０２．１１ａ、８０２．１１ｂ、又は８０２．１１ｇデータトラフィックに関しては、前記ネットワーク層で実行される、請求項２に記載の方法。
【請求項５】
前記８０２．１１ｎドライバが、無線マルチメディア機能拡張（ＷＭＥ）を実装することにより、音声、ビデオ、ベストエフォート、及びバックグラウンドの４つの優先レベルに従ってネットワークトラフィックをスケジュールする、請求項４に記載の方法。
【請求項６】
特定のサービスクラスに従って、前記パケットを分類することと、
前記パケットが分類されている前記サービスクラスに基づいて、特定の送信待ち行列インスタンス内に前記パケットを入れることと、
を更に含む、請求項１に記載の方法。
【請求項７】
前記ネットワーキングスタックが、送信のためのパケットを待ち行列に入れ、前記パケットを送信する準備が整うと、前記ドライバレベルに通知する、請求項６に記載の方法。
【請求項８】
前記ドライバによって管理される通信リンクのネットワーキング条件を、前記ネットワーキングスタックが認識することを保証するために、前記ドライバレベルから前記ネットワーキングスタックレベルに、フィードバック信号を提供することを更に含む、請求項７に記載の方法。
【請求項９】
前記ネットワークレベルが、前記通信リンクに関連付けられる、前記検出されたネットワーキング条件に基づいて、パケットスケジューリングを実行する、請求項８に記載の方法。
【請求項１０】
前記インターフェースが、前記ネットワークスタックレベルでのパケットスケジューリングと、前記ドライバレベルでのパケットスケジューリングとを切り換える、請求項１に記載の方法。
【請求項１１】
前記インターフェースのタイプ及びスケジューリングモデルに基づいて、前記ネットワークスタックが、最適なパケットスケジューラ及び待ち行列処理技術を選択する、請求項１に記載の方法。
【請求項１２】
前記ネットワークスタックが、待ち行列のサイズ、フロー制御基準値、及び破棄閾値を含めた、前記送信待ち行列と関連付けられる待ち行列パラメータを自動的に決定する、請求項６に記載の方法。
【請求項１３】
前記ネットワークスタックレベルが、待ち行列全体にわたるリンク共有配分を含めた、パケットスケジューリングのパラメータを自動的に構成する、請求項６に記載の方法。
【請求項１４】
プログラムコードを記憶するためのメモリ、及び前記プログラムコードを処理するためのプロセッサを有する、クライアント装置であって、
送信されるパケットを受信する手順と、
ネットワークスタックレベルの待ち行列内に前記パケットをエンキューする手順と、
パケットスケジューリングが、現在、ドライバレベルで実行されているか、又はネットワーキングスタックレベルで実行されているかを判定する手順と、
スケジューリングが、現在、前記ネットワークスタックレベルで実行されている場合には、前記ネットワークスタックレベルの前記待ち行列から、前記送信のためのパケットを選択する手順と、
スケジューリングが、現在、前記ドライバレベルで実行されている場合には、前記ドライバレベルの前記待ち行列から、前記送信のためのパケットを選択する手順と、
前記ネットワーキングスタックにインターフェースを接続する手順と、
応答して、インターフェースのタイプ及び前記インターフェースに関して、パケットスケジューリングが、前記ネットワークスタックレベル又は前記ドライバレベルのいずれかで実行されるべきかについての指示を、宣言する手順と、
を実行する、クライアント装置。
【請求項１５】
パケットスケジューリングが、特定のＷｉ−Ｆｉネットワークインターフェースに関しては、前記ドライバレベルで実行されるが、全ての他の媒体アクセス制御（ＭＡＣ）インターフェースに関しては、前記ネットワーキングスタックレベルで実行される、請求項１４に記載のクライアント装置。
【請求項１６】
前記他のＭＡＣインターフェースが、イーサネットインターフェース及び無線セルラーインターフェースを含む、請求項１５に記載のクライアント装置。
【請求項１７】
パケットスケジューリングが、８０２．１１ｎデータトラフィックに関しては、前記ドライバレベルで実行されるが、８０２．１１ａ、８０２．１１ｂ、又は８０２．１１ｇデータトラフィックに関しては、前記ネットワーク層で実行される、請求項１５に記載のクライアント装置。
【請求項１８】
前記８０２．１１ｎドライバが、無線マルチメディア機能拡張（ＷＭＥ）を実施することにより、音声、ビデオ、ベストエフォート、及びバックグラウンドの、４つの優先レベルに従ってネットワークトラフィックをスケジュールする、請求項１７に記載のクライアント装置。
【請求項１９】
特定のサービスクラスに従って、前記パケットを分類する手順と、
前記パケットが分類されている前記サービスクラスに基づいて、特定の送信待ち行列インスタンス内に前記パケットを入れる手順と、
を前記クライアント装置に実行させるための、更なるプログラムコードを備える、請求項１４に記載のクライアント装置。
【発明の詳細な説明】
【技術分野】
【０００１】
［優先権に対する主張］
本出願は、参照により全体が本明細書に組み込まれる、２０１２年２月３日出願の、Ｃａｈｙａ  Ｍａｓｐｕｔｒａらによる「ＳＹＳＴＥＭ  ＡＮＤ  ＭＥＴＨＯＤ  ＦＯＲ  ＩＮＴＥＬＬＩＧＥＮＴ  ＮＥＴＷＯＲＫ  ＱＵＥＵＥ  ＭＡＮＡＧＥＭＥＮＴ」と題された米国仮特許出願第６１／５９５，００３号に関連し、その利益を主張する。
【０００２】
［関連出願の相互参照］
本出願は、Ａｐｐｌｅに譲渡された、２０１２年９月１５日出願の、Ｃａｈｙａ  Ｍａｓｐｕｔｒａらにより同時に出願された米国特許出願第１３／６２０，９２０号に関連する。
【０００３】
本発明の一実施形態は、クライアント装置内でデータネットワーク通信を管理することを目的とする。他の実施形態もまた説明される。
【背景技術】
【０００４】
データネットワークにより、人々は、ネットワーク「上に」存在する、それらの対応するクライアント装置を使用して、互いに通信し、ネットワーク上の様々なソースから情報を取得することが可能となる。例えば、ユーザーのワークステーション又はラップトップコンピュータで実行されている、ウェブブラウザのアプリケーションプログラムは、ウェブサーバと接続して、ウェブページをダウンロードすることができる。この接続は、ルータなどの専用のコンピュータを含み得る、ネットワークの幾つかの中継ノード又はホップに及び得る。これらの装置は、終端ノード間の経路を発見することができ、その経路を通じて、データのパケットへと分割されているメッセージを転送することができる。各ノードには、インターネットプロトコル（ＩＰ）アドレスなどの、固有のアドレス又はグローバルアドレスを割り当てることができる。インターネットは、コンピュータのネットワークがルータを介して互いに接続される、周知の大域的インターネットワークである。
【０００５】
コンピュータネットワークプロトコルは、階層化アーキテクチャを有する。典型的には、最上層は、ウェブブラウザなどのアプリケーションプログラムによって提供される機能性を含む。これは、少なくとも終端ノードで、ネットワークを介して２つのコンピュータ間の接続を開始することができる層である。それゆえ、例えば、ユーザーは、そのユーザーのコンピュータ上で所望のウェブサイトを選択することができる。（そのコンピュータ内で実行されている）ウェブブラウザは、選択されたウェブサイトに関連付けられるサーバと接続が形成される結果をもたらす、手続きを開始する。ウェブブラウザは、インターネットプロトコルスイート又は転送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）スタックと称される一連の機能を通じて、リクエストを「下り方向に」送る。このプロトコルのスタックは、典型的には、ソフトウェア内の上位層に、多くの場合、クライアント装置内で実行されるオベレーティングシステム（ＯＳ）プログラムの一部として実施される。選択されたウェブサイトが、ウェブサーバのＩＰアドレスに変換されると、インターネットを介してそのサーバにコンタクトが取られ、ウェブサーバ内に実施された同様のプロトコルスイートの上層のプログラムを使用して、適切な接続が形成される。
【０００６】
この接続を使用するために、ユーザーのコンピュータ内のＴＣＰ／ＩＰスタックは、ウェブブラウザからのリクエストメッセージ、この例では、ウェブページを特定するリクエストを、カプセル化する。このメッセージは、ネットワークアクセス層を含めた、プロトコルスタック内の下り方向での幾つかの垂直層によって、２回以上カプセル化することができる。そのメッセージは、最終的に、クライアント装置の最下位層、すなわち物理層（典型的には、ネットワークアクセス層の一部であると見なされる層）に到着する。
【０００７】
ユーザーのコンピュータの物理層から離脱して、次いで、ネットワーク内の１つ以上のホップを通過して進行した後で、ウェブブラウザからのメッセージは、ウェブサーバ内に到着し、ウェブブラウザのピアと見なされるプログラムへと、そのウェブサーバ内のプロトコルスタックを「上り方向に」移動される。次いで、ピアのプログラムは、リクエストされたウェブページに関するデータを収集させ、既存のネットワーク接続を通じてユーザーのコンピュータに返送させることによって、そのメッセージに応答することができる。このデータは、複数のメッセージ又はパケットに分割され、リクエストメッセージが送信された方式と類似の方式で送信される。
【０００８】
アプリケーションプログラムは、ユーザーのクライアントコンピュータ内の１つ以上のプロセッサによって実行される、幾つかのアプリケーション又はプロセスを有し得る。それぞれの個別のアプリケーションは、異なるパケット損失、待ち時間、及びフロー弾性の要件を有し得る、異なるタイプのネットワークデータトラフィックを生成することができる。例として、ソーシャルネットワーキングアプリケーションは、ネットワークを介して、制御データ、テキスト、音声、及びビデオを通信することができ、それらのそれぞれは、上記の変数に関して異なる要件を有する。各アプリケーションには、典型的には、このデータを通信するための、それら自体のポート又はポートのグループが提供されるが、それらは全て、ユーザーのコンピュータ内の同じ下位層のネットワークリソースを共有することができる。現在の実装では、ネットワークを介して、各クライアント装置を特定の宛先ノード（すなわち、別のクライアント、又はサーバ）に相互接続するルータは、大きい送信バッファ及び受信バッファを含む。それゆえ、パケット損失は、殆ど又は全く存在せず、クライアント装置は、典型的には、フロー制御を考慮することなくパケットを送信することが可能となり、結果的にルータの待ち行列内部の「バッファ膨張」を生じさせる。ＴＣＰなどのプロトコルは、検出されたパケット損失に基づいて、輻輳を判定し、伝送測度を修正する、自己調節プロトコルである。パケット損失が、より大きいバッファを使用して軽減される場合、ＴＣＰプロトコル
【０００９】
更には、現在のクライアント側の実施では、パケットのバッファリングは、ドライバレベルで実施される。ＴＣＰ／ＩＰスタックは、ドライバにパケットを単に下り方向で送り出すのみであり、ドライバが、それ自体の送信待ち行列及び受信待ち行列を管理する。クライアント内部のドライバレベルで実行される、この大量のバッファリングのために（イーサネット（登録商標）ドライバは、送信前の待ち行列内に、最大４０００パケットをバッファリングすることができる）、ネットワーキングスタックには、正確なネットワーク／輻輳の情報が提供されない。それゆえ、必要とされるのは、ドライバ層とネットワークスタック層との間で使用されるフィードバックチャネルが利用される、クライアント装置内部でネットワーク待ち行列処理を実行するための、よりインテリジェントな機構である。
【発明の概要】
【００１０】
クライアント装置上でパケットスケジューリングを管理するための、コンピュータにより実行される方法。例えば、方法の一実施形態は、送信されるパケットを受信することと、ネットワークスタックレベルの待ち行列内にパケットをエンキューすることと、パケットスケジューリングが現在ドライバレベルで実行されているか、又はネットワーキングスタックレベルで実行されているかを判定することと、スケジューリングが現在ネットワークスタックレベルで実行されている場合には、ネットワークスタックレベルの待ち行列から、送信のためのパケットを選択することと、スケジューリングが現在ドライバレベルで実行されている場合には、ドライバレベルの待ち行列から、送信のためのパケットを選択することと、を含む。
【００１１】
本発明の実施形態を、限定としてではなく例として、添付図面の図に示し、図面中、同様の参照符号は同様の要素を示す。本開示での、本発明の「ａｎ」又は「１つの」実施形態への言及は、必ずしも同じ実施形態に対するものではなく、それらは、少なくとも１つを意味していることに留意されたい。
【図面の簡単な説明】
【００１２】
【図１Ａ】本発明の実施形態に係る、ネットワーキングスタックを有するクライアント装置のブロック図を示す。
【図１Ｂ】本発明の実施形態に係る、ネットワーキングスタックを有するクライアント装置のブロック図を示す。
【図２Ａ】本発明の実施形態に係る、１つの方法を示す。
【図２Ｂ】本発明の実施形態に係る、別の方法を示す。
【図３Ａ】本発明の１つの実施形態に係る、データパケットを送信するための、ネットワーキングスタックとドライバとの間の通信を示す。
【図３Ｂ】本発明の別の実施形態に係る、データパケットを送信するための、ネットワーキングスタックとドライバとの間の通信を示す。
【図３Ｃ】本発明の一実施形態に係る、クライアント側のソフトウェアアーキテクチャを示す。
【図４】例示的な送信スレッド及び例示的な始動スレッドを示す。
【図５】例示的なクラス待ち行列インスタンス及びスケジューラを示す。
【図６】サービスクラスが待ち行列インスタンスにマッピングされる一実施形態を示す。
【図７】サービスクラスが待ち行列インスタンスにマッピングされる別の実施形態を示す。
【図８】ソケットのトラフィッククラスがサービスクラスにマッピングされる実施形態を示す。
【図９Ａ】組み込みＱＦＱスケジューラ構成を有する一実施形態での、リンク共有配分の最悪ケースのシナリオを示す。
【図９Ｂ】一実施形態に係る、パケットフィルタ（ＰＦ）構成の実施例を示す。
【図１０Ａ】一実施形態に係る、フローハッシュを使用するフロー制御を示す。
【図１０Ｂ】一実施形態の待ち行列処理アルゴリズムによって使用される、現在のビンのセット及び影のビンのセットを示す。
【図１１Ａ】本発明の１つの実施形態に係る、データパケットを受け取るための、ネットワーキングスタックとドライバとの間の通信を示す。
【図１１Ｂ】本発明の別の実施形態に係る、データパケットを受け取るための、ネットワーキングスタックとドライバとの間の通信を示す。
【図１２】例示的なワークループスレッド、ポーラースレッド、及びＤＬＩＬ入力スレッドを示す。
【図１３】一実施形態に係る、スレッドデータの例示的セットを示す。
【図１４】一実施形態で採用される、アプリケーションプログラミングインターフェース（ＡＰＩ）を示す。
【図１５】一実施形態で採用される、ＡＰＩを有する複数のサービスを示す。
【図１６】クライアント側データ処理装置の一実施形態を示す。
【図１７】クライアント側データ処理装置の別の実施形態を示す。
【発明を実施するための形態】
【００１３】
本発明の実施形態は、クライアント装置上で実行される、ネットワーキングアプリケーションに関するアクティブな待ち行列管理のための、コンピュータにより実行される方法を目的とする。
【００１４】
図１Ａは、本発明の実施形態を実施することができる、クライアントコンピューティング装置１０１のブロック図である。図示のクライアント装置１０１は、インターネットなどのネットワーク１５０を介して、サーバ１２０、１２１、及び他のクライアント装置１２２と通信する、複数のアプリケーション１０５〜１０７を実行する。サーバ１２０、１２１としては、（例として、限定するものではないが）ウェブサーバ、ｅメールサーバ、インスタントメッセージサーバ、及びファイルサーバを挙げることができる。一実施形態では、アプリケーション１０５〜１０７は、ネットワーキングスタック１０２によって公開されるアプリケーションプログラミングインターフェース（ＡＰＩ）２０８に呼び出しを行い、ネットワーキングスタック１０２によって提供されるネットワーキングリソースにアクセスする。
【００１５】
この実施形態のネットワーキングスタック１０２は、アプリケーション１０５〜１０７のそれぞれのために、複数のネットワーキング待ち行列１１０〜１１２を管理するための、待ち行列管理論理１１５を含む。ネットワーキングスタック内のパケットスケジューラ１１６は、パケット分類に基づいて（以下でより詳細に説明されるように）待ち行列のそれぞれから送信されるパケット／それぞれに受信されるパケットをスケジュールする。図１Ａでは別個のモジュールとして示されるが、待ち行列管理論理１１５及びスケジューラ１１６は、単一の統合ソフトウェアモジュールとして実施することができる点が、理解されるであろう。
【００１６】
一実施形態では、待ち行列管理論理１１０〜１１２によって管理される、待ち行列１１０〜１１２のそれぞれは、発信ネットワークパケット（例えば、ＴＣＰ／ＩＰパケット）を記憶するための送信待ち行列、及び着信ネットワークパケットを記憶するための受信待ち行列を含む。送信待ち行列及び受信待ち行列は、アプリケーション１０５〜１０７のそれぞれのネットワーキング要件に基づいて、アプリケーション１０５〜１０７のそれぞれに関して、異なる方式で管理される。例えば、異なるアプリケーションは、異なるパケット損失、待ち時間、及びフロー弾性の要件を有する場合があり、それらの要件の全ては、待ち行列管理論理１１５によって監視及び管理される。一実施形態では、各アプリケーション１０５〜１０７のネットワーキング要件は、事前に（例えば、そのアプリケーションが、ＡＰＩ  １０８を介して最初に登録されるときに）指定され、そのアプリケーションに関するネットワーキングパケットは、指定された要件に基づいて、待ち行列管理論理１１５によって管理される。例として、ウェブ閲覧アプリケーションは、典型的には、リアルタイムビデオチャットアプリケーションよりも、待ち時間に耐性がある。したがって、ウェブ閲覧アプリケーションは、リアルタイムビデオチャットアプリケーションとは異なる指定のサービスレベルを有する、異なる待ち行列と関連付けられる。
【００１７】
一実施形態では、クライアント装置上にインストールされた各ドライバ１５０は、ドライバ待ち行列１５１〜１５３のセットを管理するための、待ち行列管理論理１５５を含み、ドライバ待ち行列１５１〜１５３のそれぞれもまた、異なるサービスレベルに関連付けることができる。更には、各ドライバは、ドライバレベルでパケットスケジューリングを実行するための、それ自体のスケジューラ１６０、及び、待ち行列１５１〜１５３を管理するための、それ自体の待ち行列管理論理１５５を有し得る。ネットワーキングスタック１０２と同様に、ドライバ待ち行列管理論理１５５及びドライバスケジューラ１６０は、単一の論理モジュールとして（図１に示すような別個のモジュールではなく）実施することができる。一実施形態では、各ドライバ１５０は、それ自体でパケットスケジューリングを管理する（本明細書では、「ドライバ管理」スケジューリングと称される）ように選択することができ、又は、パケットスケジューリング／待ち行列処理に関して、ネットワーキングスタック１０２のパケットスケジューラ１１６及び待ち行列管理論理１１５に依存することができる。
【００１８】
例として、限定するものではないが、イーサネット（登録商標）ドライバ及びセルラー無線（例えば、３Ｇ、４Ｇ）ドライバは、ネットワーキングスタック１０２のスケジューラ１１６によって提供される、パケットスケジューリング及び待ち行列処理に依存することができるが、その一方で、８０２．１１ｎ（Ｗｉ−Ｆｉ）ドライバは、ドライバスケジューラ１６０を使用して、パケットスケジューリング及び待ち行列処理を管理することができる。一実施形態では、Ｗｉ−Ｆｉドライバは、無線マルチメディア機能拡張（ＷＭＥ）（別名、Ｗｉ−Ｆｉマルチメディア（ＷＭＭ）規格）を実施することにより、音声、ビデオ、ベストエフォート、及びバックグラウンドの、４つの優先レベルに従って、ネットワークトラフィックをスケジュールする。しかしながら、本発明の根底をなす原理は、いずれの特定のネットワーキング規格にも限定されるものではない。
【００１９】
一実施形態では、Ｗｉ−Ｆｉドライバは、ドライバ管理スケジューリングとネットワーク層でのスケジューリングとを、動的に切り換えることが可能である。例えば、ＷＭＥに対応する８０２．１１ｎネットワーク上にある場合、ドライバは、ドライバレベルのスケジューリングを選択することができるが、８０２．１１ｂ又は８０２．１１ｇのネットワーク上にある場合、ドライバは、ネットワーク層でのスケジューリングを選択することができる。一実施形態では、ネットワークスタック管理スケジューリングを利用する場合、ネットワークスタック１０２は、パケットをデキューする準備が整うと、ドライバに通知することになる。次いで、ドライバは、そのパケットを（以下でより詳細に説明されるように）デキューして送信する。
【００２０】
図１Ａに示すように、パケットが、ネットワーク条件に関わりなく、ネットワーキングスタックからドライバに送り出され、ドライバ内でバッファリングされる、先行の実施とは対照的に、本発明の一実施形態では、ドライバ層１５０とネットワーキングスタック１０２との間に、継続的なフィードバック１７１が提供される。ドライバ１５０からネットワーキングスタック１０２へのフィードバックにより、ネットワーキングスタック１０２は、ドライバ１５０によって管理される通信リンクのネットワーキング条件を認識することが保証され、この知識に基づいて、パケットスケジューリング／待ち行列処理を実行することができる。一実施形態では、ネットワーキングスタック１０２は、検出されたネットワーキング条件に基づいて、本明細書で説明されるように、パケットスケジューリング及び待ち行列処理をインテリジェントに実施する。同様に、ネットワーキングスタック１０２からドライバ１５０へのフィードバック信号は、ネットワーキングスタックの送信／受信待ち行列１１２内部の条件（新たなパケットを特定の待ち行列から送信する準備が整っている場合など）を、ドライバにシグナルする。
【００２１】
図１Ｂに示すように、スケジューリングは、一部の通信チャネルに関しては、ネットワークスタック層で採用することができ、他の通信チャネル（例えば、上述のような幾つかのＷｉＦｉチャネル）に関しては、ドライバ層で採用することができる。具体的には、図示の実施形態では、パケットスケジューリングは、サーバ１２０及びサーバ１２３、並びにクライアント１２１への通信チャネルに関しては、ネットワークスタック層１０２内で実行することができ、その一方で、サーバ１２２への通信チャネルに関しては、ドライバ管理スケジューリングを実行することができる。更には、図１Ｂに示すように、単一のアプリケーション１０５は、異なるパケット損失、待ち時間、及びフロー弾性の要件に対応する異なる待ち行列に割り当てられる、異なるタイプのデータトラフィックを有し得る。例えば、特定のアプリケーションは、ＴＣＰ／ＵＤＰソケットを開いて、制御データ、テキスト、音声、及びビデオを通信することができ、それらのそれぞれは、上記の変数に関して異なる要件を有する。それゆえ、１つのタイプのデータ（例えば、制御データ）は、第１のサービスクラスに関連付けられた待ち行列１１３内に入れることができ、第２のタイプのデータ（例えば、対話型ビデオ）は、第２のサービスクラスに関連付けられた待ち行列１１０内に入れることができる。更には、異なるアプリケーションが、同じサービスクラスに関連付けられた同じ待ち行列内に、データを入れることができる。例えば、アプリケーション１０５及びアプリケーション１０６は、制御データに関するサービスクラスに関連付けられた待ち行列１１０内に、制御データを入れることができ、アプリケーション１０６及びアプリケーション１０７は、対話型ビデオデータに関するサービスクラスに関連付けられた待ち行列１１１内に、対話型ビデオデータを入れることができる。
【００２２】
更には、ネットワークの接続性（例えば、クライアント１０１が、イーサネット（登録商標）又はＷｉＦｉのいずれに結合されているか）及び他のネットワーク変数に応じて、クライアント装置１０１は、ネットワーク層の待ち行列管理及び／又はスケジューリングのみを、あるいはドライバ管理の待ち行列管理及び／又はスケジューリングのみを利用しつつ、依然として、本発明の根底をなす原理に準拠し得る点が、理解されるであろう。
【００２３】
本発明の一実施形態に係る方法を、図２Ａに示す。２０１では、送信されるパケットが、クライアント装置上のプロトコルスタックのネットワーキング層で受け取られる。そのパケットが、ドライバ管理スケジューリングを使用するネットワークリンクと関連付けられる場合には、２０２で判定され、次いで２０３で、そのパケットはドライバ層に提供される。次いで、ドライバ層は、２０４で、そのパケットを待ち行列に入れ、スケジュールし、送信する。しかしながら、そのパケットが、ネットワーク層でパケットスケジューリングを実行するネットワークリンクと関連付けられる場合には、次いで２０５で、ネットワークスタックが、そのパケットを、送信のために待ち行列に入れてスケジュールする。２０６で、パケットを送信する準備が整うと、ドライバに通知され、２０７で、ドライバがパケットを送信する。
【００２４】
クライアントコンピューティング装置１０１は、デスクトップコンピュータ、ノートブック若しくはラップトップコンピュータ、ビデオゲーム機、又は他の消費者向け電子機器であってもよい。本明細書で説明される一部の実施形態では、クライアント装置１０１は、双方向の音声及びビデオ機能、ｅメールメッセージング機能、並びにメディア再生機能を含み得る、ポータブル無線機器である。クライアント装置１０１とサーバとの間の通信経路は、この実施例では、クライアント装置１０１と無線基地局（例えば、セルタワー又はＷｉＦｉアクセスポイント）との間に、無線区間を有する。インターネット参照モデルでは、ネットワーキングスタック１０２、クライアント装置１０１は、任意の好適な無線通信ネットワークアクセスプロトコル（その幾つかの例が以下に記載される）に従って、基地局を介してネットワークアクセスゲートウェイと通信する。他のクライアント装置１２２には、別の基地局とゲートウェイとの組み合わせを介して、到達することができる。ネットワークアクセス層の上部には、インターネットワーキング層（例えば、インターネットプロトコル、ＩＰ、ネットワーク上の各ノードに関するアドレスを定義する）、トランスポート層（例えば、ホスト間のフロー制御、及び接続の開閉を実行する、転送制御プロトコル、ＴＣＰ）、及びアプリケーション層（例えば、アプリケーションプログラム、並びにＨＴＴＰ、ＳＭＴＰ、及びＳＳＨなどのプロセスプロトコル）が存在する。
【００２５】
図２Ｂは、ドライバ管理スケジューリング又はネットワークスタック管理スケジューリングのいずれかを使用してパケットが送信される、本発明の実施形態を示す。２５１では、送信されるパケットが、オープンソケット接続を介して、特定のアプリケーションによって生成される。例えば、対話型ビデオアプリケーションは、別のクライアントに送信されるビデオパケットを生成することができる。２５２では、ネットワーク層は、パケットのタイプに基づいて、指定のサービスクラス内でパケットを待ち行列に入れる。例えば、以下で論じられるように、１０個の異なるタイプのデータトラフィックに関するデータを待ち行列に入れるために、１０個の異なるサービスクラスが定義される。それゆえ、パケットが対話型ビデオパケットである場合には、そのパケットは、対話型ビデオに関するサービスクラスの待ち行列に入れることができる。同様に、パケットが制御データを含む場合には、そのパケットは、ネットワーク制御に関するサービスクラスの待ち行列に入れることができる。
【００２６】
パケットがどのように待ち行列に入れられるかに関わりなく、そのパケットは、ドライバ管理スケジューリング又はネットワークスタック管理スケジューリングのいずれであるかに応じて、異なる方式でデキューすることができる。ドライバ管理スケジューリングに関しては、２５４で判定され、ドライバは、２５５で、指定のサービスクラスからのデキュー動作を実行する。例えば、ドライバが８０２．１１ｎを実施している場合には、そのドライバは、ＷＭＭによって定義される４つのサービスクラスを使用してスケジューリングを実行するように、選択することができる（例えば、サービスクラスと待ち行列インスタンスとの間の１０：４マッピングを示す、図７を参照）。あるいは、他のネットワークインターフェースのタイプ（例えば、イーサネット（登録商標）、３Ｇなど）に関しては、スケジューリングは、ネットワーク層で実行することができる（例えば、サービスクラスと待ち行列インスタンスとの間の１：１マッピングを示す、図６を参照）。それゆえ、２６０で、ネットワーク層は、選択されたサービスクラスからのデキュー動作を実行する。２７０では、パケットがドライバ層に提供され、このドライバ層が、２７１でパケットを送信する。
【００２７】
それゆえ、一実施形態では、パケットを送信する必要があるとき、そのパケットは、ネットワークインターフェース用に構成されたネットワーク層スケジューラ内に移されることを、上記から理解することができる。このスケジューラは、パケットからサービスクラスを抽出し、サービスクラスにより、そのパケットをエンキューするための待ち行列インスタンスが判定される。次いで、そのパケットは、対応する待ち行列インスタンス上にエンキューされるが、待ち行列が満杯であるか、又はフロー制御している場合には、そのパケットは破棄される場合がある（この破棄／エンキューの判断は、以下で説明されるように、待ち行列処理規範／アルゴリズム（例えば、ＳＦＢ）に委ねられる）。ドライバは、行うべき作業が存在することを通知される。ある時点で、ドライバは、パケットをデキューする。待ち行列インスタンスを特定する必要がある。そのインターフェースが、「ネットワークスタックスケジューリング」用に構成されている場合には、スケジューラは、サービスされる適格な待ち行列を選択する。そのインターフェースが、「ドライバスケジューリング」用に構成されている場合には、ドライバが、サービスのために選択される待ち行列を、スケジューラに指示する。待ち行列インスタンスが特定されると、パケットが、可能な場合には、その待ち行列からデキューされる。そのパケットは、パケットを伝送する媒体を介した送信のために、ドライバに引き渡される。
【００２８】
図１Ａ、図１Ｂに示すように、一実施形態では、継続的なフィードバック１７２が、ネットワーキングスタック１０２から、アプリケーション１０５〜１０７のそれぞれに（点線の矢印によって示されるように）提供され、アプリケーション１０５〜１０７のそれぞれへの／それぞれからのネットワークフローに関するフロー制御を提供するために、使用される。例えば、特定のＴＣＰ又はＵＤＰソケットに関する送信待ち行列１１０〜１１２が、指定の閾値に達している場合、対応するアプリケーション１０５〜１０７に、新たなパケット送信を一時停止又は低減するように指示するための、フィードバック信号が生成される。
【００２９】
図３Ａ、図３Ｂは、本発明の異なる実施形態に係る、異なるネットワークドライバのモデルを示す。図３Ａでは、アプリケーション３０１は、送信されるパケットを、ネットワークスタック３０２に送り（１）、次いで、このネットワークスタック３０２は、ドライバのＩＯネットワーキングインターフェース３０３に、そのネットワークパケットを送る（２）。一実施形態では、ＩＯネットワーキングインターフェース３０３は、パケットを分類し、そのパケット分類に基づいて、適切なＩＯ出力待ち行列３０４内に、分類されたパケットを配置する（３）。上述のように、ＷＭＭに関しては、この分類は、音声、ビデオ、ベストエフォート、及びバックグラウンドを含み得る。次いで、ドライバ３０５は、それ自体のパケットスケジューラを使用して、適切なＩＰ出力待ち行列３０４から、パケットをデキューする（４、５）。
【００３０】
図３Ｂに示すネットワークスタック管理モデルでは、アプリケーション３０１は、送信されるパケットを、ネットワークスタック３０２に送り（１）、次いで、このネットワークスタック３０２は、そのパケットを（以下で説明される分類スキームを使用して）分類し、適切な送信待ち行列３０６内に、分類されたパケットを配置する（２）。一実施形態では、存在するパケット分類と同数の、異なる送信待ち行列３０６（例えば、１０個の異なるパケット分類に対する、１０個の異なる送信待ち行列）が存在する。ネットワーキングスタック３０２は、それらの待ち行列のうちの１つで新たなパケットの送信の準備が整うと、ドライバ層に通知する（３）。次いで、ドライバ３０７のＩＯネットワーキングインターフェースは、そのパケットをデキューして、送信のために、デキューされたパケットをドライバ３０５に移す（５、６）。
【００３１】
図３Ｃは、パケットを分類するためのパケット分類器２０２、アプリケーション２０１とインターフェースするためのＡＰＩ  ２０３、インターネットパケット層２０６、トランスポート層２０５（例えば、ＴＣＰ、ＵＤＰ）、及びソケット層２０４、パケット送信をスケジュールするためのパケットスケジューラ２０９、複数のクラス待ち行列２１０、フローアドバイザリモジュール２０７、及びカーネルプログラミングインターフェース（ＫＰＩ）２１１を含む、ネットワーキング層１０２の、更なるアーキテクチャの詳細を示す。これらの構成要素のそれぞれを、以下でより詳細に説明する。
Ａ．カーネルプログラミングインターフェース
【００３２】
一実施形態では、以下のプライベートＫＰＩのセットが採用される。
【００３３】
ｉｆｎｅｔ＿ａｌｌｏｃａｔｅ＿ｅｘｔｅｎｄｅｄ（）
【００３４】
新たな出力モデルに対応する、ｉｆｎｅｔインスタンスを割り当てる。これは、パブリックのｉｆｎｅｔ＿ａｌｌｏｃａｔｅ（）ＫＰＩの拡張（プライベート）バージョンであり、呼び出し元によって入力される、新たに定義されたｉｆｎｅｔ＿ｉｎｉｔ＿ｅｐａｒａｍｓ構造を必要とする。この構造は、ｉｆｎｅｔ＿ｉｎｉｔ＿ｐａｒａｍｓに類似しており、新たな出力モデルに関連する幾つかの新たなフィールドを有する。
【表１】
0005893762.tif 000002
0005893762.tif 000003
【００３５】
ｉｆｎｅｔ＿ｅｎｑｕｅｕｅ（）
【００３６】
新たなドライバ出力モデルを実施するインターフェースの出力待ち行列に、パケットをエンキューする。これは、ｐｒｅ＿ｅｎｑｕｅｕｅ（）コールバックを実施するドライバ／ファミリに提供される。
【００３７】
｛ｉｆｎｅｔ＿ｄｅｑｕｅｕｅ，ｉｆｎｅｔ＿ｄｅｑｕｅｕｅ＿ｍｕｌｔｉ｝（）
【００３８】
新たなドライバ出力モデルを実施し、スケジューリングモデルが「通常」に設定される、インターフェースの出力待ち行列から、１つ以上のパケットをデキューする。
【００３９】
｛ｉｆｎｅｔ＿ｄｅｑｕｅｕｅ＿ｓｅｒｖｉｃｅ＿ｃｌａｓｓ，ｉｆｎｅｔ＿ｄｅｑｕｅｕｅ＿ｓｅｒｖｉｃｅ＿ｃｌａｓｓ＿ｍｕｌｔｉ｝（）
【００４０】
新たなドライバ出力モデルを実施し、スケジューリングモデルが「ドライバ管理」に設定される、インターフェースの出力待ち行列から、１つ以上のパケットをデキューする。
【００４１】
ｉｆｎｅｔ＿ｓｅｔ＿ｏｕｔｐｕｔ＿ｓｃｈｅｄ＿ｍｏｄｅｌ（）
【００４２】
スケジューリングモデルを、「通常」又は「ドライバ管理」に設定する。
【００４３】
｛ｉｆｎｅｔ＿ｓｅｔ＿ｓｎｄｑ＿ｍａｘｌｅｎ，ｉｆｎｅｔ＿ｇｅｔ＿ｓｎｄｑ＿ｍａｘｌｅｎ｝（）
【００４４】
出力待ち行列の最大長を、設定及び取得する。
【００４５】
ｉｆｎｅｔ＿ｇｅｔ＿ｓｎｄｑ＿ｌｅｎ（）
【００４６】
出力待ち行列の現在の長さを取得する。
【００４７】
ｉｆｎｅｔ＿ｓｔａｒｔ（）
【００４８】
新たなドライバ出力モデルを実施するインターフェース上の、ドライバ層での送信をトリガする。これにより、ドライバのｓｔａｒｔ（）コールバックが、未だ起動されていない場合には、呼び出される結果をもたらすことができる。
【００４９】
｛ｉｆｎｅｔ＿ｓｅｔ＿ｂａｎｄｗｉｄｔｈｓ，ｉｆｎｅｔ＿ｂａｎｄｗｉｄｔｈｓ｝（）
【００５０】
インターフェースのアップリンク及びダウンリンクのリンク速度を、設定及び取得する。この速度は、ドライバによって、その層で情報が利用可能である場合は常に、ｉｆｎｅｔが接続された後に、随時設定することができる。
【００５１】
｛ｉｆｎｅｔ＿ｔｒａｎｓｍｉｔ＿ｂｕｒｓｔ＿ｓｔａｒｔ，ｉｆｎｅｔ＿ｔｒａｎｓｍｉｔ＿ｂｕｒｓｔ＿ｅｎｄ｝（）
【００５２】
ドライバが、アップリンクのリンク速度を、そのような情報をハードウェアから容易に取得することができない場合に推定するための、代替的機構。これらは、ネットワーキングスタックに、バーストの送信の開始及び終了について通知する。
【００５３】
一実施形態では、新たな出力モデル（すなわち、ネットワークスタック管理スケジューリング）に対応するとして、それ自体を登録しているドライバは、ＩＦＥＦ＿ＴＸＳＴＡＲＴフラグを使用して、フラグが立てられる。
Ｂ．データリンクインターフェース層（ＤＬＩＬ）２０８
【００５４】
始動スレッド４０２（図４に示す一実施形態）
【００５５】
新たな出力モデル（すなわち、ネットワーク層スケジューリング）に対応するインターフェースは、専用のカーネルスレッドである「始動スレッド」４０２を使用し、このスレッドのジョブは、ドライバのｓｔａｒｔ（）コールバックを起動することである。一実施形態では、このスレッドは、ｉｆｎｅｔ＿ｓｔａｒｔ（）が呼び出される場合は常に、ｉｆｎｅｔ＿ｅｎｑｕｅｕｅ（）を介してパケットをエンキューすることの一部として、未だ実行されていない場合には、実行されるようにシグナルされるものであり、出力待ち行列にパケットをエンキューすると直ちに、このアプリケーションスレッドが戻ることを可能にする。このスレッドは、デキューが順次に生じ得るように、ドライバのｓｔａｒｔ（）コールバックにシリアル化の形態を提供する。このスレッドはまた、ドライバ層での複雑性も低減するが、これは、この始動スレッドのコンテキストから、ドライバのｓｔａｒｔ（）コールバックを実行する場合、ネットワーキングスタックによってロックが保持されないため、ドライバは、影響について過度に懸念することなく、そのスレッドの実行を瞬間的に遮断することが可能な（ハードウェア関連又は非関連の）特定の動作を実行することができるためである。
トークンバケット調整器
【００５６】
更には、ネットワーク層管理の出力モデルは、インターフェース用にトークンバケット調整器（ＴＢＲ）が構成される場合、ｉｆｎｅｔ層でのアップリンク速度制限の形態を可能にする。デフォルトでは、インターフェースには、ＴＢＲが構成されておらず、ＴＢＲを有効にするには、ｉｆｃｏｎｆｉｇ（８）又はｐｆｃｔｌ（８）を介した手動構成が必要とされる。ＴＢＲが有効である場合、始動スレッドは、図４の４０２に示すように、出力待ち行列が空ではない場合は、常に、周期的に（１０ｍｓごとに）ウェイクアップすることになる。各周期の間に、ドライバは、存在する利用可能トークンと同数のバイトをデキューすることが可能となり、各周期の開始時に、それらのトークンが補充される。トークンの数は、ＴＢＲに構成されている速度に従って計算される。１つの特定のＴＢＲの実施は、（ＢＳＤによって取られる手法とは異なり）コールアウトを割り当てることを必要とせず、このことにより、周期が固定され、それゆえコールアウトの解決から独立する（異なるプラットフォームにわたって１０ｍｓが達成可能である）ため、極めて低いＣＰＵのオーバーヘッドを伴う、極めて高い速度（数十Ｇｂｐ）に適応することができる。
送信待ち行列（図５に示す一実施形態）
【００５７】
ｉｆｎｅｔのｉｆ＿ｓｎｄメンバーは、インターフェースに関する送信待ち行列を保持する。このデータ構造は、組み込みスケジューラ（タイプ、インスタンス、コールバック）、ＴＢＲ、及び任意選択的に代替スケジューラについての、情報を含む。
【００５８】
デフォルトにより、一実施形態では、このシステムは、パケットスケジューラの組み込みインスタンス（ｉｆｃｑインスタンス）を作成する。上述のように、パケットスケジューラ及びそのパラメータの選択は、ネットワークインターフェースのタイプに応じて、また場合によっては、ネットワークのトポロジーに応じても決定される。一実施形態では、パケットスケジューラが接続されると、ｉｆｃｑインスタンスは、ｉｆｃｑ＿ｄｉｓｃ内にそのインスタンスを記憶して、スケジューラの対応するルーチンへのｅｎｑｕｅｕｅ（）、ｄｅｑｕｅｕｅ（）、及びｒｅｑｕｅｓｔ（）のコールバックを構成する。「ドライバ管理」モデルを必要とするインターフェースに関しては、ｄｅｑｕｅｕｅ（）コールバックの代わりに代替的なｄｅｑｕｅｕｅ＿ｓｃ（）を提供する、特別なスケジューラが接続される。これらのコールバックの具体的実施形態は、以下の通りである。
【表２】
0005893762.tif 000004
【００５９】
スケジューラ１１６の一実施形態は、Ｎ個の数のクラスをインスタンス生成し、各クラスは、サービスクラスに相関して、待ち行列インスタンス１１０〜１１２を管理する。パケットは、それらがどのように分類されるかに応じて、これらの待ち行列インスタンスのうちの１つにエンキューされる。ＰＦ＿ＡＬＴＱ対応が構成される場合、組み込みスケジューラ及びそのパラメータは、パケットフィルタ（ＰＦ）インフラストラクチャを介して（例えば、ｐｆｃｔｌ（８）によって）上書きすることができる。このことは、パケットスケジューリングの種々の特性をモデル化する（例えば、種々のスケジューラ及び／又はパラメータを試行する）ための簡便な方法を提供する。
パケットスケジューラ１１６
【００６０】
パケットスケジューラモジュール１１６の一実施形態は、パケットを、そのクラス待ち行列インスタンス２１０のうちの１つにエンキューし、そこからデキューするための、入口点を提供する。一実施形態では、各クラスは、１つの待ち行列に対応する。パケットスケジューラは、スケジューリングアルゴリズム及びパラメータに応じて、その待ち行列の全てを管理する。
【００６１】
一実施形態では、スケジューラ１１６は、以下の技術のうちの１つを通じて構成され、ｉｆｎｅｔに接続される。
【００６２】
１．組み込み（静的）：インターフェースが、ネットワーキングスタックに接続されている場合、スケジューラは、ドライバによってリクエストされる待ち行列スケジューリングモデルに基づいて選択される。「通常」モデルに関しては、スタックは、１０個のクラス（それゆえ、１０個の待ち行列）を有するスケジューラを作成する。「ドライバ管理」モデルに関しては、４つのクラスを有する特別なスケジューラのインスタンスが、代わりに作成される。
【００６３】
２．ＰＦ（動的）：一実施形態では、組み込み（静的）構成は、ＰＦフレームワークを介して、スケジューラ及びそのパラメータを構成することによって、上書きすることができる。このことには、ＰＦ＿ＡＬＴＱ構成オプションが有効であり、かつ「ａｌｔｑ＝１」の起動時引数ＮＶＲＡＭオプションが存在することが必要とされる。一実施形態では、それは、デフォルトにより有効／可能ではない。しかしながら、有効である場合、それは、種々のスケジューラ及びパラメータで試験するための、簡便かつ好都合な機構を可能にする。
【００６４】
一実施形態では、以下のスケジューラは、デフォルトでは使用されず、ＰＦでのみ利用可能である。
【表３】
0005893762.tif 000005
【００６５】
一実施形態では、以下のスケジューラは、デフォルトにより（すなわち、ネットワーキングスタック層１０２で）使用される。
【表４】
0005893762.tif 000006
マッピング
１．１：１マッピング
【００６６】
図６に示すように、ネットワーク層管理スケジューリングに関する一実施形態で使用される、ＱＦＱ構成は、パケットサービスクラス６０１〜６１０とパケット待ち行列インスタンス６１１〜６２１とのそれぞれの間に、１：１マッピングを提供する。図示のように、１０個のサービスレベルが、４つのグループ６３０、６４０、６５０、６６０に大別され、各グループ内部に優先順位付けが提供される。これらのグループは、遅延耐性（低〜高）、損失耐性（低〜高）、弾性フロー対非弾性フロー、並びに、パケットサイズ及びパケット速度などの他の因子の観点から分類されたトラフィックの特性に基づいて、定義される。本明細書で説明されるように、「弾性」フローは、比較的固定された帯域幅を必要とするものであり、その一方で、「非弾性」フローは、非固定の帯域幅が許容可能なものである。図示の１：１マッピングにより、ネットワーキングスタックは、各サービスクラスの挙動及び差別化に対する完全な制御を達成することが可能となり、パケットは、それがどのように分類されたかに従って、これらの待ち行列のうちの１つへと直接エンキューされ、デキューの間に、スケジューラは、最も適格な待ち行列から送信されるべきパケットを判定する。
２．１０：４マッピング
【００６７】
図７に示すように、一実施形態でドライバ管理スケジューリングに関して使用されるＴＣＱ構成は、１０個のサービスクラス６０１〜６１０と４つの待ち行列インスタンス７０１〜７０４との間に、１０：４マッピングを提供する。このスケジューラは、いずれの種類のパケットスケジューリングも実行せず、その代わりに、単に待ち行列インスタンスを提供して、それらの待ち行列にサービスクラスをマッピングするという意味で、受動的である。この実施形態のネットワーキングスタックは、スケジューリングに対する制御を有さないため、待ち行列は、１：１マッピングに関するものと同様の特性で定義することができない。その代わりに、低（Ｌ）〜最高（Ｈ＋）の範囲の優先度を有するとして、認識することが可能である。パケットは、元来そのパケットが分類されていたサービスクラスを表す、待ち行列のうちの１つへと、直接エンキューされる。デキューの間に、ドライバは、送信に関して最も適格なサービスクラスを選択する責任を負う。待ち行列の数は、４つに設定され、実施アーチファクトであるが、上述のように、これはまた偶然にも、８０２．１１  ＷＭＭのアクセスカテゴリの数でもある。
待ち行列処理規範
【００６８】
一実施形態では、待ち行列処理規範又はアルゴリズムのモジュールが、クラス待ち行列の単一のインスタンスを管理し、待ち行列は、単に１つ以上のパケット（ｍｂｕｆ）のみからなる。このアルゴリズムは、パケットをエンキュー又は破棄するべきか否かを判定することに関与する。
【００６９】
一実施形態では、待ち行列処理アルゴリズムは、以下の方法のうちの１つを通じて構成され、スケジューラクラスのインスタンスに接続される。
１．組み込み（ネットワークスタック管理）：スケジューラクラスが、ｉｆｎｅｔ上にパケットスケジューラを構成する一部としてインスタンス生成される際、待ち行列処理アルゴリズムが選択される。スケジューラの全てのクラスは、同じ待ち行列アルゴリズムを共有する（それぞれが、それ自体の固有のインスタンスを有する。）
２．ＰＦ（動的、又はドライバ管理）：あるいは、組み込み（静的）構成は、パケットフィルタ（ＰＦ）フレームワークを介して、スケジューラ及びそのパラメータ（それらのクラスに関する待ち行列処理アルゴリズムを含む）を構成することによって、上書きすることができる。
アルゴリズム
【００７０】
一実施形態では、以下の待ち行列処理アルゴリズムは、デフォルトでは使用されず、ＰＦを介してのみ利用可能である。
【表５】
0005893762.tif 000007
パケット分類
【００７１】
上述のように、一実施形態では、各アウトバウンドパケットは、そのパケットのサービスクラスに対応する、クラス待ち行列インスタンス内にエンキューされる。サービスクラスの割り当て、すなわちパケット分類は、ネットワーキングスタックの全体にわたって幾つかの箇所で実施される。一般的には、パケット分類は、明示的（アプリケーションによってオプトインされる）か、又は暗黙的（システムによって設定又は上書きされる）とすることができる。
【００７２】
明示的分類：一実施形態では、アプリケーションは、図８でサービスクラスにマッピングされて示される、以下のトラフィックサービスクラス値のうちの１つを使用して、ＳＯ＿ＴＲＡＦＦＩＣ＿ＣＬＡＳＳオプションを（ｓｅｔｓｏｃｋｏｐｔ（２）を介して固定的に、又はｓｅｎｄｍｓｇ（２）を使用してメッセージごとに）発行することによって、そのトラフィックを分類することができる。
【表６】
0005893762.tif 000008
0005893762.tif 000009
【００７３】
それゆえ、一実施形態では、このシステムは、ネットワーク制御パケットを最も高い優先度の分類に割り当てることにより、制御パケットが、全ての下位の分類を有するパケットに先立って転送されることが保証される点を、上記から理解することができる。このことは、特定の制御パケット（例えば、ＴＣＰ確認応答（ＡＣＫ）パケットなど）が、他のタイプの非制御パケットの後で、待ち行列内に足止めされる（それによりシステムの性能が低下する）可能性がある、先行のシステムに勝る改善である。
【００７４】
一実施形態では、バックグラウンドシステム起動型（ＳＯ＿ＴＣ＿ＢＫ＿ＳＹＳ）として分類されるいずれのパケットも、クライアント装置上で音声呼び出しが実施されている間は、待ち行列内で一時停止されることになる。それゆえ、この実施形態は、低い優先度のパケット（例えば、バックグラウンドシステム起動型パケット）が送信される結果として、音声呼び出しが劣化するか又は破棄される可能性がある、先行のシステムに勝る、著しい利益を提供する。それゆえ、この実施形態では、サービス（例えば、ｉＣｌｏｕｄなど）にバックアップされる、ユーザーのフォトストリーム又は他のデータは、音声呼び出しと干渉することがない。
【００７５】
このシステムの一実施形態は、バックグラウンドシステム起動型としてマークされるトラフィックを防ぐことができるため、それらのトラフィックは、着信電話の呼び出しと干渉せず、それにより呼び出しの信頼性が向上する。電話の呼び出しが開始されると、ネットワーク層（例えば、ＴＣＰ／ＩＰ層）は、全てのバックグラウンドシステム起動型トラフィックを一時停止するための、フロー制御通知を受け取ることになる。それに応じて、ネットワーク層は、インターフェースにそれ以上のパケットを送り出すことを、停止することができる。ネットワーク層はまた、アプリケーションが、ネットワークスタックにそれ以上のデータを書き込むことも、阻止することができる。このことは、アプリケーションが静止されることにより、ＣＰＵの利用率を改善する助けとなり、また、音声呼び出しの信頼性も改善する。音声呼び出しが、妥当な持続時間で完了する場合には、アプリケーションは、データ通信を再開することができる。
【００７６】
一実施形態では、より低い優先度の特定のアプリケーションが一時停止されると、ネットワークスタック１０２は、（周期的に）通信リンクを（例えば、フィードバック信号１７１を介して）精査して、いつ送信を再開することができるかを判定し、この情報を、対応するアプリケーションに通信することになる。そのリンクにもはや負荷がかかっていない場合、次いで、パケット送信が再開することになる。
【００７７】
要約すると、ドライバ層１５０とネットワーキングスタック１０２との間の継続的なフロー制御フィードバック１７１、及びネットワーキングスタックとアプリケーション１０５〜１０７との間のフィードバック１７２は、ネットワークチャネル及び帯域幅の、よりインテリジェントで効率的な割り当てを提供する。
【００７８】
一実施形態では、上記の値は、保証を暗示するものではなく、むしろ、そのトラフィックの特性についての、アプリケーションからシステムへのヒントである。このシステムは、トラフィックの分類に基づいて、トラフィックに対する何らかの形態の差別化を提供する際に、最善を尽くすことになるが、パケットスケジューリングのパラメータからネットワークトポロジー又は媒体条件までの範囲に及ぶ変動要因により、保証されるものではない。
【００７９】
一実施形態では、上記の値のうちの１つに関連付けられたソケットによって生成されるトラフィックは、対応するサービスクラスの値を、待ち行列／バッファ（ｍｂｕｆ）内に伝達することになり、図８に示すように、ＳＯ＿ＴＣ値とＭＢＵＦ＿ＳＣ値との間には、１：１マッピングが存在する。
【００８０】
図９Ａは、組み込みＱＦＱスケジューラ構成を有する一実施形態での、リンク共有配分の最悪ケースのシナリオを示す。ソケットレベルの分類に加えて、カーネルの全体にわたる幾つかの箇所は、ＭＢＵＦ＿ＳＣ＿ＣＴＬサービスクラスを使用して、特定の制御タイプのパケット（例えば、ＡＲＰ、ＮＤ  ＮＳ／ＮＡ、ＩＧＭＰ／ＭＬＤ）を分類する。このことはまた、ＴＣＰ  ＡＣＫによって使用されるサービスクラスの、一時的な上昇も含む。
【００８１】
暗黙的分類：この形態の分類は、パケットフィルタ（ＰＦ）フレームワークを介して可能である。このフレームワークは、分類のルールが、ＰＦを介してインストールされ、全てのＩＰトラフィックに対して、それらが起点で元来どのように分類されていたかに関わらず、効力を発することを可能にする。ＰＦ及びｐｆｃｔｌ（８）は、サービスクラス関連のキーワードで拡張されており、図９Ｂは、組み込み設定を上書きするためにｐｆｃｔｌ（８）によって処理することが可能な、ＰＦ構成ファイルの実施例を示す。
【００８２】
それゆえ、明示的分類の場合には、アプリケーションは、デフォルトのサービスクラス（ＢＥ）を有するソケットを開く。アプリケーションは、ＳＯ＿ＴＲＡＦＦＩＣ＿ＣＬＡＳＳソケットオプションを介して、そのソケットのサービスクラスを設定することができ、それゆえ、全ての将来の送信／書き込み動作は、自動的に、パケットを、対応するサービスクラスでマークさせることになる。アプリケーションは、そのソケットに送り出される各データグラムを、ＳＯ＿ＴＲＡＦＦＩＣ＿ＣＬＡＳＳ補助メッセージオプションと選択的に関連付けるように選択することができ、それゆえ、関連付けられたパケットは、対応するサービスクラスでマークされることになる（しかしながら、他の現在のパケット又は将来のパケットに影響を及ぼすことはない）。この場合には、多くの異なるサービスクラスを、このソケットと、容易に関連付けることができる。
【００８３】
暗黙的分類の場合には、分類のルールは、パケットフィルタエンジン内にインストールされる。各ルールはシグネチャ（例えば、プロトコル、ポートなど）を含み、このシグネチャは、一致すると、パケットがサービスクラスでマークされる結果をもたらす。
【００８４】
分類タグ。待ち行列／バッファ（ｍｂｕｆ）をＭＢＵＦ＿ＳＣ値でマークすることに加えて、一実施形態では、パケット分類を実行するモジュール２０２はまた、パケットのタイプ又はフローをシステムの残部が特定することを支援するために、１つ以上のタグをパケットと関連付ける。一実施形態では、これらのタグは、ｍｂｕｆの組み込みｐｆ＿ｍｔａｇ下部構造内部に存在し、どのように分類が実行されるか（明示的又は暗黙的）に関わリなく、設定される。一実施形態で採用されるタグは、以下の通りである。
【表７】
0005893762.tif 000010
フローフィードバック
【００８５】
フローハッシュ：図１０Ａに示すように、一実施形態では、インターフェースを通じて送り出されている各ｍｂｕｆは、フローハッシュ１００１でタグ付けされ（それゆえ、ＰＦ＿ＴＡＧ＿ＦＬＯＷＨＡＳＨでマークされ）、このことは、インターフェース層で、特定のフローに属する全てのパケットを識別するために役立つ。一実施形態では、フローハッシュ１００１は、３２ビットの整数であり、以下の箇所のうちの１つで算出される。
【００８６】
１．ソケット２０４。一実施形態では、ソケットが接続されると、そのソケット２０４に関するフローハッシュが計算され、記憶される。このソケットに対する更なる送信は、それらのパケットのｍｂｕｆ構造内部に、そのハッシュ値を伝達させることになる。
【００８７】
２．パケットフィルタ（ＰＦ）。一実施形態では、パケットがドライバ１５０に入ると、それが既に分類されていない限り、フローハッシュが計算され、関連するＰＦルール及び状態内に記憶される。そのパケットをＩＰ  ２０６に戻すことが成功する場合には、そのパケットが照合されたルール又は状態と関連付けられたフローハッシュを、そのパケットと共に、ｍｂｕｆ構造内に伝達することになる。
【００８８】
一実施形態では、フローハッシュを計算するために使用されるハッシングアルゴリズムは、性能に応じて、コンピューティングシステムのプラットフォームごとに異なる。以下の表は、例示的なプラットフォーム及び対応するハッシュを示す。
【表８】
0005893762.tif 000011
【００８９】
ＴＣＰに関するフロー制御＆アドバイザリ：ＴＣＰを使用して送信するアプリケーションは、インターフェースで待ち行列に入れられるフローごとのパケットの数が上限に達する場合、本明細書で説明される待ち行列管理技術を使用して、フロー制御される。明示的な輻輳通知（ＥＣＮ）又はパケット破棄のような指標を使用する代わりに、インターフェースは、フローアドバイザリフィードバックを、トランスポート層に提供する。このことは、いずれのパケット損失も伴わずに行なうことができる。
【００９０】
以下の２つの条件のうちの一方が真である場合、接続に対するフローアドバイザリが、ＡＱＭから受け取られる。
１．ＴＣＰの送信速度が、そのリンク上で対応する帯域幅を超えて増大する。
２．その装置からの、最初のホップである無線リンク上の利用可能な帯域幅が、低下する。
【００９１】
これらの場合の双方で、より多くのパケットを送信することは、インターフェース待ち行列内にパケットを蓄積させることになり、アプリケーションによって経験される待ち時間を増大させることになる。他の場合には、パケット破棄を引き起こす可能性があり、このことは、ＴＣＰ送信器がそれらのパケットを再送信しなければならないため、性能を低下させることになる。フローアドバイザリ機構を使用することによって、ＴＣＰ送信器は、いずれのパケット損失又はいずれの性能の損失も見ることなく、利用可能な帯域幅に適応することができる。インターフェース待ち行列は、ＴＣＰパケットを決して破棄することはないが、接続に対してフローアドバイザリのみを送信することになる。この機構により、装置ドライバ内のバッファリングは著しい量で低減され、装置上の全てのＴＣＰ接続に関する待ち時間の改善を結果的にもたらす。
【００９２】
フローアドバイザリに対するＴＣＰ接続の主な応答は、その輻輳ウィンドウを低減することであり、このことにより、その接続の送信速度が、実際に低減することになる。このことは、スロースタート閾値を後退させ、その接続が輻輳回避段階に入ることを可能にすることによって、実施される。しかし、接続が既に回復期にある場合には、その接続が、そのラウンドトリップ時間内で既にパケット損失を経験しており、その送信速度を既に低下させていることを意味する。この場合には、輻輳ウィンドウが更に低減されることはない。
【００９３】
フロー制御されている接続は、フロー制御が解除されるまでは、ソケットを書き込み可能にすることを回避する。このことにより、アプリケーションは、ネットワークスタックがインターフェース上にパケットを送り出すことができない場合、そのネットワークスタック内に単にバッファリングされていく可能性がある、より多くのデータを書き込むことを阻止される。このことは、最新の更新のみを送信する必要があり、より古い更新はむしろ廃棄する、対話型アプリケーションに役立つ。
【００９４】
フロー制御状態にある間、重複確認応答又はＳＡＣＫ情報の形態で受信されたＴＣＰ確認応答内に、パケット損失の指示が存在する場合には、その接続は、フロー制御を打ち切り、損失データを直ちに再送信するために、高速回復を開始することになる。回復の間に送信されるパケットの速度は制限されるため、このことにより待ち時間がそれ以上増大することはない。インターフェースは、いずれのＴＣＰパケットも破棄しないように保証されているため、その接続は、可能な限り迅速に損失データを再送信することが可能となる。
【００９５】
接続がフロー制御状態にある場合、それは、パケットが以前よりも低速でインターフェースを離脱していることを意味する。この状況では、送信される準備が整っている、インターフェース待ち行列内で待機するパケットが存在し得る。通常、これらは、最後の送信ウィンドウの終端のパケットである。この待機時間が、その接続に対して算出される再送信タイムアウトを超える場合には、タイムアウトが発火することになる。この時点で、既に送信されたデータを再送信することは、インターフェース待ち行列内に、同じパケットの重複コピーを作成する可能性がある。このことは、後に重複確認応答を生成して、その接続を不必要に回復期に入らせる恐れがある。
【００９６】
この混乱を回避するために、フロー制御ＴＣＰ接続は、後になるまで、再送信タイマーからパケットを再送信することを回避する。待機が過度に長い場合には、いつまでも待機するのではなく、接続をタイムアウトさせることができ、アプリケーションにはエラーが返されることになる。
【００９７】
再送信タイムアウトが発信されるたびに、タイマーは、再試行する前に、後退される。このことは、リンク上での遅延の急増を検出するために役立つ。しかしながら、フロー制御されたソケットに関しては、遅延は、そのフローが一時的に遮断されることの結果である可能性がある。接続が、フロー制御状態から抜け出すと、後退は取り消される。このことは、その時点から、再送信タイマーを適時に起動させるために役立つ。
【００９８】
インターフェース待ち行列内のパケットが流れ出て、待ち行列レベルが閾値を下回ると、インターフェースは、フロー制御されていた全てのフローに、再びデータの送信を開始させるための、フローアドバイザリを生成する。この時点で、ＴＣＰソケットもまた、書き込み可能となり、アプリケーションは、データの書き込みを開始することができる。
【００９９】
フロー制御が解除されると、その接続は、以前は決して送信されなかった新たなデータを送信することになる。このことは、新たな確認応答を生成して、ＡＣＫタイマーを開始させることになる。これはまた、それまでに検出されなかった、フロー制御以前の何らかのデータ損失が、存在していたか否かを検出するためにも役立つ。送信される新たなデータが存在しない場合には、再送信タイマーは、すぐに発火することになり、確認応答されていない、いずれかの未処理データの再送信をトリガすることになる。
【０１００】
フローアドバイザリ及びフロー制御機構を使用して、ＴＣＰ接続は、リンク帯域幅の変動に適応することが可能となり、ホスト上の複数のレベルでパケットをバッファリングすることによって誘発される遅延を、最小限に抑えることが可能となる。
【０１０１】
ＵＤＰに関するフロー制御＆アドバイザリ：一実施形態では、ＵＤＰソケットは、ｃｏｎｎｅｃｔ（）システムコールを使用してピアに接続される場合にのみ、フロー制御が可能である。インターフェース待ち行列内の、ＵＤＰフローからのパケットの数が、フロー制御に関する制限を超えると、アドバイザリが生成される。このソケットは、その時点で、フロー制御されるとしてマークされる。ＴＣＰとは異なり、インターフェース待ち行列は、それ以降に生成される全てのＵＤＰパケットを破棄することになる。ソケットは書き込み不能となり、このことは、ｓｅｌｅｃｔ又はｐｏｌｌ又はｋｅｖｅｎｔシステムクラスを使用して書き込みイベントを待機しているアプリケーションが、フロー制御が解除されるまでイベントを取得しないことを意味する。アプリケーションが、いずれかの方法でソケットにデータを書き込む場合には、そのパケットは、ソケット層によって破棄され、エラー（ＥＮＯＢＵＦＳ）が返されることになる。
【０１０２】
このことは、全てのＵＤＰ書き込みが成功するものの、結局はドライバによって後にパケットが破棄された、従前の挙動とは異なる。ＵＤＰフロー制御及びアドバイザリは、アプリケーションに即時にフィードバックを与えることにより、それらのアプリケーションは、その送信速度を即時に低減することができる。例えば、ビデオアプリケーションは、より少ないデータをネットワークを介して送信するように、その符号化を変更することができる。
【０１０３】
パケットは、フロー制御されたＵＤＰソケット上のソケット層で破棄されるため、パケットが処理されてドライバに至るまで送信されるものの、結局は破棄された従前と比較して、多大なＣＰＵ利用率が節約される。別の有利点は、フロー制御されたＵＤＰのフローは、インターフェースを圧倒することができない点である。このことは、引き起こされるパケット損失を低減し、ホスト上の他のフローに関する待ち時間を改善することになる。
【０１０４】
一実施形態では、インターフェース層でのフローの追跡が、待ち行列処理アルゴリズムとしての確率的公平Ｂｌｕｅ（ＳＦＢ）（本特許出願の付録Ｂを参照）の使用により、可能となる。一実施形態では、このＳＦＢの実施は、２レベルのブルームフィルタを使用し、それにより、フロー（フローハッシュ値１００１によって指示されるようなフロー）は、各ＳＦＢレベル１００９で、正確に１つのビンにマッピングされる。この実施形態の各ビンは、パケットの数、並びにフローの破棄／マークの確率を追跡する。一実施形態では、ＳＦＢはまた、フロー制御されているフローのリストも追跡する。フロー制御及びフローアドバイザリの閾値は、ビンの割り当てに基づく（現在、待ち行列限度の１／３に設定される）。ビンの確率は、適宜に更新されるが、現在、速度制限のためには使用されない。
フローの一時停止＆再開
【０１０５】
一実施形態では、「日和見的」としてマークされる特定のソケットは、ネットワークインターフェースが制限調整されると、一時停止される。そのようなソケットによって生成されるパケットは、一実施形態では、影響を受ける待ち行列上にエンキューされる場合、破棄されることになる。一実施形態では、そのソケット上のトラフィックが無期限で遮断されることをアプリケーションに通知するために、ＮＯＴＥ＿ＳＵＳＰＥＮＤＥＤイベントが、そのソケット上に生成される。次いで、アプリケーションは、接続を打ち切るべきか否かを判断することができる。インターフェースがもはや制限調整されない場合、影響を受ける待ち行列は、もはやパケットを遮断することなく、ＮＯＴＥ＿ＲＥＳＵＭＥＤイベントが、影響を受けるソケット上に生成される。内部では、同じ機構がフロー制御によって使用される場合があり、アドバイザリが、一時停止及び再開を実施するために使用される。
インバウンドのネットワーク層スケジューリングモデル
【０１０６】
一実施形態の日和見的ポーリングは、図１１Ｂに示すようなネットワークドライバ入力モデルを使用する。ドライバ構成要素１１１１が、着信パケットに関してハードウェア１１１２にポーリングし、ＩＯネットワーキングインターフェース１１１０が、ドライバにポーリングする。各受信待ち行列インスタンスは、デキューされ（３）、ネットワークスタック１１０８へと上に移動され（４）、続いて、リクエスト側アプリケーション１１０７（このアプリケーションは、（６）で示されるように、新たなパケットに関して、関連付けられている受信待ち行列インスタンス１１０９にポーリングする）へと上に移動される（５）準備が整っている、その受信待ち行列に関連付けられるいずれかのパケットが存在するか否かを判定するために、ドライバ１１１１のＩＰネットワーキングインターフェース１１１０にポーリングする（３）。
【０１０７】
それゆえ、この新たなモデルでは、インバウンドパケットは、もはや、図１１Ａの動作１〜６によって示されるように、ドライバ／ファミリによってネットワーキングスタックへと押し上げられない。その代わりに、インバウンドパケットは、ネットワーキングスタック１１０８によってデキューされるまで、ドライバの受信待ち行列１１０９内に存在する。一実施形態では、このことは、クライアント装置ハードウェアの受信割り込み（ＩＲＱ）をオフにすることを伴う。この説明される実施形態が独特である１つの理由は、ネットワーキングスタック１１０８が（ドライバと関連して）、負荷率に応じて、ポーリング（図１１Ｂ）と旧来のモデル（図１１Ａ）との間で交互に切り換わる点である。一実施形態では、負荷が所定の閾値（例えば、ドライバの待ち行列内に蓄積されるパケットの、指定のレベル）に到達すると、このシステムは、旧来のモデル（図１１Ａ）に遷移することができる。旧来のモデルに遷移すると、ハードウェアの受信ＩＲＱがオンになり、ドライバ１１０５は、ＩＯネットワーキングインターフェース１１０４から、適切な受信待ち行列インスタンス１１０３へと、また最終的には、ネットワークスタック１１０２を介して、リクエスト側アプリケーション１１０１へと、パケットを押し上げる。
カーネルプログラミングインターフェース（ＫＰＩ）
【０１０８】
一実施形態では、上記の構成に適応するために、プライベートＫＰＩのセットが採用される。
ｉｆｎｅｔ＿ａｌｌｏｃａｔｅ＿ｅｘｔｅｎｄｅｄ（）
【０１０９】
新たな入力モデルに対応するｉｆｎｅｔインスタンスを割り当て、幾つかの関連フィールドを有する。
【表９】
0005893762.tif 000012
ｉｆｎｅｔ＿ｉｎｐｕｔ＿ｅｘｔｅｎｄｅｄ（）
【０１１０】
ｉｆｎｅｔ＿ｉｎｐｕｔ（）に類似しているが、ただし、ドライバ１１１１は、ネットワーキングスタック１１０８に、パケットチェーンの開始及び終了、並びにパケット及びバイトの総計に関連する、情報の全てを提供する。この情報を既に保有するドライバは、この新たな変異型を利用するように推奨されるが、これは、より良好な効率を可能にするためである。これは、ドライバが、新たなモデル（図１１Ｂ）を採用するか否かに関わりなく、使用することができる。
【０１１１】
一実施形態では、新たな入力モデル（図１１Ｂ）に対応するとして、それ自体を登録しているドライバは、ＩＦＥＦ＿ＲＸＰＯＬＬフラグを使用して、フラグが立てられる。
データリンクインターフェース層（ＤＬＩＬ）２０８
【０１１２】
入力スレッド：一実施形態では、ネットワーキングスタックの全体にわたる入力パケット処理は、ＤＬＩＬ入力スレッドのコンテキストの範囲内で実施される。一部のインターフェースは、それ自体の専用の入力スレッドを有するが、他のものは、共通の（メイン）入力スレッドを共有する。一実施形態では、ＤＬＩＬ入力スレッドの３つの変異型が存在する。
【０１１３】
１．メイン
【０１１４】
一実施形態では、このメイン入力スレッドは、ループバックインターフェース、並びにそれ自体の専用の入力スレッドを取得しない他のインターフェース（すなわち、Ｅｔｈｅｒｎｅｔ（登録商標）／ＰＤＰ以外の全て、又はＲＸＰＯＬＬに対応しないもの）によって使用される。このスレッドはまた、全てのプロトコル登録及びパケット注入に対処するためにも使用される。これは、ｄｌｉｌ＿ｍａｉｎ＿ｉｎｐｕｔ＿ｔｈｒｅａｄ＿ｆｕｎｃ（）内に実施される。
【０１１５】
２．旧来
【０１１６】
一実施形態では、レガシーは、ＲＸＰＯＬＬモデルを採用しないＥｔｈｅｒｎｅｔ（登録商標）／ＰＤＰインターフェースによって使用され、ｄｌｉｌ＿ｉｎｐｕｔ＿ｔｈｒｅａｄ＿ｆｕｎｃ（）内に実施される。
【０１１７】
３．ＲＸＰＯＬＬ
【０１１８】
一実施形態では、ＲＸＰＯＬＬは、ＲＸＰＯＬＬモデルを採用する任意のインターフェースによって使用され、ｄｌｉｌ＿ｒｘｐｏｌｌ＿ｉｎｐｕｔ＿ｔｈｒｅａｄ＿ｆｕｎｃ（）内に実施される。
ポーラースレッド
【０１１９】
一実施形態では、新たな入力モデル（ＲＸＰＯＬＬ）に対応するインターフェースは、専用のカーネルスレッドである、（図１２の１２０２に示す）「ポーラースレッド」を使用し、このスレッドのジョブは、ドライバから１つ以上のパケットを取得するために、ドライバのｉｎｐｕｔ＿ｐｏｌｌ（）コールバックを起動することであり、このことは、ポーリングがＯＮである場合に実施され、そうではない場合、ポーラースレッド１２０２は、休止状態のままである。このスレッドは、図１２の１２０１に示すワークループスレッドに類似しており、それらは双方とも、ＲＸＰＯＬＬ対応ＤＬＩＬ入力スレッドの受信待ち行列にパケットを預けるために、ｉｆｎｅｔ＿ｉｎｐｕｔ（）を結果的に呼び出す。
【０１２０】
次いで、パケットは、このＤＬＩＬ入力スレッドのコンテキストから、更なる処理のために、ネットワーキングスタックを上り方向に送信される。
日和見的ポーリング
【０１２１】
一実施形態では、ＲＸＰＯＬＬ対応インターフェースは、ＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＦＦモードとＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＮモードとの間で遷移する。一実施形態では、前者は、デフォルト／初期モードであり、ネットワークスタックは、負荷率が低いことを判定する場合に、このモードをインターフェースのために選択する。この負荷率は、現在、ＤＬＩＬ受信待ち行列内のパケット及びバイトのＥＷＭＡ（Ｐ＿ａｖｇ、Ｂ＿ａｖｇ）、並びにＤＬＩＬ入力スレッドのウェイクアップリクエストのＥＷＭＡ（Ｗ＿ａｖｇ）を考察することによって判定される。
【０１２２】
図１２のＤＬＬ入力スレッド１２０３を参照すると、一実施形態では、ＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＮへの切り換えは、（Ｐ＿ａｖｇ≧Ｐ＿ｈｉｗａｔ＆＆（Ｂ＿ａｖｇ≧Ｂ＿ｈｉｗａｔ｜｜Ｗ＿ａｖｇ≧Ｗ＿ｈｉｗａｔ））の場合に行われ、式中、Ｐ＿ｈｉｗａｔ、Ｂ＿ｈｉｗａｔ、及びＷ＿ｈｉｗａｔは、それぞれ、パケット、バイト、及びウェイクアップリクエストに関する高基準値である。逆に、ＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＦＦへの切り換えは、（Ｐ＿ａｖｇ≦Ｐ＿ｌｏｗａｔ＆＆Ｂ＿ａｖｇ≦Ｂ＿ｌｏｗａｔ＆＆Ｗ＿ａｖｇ≦Ｗ＿ｌｏｗａｔ）の場合に行われ、式中、Ｐ＿ｌｏｗａｔ、Ｂ＿ｌｏｗａｔ、及びＷ＿ｌｏｗａｔは、それらの変数に関する低基準値である。
【０１２３】
一実施形態では、これらの低基準値及び高基準値は、現在、特定の作業負荷に基づいて任意に選択されており、それらは、将来の作業負荷（及び変動するリンク速度）に適応するように、適宜に調整されるべきである。
【０１２４】
一実施形態では、この混成ポーリング論理の大部分は、ｄｌｉｌ＿ｒｘｐｏｌｌ＿ｉｎｐｕｔ＿ｔｈｒｅａｄ＿ｆｕｎｃ（）内部に存在し、モード間の遷移は、上記の論理に基づいて、ドライバのｉｎｐｕｔ＿ｃｔｌ（）コールバックを呼び出すことによって発生する。遷移を速度制限するように注意が払われることにより、それらの遷移が過度に頻繁に生じることはない（保持時間は、デフォルトで１秒に設定される）。
【０１２５】
図１２は、ポーリングがＯＦＦ／ＯＮされる場合の、スレッド１２０１〜１２０３の間の関連性の一実施形態を示す。
【０１２６】
一実施形態では、ポーリングＯＦＦ／ＯＮモードの間の主な相違は、ｉｆｎｅｔ＿ｉｎｐｕｔ（）若しくはｉｆｎｅｔ＿ｉｎｐｕｔ＿ｅｘｔｅｎｄｅｄ（）を呼び出す際の、コンテキスト及び頻度にある。
【０１２７】
一実施形態では、ポーリングがＯＦＦである場合、ホストＣＰＵがハードウェアからの受信ＩＲＱに対処する一部として、ワークループスレッド１２０１がスケジュールされ、このＩＲＱは、その装置が１つ以上のパケットを（例えば、ＤＭＡを介して）ホストに転送していることを、ホストにシグナルする。ハードウェアで行われるＩＲＱ結合のレベルに関わりなく、このＩＯＫｉｔワークループスレッドをスケジュールさせる頻度は、インバウンドパケットの速度によって決定される。このスケジューリングに関連付けられるコスト（コンテキスト切り換えなど）は、特に、出願人らのシステムアーキテクチャが、全てのＩＲＱをＣＰＵ０に経路指定するという事実を考慮すると、極めて多大である。それゆえ、一実施形態では、高い負荷率を検出すると、ポーリングがＯＮになる。
【０１２８】
ポーリングがＯＮであるとき、ワークループスレッド１２０１は、受信ＩＲＱをオフにすることにより静止される。パケットは、依然として、装置からホストに転送され、それらのパケットは、ｉｎｐｕｔ＿ｐｏｌｌ（）コールバックを介してネットワーキングスタック１１０８によって取得されるまで、ドライバ１１１１の受信バッファ内に蓄積する。ポーラースレッド１２０２は、この時点でアクティブであり、ワークループスレッド１２０１の同等の機能性を実行するが、ただし、このスレッドがスケジュールされる頻度は、ネットワーキングスタック１１０８によって厳密に制御される。
【０１２９】
一実施形態では、ポーリングは、媒体からのパケットの受信に関連する、パケットごとの処理コストの償却を考慮すると、結果的に性能の改善をもたらす。ポーリングがＯＮになると、ネットワークスタックは、ドライバに、ポーリングモードに入るように指示する。ポーリングモードにある間、ドライバは、ハードウェアから到着するパケットの通知に関連付けられる、そのドライバの受信割り込み又はトラップハンドラをＯＦＦにする。パケットは、ホストのメモリに（ＤＭＡ又は均等物を介して、装置から）到来し続けるが、ただし、ＣＰＵが割り込みをかけられることはない。このことにより、ＣＰＵに対する負荷が低減されるが、これは、各割り込みが、通常であれば、その割り込みを処理するための一連の作業をトリガするためであり、また、その時点でＣＰＵ上で実行されている全てのものに取って代わるため、性能に対して、ある程度の悪影響を有するためである。次いで、ネットワークスタックは、１ミリ秒間隔で（デフォルトにより、これは構成可能である）ポーリングして、各間隔中に、ドライバからパケットを引き出す。そのネットワークスタックが、パケット速度が低下していることを検出した場合には、ポーリングモードが終了され、割り込みが再び有効にされる。
【０１３０】
一実施形態では、ポーリングは、電力消費を低減するために（例えば「低電力」モードである場合）、又はユーザー活動（又は非活動）に基づいて、採用することができる。例えば、システムが低電力モードにある場合には、この情報がネットワークスタックに供給され、次いで、ネットワークスタックは、全ての適格なネットワークインターフェース上でポーリングモードに入るように選択することができる。ネットワークスタックは、次いで、システムがもはや低電力モードではない場合に、通知されることにより、ポーリングモードを終了することができる。
【０１３１】
使用行為に関しては、システムが、ユーザーインターフェース入力の対処でビジーである場合には、この情報がネットワークスタックに供給され、次いで、ネットワークスタックは、全ての適格なネットワークインターフェース上でポーリングモードに入るように選択することができる。ネットワークスタックは、システムがもはやＵＩ入力の対処でビジーではない場合に、通知されることにより、ポーリングモードを終了することができる。
受信待ち行列
【０１３２】
一実施形態では、ｉｆｎｅｔのｉｆ＿ｉｎｐメンバーは、ＤＬＩＬ入力スレッド１２０３に関する受信待ち行列を保持する。一実施形態では、このデータ構造は、図１３に示す情報を含む。
【０１３３】
その送信待ち行列とは異なり、受信待ち行列は、インターフェースではなく、ＤＬＩＬ入力スレッドインスタンスと関連付けられる。上述のように、特定のタイプのインターフェースは、共通の（メイン）入力スレッドを共有するが、他のものは、それ自体の専用の入力スレッドを取得する。また、最大Ｎ個の送信待ち行列が存在し得る送信とも異なり、現在、１つの入力スレッドごとに、１つのみの受信待ち行列インスタンスが存在する。この構造はまた、入力のために使用される実際のカーネルスレッド、ワークループ１２０１、並びにポーラースレッド１２０２についての情報も保持する。一実施形態では、これらのスレッドの全ては、それらを同じプロセッサセットでスケジュールするために（より良好なキャッシュ局所性のために）、同じスレッド親和性タグを共有するように構成される。日和見的ポーリングに関して必要とされるパラメータ（例えば、モード、｛Ｐ，Ｂ，Ｗ｝＿ａｖｇ、｛Ｐ，Ｂ，Ｗ｝＿｛ｌｏ，ｈｉ｝ｗａｔ）もまた、一実施形態では、この構造内部に存在する。
リンクイベント
【０１３４】
一実施形態では、インターフェースに関連するイベントは、ネットワーキングスタック１０２から、接続されたスケジューラ１１６及び待ち行列管理論理１１５に、また更には、全てのクラス待ち行列インスタンス１１０〜１１２上に送信される。このことにより、スケジューラ、待ち行列管理論理１１５、及びそのクラスは、必要な場合には、それらのパラメータを適宜に適応させることが可能となる。それらのイベントは、以下の通りである。
【表１０】
0005893762.tif 000013
【０１３５】
上述のように、本発明の実施形態は、スケジューリングの２つの異なるモード、（１）ネットワークスタック層でのスケジューリング、及び（２）ドライバ層でのスケジューリング、に関する、対応を含む。ドライバは、いずれのタイプのスケジューリングを使用するか、選択することができる。一実施形態では、ドライバが８０２．１１ｎを実施している場合には、そのドライバは、ＷＭＭによって定義される４つのサービスクラスを使用してスケジューリングを実行するように、選択することができ（例えば、サービスクラスと待ち行列インスタンスとの１０：４マッピングを示す、図７を参照）、その一方で、ドライバが任意の他のインターフェース（例えば、１０２．１１ｂ／ｇ、３Ｇ、イーサネット（登録商標）など）を実施している場合には、そのドライバは、ネットワーク層でスケジューリング実行させるように、選択することができる（例えば、サービスクラスと待ち行列インスタンスとの１：１マッピングを示す、図６を参照）。
【０１３６】
一実施形態では、ドライバ管理モデルでは、待ち行列の全てを、ネットワークスタック管理モデルと同様に設定することができるが、スケジューリングは、ドライバスケジューラ１６０によって実行される。それゆえ、このドライバベースのスケジューラは、次いで、優先度に基づいて、特定のクラスに対して（すなわち、ＷＭＭに関する４つのクラスを使用して）、各デキュー動作のために幾つかのパケットをリクエストすることになる。
【０１３７】
スケジューラ１１６、１６０が、いずれの待ち行列からパケットをデキューするかを判断する一方で、待ち行列管理論理１１５によって実施される待ち行列処理アルゴリズム（「ドロッパー」とも称されるが、これは、パケットを破棄するか又は待ち行列に入れるかの、選択権を有するためである）は、デキューの前に、いずれの待ち行列内にパケットを入れるべきかを判定する。一実施形態では、スケジューラ１１６が、待ち行列管理論理１１５にパケットを引き渡し、次いで、この待ち行列管理論理１１５が、そのパケットを破棄するか又はエンキューするかを判定する。
【０１３８】
上述のように、一実施形態では、ネットワークスタックによって使用されるスケジューラ１１６は、急速公平待ち行列処理（ＱＦＱ）を使用するが、その一方で、ドライバスケジューラ１６０は、トラフィッククラス待ち行列処理（ＴＣＱ）を使用し、それらのそれぞれは、上記で詳細に説明されている。
フロー制御及びＳＦＢ待ち行列処理に関する更なる詳細
【０１３９】
一実施形態では、選択されるスケジューラのタイプに関わりなく、同じ待ち行列管理論理１１５が使用される。確率的公平ｂｌｕｅ（ＳＦＢ）は、ドライバ管理スケジューラ１６０及びネットワークレベルスケジューラ１１６の双方に関して、待ち行列管理論理１１５によって実施される、デフォルトの待ち行列処理アルゴリズムとして使用することができる。図１０Ａに示すように、フローハッシングにより、異なるフロー／ソケットからのパケットを、ネットワーク及びドライバ層の双方の範囲内で容易に追跡して、ＳＦＢアルゴリズムによって利用することが可能となる。ソケット２０４が最初に接続されると、ハッシュ値１００１が計算されて、ソケットデータ構造内に記憶され、その接続されたソケット２０４の存続期間にわたって使用される。ソケットから下位層（例えば、トランスポート２０５、ＩＰ  ２０６、送信待ち行列３０６、及びドライバ１５０）にデータが送り出されるときは常に、フローハッシュ値１００１は、パケットと共に送信されて、そのソケット／フローを一意的に特定するために使用される。フローが特定されると、新たな各パケットが待ち行列に入れられる際に、１つ以上のＳＦＢビン１００９内部で、カウンタがインクリメントされ（図１０Ａの変数Ｃによって示される）、各パケットがデキューされる際にデクリメントされる。それゆえ、各フローに関して現在待ち行列に入れられているパケットの数は既知であり、そのフローに対するフロー制御を実行するために使用される。一実施形態では、特定のフローが、指定の閾値を超えて待ち行列に入れられたパケットを有する場合には（図１０ＡのカウンタＣ＞＝ＦＡＤＶ  ＴＨＲＥＳＨＯＬＤによって示されるように）、そのフローに関する確率値が、何らかの間隔でインクリメントされる。この確率が、その限界（例えば、１）に到達すると、このことは、過度に多くのパケットが存在し（すなわち、アプリケーションが過度に速く送信している）、このフローに関する更なるパケットが破棄されることを指示する。
【０１４０】
図１０Ａは、この機構を詳細に示す。一実施形態では、フローハッシュは、ソケット２０４から下位層に下降するあらゆるパケットをタグ付けするために使用され、そのため、これらの下位層は、いずれのパケットがいずれのフローに属するかを認識して、ネットワーク層にフィードバックを提供することができる。パケットは、上述のように、そのフローと関連付けられた送信待ち行列３０６内部に入れられ、ＳＦＢは、そのフローハッシュを使用して、各フローに関して、ＳＦＢビン１００９内部に記憶されたカウンタ（Ｃ1、Ｃ2）を、インクリメント及びデクリメントする。ＳＦＢは、そのメモリデータ構造内で、それらのカウンタを使用して、待ち行列処理閾値が超過されているか否かを判定する。例えば、あるフローに関して、待ち行列に入れられているパケットの数が５０であり、この数が閾値である場合には、ＳＦＢは、そのフローに関する状態を記憶して、トランスポート層にフィードバックを送り、そのフローに対応するソケット２０４に対するフロー制御をオンにする。それゆえ、そのフローは、通常からフロー制御状態に移行して、この状態に留まり、その間に、パケットが待ち行列からデキューされ、リンクを介して送信される。
【０１４１】
待ち行列内のパケットの数が、閾値を下回ると、待ち行列処理アルゴリズムが、フローアドバイザリスレッド１０５０を呼び起こし、このスレッドが起動して、ソケット２０４に対するフロー制御をオフにする。したがって、そのソケットは、次いで、再びフロー制御状態に置かれるまで、下位層を通じて、下り方向にパケットを随意に送信することができる。それゆえ、図１０Ａは、フィードバックを提供して、同じホスト上のフローが、明示的な輻輳通知（ＥＣＮ）などのＴＣＰ内の内部機構に依存することなくフロー制御／通常状態の間で移行することを可能にする、機構を示す。このことにより、単に破棄されるためだけのデータを、下り方向でネットワークスタックに送信することによって行なわれる、不必要な作業が低減されるため、性能が改善される。更には、パケットを破棄することなく、ドライバ内の待ち行列のサイズを縮小することが可能となる。これは、アプリケーションが、下り方向でむやみにパケットをスタックに送信するものの、結局はドライバによって破棄される、旧来の機構とは対照的である。対照的に、図１０Ａでは、ネットワークスタックは、待ち行列の監視により、リンク上で進行していることを知るため、そのネットワークスタックは、この情報を使用して、転送機構の挙動をインテリジェントに変化させることができる。
【０１４２】
図１０Ｂでより詳細に示される一実施形態では、ＳＦＢアルゴリズムは、パケットのハッシュ値を取得して、ＳＦＢに固有のものであり、かつフローに関するビットを選び取るために使用される、別のハッシュを計算する。図示のように、ソケットによって計算されたオリジナルのハッシュ値は、４バイト（０１、０２、０３、０４）であり、これは、ＳＦＢ待ち行列処理論理１０６０のハッシュ生成部１０６５に提供することができる。特定のフローハッシュは、０の値を提供され、本明細書で説明されるフロー制御機構が使用されないフローを特定するために使用することができる。一実施形態では、ＳＦＢは乱数を生成し、その乱数を使用して、新たなハッシュ（Ａ、Ｂ、Ｃ、Ｄ）を計算する。ＳＦＢは、これらの４つの値を使用して、図１０Ｂに示すように、それぞれが２つのレベルを有する、ビンの２つのセットである、現在のセット及び影のセットに投入する。これらの２つのレベルは、新たなハッシュ値を使用して索引付けされる配列として実施される（各スロットは、一実施形態では２５６ビットである）。それゆえ、フローは、このフローハッシュ値を使用して、ＳＦＢビン内にマッピングされる。フローが存在するか否かをチェックするために、ＳＦＢビンをチェックすることができる。ＳＦＢアルゴリズムのブルームフィルタ機能性は、特定のフローがＳＦＢビン内部に存在しないかどうかを、チェックすることが可能である。存在する場合には、そのフローを索引付けすることにより、そのフローに関連付けられたデータ（例えば、上述の確率及びカウンタ）を決定することができる。このデータは、フローが依然として存在する限り、ＳＦＢによって保持される。ある程度の間隔で、ＳＦＢは再ハッシュするため、影のセットが使用される。ブルームフィルタの特性により、多くのものを、同じビンにマッピングする可能性がある。多数のソケットが存在する場合には、データを過度に多く送信している一部のソケットは、同じビンにマッピングされた、多数のデータを送信していない他のソケットに、影響を及ぼす可能性がある。それゆえ、ＳＦＢは、周期的に、新たな乱数に基づいて、内部ハッシュを再計算する。再ハッシュの後、それらのビンは、各フローに関して、並べ替えることができる。ＳＦＢアルゴリズムの更なる詳細は、本特許出願に付録Ｂとして添付され、参照により本明細書に組み込まれる参考資料「Ｓｔｏｃｈａｓｔｉｃ  Ｆａｉｒ  Ｂｌｕｅ：Ａ  Ｑｕｅｕｅ  Ｍａｎａｇｅｍｅｎｔ  Ａｌｇｏｒｉｔｈｍ  ｆｏｒ  Ｅｎｆｏｒｃｉｎｇ  Ｆａｉｒｎｅｓｓ」中に見出すことができる。この場合には、影のセットを使用して、新たなビンにデータを移動させることができる。
日和見的挙動、フロー制御、トラフィック一時停止、及びトランスポート層の改善を含む、アプリケーション駆動トラフィック分類並びにフローフィードバック
【０１４３】
図６〜８に関して上述された、アプリケーション駆動トラフィック分類を使用して、様々な日和見的挙動を有効にすることができる。上述のように、各アプリケーションは、いずれのトラフィッククラスを、そのソケットに関するものとするべきかを、明示的に述べることができる。例えば、仮に、１つのアプリケーションが、ＢＫ＿ＳＹＳなどの低い優先度のトラフィッククラスを使用して、日付をバックアップしているが、ユーザーが、音声呼び出しを行うことを望むとする。ＧＳＭ（登録商標）が作動する方式により、ネットワークデータが送信されている間に、音声呼び出しが進行中である場合には、このことにより、音声呼び出しが劣化するか又は破棄される確率が増大する。同様に、ユーザーが、呼び出し中にウェブブラウザを開く場合には、そのこともまた、呼び出しに影響を及ぼし得る。このことを緩和するために、一実施形態では、トラフィッククラスを使用することにより、ユーザーが音声呼び出し中である場合に、不必要なトラフィックを抑制する。緊急性の低いあらゆるトラフィック（例えば、バックグラウンドトラフィック−ＢＫＳ＿ＳＹＳ）を、音声呼び出し中に一時停止することができる。一実施形態では、一時停止されたソケットに関して、デキューが生じる場合、このシステムは、デキューするものが存在しないことを装い、エンキューが生じる場合、パケットが破棄される。それゆえ、送信中のアプリケーションは、このことを、ネットワークが停止しているかのように見なすことになり、再試行する前に待機することができる。呼び出しが比較的迅速である場合には、そのアプリケーションは、呼び出しが終了すると、（ソケットを完全に遮断することなく）再開することになる。これらの技術は、ＢＫ＿ＳＹＳ以外のトラフィッククラス（例えば、ＢＫ、ＢＥなど）に関して使用することができる。一実施形態では、上述のフロー制御／アドバイザリ機構もまた、これらの状況でソケットを一時停止するために使用される（例えば、一時停止される場合には、フロー制御の指示が送信される）。それゆえ、特定のソケット（例えば、ＢＫ＿ＳＹＳ）に関するトラフィックを分類することによって、トラフィックの一時停止に対処するためのインテリジェントなフィードバック機構が提供され、これらのソケットに関する日和見的挙動が、カーネル内で有効となる。
【０１４４】
一時停止状態は、フロー制御状態とは異なる点に留意されたい。フロー制御状態では、アプリケーションは、依然としてデータを送信している場合があるが、一時停止状態では、リンクは（例えば、音声呼び出しが長時間を要するため）遮断される。それゆえ、一時停止状態では、それ以上のパケットの送信を停止することが有益であるが、これは、それらのパケットが、（待ち行列が一時停止しているため）単に破棄されることになるためである。一実施形態では、一時停止されたアプリケーションは、タイマーを始動させて、過度に長く一時停止される場合には単純に接続を閉じるように、選択することができる。
【０１４５】
要約すると、一実施形態では、音声呼び出しが受信／実施されると、
（１）システム内の権威エンティティが、日和見的制限調整モードへと、セルラーネットワークインターフェースを構成する。
（２）この日和見的モードは、影響を受ける各インターフェースのパケットスケジューラに構成される。
（３）スケジューラは、この日和見的モードで一時停止されるべき全ての送信待ち行列を検討し、現時点では、このことは、ＢＫ＿ＳＹＳ送信待ち行列にのみ適用される。影響を受ける各送信待ち行列は、一時停止モードに入り、全ての既存のパケットがフラッシュされ、更なるエンキューは、破棄を引き起こすことになる。
（４）全ての日和見的ソケット（ＢＫ＿ＳＹＳ分類を有するソケット）は、「一時停止イベント」を受信することになる。
【０１４６】
一実施形態では、音声呼び出しが終了すると、
（１）システム内の権威エンティティが、セルラーネットワークインターフェースから、日和見的制限調整モードを解除する。
（２）影響を受ける各インターフェースに関するパケットスケジューラは、日和見的制限調整モードを終了する。
（３）スケジューラは、この日和見的モードで一時停止されていた全ての送信待ち行列を検討し、現時点では、このことは、ＢＫ＿ＳＹＳ送信待ち行列にのみ適用される。影響を受ける各送信待ち行列が再開され、更なるエンキューが可能となる。
（４）全ての日和見的ソケット（ＢＫ＿ＳＹＳ分類を有するソケット）は、「再開イベント」を受信することになる。
【０１４７】
更には、性能最適化が、受信側に関して実現され、本明細書では「大量受信オフロード」と称される。一実施形態では、これは、ネットワークスタック内の関数を呼び出すことにより、パケットごとのコストを低減することによって機能する。例えば、１０個のパケットが受信され、１０個全てに対処するのではなく、１つ又は２つのみを処理することができる。ＡＶクラス（ストリーミングビデオ）などの特定のクラスに関して、この最適化を有効にすることができる。ＡＶビデオアプリケーションでは、ソフトウェアは、再生を開始する前に、数秒間にわたってビデオをバッファリングするこのことにより、このアプリケーションは、大量受信オーバーロード技術を使用して、性能利益を受けることができるが、これは、それらの技術が遅延に敏感ではないためである。
【０１４８】
一実施形態では、上り方向でスタックに提供されるフィードバックにより、ＴＣＰが送信及び受信する方式を、特定のソケットに対して調整することができる。例えば、アプリケーションが、ＢＫ又はＢＫ＿ＳＹＳとしてフローを分類する場合には、ＴＣＰの積極性は、より少ないものとなる。例えば、ソケットがＢＫであり、このリンク上の高い輻輳が検出される場合には、アプリケーションは後退して、他のフローのためのより良好な応答時間を受け入れることができる（例えば、ネットワークに対してバックアップしているソケットを遅延させて、別のソケット上のＨＴＴＰを受信することができる）。このことの全てが可能であるのは、アプリケーションが、ソケットのトラフィッククラスを明示的に指定することが可能であるためである。
【０１４９】
前述のように、一実施形態では、最も高い分類（ＣＴＬ）は、ネットワーク制御パケットに関して使用され、それらのパケットとしては、ＡＲＰ、ＡＣＫ応答、ＩＰＶ６用の近隣探索、マルチキャスト参加及び離脱、ＤＣＰ関連のパケット、ＩＰＶ６局ルータ宣伝パケット、並びにＤＮＳパケットを挙げることができる。したがって、ＤＮＳ動作は、ユーザーが、より低い優先度のソケットを使用して大量のアップロードを実行している場合には、遅延されることがない。同様に、ＡＣＫ応答が、より低い優先度のソケット上での活動の結果として遅延されることはない。このタイプの制御パケットは極めて小さく、遅延を全く伴うことなく出て行くことができる。
【０１５０】
更には、上述のように、上述の技術及びアーキテクチャは、フロー制御状態及び一時停止状態の間の、組み込みＴＣＰ及びＵＤＰ後退機構を提供する。通常は、ＴＣＰは、それ自体で（例えば、上述のようなＥＣＮを使用して）後退することによって、輻輳に対応する。ＴＣＰは、パケットを送信し、確認応答（ＡＣＫ）が得られない場合には、ＴＣＰは、何度もパケットを送信して、各再送信ごとに後退する。この再送信は、パケットが依然としてインターフェース待ち行列１５１〜１５３内に存在しており、リンクが利用可能になった後にのみ送信されることが既知である場合には、リソースの浪費である。それゆえ、この状況では、組み込みＴＣＰ若しくはＵＤＰ機構を使用して、後退及び再送信する必要性は存在しない。その代わりに、本明細書で説明される技術を使用して、フロー制御アドバイザリを発行することにより、再送信機能を無効にすることができる。
【０１５１】
更には、一実施形態では、ＴＣＰに関して使用される再送信タイマーを、より効率的に動作するように微調整することができる。典型的には、ＴＣＰは、ＡＣＫが受信されない場合、再送信タイマーを（例えば、毎回２倍に増大させて）後退させる。それゆえ、再送信タイマーは、数秒となる可能性がある。インターフェースからのフィードバックが、上述のように提供されるため、この後退を実施する必要はない。フロー制御アドバイザリが取得されると、パケットが待ち行列に入れられていることが理解される（また、再送信を続けることを望まない）ため、自動的に待機することができる。しかしながら、一実施形態では、再送信タイマーは、フロー制御がソケットに関してオフにされた後に、使用することができる。
【０１５２】
更には、フローアドバイザリは、ＴＣＰにもはやデータを書き込まないアプリケーションに至るまで、伝搬される。そのアプリケーションは、それゆえ、フロー制御がオフにされる場合、古くなったデータ（例えば、古いビデオフレーム）の全てを破棄して、より新しいデータを送信することが可能である。このことは、古くなったデータをアプリケーションが破棄しない場合には音声及びビデオの同期が外れる恐れのある、対話型ビデオデータに関して特に有益である。
【０１５３】
同様の原理は、ＵＤＰを使用して送信するアプリケーションに適用することができる。本明細書で説明されるフローアドバイザリ技術を使用しない場合は、ＵＤＰは、そのアプリケーションに、いずれのフィードバックも提供しない。それゆえ、インターフェースが破棄する場合には、アプリケーションは知ることがなく、パケットの送信を継続し、それゆえ、それらのパケットは、スタックのより低いレベルでバッファリングしなければならず、リソースを浪費する。対照的に、フロー制御状態にある場合、アプリケーションによる書き込みの全ては、即座に破棄することができる（それにより、バッファリングリソースを節約する）。上記を行うことで、パケットをバッファリングすることによって生じる著しい量の遅延が、低減される。
インバウンドのネットワークトラフィックに対処し、ネットワーク性能を改善し、サービス拒否攻撃に対処するための、日和見的ポーリング機構
【０１５４】
上述のように、一実施形態では、ＲＸＰＯＬＬ対応インターフェースは、動作の入力ポーリングオフモードと入力ポーリングオン（又はレガシー）モード（例えば、ＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＦＦとＩＦＮＥＴ＿ＭＯＤＥＬ＿ＩＮＰＵＴ＿ＰＯＬＬ＿ＯＮ）との間で遷移する。一実施形態では、入力ポーリングオフモードは、デフォルト／初期モードとして使用され、ネットワークスタックによって、負荷率が低いことが判定される場合に選択される。この負荷率は、変数Ｐ＿ａｖｇ、Ｂ＿ａｖｇ、及びＷ＿ａｖｇ（それぞれ、パケット、バイト、及びウェイクアップリクエストの数に関する値）を評価することによって、決定することができる。図１２のＤＬＬ入力スレッド１２０３を参照すると、一実施形態では、入力ポーリングオンモードへの切り換えは、（Ｐ＿ａｖｇ≧Ｐ＿ｈｉｗａｔ＆＆（Ｂ＿ａｖｇ≧Ｂ＿ｈｉｗａｔ｜｜Ｗ＿ａｖｇ≧Ｗ＿ｈｉｗａｔ））の場合に行われ、式中、Ｐ＿ｈｉｗａｔ、Ｂ＿ｈｉｗａｔ、及びＷ＿ｈｉｗａｔは、それらの変数に関する高基準値である。
【０１５５】
逆に、ポーリングオフモードへの切り換えは、（Ｐ＿ａｖｇ≦Ｐ＿ｌｏｗａｔ＆＆Ｂ＿ａｖｇ≦Ｂ＿ｌｏｗａｔ＆＆Ｗ＿ａｖｇ≦Ｗ＿ｌｏｗａｔ）の場合に行われ、式中、Ｐ＿ｌｏｗａｔ、Ｂ＿ｌｏｗａｔ、及びＷ＿ｌｏｗａｔは、それらの変数に関する低基準値である。
【０１５６】
一実施形態では、これらの低基準値及び高基準値は、特定の作業負荷に基づいて任意に選択することができ、それらは、将来の作業負荷（及び変動するリンク速度）に適応するように、適宜に調整されるべきである。
【０１５７】
高い負荷率に基づいて、この方式でポーリングをオンにすることは、性能を向上させ、サービス拒否攻撃を防止する。これは、ポーリング機構を使用することで、ネットワーク層の受信待ち行列は、ドライバ層の待ち行列からのパケットを待ち行列に入れるための、十分な余地を有する場合にのみ、それらのパケットをリクエストすることになるためである。余地を有さない場合、ネットワーク層の受信待ち行列は、より多くのパケットをリクエストするためのポーリングをすることなく、パケットは、インターフェースによって（すなわち、ドライバ層待ち行列が充満される場合）破棄されることになる。それゆえ、サービス拒否は、ドライバ層で防止され、ネットワーク層まで上り方向に伝搬されない。
種々のＡＰＩ実施形態
【０１５８】
一実施形態で実施されるＡＰＩは、ソフトウェア構成要素（以降では「ＡＰＩ実施ソフトウェア構成要素」）によって実施されるインターフェースであり、異なるソフトウェア構成要素（以降では「ＡＰＩ呼び出しソフトウェア構成要素」）が、そのＡＰＩ実施ソフトウェア構成要素によって提供される１つ以上の関数、メソッド、手続き、データ構造、及び／又は他のサービスにアクセスして使用することを可能にするものである。例えば、ＡＰＩは、ＡＰＩ呼び出しソフトウェア構成要素の開発者（この開発者は、サードパーティーの開発者であり得る）が、ＡＰＩ実施ソフトウェア構成要素によって提供される指定の機能を活用することを可能にする。１つのＡＰＩ呼び出しソフトウェア構成要素が存在する場合があり、又は、２つ以上のそのようなソフトウェア構成要素が存在する場合もある。ＡＰＩは、ソフトウェアアプリケーションからの、サービスに関するリクエストに対応するために、コンピュータシステム又はプログラムライブラリが提供する、ソースコードインターフェースとすることができる。ＡＰＩは、メモリ内にデータがレイアウトされる方式の、明示的な低レベルの記述ではなく、アプリケーションが構築される際に解釈実行又はコンパイルすることが可能な、プログラミング言語によって指定することができる。
【０１５９】
ＡＰＩは、ＡＰＩ呼び出しソフトウェア構成要素が、ＡＰＩ実施ソフトウェア構成要素の指定の機能にアクセスして使用する際に使用する、言語及びパラメータを定義する。例えば、ＡＰＩ呼び出しソフトウェア構成要素は、ＡＰＩによって公開される１つ以上のＡＰＩ呼び出し（関数呼び出し又はメソッド呼び出しと称される場合がある）を通じて、ＡＰＩ実施ソフトウェア構成要素の指定の機能にアクセスする。ＡＰＩ実施ソフトウェア構成要素は、ＡＰＩ呼び出しソフトウェア構成要素からのＡＰＩ呼び出しに応答して、ＡＰＩを通じて値を返すことができる。ＡＰＩは、ＡＰＩ呼び出しのシンタックス及び結果（例えば、ＡＰＩ呼び出しをどのように起動するか、及びＡＰＩ呼び出しが何を行うか）を定義するが、ＡＰＩは、典型的には、ＡＰＩ呼び出しによって指定される機能ＡＰＩ呼び出しがどのように達成するかを、明らかにしない。様々な関数呼び出し又はメッセージが、呼び出しソフトウェア（ＡＰＩ呼び出しソフトウェア構成要素）とＡＰＩ実施ソフトウェア構成要素との間で、１つ以上のアプリケーションプログラミングインターフェースを介して転送される。関数呼び出し又はメッセージの転送は、発行、開始、起動、呼び出し、受信、返信、又は関数呼び出し若しくはメッセージへの応答を含み得る。それゆえ、ＡＰＩ呼び出しソフトウェア構成要素は、呼び出しを転送することができ、ＡＰＩ実施ソフトウェア構成要素は、呼び出しを転送することができる。
【０１６０】
例として、ＡＰＩ実施ソフトウェア構成要素２０１０及びＡＰＩ呼び出しソフトウェア構成要素は、オベレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュールとすることができる（ＡＰＩ実施ソフトウェア構成要素及びＡＰＩ呼び出しソフトウェア構成要素は、互いに同じタイプ又は異なるタイプのソフトウェアモジュールとすることができる点を理解されたい）。ＡＰＩ呼び出しソフトウェア構成要素は、ローカルソフトウェア構成要素（すなわち、ＡＰＩ実施ソフトウェア構成要素と同じデータ処理システム上にある）か、又は、ネットワークを介して、ＡＰＩを通じてＡＰＩ実施ソフトウェア構成要素と通信する、リモートソフトウェア構成要素（すなわち、ＡＰＩ実施ソフトウェア構成要素とは異なるデータ処理システム上にある）とすることができる。ＡＰＩ実施ソフトウェア構成要素はまた、ＡＰＩ呼び出しソフトウェア構成要素としても機能することができ（すなわち、異なるＡＰＩ実施ソフトウェア構成要素によって公開されるＡＰＩに、ＡＰＩ呼び出しを行なうことができ）、ＡＰＩ呼び出しソフトウェア構成要素はまた、異なるＡＰＩ呼び出しソフトウェア構成要素に公開されるＡＰＩを実施することによって、ＡＰＩ実施ソフトウェア構成要素としても機能することができる。
【０１６１】
ＡＰＩは、異なるプログラミング言語で書かれた、複数のＡＰＩ呼び出しソフトウェア構成要素が、ＡＰＩ実施ソフトウェア構成要素と通信することを可能にする（それゆえ、ＡＰＩは、ＡＰＩ実施ソフトウェア構成要素とＡＰＩ呼び出しソフトウェア構成要素との間で、呼び出し及び返信を変換するための機能を含み得る）が、ＡＰＩは、特定のプログラミング言語に関して実施されてもよい。
【０１６２】
図１４は、ＡＰＩ  １４２０を実施するＡＰＩ実施ソフトウェア構成要素１４１０（例えば、オベレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）を含む、ＡＰＩアーキテクチャの一実施形態を示す。ＡＰＩ  １４２０は、ＡＰＩ呼び出しソフトウェア構成要素１４３０によって使用することが可能な、ＡＰＩ実施ソフトウェア構成要素の１つ以上の関数、メソッド、クラス、オブジェクト、プロトコル、データ構造、フォーマット、及び／又は他の機能を指定する。ＡＰＩ  １４２０は、ＡＰＩ実施ソフトウェア構成要素内の関数が、どのようにＡＰＩ呼び出しソフトウェア構成要素からパラメータを受信するか、及び、その関数が、どのようにＡＰＩ呼び出しソフトウェア構成要素に結果を返すかを、指定することができる。ＡＰＩ呼び出しソフトウェア構成要素１４３０（例えば、オベレーティングシステム、ライブラリ、装置ドライバ、ＡＰＩ、アプリケーションプログラム、又は他のソフトウェアモジュール）は、ＡＰＩ  １４２０によって指定される、ＡＰＩ実施ソフトウェア構成要素１４１０の機能にアクセスして使用するために、ＡＰＩ  １４２０を通じてＡＰＩ呼び出しを行う。ＡＰＩ実施ソフトウェア構成要素１４１０は、ＡＰＩ呼び出しに応答して、ＡＰＩ呼び出しソフトウェア構成要素１４３０に、ＡＰＩ  １４２０を通じて値を返すことができる。
【０１６３】
ＡＰＩ実施ソフトウェア構成要素１４１０は、ＡＰＩ  １４２０を通じて指定されず、かつＡＰＩ呼び出しソフトウェア構成要素１４３０に利用可能ではない、更なる関数、メソッド、クラス、データ構造、及び／又は他の機能を含み得ることが理解されるであろう。ＡＰＩ呼び出しソフトウェア構成要素１４３０は、ＡＰＩ実施ソフトウェア構成要素１４１０と同じシステム上に存在することができ、又は、遠隔に配置され、ネットワークを介して、ＡＰＩ  １４２０を使用してＡＰＩ実施ソフトウェア構成要素１４１０にアクセスすることができる点を理解されたい。図１４は、ＡＰＩ  １４２０と相互作用する、単一のＡＰＩ呼び出しソフトウェア構成要素１４３０を示すが、このＡＰＩ呼び出しソフトウェア構成要素１４３０とは異なる言語（又は同じ言語）で書くことが可能な、他のＡＰＩ呼び出しソフトウェア構成要素もまた、ＡＰＩ  １４２０を使用することができる点を理解されたい。
【０１６４】
ＡＰＩ実施ソフトウェア構成要素１４１０、ＡＰＩ  １４２０、及びＡＰＩ呼び出しソフトウェア構成要素１４３０は、機械（例えば、コンピュータ又は他のデータ処理システム）によって読み取り可能な形態で情報を記憶するための、任意の機構を含む、機械可読媒体内に記憶することができる。例えば、機械可読媒体としては、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み出し専用メモリ、フラッシュメモリ装置などが挙げられる。
【０１６５】
例示的実施形態の図１５（「ソフトウェアスタック」）では、アプリケーションは、幾つかのサービスＡＰＩを使用して、サービス１又はサービス２への呼び出しを行なうことができ、幾つかのＯＳ  ＡＰＩを使用して、オペレーティングシステム（ＯＳ）への呼び出しを行なうことができる。サービス１及びサービス２は、幾つかのＯＳ  ＡＰＩを使用して、ＯＳへの呼び出しを行なうことができる。
【０１６６】
サービス２は、２つのＡＰＩを有し、それらの一方（サービス２  ＡＰＩ  １）が、アプリケーション１から呼び出しを受信して、アプリケーション１に値を返し、他方（サービス２  ＡＰＩ  ２）が、アプリケーション２から呼び出しを受信して、アプリケーション２に値を返すことに留意されたい。サービス１（例えば、ソフトウェアライブラリとすることができる）は、ＯＳ  ＡＰＩ  １への呼び出しを行い、ＯＳ  ＡＰＩ  １から戻り値を受信し、サービス２（例えば、ソフトウェアライブラリとすることができる）は、ＯＳ  ＡＰＩ  １及びＯＳ  ＡＰＩ  ２の双方への呼び出しを行い、双方から戻り値を受信する。アプリケーション２は、ＯＳ  ＡＰＩ  ２への呼び出しを行い、ＯＳ  ＡＰＩ  ２から戻り値を受信する。
例示的なデータ処理装置及びインターフェース
【０１６７】
図１６は、本発明の一部の実施形態で使用することができる、例示的なコンピュータシステムを示すブロック図である。図１６は、コンピュータシステムの様々な構成要素を示すが、そのような詳細は本発明と密接に関連するものではないため、それらの構成要素を相互接続する、いずれかの特定のアーキテクチャ又は方式を表すことを意図するものではない点を理解されたい。より少ない構成要素、又はより多くの構成要素を有する他のコンピュータシステムもまた、本発明と共に使用することができる点も、理解されるであろう。
【０１６８】
図１６に示すように、データ処理システムの形態であるコンピュータシステム２３００は、処理システム２３２０、電源２３２５、メモリ２３３０、及び不揮発性メモリ２３４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）など）と結合されている、バス２３５０を含む。バス２３５０は、当該技術分野において周知であるような、様々なブリッジ、コントローラ、及び／又はアダプタを通じて、互いに接続することができる。処理システム２３２０は、メモリ２３３０及び／又は不揮発性メモリ２３４０から命令を取得して、それらの命令を実行することにより、上述のような動作を実行することができる。バス２３５０は、上記の構成要素を一体に相互接続し、また、それらの構成要素を、任意選択のドック２３６０、ディスプレイコントローラ＆ディスプレイ装置２３７０、入出力装置２３８０（例えば、ＮＩＣ（ネットワークインターフェースカード）、カーソル制御（例えば、マウス、タッチスクリーン、タッチパッドなど）、キーボードなど）、並びに任意選択の無線送受信機２３９０（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ、赤外線など）にも相互接続する。
【０１６９】
図１７は、本発明の一部の実施形態で使用することができる、例示的なデータ処理システムを示すブロック図である。例えば、データ処理システム２４００は、ハンドヘルドコンピュータ、携帯情報端末（ＰＤＡ）、モバイル電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット又はハンドヘルドコンピューティング装置（モバイル電話、メディアプレーヤ、及び／又はゲームシステムを含み得る）とすることができる。別の実施例としては、データ処理システム２４００は、ネットワークコンピュータ、又は別の装置内部の組み込み型処理装置とすることができる。
【０１７０】
本発明の一実施形態によれば、データ処理システム２４００の例示的アーキテクチャは、上述のモバイル機器に関して使用することができる。データ処理システム２４００は、１つ以上のマイクロプロセッサ、及び／又は集積回路上のシステムを含み得る、処理システム２４２０を含む。処理システム２４２０は、メモリ２４１０、電源２４２５（１つ以上のバッテリを含む）、音声入出力２４４０、ディスプレイコントローラ及びディスプレイ装置２４６０、任意選択の入出力２４５０、入力装置２４７０、並びに無線送受信機２４３０と結合される。図２４には示されない追加的構成要素もまた、本発明の特定の実施形態の、データ処理システム２４００の一部とすることができ、また本発明の特定の実施形態では、図１６に示すものよりも少ない構成要素を使用することができる点が、理解されるであろう。更には、図１６には示されない１つ以上のバスを使用して、当該技術分野において周知であるように、様々な構成要素を相互接続することができる点が、理解されるであろう。
【０１７１】
メモリ２４１０は、データ処理システム２４００による実行のための、データ及び／又はプログラムを記憶することができる。音声入出力２４４０は、マイクロホン及び／又はスピーカを含み、例えば、そのスピーカ及びマイクロホンを通じて、音楽を再生し、かつ／又は電話機能性を提供することができる。ディスプレイコントローラ及びディスプレイ装置２４６０は、グラフィカルユーザーインターフェース（ＧＵＩ）を含み得る。無線（例えば、ＲＦ）送受信機２４３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、Ｂｌｕｅｔｏｏｔｈ（登録商標）送受信機、無線セルラー電話送受信機など）を使用して、他のデータ処理システムと通信することができる。１つ以上の入力装置２４７０により、ユーザーは、システムに入力を提供することが可能となる。これらの入力装置は、キーパッド、キーボード、タッチパネル、マルチタッチパネルなどとすることができる。任意選択の他の入出力２４５０は、ドック用のコネクタとすることができる。
【０１７２】
本発明の実施形態は、上記のような様々なステップを含み得る。それらのステップは、汎用プロセッサ又は特殊目的プロセッサに特定のステップを実行させる、機械実行可能命令として具体化することができる。あるいは、これらのステップは、それらのステップを実行するための配線論理を含む特定のハードウェア構成要素によって、又はプログラムされたコンピュータ構成要素とカスタムハードウェアとの任意の組み合わせによって、実行することができる。
【０１７３】
本発明の要素はまた、機械実行可能プログラムコードを記憶するための、機械可読媒体としても提供することができる。この機械可読媒体としては、フロッピー（登録商標）ディスケット、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、又は、電子プログラムコードを記憶するために好適な他のタイプの媒体／機械可読媒体を挙げることができるが、これらに限定されない。
【０１７４】
上述の説明の全体を通して、説明の目的上、数多くの具体的な詳細が、本発明の完全な理解を提供するために記載された。しかしながら、本発明は、これらの具体的な詳細の一部を伴わずとも実践することができる点が、当業者には明らかとなるであろう。例えば、本明細書で説明される機能モジュール及び方法は、ソフトウェア、ハードウェア、若しくはそれらの任意の組み合わせとして実施することができる点が、当業者には容易に明らかとなるであろう。更には、本発明の実施形態は、モバイルコンピューティング環境のコンテキストの範囲内で（すなわち、モバイル機器１２０〜１２３、６０１〜６０３を使用して）、本明細書で説明されるが、本発明の根底をなす原理は、モバイルコンピューティングでの実施に限定されるものではない。例えば、デスクトップコンピュータ若しくはワークステーションコンピュータを含めた、実質上あらゆるタイプのクライアントデータ処理装置又はピアデータ処理装置を、一部の実施形態で使用することができる。したがって、本発明の範囲及び趣旨は、以下の特許請求の範囲によって判断されるべきである。
【図１Ａ】
0005893762.tif 000014
【図１Ｂ】
0005893762.tif 000015
【図２Ａ】
0005893762.tif 000016
【図２Ｂ】
0005893762.tif 000017
【図３Ａ】
0005893762.tif 000018
【図３Ｂ】
0005893762.tif 000019
【図３Ｃ】
0005893762.tif 000020
【図４】
0005893762.tif 000021
【図５】
0005893762.tif 000022
【図６】
0005893762.tif 000023
【図７】
0005893762.tif 000024
【図８】
0005893762.tif 000025
【図９Ａ】
0005893762.tif 000026
【図９Ｂ】
0005893762.tif 000027
【図１０Ａ】
0005893762.tif 000028
【図１０Ｂ】
0005893762.tif 000029
【図１１Ａ】
0005893762.tif 000030
【図１１Ｂ】
0005893762.tif 000031
【図１２】
0005893762.tif 000032
【図１３】
0005893762.tif 000033
【図１４】
0005893762.tif 000034
【図１５】
0005893762.tif 000035
【図１６】
0005893762.tif 000036
【図１７】
0005893762.tif 000037