JP4921569B2 - オフロードユニットを使用したｔｃｐ接続のためのデータ処理 - Google Patents

Description

関連出願へのクロスレファレンス

[0001]本出願は、参考として全体をここに援用する、発明者及び譲受人が本出願と共通の２００３年６月５日出願の「HARDWARE-OPERATED TCP/IP (HOT) PROCESSING」と題する共通所有の出願中のプロビジョナル米国特許出願第６０／４７６，５７０号から優先権を請求する。

発明の分野

[0002]本発明の１つ以上の態様は、一般に、送信制御プロトコル（ＴＣＰ）処理に係り、より詳細には、ＴＣＰベースの通信を最適化することに係る。

背景

[0003]従来のＴＣＰ処理は、クライアントとサーバーとの間のデータ転送を加速するために開発されたシステム及び方法により例示される。例えば、中央処理ユニット（ＣＰＵ）のようなホストプロセッサで実行されるソフトウェア具現化は、ホストプロセッサからＴＣＰ処理をオフロードするように設計された高価な専用のハードウェア具現化に比して、比較的低廉で且つ低速である。

[0004]図１は、ＣＰＵ１１０と、ネットワークインターフェイスカード（ＮＩＣ）１５０とを含む、一般的に１００で示された従来のコンピュータシステムの実施形態を例示するブロック図である。このコンピュータシステム１００は、デスクトップコンピュータ、サーバー、ラップトップコンピュータ、パルムサイズコンピュータ、タブレットコンピュータ、ゲームコンソール、セルラー電話、コンピュータベースのシミュレータ等でよい。ＣＰＵ１１０をシステムコントローラ１２０に結合しているバス１１２は、フロントサイドバス（ＦＳＢ）でよい。従って、コンピュータシステム１００は、ＩＮＴＥＬ（登録商標）ハブアーキテクチャーとしても知られているハブベースのアーキテクチャーでよく、この場合、システムコントローラ１２０はメモリコントローラハブであり、Ｉ／Ｏブリッジ１４０がハブ対ハブインターフェイス１２６を経てシステムコントローラ１２０に結合される。システムコントローラ１２０は、メモリバス１３２を経てシステムメモリ１３０に結合される。Ｉ／Ｏブリッジ１４０は、周辺コンポーネントインターフェイス（ＰＣＩ）バス１８２のためのコントローラを含むと共に、システムマネージメントバス１４２、ユニバーサルシリアルバス１４４等のためのコントローラを含んでもよい。Ｉ／Ｏブリッジ１４０は、単一集積回路でもよいし、単一半導体プラットホームでもよい。この技術で知られたシステムコントローラ１２０は、例えば、ＩＮＴＥＬ（登録商標）ノースブリッジを含む。この技術で知られたＩ／Ｏブリッジ１４０は、例えば、ＩＮＴＥＬ（登録商標）サウスブリッジ、並びにＮＶＩＤＩＡ（登録商標）媒体及び通信プロセッサ（ＭＣＰ）チップを含む。

[0005]ＮＩＣ１５０は、ＰＣＩバス１８２を１つ以上のＰＣＩデバイス１８０とで共有してもよい。ＮＩＣ１５０は、ＰＣＩインターフェイス１４５と、専用プロセッサ１５５と、媒体アクセスコントローラ（ＭＡＣ）１６５と、専用メモリ１６０と、イーサネットネットワーク１７２へインターフェイスするためのイーサネットインターフェイス１７０とを備えている。ＮＩＣ１５０用のソフトウェアドライバ１１９は、ＮＩＣ１５０と、ＣＰＵ１１０で実行されるアプリケーションプログラム１１７との間で通信する。システムメモリ１３０内には、アプリケーションメモリスペース１２５、ＴＣＰスタックメモリスペース１４５及びドライバメモリスペース１３５が割り当てられる。

[0006]ＮＩＣ１５０内の専用プロセッサ１５５は、ＣＰＵ１１０がＴＣＰスタック１１５を実行してＴＣＰ処理を遂行するのに代わって、ＴＣＰ処理に使用される。それ故、ＮＩＣ１５０は、ＣＰＵ１１０をオフロードし、他のアプリケーションのサイクルを処理するようにＣＰＵ１１０を解放する。同様に、専用メモリ１６０は、ＴＣＰスタックメモリスペース１４５に置き換わるもので、他のアプリケーションに割り当てるようにＴＣＰスタックメモリスペース１４５を解放する。しかしながら、専用メモリ１６０及び専用プロセッサ１５５を含むＮＩＣ１５０は、ＣＰＵ１１０で実行されるＴＣＰ処理のためのソフトウェア具現化よりコストが高い。

[0007]それ故、ホストプロセッサから幾つかのタスクをオフロードすることによりＴＣＰ処理を最適化すると共に、専用ハードウェア具現化に比してシステムコストを低減するような部分ハードウェア具現化が要望される。

概要

[0008]本発明の方法の種々の実施形態は、オフロードユニットを使用してフレームの第１部分を処理して、第１の処理されたフレームデータを発生するステップと、オフロードユニットを使用してフレームの第２部分を処理して、第２の処理されたフレームデータを発生するステップと、ＣＰＵで実行されるアプリケーションプログラムを使用して第２の処理されたフレームデータを処理して、第３の処理されたフレームデータを発生するステップとを備えている。

[0009]本発明の方法の種々の実施形態は、オフロードユニットを使用してデレゲートＴＣＰ接続を処理するステップと、ＣＰＵで実行されるアプリケーションプログラムを使用して、非デレゲートＴＣＰ接続を処理するステップと、ＣＰＵで実行されるアプリケーションプログラムを使用して、特殊なケースが存在する全てのフレームを処理するステップとを備えている。オフロードユニットは、特殊なケースが存在しないフレームを処理するように構成される。

[0010]本発明の方法の種々の実施形態は、ＴＣＰ接続を確立するステップと、ハードウェアによる処理のためにＴＣＰ接続をデレゲートすべきかどうか決定するステップとを備えている。

[0011]本発明の方法の種々の実施形態は、デレゲート接続テーブルインデックスを受信するステップと、ＴＣＰスタックからプロトタイプヘッダ及び送信用のデータを受信するステップと、デレゲート接続テーブルインデックスを使用してデレゲート接続テーブルエントリーにアクセスするステップと、送信用のデータの一部分に基づいてＴＣＰチェック和を計算するステップと、ＴＣＰチェック和及び送信用のデータの一部分を含むフレームを出力するステップとを備えている。

[0012]本発明の種々の実施形態は、ＴＣＰ接続のためのデータを処理するシステムを備えている。このシステムは、ＴＣＰスタックと、ソフトウェアドライバと、オフロードユニットとを含む。ＴＣＰスタックは、少なくとも１つのレガシーバッファに記憶された受信フレームを処理するように構成される。ソフトウェアドライバは、ＴＣＰスタックとオフロードユニットとの間をインターフェイスするように構成される。オフロードユニットは、デレゲート接続において受信されたフレームを処理して、ペイロードデータ及び部分的に処理されたフレームを発生するように構成される。

[0013]本発明の種々の実施形態は、ＴＣＰスタックとオフロードユニットとの間で通信するシステムを備えている。このシステムは、ＴＣＰスタックからオフロードユニットへコマンドを送信する手段と、オフロードユニットからＴＣＰスタックへ通知記述を送信する手段とを含む。

[0014]本発明は、ＴＣＰ接続のためのデータを処理する新規なシステム及び方法を包含する。

[0015]添付図面は、本発明の１つ以上の態様に基づく実施形態を示すが、図示された実施形態に本発明を限定するものではなく、本発明を説明し及び理解するためのものに過ぎない。

[0016]ホストコンピュータ及びネットワークインターフェイスカードを含む従来のコンピュータシステムの実施形態を示すブロック図である。 [0017]本発明の１つ以上の態様に基づくホストコンピュータを含むコンピュータシステムの実施形態を示すブロック図である。 本発明の１つ以上の態様に基づくホストコンピュータを含むコンピュータシステムの実施形態を示すブロック図である。 [0018]本発明の１つ以上の態様に基づく図２Ａ及び２Ｂに示されたハードウェア最適化ＴＣＰサブユニットを示す図である。 [0019]本発明の１つ以上の態様に基づきデレゲート接続を設定する方法の一実施形態を示す図である。 [0020]本発明の１つ以上の態様に基づきフレームを受信する方法の一実施形態を示す図である。 [0021]本発明の１つ以上の態様に基づくスロースタートシーケンスの一実施形態を示す図である。 [0022]本発明の１つ以上の態様に基づく図２Ａ及び２Ｂに示されたアプリケーションメモリスペースにおけるユーザバッファの一実施形態を示す図である。 [0023]本発明の１つ以上の態様に基づくユーザバッファ記述子の一実施形態を示す図である。 [0024]本発明の１つ以上の態様に基づく図２Ａ及び２Ｂに示されたソフトウェアドライバメモリスペースにおけるレガシーバッファの一実施形態を示す図である。 [0025]本発明の１つ以上の態様に基づくレガシーバッファタグテーブルの一実施形態を示す図である。 [0026]本発明の１つ以上の態様に基づくレガシーバッファ記述子の一実施形態を示す図である。 [0027]本発明の１つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへコマンドを転送するためのコマンドリングを示す概念図である。 [0028]本発明の１つ以上の態様に基づきオフロードユニットからアプリケーションプログラムへ接続情報を転送するための通知リングを示す概念図である。 [0029]本発明の１つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへ受信バッファ情報を転送するための受信記述子リングを示す概念図である。 [0030]本発明の１つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへ送信バッファ情報を転送するための送信記述子リングを示す概念図である。 [0031]本発明の１つ以上の態様に基づき図３に示されたハードウェア最適化ＴＣＰサブネットの一部分を含むブロック図である。 [0032]本発明の１つ以上の態様に基づき有効フレームを処理する方法の一実施形態を示す図である。 [0033]本発明の１つ以上の態様に基づきシーケンスずれフレームを処理する方法の一実施形態を示す図である。 [0034]本発明の１つ以上の態様に基づきユーザバッファを待機する方法の一実施形態を示す図である。 [0035]本発明の１つ以上の態様に基づきユーザバッファ処理を完了する方法の一実施形態を示す図である。 [0036]本発明の１つ以上の態様に基づき通知を決定する方法の一実施形態を示す図である。 [0037]本発明の１つ以上の態様に基づきユーザバッファ追従レガシー処理を同期する方法の一実施形態を示す図である。 [0038]本発明の１つ以上の態様に基づき送信用のデータを表示するのに使用されるフォーマットを示す図である。 本発明の１つ以上の態様に基づき送信用のデータを表示するのに使用されるフォーマットを示す図である。 [0039]本発明の１つ以上の態様に基づき出て行くフレームを編集する方法の実施形態を示す図である。 本発明の１つ以上の態様に基づき出て行くフレームを編集する方法の実施形態を示す図である。 [0040]本発明の１つ以上の態様に基づき送信に含ませる確認を発生する方法の一実施形態を示す図である。

本発明の詳細な説明

[0041]以下の説明において、本発明をより完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、本発明は、１つ以上のこれら特定の細部を伴わずに実施されてもよいことが明らかであろう。他の事例において、本発明を不明瞭にするのを回避するために、良く知られた特徴は説明しないことにする。

[0042]図２Ａ及び２Ｂは、本発明の１つ以上の態様に基づくＣＰＵ１１０及びハードウェア最適化ＴＣＰ（ＨＯＴ）ユニット２５０を備えたコンピュータシステム２００の実施形態を示すブロック図である。図２Ａにおいて、オフロードユニットであるＨＯＴユニット２５０は、ＣＰＵ１１０からあるＴＣＰ処理をオフロードする。ＣＰＵ１１０は、少なくともあるＴＣＰ処理、より詳細には、以下に述べるようにＨＯＴユニット２５０で遂行されないＴＣＰ処理を完了するためのコードを含むＴＣＰスタック２１５を実行する。ＣＰＵ１１０は、バス１１２を経てシステムコントローラ１２０に結合される。システムコントローラ１２０は、システムバス１３２によりシステムメモリ１３０に結合される。システムメモリ１３０は、以下に詳細に述べるＴＣＰスタックメモリスペース２２５と、ドライバメモリスペース２３５と、接続テーブル（ＣＴ）２４５とを備えている。システムコントローラ１２０は、ハブ対ハブインターフェイス１２６を経てＩ／Ｏコントローラ２４０に結合される。

[0043]Ｉ／Ｏコントローラ２４０は、ＰＣＩバス２８２のためのコントローラを含むと共に、システムマネージメントバス（ＳＭＢｕｓ）１４２、ユニバーサルシリアルバス（ＵＳＢ）１４４等のためのコントローラを含んでもよい。別の実施形態では、Ｉ／Ｏコントローラは、ＰＣＩエクスプレスバスのためのコントローラを含む。又、Ｉ／Ｏコントローラ２４０は、ＨＯＴユニット２５０も含み、ＰＣＩバス２８２を経てＩ／Ｏコントローラ２４０に結合されたデバイスからＨＯＴユニット２５０を効果的に減結合する。より詳細には、ハブ対ハブインターフェイス１２６は、システムコントローラ１２０を経てＨＯＴユニット２５０をシステムメモリ１３０へ結合する高速工業規格又は所有権バスでよい。Ｉ／Ｏコントローラ２４０に結合されるデバイスは、ＰＣＩバス２８２に使用可能な帯域巾を共有し、この帯域巾は、通常、ハブ対ハブインターフェイス１２６に使用可能な帯域巾より狭い。Ｉ／Ｏコントローラ２４０内にＨＯＴユニット２５０を配置したことで、ＨＯＴユニット２５０とＣＰＵ１１０及びシステムメモリ１３０との間の待ち時間が、図１に示されたＮＩＣ１５０とＣＰＵ１１０との間の待ち時間に比して短くなる。従来、ドライバ２５５を経てＮＩＣ１５０のようなＮＩＣとソフトウェアスタックのようなアプリケーションプログラムとの間で通信を行なうには、短い待ち時間が重要となる。例えば、ドライバメモリスペース１３５に記憶されたフレームデータをアプリケーションメモリスペース１２５に結合するコピーする準備ができたことを通信するために、ＮＩＣ１５０とＣＰＵ１１０との間でコマンドを通過させる上で、短い待ち時間が特に重要である。更に、ハブ対ハブインターフェイス１２６及びメモリバス１３２の各々は、ＰＣＩバス２８２より広い帯域巾をサポートするので、ＨＯＴユニット２５０は、ＰＣＩバス２８２を経てＩ／Ｏコントローラ２４０に結合されたデバイスより広い帯域巾でシステムメモリ１３０にアクセスすることができる。システムメモリ１３０に広い帯域巾でアクセスできることで、ＨＯＴユニット２５０は、時々「パケット」とも称される受信フレームを、ＰＣＩバス２８２のような狭帯域巾バスを経てＩ／Ｏコントローラ２４０に結合されたデバイスより更に迅速に、アプリケーションメモリスペース２２７又はドライバメモリスペース２３５へ転送することができる。

[0044]ＨＯＴユニット２５０は、入力／出力インターフェイス２４２へインターフェイスするコントローラを含む。入力／出力インターフェイス２４２は、ＨＯＴユニット２５０を、物理層（ＰＨＹ）、例えば、８０２．３ＰＨＹ、ＨＰＮＡ１．０ＰＨＹ、ＨＰＮＡ２．０ＰＨＹ等へ結合してもよい。別の実施形態では、ＰＨＹがＨＯＴユニット２５０内に含まれ、入力／出力インターフェイス２４２は、ギガビットイーサネットのようなイーサネットインターフェイスである。Ｉ／Ｏコントローラ２４０は、単一集積回路でもよいし又は単一半導体プラットホームでもよい。

[0045]図２Ｂは、一体化コントローラ２２０を含むコンピュータシステム２００の別の実施形態を示す。一体化コントローラ２２０は、システムコントローラ１２０及びＩ／Ｏコントローラ２４０により遂行される機能の少なくとも幾つかを遂行すると共に、ＨＯＴユニット２５０を備えている。又、一体化コントローラ２２０は、付加的なインターフェイスコントローラ（図示せず）、例えば、ＳＭＢｕｓ、ＵＳＢ、汎用Ｉ／Ｏ（ＧＰＩＯ）、一体化デバイスエレクトロニックス（ＩＤＥ）等を含んでもよい。

[0046]ＴＣＰスタック２１５は、１つ以上のＴＣＰ接続をデレゲート接続として選択する。デレゲート接続(delegated connection)とは、ＴＣＰスタック２１５による介入が最小の状態でＨＯＴユニット２５０により処理されるＴＣＰ接続である。デレゲートされない接続、又は特殊な処理を要求するデレゲートされた接続は、ＴＣＰスタック２１５により完全に、又は部分的に処理される。ＴＣＰスタック２１５は、システムメモリ１３０内に記憶されたドライバ２５５を使用して、ＨＯＴユニット２５０内の以下に詳細に述べるデレゲート接続テーブルのエントリーを初期化することにより、デレゲート接続を設定する。ドライバ２５５は、実際には、ＴＣＰスタック２１５とＨＯＴユニット２５０との間の変換器であり、ＴＣＰスタック２１５により要求されたときにＨＯＴユニット２５０へコマンドを発行する。又、ドライバ２５５は、ＨＯＴユニット２５０から通知が受け取られたときにＴＣＰスタック２１５にそれを知らせる。ＴＣＰスタック２１５とＨＯＴユニット２５０との間の通信はドライバ２５５を使用して遂行されるが、ドライバ２５５は、これ以降、明確に指示されなくてもよい。

[0047]デレゲート接続に対する接続状態データのみを記憶するデレゲート接続テーブルとは異なり、システムメモリ１３０内の接続テーブル２４５は、全てのアクティブな接続に対する接続状態データを記憶する。それ故、ＴＣＰスタック２１５は、ＨＯＴユニット２５０により要求されたときにデレゲート接続の処理を行うことができる。ＴＣＰスタック２１５によるデレゲート接続の処理は、「レガシー処理」と称される。

[0048]図３は、本発明の１つ以上の態様に基づき図２Ａ及び２Ｂに示されたＨＯＴユニット２５０のブロック図である。ＤＭＡエンジン３１０内の直接メモリアクセス（ＤＭＡ）インターフェイスは、Ｉ／Ｏコントローラ２４０又は一体化コントローラ２２０内の１つ以上のサブユニットにインターフェイスする。ＤＭＡインターフェイスは、システムメモリ１３０とＨＯＴユニット２５０内のサブユニットとの間でデータを送信及び受信し、且つＣＰＵ１０とＨＯＴユニット２５０内のサブユニットとの間でコマンドを送信及び受信するのに使用される。

[0049]送信エンジン３２０は、確認の挿入及びチェック和繰り返し冗長チェック計算を含む、出て行くフレームのパーズ及び編集を行なって、出て行くフレームを発生するように構成されたサブユニットを備えている。送信インターフェイス３３０は、送信用の出て行くフレームを記憶する１つ以上のバッファと、入力／出力インターフェイス２４２を経てＨＯＴユニット２５０に結合されるＰＨＹにインターフェイスするよう構成されたサブユニットとを備えている。ＨＯＴユニット２５０の別の実施形態では、ＰＨＹがＨＯＴユニット２５０に一体化される。送信エンジン３２０は、デレゲート接続に対する接続状態データを記憶するデレゲート接続テーブル（ＤＣＴ）３５０に結合される。このデレゲート接続テーブル３５０は、記憶リソース、例えば、ランダムアクセスメモリ（ＲＡＭ）、レジスタファイル等である。又、デレゲート接続のための接続状態データの少なくとも一部分は、接続テーブル２４５にも記憶される。

[0050]デレゲート接続テーブル３５０に記憶される状態情報は、確認状態、接続アドレス、システムメモリバッファに対するポインタ、接続追跡フラグ、事象制御情報、送信ウインドウサイズ、受信ウインドウサイズ、タイムスタンプデータ等を含んでもよい。確認状態は、次に受信が予想されるシーケンス番号のシーケンス番号、確認の適時発生を制御するスレッシュホールド等を含んでもよい。送信エンジン３２０は、フレーム処理中に接続テーブルインデックス即ちＤＣＴインデックスを使用してデレゲート接続に関連したエントリーにアクセスして、デレゲート接続テーブル３５０の一部分を読み取り及び書き込みする。このエントリーに記憶された接続状態データは、図７に関連して説明するように、デレゲート接続がアクティブである間に、ＴＣＰスタック２１５、送信エンジン３２０及び受信エンジン３６０により更新される。

[0051]受信インターフェイス３７０は、入力／出力インターフェイス２４２を経てＨＯＴユニット２５０に結合されたＰＨＹにインターフェイスするように構成されたサブユニットを備えている。又、受信インターフェイス３７０は、受信エンジン３６０を行先とする受信フレームを記憶するための受信ＦＩＦＯ（先入れ先出し）バッファも備えている。受信エンジン３６０は、部分的に処理されたフレーム又は単にＴＣＰペイロードデータを、以下に詳細に述べるように、ＤＭＡエンジン３１０を経てシステムメモリ１３０へアップロードする。

[0052]受信エンジン３６０は、到来するフレームのパーズを行なって、そのフレームが有効であるかどうか決定し、即ちチェック和を計算し、フラグを確認し、フレーム形式、例えば、ＩＰ、ＵＤＰ、ＴＣＰ等を識別するように構成されたサブユニットを備えている。パーズされたフレームが有効でないときには、それが、レガシー処理のためにドライバメモリスペース２３５のレガシーバッファにアップロードされる。受信フレームがＩＰパケットをＴＣＰセグメントと共に含む場合には、ＴＣＰスタック２１５に通知がなされると共に、このＴＣＰスタックは、必要なＴＣＰ処理を実行した後、そのアップロードされたフレームをレガシーバッファからアプリケーションメモリスペース２２７へコピーする。

[0053]パーズされたフレームが有効であると決定された場合には、受信エンジン３６０は、ソースＩＰアドレス、ＴＣＰシーケンス番号（ＳＮ）、ＴＣＰ確認（ＡＣＫ）番号、ＴＣＰソース及び行先ポート番号、ＴＣＰウインドウサイズ、ＴＣＰヘッダ長さ等を抽出する。非デレゲート接続において受信されたパーズ済みフレームは、ドライバメモリスペース２３５のレガシーバッファへ処理のためにアップロードされる。デレゲート接続において受信された、特殊なケースでないパーズ済みフレーム、例えば、順序ずれシーケンス番号、ＴＣＰプッシュフラグセット等が処理されると共に、ＴＣＰペイロードデータがアプリケーションメモリスペース２２７のユーザバッファにアップロードされる。ＴＣＰペイロードデータをアプリケーションメモリスペース２２７に直接アップロードするのは、ドライバメモリスペース２３５を経てペイロードデータをアップロードするより効率的である。というのは、ＴＣＰペイロードデータは、その後、ドライバメモリスペース２３５からアプリケーションメモリスペース２２７へコピーされる必要がないからである。

[0054]図４Ａは、本発明の一実施形態に基づきデレゲート接続を設定するための方法ステップを示すフローチャートである。ステップ４１０において、コンピュータシステム２００は、当業者に良く知られたプロセスを使用して三方ハンドシェークによりＴＣＰ接続を確立する。ステップ４１２では、ＴＣＰスタック２１５は、ＨＯＴユニット２５０による処理のために接続をデレゲートすべきかどうか決定する。ＴＣＰスタック２１５は、デレゲート接続の特性、例えば、接続の形式に対して指定されたユーザ定義プライオリティ、接続に対して指定された期間、接続に対して指定されたフレームレート、バルク転送を遂行するのに適したアプリケーションに対して接続が使用されるかどうか、接続により使用される特定のＴＣＰポート等に基づいて、接続をデレゲートするよう決定してもよい。

[0055]ステップ４１２において、ＴＣＰスタック２１５が、ＨＯＴユニット２５０による処理のために接続をデレゲートすべきでないと決定した場合は、ステップ４１４において、ＴＣＰスタック２１５は、接続を処理するためにＣＴ２４５のエントリーを設定し、次いで、ステップ４２２へ進む。ステップ４１２において、ＴＣＰスタック２１５が、ＨＯＴユニット２５０による処理のために接続をデレゲートすべきであると決定した場合は、ステップ４１６において、ＴＣＰスタック２１５は、ＨＯＴユニット２５０へコマンドを発行して、ＤＣＴ３５０のエントリーを接続状態データで設定する。ステップ４１８において、ＴＣＰスタック２１５は、以下に詳細に述べるように、後受信バッファ（ＰＲＢ）コマンドをＨＯＴユニット２５０へ発行して、システムメモリ１３０における１つ以上のユーザバッファの位置及びサイズをＨＯＴユニット２５０に与えるべきかどうか決定する。ステップ４１８において、ＴＣＰスタック２１５が、ＰＲＢコマンドを発行すると決定した場合には、ステップ４２０において、ＴＣＰスタック２１５は、ＰＲＢコマンドを発行する。ステップ４１８において、ＴＣＰスタック２１５が、ＰＲＢコマンドを発行しないと決定した場合には、ＴＣＰスタック２１５は、ステップ４２２へ進む。ステップ４２２において、接続設定が完了となる。

[0056]図４Ｂは、本発明の一実施形態に基づきフレームを受信するための方法ステップを示すフローチャートである。ステップ４２４において、ＨＯＴユニット２５０は、入力／出力インターフェイス２４２を経てフレームを受信し、そのフレームを部分的に処理して、部分的にパーズされたフレーム及びヘッダデータを発生することができる。ステップ４１６において、ＨＯＴユニット２５０は、フレームがデレゲート接続において受信されたかどうか決定し、もしそうでなければ、ステップ４４０において、ＨＯＴユニット２５０は、データリンク層とネットワーク層のプロトコルヘッダデータの完全なセットを含む部分的に処理されたフレームを、１つ以上のレガシーバッファにアップロードする。ステップ４４２において、ＴＣＰスタック２１５は、レガシーバッファへアップロードされた部分的に処理されたフレームを処理する。

[0057]ステップ４１６において、ＨＯＴユニット２５０が、フレームがデレゲート接続において受信されたと決定した場合には、ステップ４２６において、ＨＯＴユニット２５０は、フレームのパーズを完了し、ＴＣＰペイロードデータを抽出する。ステップ４２７において、ＨＯＴユニット２５０が、ユーザバッファが使用可能であるかどうか決定し、もしそうであれば、ステップ４２８において、ＨＯＴユニット２５０は、ＴＣＰペイロードデータを１つ以上のユーザバッファにアップロードする。ステップ４２７において、ＨＯＴユニット２５０が、ユーザバッファが使用できないと決定した場合には、ステップ４３０において、ＨＯＴユニット２５０は、ペイロードデータの一部分をレガシーバッファにアップロードし、ＴＣＰスタック２１５にそれを通知する。一実施形態において、前記一部分は、デレゲート接続に対応してＤＣＴ３５０のエントリーに記憶された「スタートアップ限界」値により指定される。この「スタートアップ限界」は、最大受信フレームサイズに等しい最大値と、アプリケーションプログラム２１７又はＴＣＰスタック２１５により決定された最小値とをとり得る変数である。

[0058]ステップ４３２において、ＴＣＰスタック２１５は、レガシーバッファにアップロードされたＴＣＰペイロードデータの一部分を処理する。ステップ４３４において、ＨＯＴユニット２５０は、デレゲート接続に対してＴＣＰスタック２１５により発行された１つ以上のＰＲＢコマンドが処理されたかどうか決定する。ステップ４３６において、ＨＯＴユニット３５０は、残りのＴＣＰペイロードデータを１つ以上のユーザバッファへアップロードする。ステップ４３４において、ＨＯＴユニット２５０が、デレゲート接続に対する１つ以上のＰＲＢコマンドが処理されなかったと決定した場合には、ステップ４３８において、ＨＯＴユニット２５０は、残りのＴＣＰペイロードデータをレガシーバッファにアップロードし、ＴＣＰスタック２１５にそれを通知する。別の実施形態では、ＴＣＰスタック２１５がステップ４３４を完了し、次いで、ステップ４３８において、ＴＣＰスタック２１５は、ＨＯＴユニット２５０に、残りのＴＣＰペイロードデータをレガシーバッファにアップロードするように命令する。

[0059]一実施形態において、メッセージ信号化割り込み(messagesignaledinterrupt)（ＭＳＩ）は、ＨＯＴユニット２５０が多数の割り込みベクトルを使用してその種々の割り込みソースを信号するためのメカニズムを与える。ＭＳＩを使用すると、ホストの割り込み取り扱い効率を得ることができる。一実施形態では、コンピュータシステム２００は、割り込みベクトルを８個まで使用する。

[0060]図４Ｃは、本発明の一実施形態に基づきスロースタートシーケンスを完了するための方法ステップを示すフローチャートである。スロースタート及び混雑回避アルゴリズムは、ＴＣＰプロトコル（ＲＦＣ７９３、ＲＦＣ１１２２及び関連ドキュメントに記載された）により指定され、それ故、当業者に良く知られている。ＴＣＰは、スロースタート及び混雑回避を使用して、所与の接続に対する使用可能な帯域巾を決定する。２つの変数、ｓｓｔｈｒｅｓｈ（スロースタートスレッシュホールド）及びｃｗｎｄ（混雑ウインドウ）が、デレゲート接続の振舞いを決定する。ＨＯＴユニット２５０は、受信したＡＣＫのカウントを含む特定のＡＣＫ情報をＴＣＰスタック２１５へアップロードする。ＡＣＫを受信するごとにＴＣＰスタック２１５に通知するのではなく、ＨＯＴユニット２５０は、ＡＣＫを合体するようにＴＣＰスタック２１５により構成されて、ＴＣＰスタック２１５で指定された頻度でＴＣＰスタック２１５へＡＣＫをアップロードしてもよい。ＡＣＫを合体することで、ＨＯＴユニット２５０は、それがデレゲート接続の状態についてＴＣＰスタック２１５に通知する頻度を減少することが許され、これは、多くの場合に性能を改善することが予想される。より詳細には、ＡＣＫを受信するごとにＣＰＵ１１０が割り込まれないので、ＣＰＵ１１０の利用が通常減少される。受信したＡＣＫのカウントを含ませることで、ＴＣＰスタック２１５は、スロースタート及び混雑回避を実施するための通知のたびに受信されたＡＣＫの数を決定することが許される。

[0061]ステップ４５２において、アプリケーションプログラム２１７は、ｃｗｎｄをデレゲート接続に対して１セグメントにセットし、次いで、ＴＣＰスタック２１５は、送信バッファ記述子をＨＯＴユニット２５０に出力し、これについては、図６Ｄを参照して詳細に説明する。ステップ４５４において、ＨＯＴユニット２５０は、行先からＡＣＫが受信されたかどうか決定する。ＨＯＴユニット２５０は、ＡＣＫが受信されるまでステップ４５４に留まり、次いで、ＨＯＴユニット２５０は、ＴＣＰスタック２１５に通知し、ステップ４５６へ進む。一実施形態において、ＨＯＴユニット２５０は、受信したＡＣＫのカウントをＴＣＰスタック２１５へ出力し、このＴＣＰスタック２１５は、各通知と通知との間にデレゲート接続に対して受信したＡＣＫの数を計算してもよい。

[0062]ステップ４５６において、ＴＣＰスタック２１５は、ｃｗｎｄがデレゲート接続に対してｓｓｔｈｒｅｓｈ以上であるかどうか決定し、もしそうであれば、ステップ４５８において、ＴＣＰスタック２１５は、デレゲート接続に対して受信したＡＣＫの数に基づいてｃｗｎｄを指数関数的に増加し、即ちオープンする。又、ステップ４５８において、ＴＣＰスタック２１５は、送信バッファ記述子をＨＯＴユニット２５０へ出力し、ステップ４５４へ復帰する。

[0063]一実施形態では、ステップ４５８において、ＴＣＰスタック２１５は、ＡＣＫを受信するたびにＴＣＰスタック２１５に通知するようにＨＯＴユニット２５０を構成する。別の実施形態では、ＴＣＰスタック２１５は、受信したＡＣＫのカウントをＴＣＰスタック２１５に通知し、これにより、幾つかのＡＣＫを合体するようにＨＯＴユニット２５０を構成する。ステップ４５６において、ＴＣＰスタック２１５が、ｓｓｔｈｒｅｓｈがデレゲート接続に対してｃｗｎｄ未満であると決定した場合には、ステップ４６０において、ＴＣＰスタック２１５は、混雑回避段階にある。混雑回避が使用されるときには、ｃｗｎｄが最大送信ウインドウサイズに等しくなるか又はパケットがドロップされるまで、ｃｗｎｄが直線的にオープンとなる。

[0064]図５Ａは、本発明の１つ以上の態様に基づき図２Ａ及び２Ｂに示されたアプリケーションメモリスペース２２７に記憶されたユーザバッファの実施形態を示す。ＨＯＴユニット２５０によりアップロードされるペイロードデータを受信するために、ユーザバッファ５１０、ユーザバッファ５１２又はユーザバッファ５１４のような各ユーザバッファがアプリケーションメモリスペース２２７に割り当てられる。ユーザバッファアドレス５１５のような物理的メモリアドレスは、アプリケーションメモリスペース２２７におけるユーザバッファ５１０の位置を指示する。同様に、ユーザバッファアドレス５２０は、ユーザバッファ５１２の位置を指示し、ユーザバッファアドレス５２５は、ユーザバッファ５１４の位置を指示する。ユーザバッファは、アプリケーションメモリスペース２２７内の物理的に隣接するメモリ位置に記憶されてもよいし、又はアプリケーションメモリスペース２２７内の物理的に非隣接のメモリ位置に記憶されてもよい。

[0065]図５Ｂは、本発明の１つ以上の態様に基づくユーザバッファ記述子の実施形態を示す。各ユーザバッファは、そのユーザバッファ内に記憶できるバイトの数により決定された対応長さを有する。例えば、ユーザバッファ５１０の長さは、ユーザバッファ長さ５３５である。ユーザバッファ記述子は、ユーザバッファアドレス５１５のようなユーザバッファアドレスと、ユーザバッファ長さ５３５のような対応ユーザバッファ長さとを含むデータ構造体である。別の実施形態では、ユーザバッファ記述子は、特殊な取り扱い等を含む記述子フラグを含んでもよい。ユーザバッファ記述子フラグは、とりわけ、ＰＲＢコマンドに含まれたユーザバッファへペイロードデータがアップロードされるときにＨＯＴユニット３５０が通知コマンドを発行することを要求するビットを含むことができる。

[0065]更に別の実施形態では、ユーザバッファ記述子は、ユーザバッファアドレス、ユーザバッファ長さ及びユーザバッファエンドアドレスの組合せを含んでもよい。上述したように、ユーザバッファ記述子は、ＴＣＰスタック２１５によりＰＲＢコマンドを使用してＨＯＴユニット２５０に与えられる。アプリケーションメモリスペース２２７内に位置する物理的メモリアドレスをＨＯＴユニット２５０へ与えることで、ＨＯＴユニット２５０は、ペイロードデータをアプリケーションメモリスペース２２７へ直接的にアップロードすることができる。

[0067]アプリケーションプログラム２１７は、オペレーティングシステムにより割り当てられた仮想的に隣接するアドレススペースであるユーザアドレススペースを管理する。アプリケーションプログラム２１７がユーザアドレススペース情報をＴＣＰスタック２１５へ転送するときに、ＴＣＰスタック２１５は、オペレーティングシステムがユーザバッファアドレススペースに対応するメモリをロックすることを要求する。オペレーティングシステムは、ある量のメモリをロックすると共に、システムメモリ１３０の物理的に隣接する部分に対応する１つ以上の物理的アドレス（及び長さ）をＴＣＰスタック２１５へ戻す。ＨＯＴユニット２５０によりアクセスされる物理的アドレススペースは、ＴＣＰスタック２１５により管理され、必ずしも物理的に隣接していない。ＴＣＰスタック２１５は、ユーザアドレススペースと物理的アドレススペースとの間を変換する。別の実施形態では、ドライバ２５５は、ユーザアドレススペースと物理的アドレススペースとの間を変換する。

[0068]図５Ｃは、本発明の１つ以上の態様に基づき図２Ａ及び２Ｂに示されたドライバメモリスペース２３５に記憶されるレガシーバッファの実施形態を示す。ＨＯＴユニット２５０によりアップロードされた部分的に処理されたフレームを受信するために、レガシーバッファ５５０、レガシーバッファ５５２又はレガシーバッファ５５４のような各レガシーバッファがドライブメモリスペース２３５に割り当てられる。レガシーバッファアドレス５５５のような物理的メモリアドレスは、ドライブメモリスペース２３５におけるレガシーバッファ５５０の位置を指示する。同様に、レガシーバッファアドレス５６０は、レガシーバッファ５５２の位置を指示し、レガシーバッファアドレス５６５は、レガシーバッファ５５４の位置を指示する。レガシーバッファは、ドライブメモリスペース２３５内の隣接するメモリ位置に記憶されてもよいし、又はドライブメモリスペース２３５内の非隣接のメモリ位置に記憶されてもよい。

[0069]図５Ｄは、本発明の１つ以上の態様に基づくレガシーバッファタグテーブル５９０の実施形態を示す。各レガシーバッファアドレスは、独特のタグに関連している。例えば、レガシーバッファアドレス５５５は、タグ５７５に関連しており、レガシーバッファアドレス５６０は、タグ５８０に関連しており、更に、レガシーバッファアドレス５６５は、タグ５８５に関連している。レガシーバッファタグテーブル５９０は、ドライバ２５５により維持され、一実施形態ではドライバメモリスペース２３５に記憶されてもよいし、又は別の実施形態ではＴＣＰスタックメモリスペース２２５に記憶されてもよい。

[0070]図５Ｅは、本発明の１つ以上の態様に基づくレガシーバッファ記述子の実施形態を示す。各レガシーバッファは、そのレガシーバッファに記憶できるバイトの数により決定された対応する長さを有する。例えば、レガシーバッファ５５０の長さは、レガシーバッファ長さ５７０である。別の実施形態では、全てのレガシーバッファの長さが等しい。レガシーバッファ記述子は、レガシーバッファアドレス５５５のようなレガシーバッファアドレスと、レガシーバッファ長さ５７０のような対応するレガシーバッファ長さと、タグ５７５のような対応するタグとを含むデータ構造体である。別の実施形態では、レガシーバッファ記述子は、レガシーバッファアドレスと、レガシーバッファ長さと、タグと、レガシーバッファエンドアドレスとの組合せを含んでもよい。レガシーバッファ記述子は、図６Ｃに関連して更に説明するように、ドライバ２５５により受信（バッファ）記述子リングを使用してＨＯＴユニット２５０へ与えられる。

[0071]ドライバ２５５とＨＯＴユニット２５０との間の通信は、ドライバメモリスペース２３５に記憶されたデータ構造体を介して遂行される。リングとは、以下に更に述べるように、多数のエントリーを含むデータ構造体である。リングは、ドライバ２５５により使用されるポインタ及びＨＯＴユニット２５０により使用される別のポインタと共にエントリーの円形待ち行列として編成される。各リングは、ドライバメモリスペース２３５の隣接する物理的メモリに記憶される。

[0072]図６Ａは、ドライバ２５５からＨＯＴユニット２５０へコマンドを転送すると共に、ＨＯＴユニット２５０からドライバ２５５へ状態を転送するためのコマンドリング６０１を示す概念図である。このコマンドリング６０１は、ＤＣＴ３５０におけるデレゲート接続エントリーを初期化し、ユーザバッファ記述子をＤＣＴ３５０に与えるのに使用される。コマンドリング６０１は、図６Ａにコマンドリングエントリー６０３として各々示された多数のエントリーを含む。各コマンドリングエントリー６０３は、そのエントリーがＨＯＴユニット２５０又はドライバ２５５のいずれかにより所有されることを指示する「自分（own）」のビットを含む。スタート時に、各エントリーにおける「自分」のビットは、エントリーがドライバ２５５により所有されたことを指示するように初期化され、コマンド書き込みポインタ６０７及びコマンド読み取りポインタ６０５は、コマンドリング６０１における同じエントリーである。ＴＣＰスタック２１５がドライバ２５５を経てエントリーへコマンドを書き込むと、「自分」のビットは、そのエントリーがＨＯＴユニット２５０により所有されたことを指示するようにセットされ、コマンド書き込みポインタ６０７は、コマンドリング６０１内の次のコマンドリングエントリー６０３を指すように変更される。ＨＯＴユニット２５０が、コマンド読み取りポインタ６０５によりアドレスされたエントリーを読み取って処理を完了すると、「自分」のビットは、そのエントリーがドライバ２５５により所有されたことを指示するようにセットされる。コマンド読み取りポインタ６０５は、コマンド書き込みポインタ６０７を通すことが許されない。コマンド読み取りポインタ６０５又はコマンド書き込みポインタ６０７のいずれかがコマンドリング６０１の最後のエントリーに到達すると、ポインタは、コマンドリング６０１の最初のエントリーへラップする。当業者であれば、ＨＯＴユニット２５０へコマンドを通信するのに他のメカニズムを使用してもよく、例えば、コマンドのリンクリスト、ＦＩＦＯ、共有メモリ機構等を使用してもよいことが理解されよう。

[0073]「自分」のビットに加えて、各コマンドリングエントリー６０３は、コマンドフィールド、ＤＣＴインデックス、コマンド特有の制御及び／又は状態情報、コマンド特有のデータ等を含む。上述したように、ＤＣＴインデックスは、デレゲート接続に対応するＤＣＴ３５０のエントリーを識別する。コマンドフィールドは、ＰＲＢコマンド、更新テーブルエントリー（ＵＴＥ）コマンド、無効化テーブルエントリー（ＩＴＥ）コマンド、ダンプ接続バッファテーブルエントリー（ＤＣＢＴＥ）コマンド等のコマンドに対するコマンド識別子を含む。ドライバ２５５によりコマンドが書き込まれるときには、コマンド特有の制御／状態情報は、コマンド特有の制御を含む。コマンドが読み取られ、ＨＯＴユニット３５０により更新されるときには、コマンド特有の制御／状態情報は、コマンド特有の状態を含むように更新される。コマンド特有のデータは、以下で更に説明するように、ドライバ２５５により書き込まれ、ＨＯＴユニット３５０により読み取られる。

[0074]ＰＲＢコマンドは、ＴＣＰスタック２１５及びドライバ２５５を経てＨＯＴユニット３５０へユーザバッファ記述子を通すためにアプリケーションプログラム２１７により使用される。各ユーザバッファ記述子は、ペイロードデータをアップロードするためにＨＯＴユニット３５０に対するアプリケーションメモリスペース２２７の物理的アドレスを指示する。ＴＣＰスタックは、１つ以上のユーザアドレスを受け取り、ユーザバッファ記述子に含ませるための対応する物理的アドレスを決定する。ＴＣＰスタック２１５は、単一デレゲート接続テーブルエントリーに対して、アプリケーションプログラム２１７に代わって、ＰＲＢコマンドを使用して、ドライバ２５５を経て１つ以上のユーザバッファ記述子をポスティングすることができる。ドライバ２５５は、ＰＲＢコマンド内のコマンド特有の制御及び／又は状態情報フィールドにユーザバッファの数を含ませる。ドライバ２５５は、以前にポスティングされたユーザバッファのどれほど多くがＨＯＴユニット３５０によりアップロードされたか決定するに必要な情報を有していないので、ＨＯＴユニット３５０は、ＰＲＢコマンドから受け入れられたユーザバッファの数を指示する値をコマンド特有の制御及び／又は状態情報フィールドに書き込む。

[0075]又、ＰＲＢコマンドにおけるコマンド特有の制御及び／又は状態情報フィールドは、「同期（sync）」ビットも含む。ＴＣＰスタック２１５は、図９Ｂに関連して以下に更に説明するように、アサートされたレガシーフラグを含む通知コマンドがＨＯＴユニット３５０から通知リング６１１を経て受信されたときに、「同期」ビットを書き込むようにドライバ２５５に要求する。

[0076]ドライバ２５５により構成されたＰＲＢコマンドにおけるコマンド特有のデータフィールドは、ＰＲＢコマンドでポスティングされる第１バッファの第１バイトに対応するスタートＴＣＰシーケンス番号、ＰＲＢコマンドに含まれた各ユーザバッファに対するユーザバッファ記述子等を含む。ユーザバッファ記述子は、アプリケーションメモリスペース２２７における位置を指定する物理的アドレス、ユーザバッファの長さ、特殊な取り扱いを指示する記述子フラグ等を含む。

[0077]ＵＴＥコマンドは、ドライバ２５５によりＤＣＴ３５０のエントリーを更新するのに使用されると共に、デレゲート接続がアクティブである間にデレゲート接続を設定し且つ接続データを更新するのに使用される。ＩＴＥコマンドは、デレゲート接続を無効化するのに使用される。ＨＯＴユニット２５０は、ＩＴＥコマンドを受信すると、そのＩＴＥコマンドに指定されたＤＣＴインデックスに対応するデレゲート接続をクリアする前に、送信エンジン３２０及び受信エンジン３６０による処理が完了するのを必要に応じて待機する（新たなＴＣＰ処理がスタートするのを阻止しながら）。ＤＣＢＴＥコマンドは、ＨＯＴユニット３５０が、ＤＣＢＴＥコマンドに含まれたＤＣＴインデックスで指定されたエントリーの一部分をレガシーバッファへアップロードするようにさせる。

[0078]ドライバ２５５は、ＰＲＢコマンドに対する送信又は受信処理に干渉せずに、コマンドリング６０１にアクセスすることができる。これは、ドライバ２５５がＨＯＴユニット３５０に適時に新たなユーザバッファを与えるのを許し、受信フレームを阻止するのではなくＨＯＴユニット３５０により受け入れできる見込みを改善する。

[0079]図６Ｂは、ＨＯＴユニット２５０からドライバ２５５へ事象通知記述子を転送するための通知リング６１１を示す概念図である。この通知リング６１１は、ＨＯＴユニット２５０からドライバ２５５を経てＴＣＰスタック２１５へ接続情報を搬送する。当業者であれば、ＨＯＴユニット２５０からＴＣＰスタック２１５へ情報を通信するのに、他のメカニズムを使用してもよく、例えば、通信記述子のリンクリスト、ＦＩＦＯ、共有メモリ機構等を使用してもよいことが理解されよう。

[0080]通信リング６１１は、図６Ｂに通知リングエントリー６１３として各々示された多数のエントリーを含む。各通知リングエントリー６１３は、そのエントリーがＨＯＴユニット２５０又はドライバ２５５のいずれかにより所有されることを指示する「自分」のビットを含む。スタート時に、各エントリーにおける「自分」のビットは、エントリーがＨＯＴユニット２５０により所有されたことを指示するように初期化され、通知書き込みポインタ６１７及び通知読み取りポインタ６１５は、通知リング６１１における同じエントリーである。ＨＯＴユニット２５０が通知記述子をドライバ２５５に書き込むと、「自分」のビットは、そのエントリーがドライバ２５５により所有されたことを指示するようにセットされ、通知書き込みポインタ６１５は、通知リング６１１内の次の通知リングエントリー６１３を指すように変更される。ドライバ２５５が、通知読み取りポインタ６１７によりアドレスされたエントリーを読み取って処理を完了すると、「自分」のビットは、そのエントリーがＨＯＴユニット２５０により所有されたことを指示するようにセットされる。通知読み取りポインタ６１７は、通知書き込みポインタ６１５を通すことが許されない。通知読み取りポインタ６１７又は通知書き込みポインタ６１５のいずれかが通知リング６１１の最後のエントリーに到達すると、ポインタは、通知リング６１１の最初のエントリーへラップする。

[0081]「自分」のビットに加えて、各通知リングエントリー６１３は、通知フラグフィールド、ＤＣＴインデックス、及び任意のタグであって、これが存在する場合に、ＤＣＴインデックスで指定されたデレゲート接続に対して、特定のレガシーバッファへの参照、次に予想されるシーケンス番号、最高の受信ＡＣＫ番号、最も最近受信した送信ウインドウサイズ、現在ＴＣＰタイムスタンプ等を与える任意のタグを含む。通知フラグフィールドは、「レガシー」フラグ、「プッシュ通知」フラグ、「複写ＡＣＫ」フラグ、「シーケンス番号スレッシュホールド」フラグ、「ＡＣＫスレッシュホールド」フラグ、「要求バッファ」フラグ等を含む。「レガシー」フラグは、ペイロードデータ又は部分的にパーズされたフレームデータがＨＯＴユニット２５０によりレガシーバッファへアップロードされたときにアサートされる。「プッシュ通知」フラグ、「複写ＡＣＫ」フラグ、「シーケンス番号スレッシュホールド」フラグ、「ＡＣＫスレッシュホールド」フラグ、及び「要求バッファ」フラグの機能は、図９Ａを参照して説明する。

[0082]任意のタグは、図８Ｃに関連して更に説明するように、ＨＯＴユニット２５０がペイロードデータ又は部分的にパーズされたフレームデータをレガシーバッファへアップロードするときに含まれる。このタグは、以下に更に述べるように、ドライバ２５５から受信記述子リングを経て受け取られ、このタグを使用して、ペイロードデータ又は部分的にパーズされたフレームデータがアップロードされたレガシーバッファに所与の通知を関連付ける。ドライバ２５５は、通知と共に受け取られたタグを使用して、そのタグに関連したレガシーバッファタグテーブル５９０のエントリーを読み取ることにより、ドライバメモリスペース２３５においてレガシーバッファを探索することができる。

[0083]ＨＯＴユニット２５０は、通知リング６１１を使用して、ドライバ２５５による更なる処理を要求する接続状態を適時にドライバ２５５に通知し、しかも、ＨＯＴユニット２５０による送信又は受信処理に対する影響がもしあっても最小であるようにすることができる。通知リング６１１の動作で、ドライバ２５５は、ＨＯＴユニット３５０に新たなユーザバッファを適時に与えることが許され、受信フレームを阻止するのではなくＨＯＴユニット３５０により受け入れることのできる見込みを改善する。

[0084]図６Ｃは、本発明の１つ以上の態様に基づきＴＣＰスタック２１５からドライバ２５５を経てＨＯＴユニット２５０へ受信バッファ情報を転送するための受信記述子リング６２１を示す概念図である。この受信記述子リング６２１は、ＨＯＴユニット２５０へレガシーバッファ記述子を与えるのに使用される。非ＴＣＰフレーム、非デレゲート接続において受信されたフレーム、異常（予期しないフラグ、シーケンスずれ、無効チェック和、等）を含むデレゲート接続において受信されたフレーム、及びＤＣＴ３５０からアップロードされる接続データを含む多数の形式のデータを、ＨＯＴユニット２５０によりレガシーバッファへアップロードすることができる。当業者であれば、ＨＯＴユニット２５０へバッファ記述子を与えるのに他のメカニズムを使用してもよく、例えば、バッファ記述子のリンクリスト、ＦＩＦＯ、共有メモリ機構等を使用してもよいことが理解されよう。

[0085]受信記述子リング６２１は、図６Ｃに受信記述子リングエントリー６２３として各々示された多数のエントリーを含む。各受信記述子エントリー６２３は、そのエントリーがＨＯＴユニット２５０又はドライバ２５５のいずれかにより所有されることを指示する「自分」のビットを含む。「自分」のビットの機能は、図６Ａに関連して説明した通りである。受信記述子書き込みポインタ６２７の機能は、コマンド書き込みポインタ６０７と同じであり、受信記述子読み取りポインタ６２５の機能は、コマンド読み取りポインタ６０５と同じである。

[0086]「自分」のビットに加えて、各受信記述子リングエントリー６２３は、レガシーバッファ記述子、受信制御及び／又は状態フィールド、等を含む。図５Ｅに関連して既に述べたように、レガシーバッファ記述子は、ドライバメモリスペース２３５内の位置を指定する物理的アドレス、レガシーバッファ長さ、及び任意のタグを含む。

[0087]受信記述子リングエントリー６２３がドライバ２５５により書き込まれるときには、受信記述子リングエントリー６２３は、他のビットの中でも、受信記述子リングエントリー６２３で指定されたレガシーバッファにデータがアップロードされるときにＨＯＴユニット３５０が割り込みを発行するのを要求するビットを含むことができる。受信記述子リングエントリー６２３がＨＯＴユニット３５０により読み取られて更新されるときには、受信制御及び／又は状態情報は、ペイロードデータ又はパーズされたフレームデータがレガシーバッファへアップロードされるときに接続状態を含むように更新される。レガシーバッファにアップロードされた非デレゲート接続に対してＨＯＴユニット３５０により書き込まれる受信制御及び／又は状態情報は、受信フレーム終了指示子、最大フレームサイズ超過指示子等を含むことができる。レガシーバッファにアップロードされたデレゲート接続に対してＨＯＴユニット３５０により書き込まれる受信制御及び／又は状態情報は、スタートバッファ指示子、ユーザバッファ使用不可指示子、受信フレーム終了、レンジ外れＡＣＫ受信指示子、等を含むことができる。

[0088]図６Ｄは、本発明の１つ以上の態様に基づきＴＣＰスタック２１５からドライバ２５５を経てＨＯＴユニット２５０へ送信バッファ情報を転送するための送信記述子リング６３１を示す概念図である。この送信記述子リング６３１は、送信バッファ記述子をＨＯＴユニット２５０へ与えるのに使用される。当業者であれば、バッファ記述子をＨＯＴユニット２５０へ与えるのに他のメカニズムを使用してもよく、例えば、バッファ記述子のリンクリスト、ＦＩＦＯ、共有メモリ機構等を使用してもよいことが理解されよう。

[0089]送信記述子リング６３１は、図６Ｄに送信記述子リングエントリー６３３として各々示された多数のエントリーを含む。各送信記述子エントリー６３３は、そのエントリーがＨＯＴユニット２５０又はドライバ２５５のいずれかにより所有されることを指示する「自分」のビットを含む。自分のビットの機能は、図６Ａに関連して説明した通りである。送信記述子書き込みポインタ６３７の機能は、コマンド書き込みポインタ６０７と同じであり、送信記述子読み取りポインタ６３５の機能は、コマンド読み取りポインタ６０５と同じである。

[0090]「自分」のビットに加えて、各送信記述子リングエントリー６３３は、送信バッファ記述子、ＤＣＴインデックス、送信特有制御、送信制御／状態フィールド、送信バッファバイトカウント、等を含む。送信バッファ記述子は、送信のためのフレームデータが記憶されたアプリケーションメモリスペース２２７又はＴＣＰスタックメモリスペース２２５内の位置を指定する物理的アドレスを含む。ＨＯＴユニット２５０は、物理的アドレスを使用して、送信のためのフレームデータをドライバメモリスペース２３５から読み取る。送信特有の制御は、送信エンジン３２０がフレームの第１バイトのシーケンス番号をＤＣＴ３５０にセーブするための要求を含むことができる。フレームに対してＡＣＫが受け取られると、ＨＯＴユニット２５０は、通知コマンドを発生してもよい。

[0091]ドライバ２５５により書き込まれる送信制御及び／又は状態フィールドは、送信フレーム終了指示子、ＴＣＰセグメント化をイネーブルするビット、ＨＯＴユニット２５０においてＴＣＰチェック和計算をイネーブルする１つ以上のビット、ＴＣＰセグメント化中に使用するための最大セグメントサイズ等を含むことができる。送信記述子リングエントリー６３３がＨＯＴユニット２５０により読み取られて更新されるときには、送信特有の制御及び／又は状態情報が、送信特有の状態を含むように更新される。送信特有の状態は、キャリアロス指示子、送信再試みカウント、再試みエラー等を含むことができる。

[0092]図７は、本発明の１つ以上の態様に基づく図３に示されたＨＯＴユニット２５０の一部分を含むブロック図である。ＤＣＴ３５０は、ドライバ２５５からコマンドリング６０１を経て受け取られたコマンドを処理するためのＣＭＤユニット７１０を備えている。デレゲート接続情報は、ＤＣＴ３５０内において、接続バッファテーブル（ＣＢＴ）７１５、接続データテーブル（ＣＤＴ）７２０、及び接続一致テーブル（ＣＭＴ）７２５に記憶される。ＣＢＴ７１５、ＣＤＴ７２０、及びＣＭＴ７２５内のデレゲート接続のエントリーは、ＣＭＤユニット７１０により書き込むことができる。ＣＭＴ７２５は、デレゲート接続識別情報を記憶し、ＣＭＴ７２５は、デレゲート接続が設定されたときにＣＭＤユニット７１０により書き込まれる。ＣＭＴ７２５において、デレゲート接続に対応するエントリーは、接続がデレゲートされたままである限り又は接続が終了するまで、その対応性を維持する。ＣＭＴ７２５のエントリーは、行先ＩＰアドレス、ソースＩＰアドレス、ソースＴＣＰポート、行先ＴＣＰポート等を含む。

[0093]ＣＤＴ７２０のエントリーは、デレゲート接続が設定されたときにＣＭＤユニット７１０により初期化される。ＣＤＴ７２０内のエントリーは、予想されるシーケンス番号、ＡＣＫ番号、タイムスタンプデータ、非確認(unACKnowledged)フレームのカウント、等のデレゲート接続に対するデレゲート接続状態情報を含む。ＣＤＴ７２０のエントリー内のフィールドは、フレームがデレゲート接続上で送信するように構成されたときに、送信エンジン３２０により読み取られて任意に変更される。同様に、ＣＤＴ７２０のエントリー内のフィールドは、デレゲート接続上の到来フレームが処理されるときに、受信エンジン３６０内のユニットにより読み取られて任意に変更される。ＣＢＴ７１５のエントリーは、ＰＲＢコマンドがデレゲート接続に対して受信されたときに、ＣＭＤユニット７１０により１つ以上のユーザバッファ記述子と共に書き込まれる。ユーザバッファ情報は、受信エンジン３６０内のバッファアップロードユニット７４５により読み取られて任意に変更される。

[0094]デレゲート接続情報は、ＣＢＴ７１５に影響するユーザバッファポスティングからＣＤＴ７２０に記憶された状態情報のアクセスを減結合するように、ＣＢＴ７１５、ＣＤＴ７２０及びＣＭＴ７２５間に分布されている。更に、状態情報は、最も最近受信したフレームに基づいて受信エンジン３６０により更新されるので、送信エンジン３２０及びＴＣＰスタック２１５は、フレーム構成中に現在状態情報にアクセスすることができる。同様に、状態情報は、最も最近送信されたフレームに基づいて送信エンジン３２０により更新されるので、受信エンジン３６０及びＴＣＰスタック２１５は、フレーム処理中に最新の状態情報にアクセスすることができる。

[0095]受信インターフェイス３７０内において、バッファである受信ＦＩＦＯ７３０は、到来するフレームをバッファする。受信インターフェイス３７０は、受信エンジン３６０内の前パーズユニット７３５にフレーム及び有効フレーム指示子を出力する。前パーズユニット７３５は、有効フレームをパーズして、部分的にパーズされたフレームを発生すると共に、ＣＭＴ７２５を読み取って、デレゲート接続上にフレームが受信されたかどうか決定する。前パーズユニット７３５は、部分的にパーズされたフレームをパージングユニット７４０へ出力する。このパージングユニット７４０は、各々の部分的にパーズされたフレームのプロトコル形式、例えば、ＴＣＰ、ＵＤＰ、ＩＰ等を決定し、そして任意であるが、その部分的にパーズされたフレームをパーズして、パーズされたフレーム及び部分的にパーズされたフレームを発生する。パージングユニット７４０は、ＣＤＴ７２０を読み取り、１つ以上の特殊なケースが存在するかどうか決定し、更に、部分的にパーズされたフレーム、パーズされたフレーム、又はフレームをバッファアップロードユニット７４５へ出力する。又、パージングユニット７４０は、任意であるが、通知ユニット７５０内のレジスタのような記憶素子に記憶された以下で更に説明する通知フラグをセットする。

[0096]バッファアップロードユニット７４５は、ＣＢＴ７１５を読み取り、そして任意であるが、ＣＢＴ７１５及びＣＤＴ７２０に書き込みを行なう。バッファアップロードユニット７４５は、フレーム、部分的にパーズされたフレーム、及びパーズされたフレームを、ＤＭＡエンジン３１０を経てシステムメモリ１３０へアップロードする。バッファアップロードユニット７４５は、ＣＢＴ７１５に記憶されたユーザバッファ記述子又はドライバ２５５から受信記述子リング６２１を経て受信したレガシーバッファ記述子に記憶されたデータに基づいて、システムメモリ１３０に書き込むべき位置を指定する。同様に、送信エンジン３２０は、ドライバ２５５から送信記述子リング６３１を経て受信された送信バッファ記述子に基づいて、システムメモリ１３０において読み取るべき位置を指定する。通知ユニット７５０は、ドライバ２５５への通知を、ＤＭＡエンジン３１０を経て通知リング６１１へ出力する。

[0097]限定された数の接続に対するデレゲート接続情報は、ＣＭＴ７２５に記憶され、限定された数に到達した後に、過剰な接続に対する接続情報は、システムメモリ１３０内のＣＴ２４５（図２Ａ又は２Ｂ）のみに記憶される。一実施形態では、ＣＴ２４５の接続情報にアクセスして、過剰な接続に対して到来するフレーム及び出て行くフレームを処理するのではなく、ＨＯＴユニット２５０が、部分的に処理されたフレームをドライバメモリスペース２３５内のレガシーバッファにアップロードする。別の実施形態では、ＨＯＴユニット２５０は、ＤＣＴ３５０をキャッシュとして取り扱い、必要に応じてＣＴ２４５にアクセスして、当該接続データを探索する。ＴＣＰスタック２１５は、ＨＯＴユニット２５０により遂行される付加的な到来するフレーム又は出て行くフレームの処理とは独立して、部分的に処理されたフレームの処理を完了する。それ故、過剰接続のレガシー処理は、通常、ＨＯＴユニット２５０なしにコンピュータシステム２００でフレームを処理する場合以上のレートで行なわれる。このレートは、フレームがＨＯＴユニット２５０により部分的に処理されるので良好であり、受信インターフェイス３７０で遂行されたフレーム確認の結果も、ドライバメモリスペース２３５へアップロードされる。更に、ドライバ２５５及びＴＣＰスタック２１５によるレガシー処理は、ＨＯＴユニット２５０による送信処理又はＨＯＴユニット２５０による受信処理と同時に進行することができる。

[0098]図８Ａは、本発明の一実施形態に基づき有効フレームを処理するための方法ステップを示すフローチャートである。ステップ８０１において、受信エンジン３６０内の前パーズユニット７３５により有効フレームが受信される。ステップ８０３において、前パーズユニット７３５は、有効フレームがＴＣＰフレームであるかどうか決定し、もしそうでなければ、ステップ８０５において、当業者に知られた非ＴＣＰ処理が完了される。一実施形態では、受信エンジン３６０は、受信したＵＤＰフレームの処理を完了する。別の実施形態では、受信エンジン３６０は、他のプロトコルの処理を完了する。更に別の実施形態では、受信エンジン３６０は、他のプロトコルのフレームをドライバメモリスペース２３５へアップロードし、ドライバ２５５に通知する。

[0099]ステップ８０３において、前パーズユニット７３５が、有効フレームがＴＣＰフレームであると決定した場合には、ステップ８０７において、前パーズユニット７３５は、ＣＭＴ７２５から１つ以上のエントリーを読み取る。ステップ８０９において、前パーズユニット７３５は、以下「フレーム」と称されるＴＣＰフレームがデレゲート接続において受信されたかどうか決定し、即ちフレームがＣＭＴ７２５のエントリーに一致するかどうか決定する。前パーズユニット７３５は、行先ＩＰアドレス、ソースＩＰアドレス、ソースＴＣＰポート及び行先ＴＣＰポートをフレームから抽出し、それらの値を使用して、ＣＭＴ７２５における一致エントリーをサーチする。一致は、接続がデレゲートされていることを指示する。ステップ８０９において、前パーズユニット７３５が、フレームがデレゲート接続において受信されなかったと決定した場合には、ステップ８１３において、フレームのレガシー処理が完了となる。前パーズユニット７３５は、パージングユニット７４０を経てバッファアップロードユニット７４５へフレームを出力し、フレームがデレゲート接続において受信されなかったことを指示することにより、レガシー処理を開始する。バッファアップロードユニット７４５は、少なくとも部分的にパーズされたフレームを、ＤＭＡエンジン３１０を経てドライバメモリスペース２３５へアップロードし、以下に詳細に述べるように、レガシー処理の要求と共にドライバ２５５に通知する。

[00100]ステップ８０９において、前パーズユニット７３５が、フレームがデレゲート接続において受信されたと決定した場合には、ステップ８１１において、前パーズユニット７３５は、部分的に処理されたフレームをパージングユニット７４０へ出力する。ステップ８１１では、パージングユニット７４０は、部分的に処理されたフレームをパーズして、パーズされたフレームを発生すると共に、特殊なケース、例えば、ＩＰ又はＴＣＰオプション、無効フラグ等があるかどうか決定し、もしそうであれば、ステップ８１２において、パージングユニットは、パーズされたフレームをバッファアップロードユニット７４５へ出力して、特殊なケースがあることを指示する。ステップ８１２において、バッファアップロードユニット７４５は、デレゲート接続に対応するＣＢＴ７２０のエントリーにおいて「同期要求」フラグをセットし、又、デレゲート接続に対応するＣＢＴ７１５のエントリーにあるユーザバッファ記述子をフラッシュする。ステップ８１３において、バッファアップロードユニット７４５は、パーズされたフレームを、ＤＭＡエンジン３１０を経てドライバメモリスペース２３５へアップロードし、レガシー処理の要求と共にドライバ２５５に通知する。ステップ８１２においてデレゲート接続に対して「同期要求」フラグをセットすると、デレゲート接続がレガシー処理を使用して処理されることを指示する。受信エンジン３６０は、図９Ａに関連して更に述べるように、将来のバッファポスティング事象により同期要求フラグがクリアされるまで、デレゲート接続に対するユーザバッファ記述子コマンドを受け入れない。

[00101]ステップ８１１において、パージングユニット７４０が、特殊なケースがないと決定した場合には、ステップ８１５において、パージングユニット７４０は、デレゲート接続に対応するＣＤＴ７２０のエントリーを読み取る。ステップ８１７において、パージングユニット７４０及びバッファアップロードユニット７４５は、図９Ａに関連して更に説明するように、通知ユニット７５０に記憶された通知フラグがもしあれば、どれがセットされたか決定する。ステップ８１９において、パージングユニット７４０は、ＴＣＰフレームから抽出されたシーケンス番号（ＳＮ）が、デレゲート接続に対応してＣＤＴ７２０のエントリーに記憶されたシーケンス番号（ＤＣＴ ＳＮ）に等しくないかどうか決定し、もしそうであれば、ステップ８２１において、パージングユニット７４０によりシーケンスずれ回復が要求される。シーケンスずれ回復は、図８Ｂに関連して更に説明する。

[00102]ステップ８１９において、パージングユニット７４０が、ＳＮがＤＣＴ ＳＮに等しいと決定すると、ステップ８２３において、パージングユニット７４０は、パーズされたフレームをバッファアップロードユニット７４５へ出力する。ステップ８２３において、バッファアップロードユニット７４５は、デレゲート接続に対応するＣＢＴ７１５のエントリーを読み取る。ステップ８２５において、バッファアップロードユニット７４５は、ユーザバッファが使用可能かどうか決定する。「ユーザバッファ」という語は、「ＨＯＴバッファ」という語と交換可能である。ＨＯＴバッファが使用できない場合には、ステップ８２７において、バッファアップロードユニット７４５は、ＨＯＴバッファが使用可能になるのを待機するか、又はパーズされたＴＣＰフレームを、ＤＭＡエンジン３１０を経てレガシーバッファへアップロードする。これについては、図８Ｃに関連して更に説明する。

[00103]ステップ８２５において、バッファアップロードユニット７４５が、ＨＯＴバッファが使用可能であると決定すると、ステップ８２９において、バッファアップロードユニット７４５は、パーズされたフレームの処理を完了し、ペイロードデータの少なくとも一部分をＨＯＴバッファへアップロードする。これについては、図８Ｄに関連して更に説明する。ステップ８３１において、ペイロードデータの一部分をＨＯＴバッファにアップロードした後に、バッファアップロードユニット７４５は、パーズされたフレームに付加的なペイロードデータがあるかどうか決定し、もしあれば、ステップ８２５及び８２９を繰り返す。ステップ８３１において、バッファアップロードユニット７４５が、全てのペイロードデータが１つ以上のＨＯＴバッファへアップロードされたと決定すると、ステップ８３３において、バッファアップロードユニットは、パーズされたフレームにおけるＴＣＰ「プッシュ」フラグがアサートされたかどうか決定する。ステップ８３３において、バッファアップロードユニット７４５が、ＴＣＰ「プッシュ」フラグがアサートされたと決定すると、バッファアップロードユニット７４５は、デレゲート接続に対応するＣＢＴ７１５のエントリーに対して「同期要求」フラグをセットし、デレゲート接続に対応するＣＢＴ７１５のエントリーにおけるユーザバッファ記述子をフラッシュする。ステップ８３３において、バッファアップロードユニット７４５が、ＴＣＰ「プッシュ」フラグがアサートされないと決定すると、受信エンジン３６０は、ステップ８０１へ進む。

[00104]図８Ｂは、本発明の一実施形態に基づきシーケンスずれフレームを処理するための方法ステップを示すフローチャートである。当業者であれば、図８Ｂを参照して述べる方法ステップは、図８Ａのステップ８２１を遂行する１つのやり方を構成することが理解されよう。シーケンスずれ回復は、ＤＣＴ ＳＮに記憶された値に基づいて予想されるものより大きなＳＮ（例えば、１つ以上の失われたフレームから生じる）、又はＤＣＴ ＳＮ未満のＳＮ（例えば、送信時間切れ又は失われたＡＣＫのためにフレームの再送信から生じる）を含むケースを取り扱う。ＳＮがＤＣＴ ＳＮより大きいときには、受信エンジン３６０は、３回までの連続する同一構成のＡＣＫ（正しいシーケンスで受け取った最後のフレームに各々対応する）の送信を含む「高速回復」アルゴリズムを実行し、デレゲート接続に対してユーザバッファを無効化し（フラッシュし）、次いで、全フレームを１つ以上のレガシーバッファにアップロードする。ＳＮがＤＣＴ ＳＮ未満であるときには、受信エンジン３６０は、フレームに対してＡＣＫを送信し、デレゲート接続に対してユーザバッファを無効化し、次いで、全フレームを１つ以上のレガシーバッファへアップロードする。

[00105]ステップ８３０において、パージングユニット７４０は、フレームから抽出されたＳＮが、図８Ａのステップ８１５においてＣＤＴ７２０から読み取られたＤＣＴ ＳＮ未満であるかどうか決定し、もしそうであれば、ステップ８３２において、パージングユニット７４０は、フレームに対してＡＣＫを発生するように送信エンジン３２０に信号する。又、ステップ８３２において、パージングユニット７４０は、パーズされたフレームをバッファアップロードユニット７４５へ出力し、ステップ８３８へ進む。ステップ８３０において、パージングユニット７４０が、フレームから抽出されたＳＮがＤＣＴ ＳＮ未満でないと決定した場合には、ステップ８３４において、パージングユニット７４０は、ステップ８１５においてＣＤＴ７２０から読み取られた「高速ＡＣＫ」値が３未満であるかどうか決定し、もしそうであれば、パージングユニット７４０は、ステップ８３６において、パーズされたフレームに対してＡＣＫを発生するように送信エンジン３２０に信号する。又、ステップ８３６において、パージングユニット７４０は、パーズされたフレームをバッファアップロードユニット７４５へ出力すると共に、ＣＤＴ７２０に記憶された「高速ＡＣＫ」値を増加するようにバッファアップロードユニット７４５に指示する。

[00106]ステップ８３３において、バッファアップロードユニット７４５は、ＣＢＴ７１５に記憶されたデレゲート接続に対応するＨＯＴバッファをフラッシュする。ステップ８４０において、バッファアップロードユニット７４５は、ＣＢＴ７１５におけるデレゲート接続に対応する「同期要求」フラグをセットし、そして任意であるが、ＣＤＴ７２０に記憶されたデレゲート接続に対する接続状態データ、例えば、高速ＡＣＫ、ＤＣＴ ＳＮ、ＡＣＫ番号等を更新する。ステップ８１３において、バッファアップロードユニット７４５は、パーズされたＴＣＰフレームを、ＤＭＡエンジン３１０を経てドライバメモリスペース２３５へアップロードし、レガシー処理の要求と共にドライバ２５５に通知する。

[00107]図８Ｃは、本発明の一実施形態に基づきユーザバッファを待機するための方法ステップを示すフローチャートである。当業者であれば、図８Ｃを参照して説明する方法ステップは、図８Ａのステップ８２７を遂行する１つのやり方を構成することが理解されよう。受信エンジン３６０は、ユーザバッファにアップロードされたデータがＴＣＰスタック２１５によりドライバメモリスペース２３５からアプリケーションメモリスペース２２７へコピーされる必要がないので、パーズされたフレーム又は部分的にパーズされたフレームをレガシーバッファにアップロードするのではなく、ユーザバッファを待機する。更に、デレゲート接続がレガシーバッファを使用して処理されると、ＴＣＰスタック２１５は、「同期要求」フラグに応答しなければならず、その結果、「同期要求」フラグは、デレゲート接続に対するパーズされたフレーム又は部分的にパーズされたフレームが受信エンジン３６０によりユーザバッファへアップロードされる前に、クリアされる。

[00108]ステップ８５０において、バッファアップロードユニット７４５は、「要求バッファ」フラグが、デレゲート接続に対応して図８Ａのステップ８２３で読み取られたエントリーにおいてセットされたかどうか決定する。「要求バッファ」フラグがセットされない場合には、ステップ８５２において、バッファアップロードユニット７４５は、デレゲート接続に対応するＣＢＴ７１５のエントリーにおける要求バッファフラグをセットし、バッファ要求タイマーを、レジスタに記憶された値に初期化する。別の実施形態では、バッファ要求タイマーは、デレゲート接続に対応するＣＢＴ７１５のエントリーに記憶された値に初期化される。ステップ８５０において、バッファアップロードユニット７４５が、「要求バッファ」フラグがセットされたと決定した場合には、バッファアップロードユニット７４５は、ステップ８６２へ進む。

[00109]ステップ８５４において、バッファアップロードユニット７４５は、「スタートアップ限界」値で決定された数のバイトを、ＤＭＡエンジン３１０を経てレガシーバッファへアップロードする。ＴＣＰスタック２１５により初期化されるスタートアップ限界は、デレゲート接続に対応してＣＤＴ７２０のエントリーに記憶される。ステップ８５６において、バッファアップロードユニット７４５は、通知ユニット７５０に記憶された「要求バッファ」フラグをセットし、この通知ユニット７５０は、通知リングを経てドライバ２５５へ通知を発行する。通知は、関連レガシーバッファ記述子からのタグフィールドに使用された同じタグ値を含む。通知ユニット７５０は、通知を送信した後に通知フラグをクリアする。当業者に知られた技術を使用して、パーズされたフレームがドライバメモリスペース２３５へアップロードされた後、ドライバ２５５がそれに対応する通知を受信するように確保する。

[00110]ステップ８５８において、バッファアップロードユニット７４５は、受信ＦＩＦＯ７３０の「いっぱい状態」を指示する値が限界値、例えば「高水位線」マークより高いかどうか決定し、もしそうであれば、バッファアップロードユニット７４５は、ステップ８６２へ進む。一実施形態では、高水位線マークが固定である。別の実施形態では、高水位線マークが、ドライバ２５５によりプログラムされたレジスタに記憶される。ステップ８５８において、バッファアップロードユニット７４５が、受信ＦＩＦＯ７３０の「いっぱい状態」を指示する値が「高水位線」マークより高くないと決定した場合に、ステップ８６０において、バッファアップロードユニット７４５は、バッファ要求タイマーが時間切れしたかどうか決定する。ステップ８６０において、バッファアップロードユニット７４５が、バッファ要求タイマーが時間切れしたと決定した場合には、ステップ８６２において、バッファアップロードユニット７４５は、ＣＢＴ７１５に記憶された「同期要求」フラグ及び通知ユニット７５０に記憶されたレガシーフラグをセットする。ステップ８１３において、バッファアップロードユニット７４５は、パーズされたフレームを、ＤＭＡエンジン３１０を経てドライバメモリスペース２３５へアップロードする。通知ユニット７５０は、通知リングを経てドライバ２５５へ通知を発行し、通知ユニット７５０は、通知フラグをクリアし、更に、受信エンジン３６０は、図８Ａのステップ８０１へ復帰する。通知は、関連レガシーバッファ記述子からのタグフィールドに使用された同じタグ値を含む。当業者に知られた技術を使用して、パーズされたフレームがドライバメモリスペース２３５へアップロードされた後、ドライバ２５５がそれに対応する通知を受信するように確保する。

[00111]ステップ８６０において、バッファアップロードユニット７４５が、バッファ要求タイマーが時間切れしないと決定した場合には、ステップ８６４において、バッファアップロードユニット７４５は、ユーザバッファが使用可能であるかどうか、即ちアプリケーションプログラムがコマンドリングを経てユーザバッファをポスティングしたかどうか決定する。ユーザバッファが使用可能でない場合には、バッファアップロードユニット７４５は、ステップ８５８に復帰する。ユーザバッファが使用可能である場合には、バッファアップロードユニット７４５は、ステップ８２９において、パーズされたフレームの処理を完了し、ペイロードデータをユーザバッファへアップロードする。これについては、図８Ｄに関連して更に説明する。ステップ８２９に続いて、受信エンジン３６０は、図８Ａのステップ８３１へ復帰する。

[00112]図８Ｄは、本発明の一実施形態に基づきＨＯＴバッファ処理を完了するための方法ステップを示すフローチャートである。当業者に明らかなように、図８Ｄを参照して述べる方法ステップは、図８Ａのステップ８２９を遂行する１つのやり方を構成する。ＨＯＴユニット２５０が到来するデータを受信したときには、ＡＣＫを送信者（行先接続）へ送信して、どれほど多くのデータをＨＯＴユニット２５０へ送信できるか指示する受信ウインドウを、受信経路の飽和を許すに充分な巾で開いたままにするよう確保しなければならない。受信したフレームが適時に確認されないときには、受信ウインドウを閉じることが必要となり、さもなければ、送信者の再送信タイマーが時間切れとなって、送信者が１つ以上のフレームを再送信することになる。

[00113]ＡＣＫを送信者に送信するのに加えて、ドライバ２５５は、フレームがＨＯＴユニット２５０により受信されたときに、シーケンス番号、タイマー等に基づいて通知される。ＣＤＴ７２０は、受信したＴＣＰペイロードのサイズだけＤＣＴ ＳＮを増加することにより更新され、非確認フレームのカウントが増加され、更に、ＴＣＰタイムスタンプオプションが受信フレームに適当に含まれていた場合には、受信フレームから抽出された最も最近受信されたＴＣＰタイムスタンプがデレゲート接続に対してＣＤＴ７２０に記憶される。

[00114]ステップ８７６において、パージングユニット７４０は、非確認フレームのカウントが非確認フレーム限界より大きいかどうか決定し、もしそうであれば、ステップ８８０へ進む。非確認フレーム限界は、接続に対してＣＤＴ７２０に記憶され、ＴＣＫスタック２１５により決定される。別の実施形態では、パージングユニット７４０は、ステップ８７６において、デレゲート接続上で受信された非確認フレームのカウントが、非確認フレーム限界以上であるかどうか決定する。更に別の実施形態では、バッファアップロードユニット７４５は、非確認フレームのカウントが非確認フレーム限界より大きいかどうか決定する。

[00115]ステップ８７６において、パージングユニット７４０が、非確認フレームのカウントが非確認フレーム限界以下であると決定した場合には、ステップ８７８において、パージングユニット７４０は、送信タイマーが時間切れしたかどうか決定する。送信ＡＣＫタイマーは、送信者が適時にＡＣＫを受信しないことによる不必要な再送信を最小にするために、送信者の再送信タイマーが時間切れする前に時間切れするように構成される。一実施形態では、送信ＡＣＫタイマーの時間切れ周期は、全デレゲート接続に対して一定である。別の実施形態では、送信ＡＣＫタイマーの時間切れ周期は、デレゲート接続ごとにＴＣＰスタックによりプログラムされてもよい。

[00115]ステップ８７８において、パージングユニット７４０が、送信ＡＣＫタイマーが時間切れしたと決定した場合には、ステップ８８０において、パージングユニット７４０は、パーズされたフレームに対するＡＣＫを発生するように送信エンジン３２０に信号し、送信エンジン３２０は、パーズされたフレームをバッファアップロードユニット７４５へ出力する。ステップ８８２において、バッファアップロードユニット７４５は、接続に対してＣＤＴ７２０のエントリーに記憶された非確認フレームカウントをゼロにセットすることによりこれを更新すると共に、「最後の送信ＡＣＫ」値を、フレームから抽出されたＳＮ値へ更新する。又、バッファアップロードユニット７４５は、増分的ＡＣＫ番号、増分的シーケンス番号、等の接続状態データも更新し、送信ＡＣＫタイマーをリセットした後に、ステップ８８６へ進む。

[00117]ステップ８７８において、バッファアップロードユニット７４５が、送信ＡＣＫタイマーが時間切れしないと決定した場合には、ステップ８８４において、バッファアップロードユニット７４５は、例えば、非確認フレームのカウント等を更新することにより、ＣＤＴ７２０におけるデレゲート接続に対応するエントリーを更新する。

[00118]ステップ８８６において、ペイロードデータは、バッファアップロードユニット７４５によりＤＭＡエンジン３１０を経てアプリケーションメモリスペース２２７のＨＯＴバッファＴＣＰへアップロードされる。ステップ８８８において、通知ユニット７５０は、通知フラグがセットされたかどうか決定し、もしそうであれば、ステップ８９０において、通知ユニット７５０は、通知リングを経てドライバ２５５へ通知を発行する。通知ユニット７５０は、通知フラグ、送信ウインドウサイズ、ＳＮ、最後のＡＣＫ番号、ＴＣＰタイムスタンプ値、レガシー記述子からのタグ値等を含む事象通知記述子を構成する。通知ユニット７５０は、通知を送信した後に、通知フラグをクリアする。

[00119]通知ユニット７５０は、事象通知記述子をＤＭＡエンジン３１０へ出力し、このＤＭＡエンジンは、事象通知記述子を、ドライバメモリスペース２３５に記憶されたオフロード事象通知リングへ転送する。オフロード事象通知リングは、隣接メモリブロックにおいて円形待ち行列として編成される。ＨＯＴユニット２５０は、オフロード事象通知リングを書き込み、ドライバ２５５は、オフロード事象通知リングを読み取る。ＴＣＰスタック２１５は、オフロード事象通知リングから読み取られたデータを使用してＣＴ２４５を更新し、これにより、ＣＴ２４５とＤＣＴ３５０との間にコヒレンスを維持する。又、ＴＣＰスタック２１５は、ＣＤＴ７１５からのエントリーを１つ以上のレガシーバッファにアップロードすることによりＣＴ２４５とＤＣＴ３５０との間にコヒレンスを維持してもよい。

[00120]ステップ８９０に続いて、受信エンジン３６０は、ステップ８０１へ戻り、別の有効フレームを処理する。ステップ８８８において、通知ユニット７５０が、１つ以上の通知フラグがセットされないと決定した場合には、受信エンジン３６０は、ステップ８０１へ戻り、別の有効フレームを処理する。

[00121]図９Ａは、本発明の一実施形態に基づき通知を決定するための方法ステップを示すフローチャートである。当業者に明らかなように、図９Ａを参照して説明する方法ステップは、図８Ａのステップ８１７を遂行する１つのやり方を構成する。各フレームが行先により受信されたことを、ドライバ２５５を経てＴＣＰスタック２１５に通知するためにＣＰＵ１１０に割り込むのではなく、スレッシュホールドを使用して、ＨＯＴユニット２５０により受信されたシーケンス番号をドライバ２５５又はＴＣＰスタック２１５へ通信する頻度を制御してもよい。同様に、送信フレームごとにＡＣＫが受信されたことをドライバ２５５に通知するためにＣＰＵ１１０に割り込むのではなく、ＡＣＫスレッシュホールド又は特定のＡＣＫ番号を使用して、ＨＯＴユニット２５０により受信されたＡＣＫをドライバ２５５へ送信するのを制御してもよい。

[00122]フレーム処理中にＣＰＵ１１０が受ける割り込みの頻度を下げることで、他のアプリケーションを実行するようにＣＰＵ１１０を解放し、通常は、ＣＰＵ１１０が実行するアプリケーション命令の数を増加することによりこれらアプリケーションの性能を改善する。スレッシュホールドは、デレゲート接続に対して受信接続状態及び送信接続状態をＴＣＰスタック２１５に通知するための割り込みと割り込みとの間のバランスを決定する上で融通性を許す。

[00123]ステップ９０１において、パージングユニット７４０は、送信ウインドウが右から収縮するかどうか決定する。パージングユニット７４０は、フレームから抽出したＡＣＫ番号をフレームから抽出した受信ウインドウサイズと加算したものが、デレゲート接続に対してＣＤＴ７２０に記憶された最大送信ウインドウサイズより小さいときに、送信ウインドウが右から収縮すると決定する。バッファアップロードユニット７４５は、デレゲート接続に対してＣＤＴ７２０に記憶された最大送信ウインドウサイズを、フレームから抽出した送信ウインドウサイズで更新する。ステップ９０１において、パージングユニット７４０が、送信ウインドウが右から収縮していると決定した場合には、ステップ９０３において、パージングユニット７４０は、通知ユニット７５０の送信ウインドウ通知フラグをセットする。

[00124]ステップ９０５において、パージングユニット７４０は、複写ＡＣＫ（１つ以上の受信フレームにおいて同じＡＣＫ番号）が受け取られたかどうか決定し、これは、行先が１つ以上のフレームの再送信を要求していることを指示する。ステップ９０５において、パージングユニット７４０が、複写ＡＣＫが受け取られたと決定した場合には、ステップ９０３において、パージングユニット７４０は、通知ユニット７５０の「複写ＡＣＫ通知」フラグをセットする。

[00125]ステップ９０７において、パージングユニット７４０は、ＳＮがスレッシュホールド例えば限界より大きいかどうか決定し、このスレッシュホールドは、増分的シーケンス番号を指示する。この増分的シーケンス番号は、デレゲート接続が設定されるときにＴＣＰスタック２１５により初期化されると共に、通知がドライバ２５５へ送信されるときにバッファアップロードユニット７４５により更新される。一実施形態において、増分的シーケンス番号は、その増分的シーケンス番号をシーケンス増加値で増加することにより更新される。このシーケンス増加値は、固定でもよいし、又はＴＣＰスタック２１５によりプログラムされてもよい。ステップ９０７において、パージングユニット７４０が、ＳＮがスレッシュホールドより大きいことを決定すると、ステップ９０３において、シーケンス番号スレッシュホールドフラグがセットされる。

[00126]ステップ９０９において、パージングユニット７４０は、ＣＤＴ７２０に記憶された最後のＡＣＫ番号（デレゲート接続に対して受け取られた最も進んだＡＣＫ番号）が、増分的ＡＣＫ番号を指示する限界より大きいかどうか決定する。最後のＡＣＫ番号は、デレゲート接続が設定されたときにＴＣＰスタック２１５により初期化され、そしてＡＣＫが受け取られたときにバッファアップロードユニット７４５により更新される。増分的ＡＣＫ番号は、デレゲート接続が設定されたときにＴＣＰスタック２１５により初期化され、そして通知がＴＣＰスタック２１５へ送信されたときにバッファアップロードユニット７４５により更新される。一実施形態において、増分的ＡＣＫ番号は、その増分的ＡＣＫ番号をＡＣＫ増加値で増加することにより更新される。このＡＣＫ増加値は、固定でもよいし、又はＴＣＰスタック２１５によりプログラムされてもよい。

[00127]ステップ９０９において、パージングユニット７４０は、ＣＤＴ７２０に記憶された最後のＡＣＫ番号が、ＴＣＰスタック２１５によりプログラムされた特定のＡＣＫ番号を指示する他の限界より大きいかどうか決定してもよい。ステップ９０９において、パージングユニット７４０が、最後のＡＣＫ番号が限界（増分的ＡＣＫ番号を指示する）又は他の限界（特定のＡＣＫ番号を指示する）より大きいと決定した場合には、ステップ９０３において、ＡＣＫスレッシュホールドフラグがセットされる。

[00128]ステップ９１１において、パージングユニット７４０は、１つ以上のタイマーが時間切れしたかどうか決定する。受信ＡＣＫタイマーは、不必要な再送信を最小にするために、ＴＣＰスタック２１５の再送信タイマーが時間切れする前に時間切れするように構成される。レジスタに記憶されたデレゲート接続に対する受信ＡＣＫタイマーの時間切れ周期は、ＴＣＰスタック２１５によってプログラムされてもよいし、デレゲート接続に対するラウンドトリップ時間に基づいてもよい。受信ＳＮタイマーは、ＨＯＴユニット２５０によりデータが受信されたことをＴＣＰスタック２１５に通知するように構成される。レジスタに記憶されたデレゲート接続に対する受信ＳＮタイマーの時間切れ周期は、ＴＣＰスタック２１５によりプログラムされてもよい。別の実施形態では、受信ＡＣＫタイマー及び受信ＳＮタイマーの時間切れ周期は、デレゲート接続に対応するＣＭＴ７２５のエントリーに記憶される。

[00129]ステップ９１１において、パージングユニット７４０が、タイマーが時間切れしたと決定された場合には、それに対応する通知フラグがステップ９０３において更新され、パージングユニット７４０がステップ９１３へ進む。例えば、受信ＳＮタイマーが時間切れしたときには、「シーケンス番号スレッシュホールド」フラグがセットされ、一方、受信ＡＣＫタイマーが時間切れしたときには、「ＡＣＫスレッシュホールド」フラグがセットされる。ステップ９１１において、受信エンジン３６０が、１つ以上のタイマーがいずれも時間切れしないと決定すると、パージングユニット７４０は、ステップ９１３において、パーズされたフレームをバッファアップロードユニット７４５へ出力し、このバッファアップロードユニット７４５は、フレームから抽出したプッシュフラグがアサートされたかどうか決定する。プッシュフラグがアサートされた場合には、ステップ９０３においてプッシュ通知フラグがセットされ、バッファアップロードユニット７４５は、図８Ａのステップ８１９へ進む。

[00130]図９Ｂは、本発明の一実施形態に基づきレガシー処理に続いてユーザバッファを同期するための方法ステップを示すフローチャートである。既に述べたように、デレゲート接続は、シーケンス番号が予想シーケンス番号ＤＣＴ ＳＮより大きいフレームをパージングユニット７４０が検出したときにレガシーバッファを使用して処理される。例えば、１つ以上のフレームが送信エラーにより失われたときに、通知ユニット７５０は、接続に対してレガシー処理を要求し、そしてバッファアップロードユニット７４５は、接続に対してＨＯＴバッファを無効化する。ＣＤＴ７２０に記憶されたＳＮは変化しないので、その後に受け取られる全てのフレームは、再送信が行われるまでシーケンスずれであると考えられる。

[00131]再送信フレームが受け取られるまで、バッファアップロードユニット７４５は、接続に対して受け取られたフレームをレガシーバッファへアップロードする。ＴＣＰスタック２１５は、ペイロードデータをレガシーバッファからユーザバッファへコピーする。再送信フレームがレガシーバッファへアップロードされると、ＴＣＰスタック２１５は、正しいシーケンスで受け取られた全てのフレームに対してＡＣＫを送信する。送信エンジン３２０は、接続に対してＣＤＴ７２０に記憶されたＤＣＴ ＳＮを更新する。シーケンス内の全ての再送信フレームがレガシーバッファへアップロードされると、ＴＣＰスタック２１５は、ＡＣＫを送信する前にＨＯＴバッファをポスティングする。ＨＯＴバッファをポスティングすることで、バッファアップロードユニット７４５は、ユーザバッファを要求せずにＨＯＴバッファを使用して接続に対する到来フレームの処理を再開することが許される。

[00132]ステップ９３０において、ＣＭＤユニット７１０は、コマンドリングからＤＭＡエンジン３１０を経てＰＲＢコマンドを受け取る。ＰＲＢコマンドは、他のフィールドの中でも、接続に対するエントリーに対応するＤＣＴインデックスと、同期ビットとを含む。ステップ９３２において、ＣＭＤユニット７１０は、インデックスを使用してＣＢＴ７１５を読み取る。ステップ９３４において、ＣＭＤユニット７１０は、ＣＢＴ７１５のエントリーから読み取られた同期要求フラグがセットされたかどうか決定し、もしそうであれば、ステップ９３６において、ＣＭＤユニット７１０は、ＰＲＢコマンドの同期ビットがセットされたかどうか決定する。ステップ９３４において、ＣＭＤユニット７１０が、ＣＢＴ７１５のエントリーから読み取られた「同期要求」フラグがセットされないと決定すると、ＣＭＤユニット７１０は、ステップ９３８において、ＣＢＴ７１５のエントリーの「同期要求」フラグをクリアし、ステップ９４０へ進む。「同期要求」フラグがクリアされると、ＨＯＴバッファを使用して接続を処理することができる。ステップ９３６において、ＣＭＤユニット７１０が、ＰＲＢコマンドの同期ビットがセットされないと決定すると、「同期要求」フラグはクリアされず、接続は、レガシー処理を使用して処理され続ける。

[00133]送信エンジン３２０は、ＴＣＰスタック２１５から出て行くフレームをオフロード処理するサブユニットを備えている。例えば、送信エンジン３２０は、ＴＣＰセグメント化を遂行し、ＴＣＰ及びＩＰｖ４チェック和を計算し、更に、ＡＣＫをピギーバック搬送するように出て行くフレームを編集すると共に、デレゲート接続に対する最新の状態データ（ＤＣＴ３５０から読み取られた）を含むように構成されてもよい。ドライバ２５５又は受信エンジン３６０によりなされるＤＣＴ３５０に対する更新は、以下に説明するように、送信に含まれてもよい。

[00134]図１０Ａは、例えば、「大型発信」送信中に、本発明の１つ以上の態様に基づきＤＭＡエンジン３１０によりシステムメモリ１３０からＨＯＴユニット２５０へデータが転送されるときに送信用のデータを表わすのに使用されるフォーマットを示す。フィールド１００７は、イーサネットヘッダのような媒体特有のＭＡＣヘッダである。フィールド１００５は、ＭＡＣヘッダを含むプロトタイプヘッダと、ＩＰヘッダと、ＳＮ、送信ＡＣＫ番号、ＴＣＰタイムスタンプ等を含むＴＣＰヘッダである。フィールド１０１０は、送信用のデータであり、ＴＣＰスタックメモリスペース２２５に配置される。フィールド１００７、フィールド１００５及びフィールド１０１０の組合体は、システムメモリ１３０に存在する。

[00135]図１０Ｂは、本発明の１つ以上の態様に基づき送信エンジン３２０から送信インターフェイス３３０へデータが送信されるときに送信用のデータを表わすのに使用されるフォーマットを示す。ＤＭＡエンジン３１０は、システムメモリスペース１３０から図１０Ａに示すフォーマットを読み取り、そして送信エンジン３２０は、セグメント化が実行可能となり且つフィールド１０１０の一部分がセグメントに含まれるときに図１０Ｂに示すフォーマットを発生し、ここで、各セグメントはフレームである。送信インターフェイス３３０は、図１０Ｂに示すＩＰデータグラムフォーマットをフレームとして出力する。別の実施形態では、ＴＣＰスタック２１５は、プロトコルヘッダを発生し、そのプロトコルヘッダをＴＣＰスタックメモリスペース２２５に記憶する。プロトコルヘッダは、ＨＯＴユニット２５０によりＴＣＰスタックメモリスペース２２５から読み取られ、送信用のデータは、ＨＯＴユニット２５０によりアプリケーションメモリスペース２２７から読み取られる。

[00136]フィールド１０１５はＩＰヘッダであり、フィールド１０２０はＴＣＰヘッダであり、フィールド１０２５はセグメント化データである。当業者に明らかなように、図１０Ｂに示すフォーマットは、ＴＣＰに準拠するフォーマットである。ＴＣＰヘッダは、送信ＡＣＫ番号、送信ＳＮ等を含む。セグメント化データは、フィールド１０１０における送信用データの一部分である。フィールド１０３０は、任意に更新される送信ＡＣＫ番号、更新される送信ＳＮ等を含む別のＴＣＰヘッダである。更新される送信ＳＮは、以前のセグメントに含まれたデータバイトの量だけ増加され、これは、最大フレームサイズと、データリンク、ネットワーク及び搬送層ヘッダサイズとの間の差と同じである。フィールド１０３５は、フィールド１０１０における送信用データの別の部分であるセグメント化データである。

[00137]図１１Ａは、本発明の一実施形態に基づき図１０Ａに示すフォーマットで表わされた出て行くフレームをセグメントへとセグメント化する方法ステップであって、出て行くフレームを編集することを含む方法ステップを示すフローチャートである。ステップ１１０１において、ＤＭＡエンジン３１０は、ＴＣＰスタック２１５からドライバ２５５を経て送信記述子を受け取る。送信記述子は、システムメモリ１３０に記憶された送信バッファの位置の物理的アドレスを含み、送信バッファは、プロトタイプヘッダ及び送信用データを含む。又、送信記述子は、処理オプションを指定する制御ビット、任意のＤＣＴインデックス、送信オプションを指定する制御ビット等も含む。

[00138]ステップ１１０３において、ＤＭＡエンジン３１０は、送信バッファを読み取り、送信記述子及び送信バッファを送信エンジン３２０へ出力する。ステップ１１０９において、送信エンジン３２０は、プロトタイプヘッダから抽出されたＩＰヘッダデータに基づいてＩＰチェック和を計算する。ステップ１１１１において、送信エンジン３２０は、セグメント化の後の最大セグメントサイズ（接続設定中に行先によりセットされる）に基づいて、送信バッファに含まれる送信用データの一部分を決定する。ステップ１１１３において、送信エンジン３２０は、図１１Ｂを参照して以下に述べるように、送信用のセグメントを構成する。

[00139]ステップ１１３１において、送信エンジン３２０は、プロトタイプヘッダから抽出されたＴＣＰヘッダデータ、ＤＣＴ３５０から読み取られた接続状態データ、及び現在フレームにおける送信用データの部分に基づいて、ＴＣＰチェック和を計算する。計算されたチェック和は、フレームのＴＣＰヘッダに記憶される。ステップ１１３３において、送信エンジン３２０は、フレームに含まれたデータのサイズ（バイト単位）とヘッダのサイズとの差だけ送信ＳＮを増加することにより、デレゲート接続に対してＤＣＴ３５０に記憶された送信ＳＮを更新する。ステップ１１３５において、送信エンジン３２０は、計算されたＴＣＰチェック和を含む構成されたフレームを送信インターフェイス３３０へ出力する。送信インターフェイス３３０は、その構成されたフレームを出力する。

[00140]図１１Ｂは、本発明の一実施形態に基づき出て行くフレームを構成するための方法ステップを示すフローチャートである。当業者に明らかなように、図１１Ｂを参照して述べる方法ステップは、図１１Ａのステップ１１１３を遂行する１つのやり方を構成する。出て行くフレームは、ＣＤＴ７２０に記憶された接続状態データを使用して構成され、従って、出て行くフレームは、最も最近受け取られたフレームに対応するＡＣＫ番号のような接続に対する最新の状態データを含む。セグメント化中を含む送信中に、ＡＣＫは、もし可能であれば「ピギーバック」搬送され、即ち送信のためのフレーム出力に含まれ、フレーム（大型発信）が完全にセグメント化されて送信される後まで個別のＡＣＫの出力を待機するのではない。この適時のＡＣＫは、送信者から見た受信ウインドウがオープンのままで、送信者がデータの送信を続けられるよう確保する。更に、大型発信が完了するまでＡＣＫを延期すると、送信者の再送信タイマーが時間切れしたときに送信者による無駄な再送信を招くか、又はＡＣＫが「大型発信」間にしか生じないように遅延されるために受信データ流に不必要なバースティネス(burstiness)を招くことがある。

[00141]ステップ１１１５において、送信エンジン３２０は、送信要求と共にステップ１１０１で受信されたＤＣＴインデックスを使用して、送信要求がデレゲート接続に対応するかどうか決定し、対応しない場合には、図１１Ａのステップ１１３１へ進む。さもなければ、ステップ１１１７において、送信エンジン３２０は、ステップ１１０１で受信されたＤＣＴインデックスを使用してＣＤＴ７２０にアクセスし、デレゲート接続に対する接続状態データを得る。ステップ１１１９において、送信エンジン３２０は、構成されたフレームに対する送信ＳＮを決定する。ＴＣＰスタック２１５から受信されるＳＮが、データ流において、接続に対してＣＤＴ７２０に記憶される送信ＳＮより後であるときには、送信エンジン３２０は、送信ＳＮを、ＴＣＰスタック２１５から受信されたＳＮにセットする。

[00142]ステップ１１２１において、送信エンジン３２０は、処理オプションを指定する制御ビットを検査し、ＴＣＰスタック２１５が、フレームの第１バイトのＳＮをＣＤＴ７２０にセーブするよう送信エンジン３２０に要求するかどうか決定する。セーブされたＳＮは、図９Ａのステップ９０７に使用され、そのセーブされたＳＮに対応するＡＣＫが受信されたときにＴＣＰスタック２１５の通知を制御する。ステップ１１２１において、送信エンジン３２０が、ＴＣＰスタック２１５が特定のＡＣＫ番号に対する通知を要求すると決定した場合には、ステップ１１２３において、送信エンジン３２０は、接続に対してＳＮを特定のＡＣＫ番号としてＣＤＴ７２０にセーブする。

[00143]ステップ１１２５において、送信エンジン３２０は、構成されたフレームに対してＡＣＫ番号を決定する。ＴＣＰスタック２１５から受信されたＡＣＫ番号が、データ流において、接続に対して記憶されるＤＣＴ ＳＮより後であるときには、送信エンジン３２０は、ＤＣＴ ＳＮを、ＴＣＰスタック２１５から受信されたＡＣＫ番号にセットする。又、送信エンジン３２０は、接続に対してＣＤＴ７２０に記憶される最後のＡＣＫ番号を、ＴＣＰスタック２１５から受信されたＡＣＫ番号又はＤＣＴ ＳＮの大きい方にセットする。

[00144]ステップ１１２７において、送信エンジン３２０は、デレゲート接続に対してＣＤＴ７２０に記憶された接続状態データを検査することによりＴＣＰタイムスタンプオプションがイネーブルされたかどうか決定する。ＴＣＰタイムスタンプオプションがイネーブルされないときには、送信エンジンは、図１１Ａのステップ１１３１へ進む。さもなければ、ステップ１１２９において、送信エンジン３２０は、構成されたフレームのＴＣＰヘッダに自走タイマーの現在値を含ませる。又、送信エンジン３２０は、ＴＣＰスタック２１５から受信されたタイムスタンプと、接続に対してＣＤＴ７２０に記憶されたタイムスタンプ（最も最近受け取られたタイムスタンプ）との大きい方も含ませる。ＴＣＰスタック２１５から受信されたタイムスタンプが、接続に対して記憶されたタイムスタンプより大きいときには、接続に対して記憶されたタイムスタンプが、ＴＣＰスタック２１５から受信されたタイムスタンプにセットされる。送信エンジン３２０は、ステップ１１３１へ進み、構成されたフレームに対するＴＣＰチェック和を計算する。

[00145]図１１Ｃは、本発明の一実施形態に基づき送信即ちピギーバック搬送に含ませるためにＡＣＫを発生する方法ステップを示すフローチャートである。図１１Ｃに示す方法は、フレームが受信されたときに受信エンジン３６０により完了される。ステップ１１４５において、受信エンジン３６０は、デレゲート接続に対する逐次ＴＣＰフレームを受信する。ステップ１１４７において、受信エンジン３６０は、デレゲート接続に対応してＤＣＴ３６０において接続状態データ、例えば、ＴＣＰタイムスタンプ、ＳＮ、送信ウインドウサイズ等を更新する。ＤＣＴ ＳＮは、次に予想される到来するＳＮへと更新される。

[00146]ステップ１１４９において、受信エンジン３６０は、ＳＮと最後のＡＣＫ番号（ＤＣＴ３５０から読み取られた）との間の差であるＡＣＫ差を計算する。ステップ１１５１において、受信エンジン３６０は、このＡＣＫ差が、受信したフレームに対するＡＣＫをトリガーするためにＴＣＰスタック２１５によりプログラムされた限界より大きいかどうか決定する。ＡＣＫ差がこの限界より大きい場合には、受信エンジン３６０は、ステップ１１５７へ進む。さもなければ、ステップ１１５３において、受信エンジン３６０は、ＤＣＴ ＳＮが、増分的シーケンス番号又は特定のシーケンス番号であるスレッシュホールドより大きいかどうか決定する。ＤＣＴ ＳＮがこのスレッシュホールドより大きい場合には、受信エンジン３６０は、ステップ１１５７へ進む。さもなければ、ステップ１１５５において、受信エンジン３６０は、上述した送信ＡＣＫタイマーが時間切れしたかどうか決定し、もしそうでなければ、送信ＡＣＫタイマー及び非確認カウントが更新される。ステップ１１５５において、受信エンジン３６０が、送信ＡＣＫタイマーが時間切れしたと決定した場合には、ステップ１１５７において、受信エンジン３６０は、デレゲート接続に対してＤＣＴ３５０に記憶された接続状態データを更新し、例えば、非確認カウントをクリアし、最後のＡＣＫ番号を更新し、増分的シーケンス番号を更新し、等々である。又、受信エンジン３６０は、送信ＡＣＫタイマーをリセットする。ステップ１１５９において、受信エンジン３６０は、送信のためのフレームにＡＣＫを含ませ、即ちＡＣＫをピギーバック搬送するように送信エンジン３２０に信号する。

[00147]ＨＯＴユニット３５０は、デレゲート接続に対して受信した有効ＴＣＰフレームのＴＣＰ処理をオフロードする一方、ドライバ２５５又はＴＣＰスタック２１５が受信ＡＣＫ及びタイマーに基づいて割り込みのスレッシュホールドを決定する融通性を許す。これらスレッシュホールドを使用して割り込みを減少し、他のアプリケーションを処理するようにＣＰＵ１１０を解放してもよい。更に、ＨＯＴユニット３５０は、送信に対するＡＣＫを発生すると共に、ＡＣＫをピギーバック搬送し、ＴＣＰ及びＩＰｖ４チェック和を計算し、更に、ＴＣＰセグメント化を遂行するように出て行くフレームを編集する。送信者へＡＣＫを適時に発生して送信することで、受信ウインドウをオープンに保って、帯域巾利用を改善し、且つ単一方向及び両方向通信中に不必要な再送信を減少することができる。最終的に、アプリケーションメモリスペース２２７のユーザバッファへのペイロードデータのアップロードは、ドライバメモリスペース２３５からアプリケーションメモリスペース２２７へデータをコピーする必要性を低減する。デレゲート接続に対してユーザバッファが使用できず且つ受信ＦＩＦＯがいっぱいであるときには、到来するデータを受け入れないのではなく、レガシーバッファを使用して受信フレームをアップロードすることができる。ＨＯＴユニット２５０は、大量の専用メモリ又は専用プロセッサに依存しない一方、ＣＰＵ１１０から幾つかのＴＣＰ処理をオフロードする。又、ＨＯＴユニット２５０は、ホストプロセッサから幾つかのＴＣＰ処理をオフロードすると共に、到来するデータを受け入れながら過剰な接続を取り扱う。

[00148]別の態様において、本発明は、ＴＣＰ接続に対するフレームを処理する方法を提供する。この方法は、オフロードユニットを使用してフレームの第１部分を処理して、第１の処理されたフレームデータを発生するステップと、オフロードユニットを使用してフレームの第２部分を処理して、第２の処理されたフレームデータを発生するステップと、ＣＰＵで実行されるＴＣＰスタックを使用して前記第２の処理されたフレームデータを処理して、第３の処理されたフレームデータを発生するステップとを備えている。別の態様において、この方法は、更に、各フレームの処理中に特殊なケースが存在するかどうか決定するステップも含む。更に別の態様において、この方法は、更に、第１の処理されたフレームデータをユーザバッファへアップロードするステップも含む。更に別の態様において、この方法は、更に、第２の処理されたフレームデータをレガシーバッファへアップロードするステップも含む。更に別の態様において、この方法は、更に、システムメモリにおけるレガシーバッファの位置に対応するタグをソフトウェアドライバへ送信するステップも含む。

[00149]別の態様において、本発明は、ＴＣＰ接続に対するデータを処理するシステムを提供する。このシステムは、少なくとも１つのレガシーバッファに記憶された受信フレームを処理するように構成されたＴＣＰスタックと、ＴＣＰスタックとオフロードユニットとの間をインターフェイスするように構成されたソフトウェアドライバとを備え、前記オフロードユニットは、デレゲート接続において受信されたフレームを処理して、ペイロードデータ及び部分的に処理されたフレームを発生するように構成される。更に別の態様において、オフロードユニットは、特殊なケースが存在しないフレームを処理するように構成される。更に別の態様において、オフロードユニットは、特殊なケースが存在すると決定されたときにＴＣＰスタックに通知するように構成される。更に別の態様において、オフロードユニットは、部分的に処理されたフレームを少なくとも１つのレガシーバッファへアップロードするように構成される。更に別の態様において、オフロードユニットは、ペイロードデータを少なくとも１つのユーザバッファへアップロードするように構成される。更に別の態様において、オフロードユニットは、ペイロードデータをレガシーバッファへアップロードするか又は処理されたフレームをユーザバッファへアップロードしながら、付加的なフレームを受信するように構成される。更に別の態様において、ＴＣＰスタックは、少なくとも１つのユーザバッファに対応する位置情報をオフロードユニットに与える。更に別の態様において、オフロードユニットは、ユーザバッファ情報及びデレゲート接続状態情報を記憶するように構成されたデレゲート接続テーブルを備えている。

[00150]別の態様において、本発明は、デレゲート及び非デレゲートＴＣＰ接続に対するフレームを処理するための方法を提供する。この方法は、特殊なケースが存在しないフレームを処理するように構成されたオフロードユニットを使用してデレゲートＴＣＰ接続を処理するステップと、ＣＰＵで実行されるＴＣＰスタックを使用して、非デレゲートＴＣＰ接続を処理するステップと、ＣＰＵで実行されるＴＣＰスタックを使用して、特殊なケースが存在する全てのフレームを処理するステップとを備えている。更に別の態様では、デレゲートＴＣＰ接続の処理は、ペイロードデータを発生する。更に別の態様では、ペイロードデータは、オフロードユニットによりシステムメモリの一部分へアップロードされる。更に別の態様では、この方法は、更に、デレゲート接続に対してデータが受信されたときにオフロードユニットに記憶された接続状態情報を更新するステップも含む。更に別の態様において、この方法は、更に、デレゲート接続に対してデータが送信されたときにオフロードユニットに記憶された接続状態情報を更新するステップも含む。

[00151]別の態様において、本発明は、デレゲート接続を設定する方法を提供する。この方法は、ＴＣＰ接続を確立するステップと、ハードウェアによる処理のためにＴＣＰ接続をデレゲートすべきかどうか決定するステップとを備えている。更に別の態様において、この方法は、更に、ＴＣＰ接続をデレゲートすべきと決定したときにデレゲート接続テーブルのエントリーを設定するステップも含む。更に別の態様において、この方法は、更に、デレゲート接続に対するユーザバッファ情報をハードウェアへ転送するステップも含む。

[00152]別の態様において、本発明は、ＴＣＰスタックとオフロードユニットとの間で通信するためのシステムを提供する。このシステムは、ＴＣＰスタックからオフロードユニットへコマンドを送信するための手段と、オフロードユニットからＴＣＰスタックへ通知記述子を送信するための手段とを備えている。更に別の態様では、このシステムは、更に、オフロードユニットからＴＣＰスタックへコマンド特有の状態を送信するための手段も備えている。更に別の態様では、このシステムは、更に、ＴＣＰスタックからオフロードユニットへ受信バッファ記述子を送信するための手段も備えている。更に別の態様では、このシステムは、更に、ＴＣＰスタックからオフロードユニットへ送信バッファ記述子を送信するための手段も備えている。

[00153]別の態様において、本発明は、オフロードユニットを使用して出て行くフレームを編集する方法を提供する。この方法は、デレゲート接続テーブルインデックスを受信するステップと、ＴＣＰスタックからプロトタイプヘッダ及び送信用のデータを受信するステップと、デレゲート接続テーブルインデックスを使用してデレゲート接続テーブルエントリーにアクセスするステップとを備えている。又、この方法は、送信用のデータの一部分に基づいてＴＣＰチェック和を計算するステップと、ＴＣＰチェック和及び送信用のデータの一部分を含むフレームを出力するステップも備えている。更に別の態様では、この方法は、更に、デレゲート接続テーブルエントリーを更新するステップも備えている。更に別の態様では、この方法は、接続テーブルエントリーにアクセスするステップと、送信用のデータの別の部分に基づいてＴＣＰチェック和を計算するステップと、このＴＣＰチェック和及び送信用データの別の部分を含む付加的なフレームを出力するステップとを備えている。更に別の態様において、アプリケーションプログラムは、行先が特定シーケンス番号の受信を確認したときに通知を要求する。更に別の実施形態では、この方法は、更に、フレームにおいて確認をピギーバック搬送するステップも含む。

[00154]以上、特定の実施形態について本発明を説明した。しかしながら、特許請求の範囲に規定された本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、以上の説明及び添付図面は、本発明を単に例示するもので、限定するものではない。方法の請求項におけるステップの列挙は、特に指示のない限り、特定の順序でそれらステップを遂行することを意味していない。特許請求の範囲における要素を示す文字（例えば、「ａ）」、「ｂ）」、「ｉ）」、「ｉｉ）」等）は、ステップ又は他のオペレーションを実行するための特定の順序を示すものではなく、それら要素を単に参照するために含まれたものである。

１１０…ＣＰＵ、１２０…システムコントローラ、１２６…ハブ対ハブインターフェイス、１３０…システムメモリ、１３２…システムバス、１４２…システムマネージメントバス、２００…コンピュータシステム、２１５…ＴＣＰスタック、２２０…一体化コントローラ、２２５…ＴＣＰスタックメモリスペース、２２７…アプリケーションメモリスペース、２３５…ドライバメモリスペース、２４０…Ｉ／Ｏコントローラ、２４５…接続テーブル（ＣＴ）、２５０…ハードウェア最適化ＴＣＰ（ＨＯＴ）ユニット、２５５…ドライバ、２８２…ＰＣＩバス、３１０…ＤＭＡエンジン、３２０…送信エンジン、３３０…送信インターフェイス、３５０…デレゲート接続テーブル（ＤＣＴ）、３６０…受信エンジン、３７０…受信インターフェイス。

Claims (10)

1. デレゲート接続テーブルを有するオフロードユニットを用いて、出入りするフレームを処理する方法において、
   前記オフロードユニットによって処理するためにホストＣＰＵによって実行されたＴＣＰスタックによって選択された接続に対応する接続テーブルインデックスと、シーケンス番号と、確認番号とを含んでいる接続状態データを用いて、前記デレゲート接続テーブルのエントリーを初期化するステップと、
   プロトタイプヘッダと、前記ＴＣＰスタックからの送信データとを有する、出て行くフレームを受信するステップと、
   前記出て行くフレームのデータを複数のデータセグメントにセグメント化するステップと、
   各データセグメントに対し、
   ＴＣＰチェック和を計算する工程と、
   送信シーケンス番号及び送信確認番号を決定する工程と、
   前記デレゲート接続テーブルに記憶されたシーケンス番号及び確認番号を更新する工程と、
   前記選択された接続にわたるデータ送信のために、前記ＴＣＰチェック和、前記送信シーケンス番号、前記送信確認番号、ＴＣＰタイムスタンプ及び前記データセグメントを含むフレームを出力する工程とを有するステップとを備え、
   前記フレームを出力する前記工程は、前記ＴＣＰスタックから受信したＴＣＰタイムスタンプが前記デレゲート接続テーブルにおいて記憶されたＴＣＰタイムスタンプよりも大きい場合、前記ＴＣＰスタックから受信したＴＣＰタイムスタンプと同じＴＣＰタイムスタンプを含む前記フレームを出力する、方法。
   
2. 前記デレゲート接続テーブルに記憶された確認番号は、前記デレゲート接続テーブルにおいて記憶されたシーケンス番号及び前記ＴＣＰスタックから受信した確認番号の一方よりも大きくなるように更新される、請求項１の方法。
   
3. 前記決定する前記工程は、前記ＴＣＰスタックから受信したシーケンス番号が前記デレゲート接続テーブルにおいて記憶されたシーケンス番号よりも大きい場合、前記送信シーケンス番号を、前記ＴＣＰスタックから受信したシーケンス番号と同じシーケンス番号に決定する、請求項２の方法。
   
4. 前記ＴＣＰスタックから受信した確認番号が前記デレゲート接続テーブルにおいて記憶されたシーケンス番号よりも大きい場合、前記デレゲート接続テーブルにおいて記憶されたシーケンス番号は、前記ＴＣＰスタックから受信した確認番号として更新される、請求項２の方法。
   
5. 前記オフロードユニットにデレゲートされない接続又は特別な処理を要求する接続が、前記ＴＣＰスタックによって処理され、
   前記オフロードユニットが、前記ＴＣＰスタックによって前記デレゲートされた接続のうちの一つのレガシー処理を要求して、出て行くフレームが、前記ＴＣＰスタック又はオフロード接続のどちらか一方によって送信される、請求項２の方法。
6. 前記オフロードユニットが、前記デレゲート接続テーブルにおいて記憶されたシーケンス番号（ＳＮ）を用いて、入ってくるフレームのそれぞれのシーケンス番号（ＳＮ）を比較し、
   等しくない場合には、全てのフレームが前記ＴＣＰスタックによってレガシー処理のために更新される、請求項１の方法。
   
7. デレゲート接続テーブルを有するオフロードユニットを用いて、出入りするフレームを処理する方法において、
   前記オフロードユニットによって処理するためにホストＣＰＵによって実行されたＴＣＰスタックによって選択された接続に対応する接続テーブルインデックスと、確認フレームのカウントとを含んでいる接続状態データを用いて、前記デレゲート接続テーブルのエントリーを初期化するステップと、
   入ってくるＴＣＰフレームを行先接続から受信するステップと、
   前記行先接続が前記オフロードユニットによって処理するためにデレゲートされた接続であることを決定するステップと、
   前記ＴＣＰフレームのシーケンス番号がデレゲート接続テーブルにおいて記憶されたシーケンス番号に対して連続しているかどうかを決定するステップと、
   前記オフロードユニットにおいて前記入ってくるフレームを処理すると共に、前記デレゲート接続テーブルにおいて記憶された確認フレームの前記カウントを増分するステップと、
   前記デレゲート接続テーブルにおいて記憶されたシーケンス番号を更新するステップと、
   前記デレゲート接続テーブルにおいて記憶された確認フレームの前記カウントが所定の限度よりも大きい場合、前記行先に受信データ確認を送信するステップとを備える、方法。
8. 前記行先に受信データ確認を送信するステップの後に、前記デレゲート接続テーブルにおいて記憶された確認フレームの前記カウントをゼロに更新するステップをさらに備える、請求項７の方法。
9. タイマーが時間切れであることを決定するステップと、
   前記行先への受信データ確認を送信するステップとをさらに備える、請求項７の方法。
10. 出入りするフレームを処理する装置において、
    出て行くフレームを行先接続に送信するように構成された送信エンジンと、
    入ってくるフレームを行先接続から受信するように構成された受信エンジンと、
    デレゲート接続テーブルの情報を記憶するための第１のテーブルと、デレゲート接続状態の情報を記憶するための第２のテーブルと、メモリ位置の情報を記憶するための第３のテーブルとによって構成された記憶ユニットであって、前記第１、第２及び第３のテーブルの同時アクセスを許可するために、前記第１、第２及び第３のテーブルのそれぞれが互いに分離されている、記憶ユニットと、
    オフロード処理のためにホストＣＰＵによって実行されたＴＣＰスタックによって選択された接続に対応する接続テーブルインデックスを含んでいる接続状態データを用いて、前記第１のテーブルのエントリーを初期化する手段と、
    ＴＣＰチェック和を決定する手段と、
    前記選択された接続のために、前記第２のテーブルからシーケンス番号、ＴＣＰタイムスタンプ及び確認番号を含む前記接続状態データを得る手段と、
    前記接続状態データと、送信シーケンス番号を含む前記フレームと、送信確認番号とに対して少なくとも部分的に応答して送信するためのフレームを構成する手段であって、前記送信確認番号が、前記シーケンス番号と、前記第２のテーブルにおいて記憶された確認番号とに基づいて決定される、手段とを備える、装置。

Images