(57)【要約】  ＴＣＰオフロードエンジン（ＴＯＥ）デバイスが、複数のＴＣＰ／ＩＰプロトコル処理操作を同時並行で行うステートマシンを備える。第１の態様では、該ステートマシンが第１メモリ、第２メモリ、及び組合せロジックを有する。第１メモリは複数のＴＣＰ状態変数を格納し、かつ同時に出力する。第２メモリは複数のヘッダ値を格納し、かつ同時に出力する。順次プロセッサ技術とは異なり、組合せロジックは、順次プロセッサ命令や順次メモリアクセスを実行することなくＴＣＰ状態変数とヘッダ値からフラッシュ検出信号を生成する。第２の態様では、ＴＯＥがＴＣＢバッファにおける複数のＴＣＰ状態変数の更新を全て同時に行い、ＴＣＢバッファメモリへの複数の順次書き込みを不要とするステートマシンを備える。第３の態様では、ＴＯＥが、１つのステートマシンクロックサイクルでＤＭＡ転送をセットアップするステートマシンを含む。【選択図】    図１
2007517286.tif 000002
【特許請求の範囲】
【請求項１】
ＴＣＰコネクションに関連するＴＣＰプロトコル処理のタスクをホストからオフロードできるＴＣＰオフロードエンジン（ＴＯＥ）であって、
前記ＴＣＰコネクションに関連する少なくとも２つのＴＣＰ状態値を格納しかつ同時に出力し、前記少なくとも２つのＴＣＰ状態値が受信パケットシーケンスリミット、予測受信パケットシーケンス番号、送信シーケンスリミット、送信アクノリッジ番号、及び送信シーケンス番号からなる群から選択されたものである、第１メモリと、
前記ＴＣＰコネクションを介してやりとりされるパケットの少なくとも２つのパケットヘッダ値を格納しかつ同時に出力し、前記少なくとも２つのパケットヘッダ値が受信パケットシーケンス番号、パケットペイロードサイズ、パケットアクノリッジ番号、及びパケット送信ウインドウ値からなる群から選択されたものである、第２メモリと、
前記少なくとも２つのＴＣＰ状態値及び前記少なくとも２つのパケットヘッダ値を受け取りかつそれらからエラー条件が発生したか否かを表すフラッシュ検出信号を生成し、前記少なくとも２つのＴＣＰ状態値及び前記少なくとも２つのパケットヘッダ値の全てが同時に供給される、組合せロジックとを有することを特徴とするＴＯＥ。
【請求項２】
前記フラッシュ検出信号が前記エラー条件を示している場合、前記ＴＯＥが、前記受信パケットシーケンスリミット、前記予測受信パケットシーケンス番号、前記送信シーケンスリミット、前記送信アクノリッジ番号、及び前記送信シーケンス番号を前記ホストに転送することを特徴とする請求項１に記載のＴＯＥ。
【請求項３】
前記ＴＣＰ状態値の群の中の３以上の値が前記組合せロジックに同時に供給され、かつ前記ＴＣＰ状態値の群の中の３以上の値が前記フラッシュ検出信号を生成するのに用いられることを特徴とする請求項１に記載のＴＯＥ。
【請求項４】
前記パケットヘッダ値の群の中の３以上の値が前記組合せロジックに同時に供給され、かつ前記パケットヘッダ値の群の中の３以上の値が前記フラッシュ検出信号を生成するのに用いられることを特徴とする請求項１に記載のＴＯＥ。
【請求項５】
前記ＴＯＥは、それぞれが１つのＴＣＰ識別子と関連付けられている複数のＴＣＰコネクションを制御可能であり、
前記第１メモリが複数のトランザクション制御ブロックを有し、
前記第１メモリは、あるＴＣＢ識別子に関連するＴＣＰコネクションのためのＴＣＰ状態情報を含むＴＣＢにアクセスするために、そのＴＣＢ識別子によってアドレス指定が可能であることを特徴とする請求項１に記載のＴＯＥ。
【請求項６】
前記組合せロジックは、クロック信号を供給されるステートマシンの部分であり、
前記組合せロジックは、前記クロック信号の１クロック時間内に前記少なくとも２つのＴＣＰ状態値と前記少なくとも２つのパケットヘッダ値とから前記フラッシュ検出信号を生成することを特徴とする請求項１に記載のＴＯＥ。
【請求項７】
前記ステートマシンは命令のフェッチ、命令のデコード、及び命令の実行を行わないことを特徴とする請求項６に記載のＴＯＥ。
【請求項８】
前記ステートマシンは、前記クロック信号の１クロック時間内に、前記第１メモリ内の前記予測受信パケットシーケンス番号及び前記受信パケットシーケンスリミットの値が更新されるようにすることを特徴とする請求項７に記載のＴＯＥ。
【請求項９】
前記ＴＣＰコネクションは、前記ホスト上のスタックの実行によってセットアップされたものであり、前記ＴＣＰコネクションの制御は、次いで前記ホストから前記ＴＯＥに渡されたものであることを特徴とする請求項８に記載のＴＯＥ。
【請求項１０】
ペイロードを有するパケットが前記ＴＯＥ上に受信され、
前記ＴＯＥが、発信元アドレス値、移動する情報量を示すサイズ値、及び宛先アドレス値を用いて、前記ペイロードを前記ＴＯＥから前記ホストに移動させるＤＭＡコントローラを更に有し、前記ステートマシンが該ステートマシンの１つの状態において、前記発信元アドレス値、前記サイズ値及び前記宛先アドレス値を前記ＤＭＡコントローラに供給させることを特徴とする請求項７に記載のＴＯＥ。
【請求項１１】
ＴＣＰコネクションに関連するＴＣＰプロトコル処理のタスクをホストからオフロードできるＴＣＰオフロードエンジン（ＴＯＥ）であって、
前記ＴＣＰコネクションに関連する少なくとも２つのＴＣＰ状態値を格納しかつ同時に出力し、前記少なくとも２つのＴＣＰ状態値が、受信パケットシーケンスリミット、予測受信パケットシーケンス番号、送信シーケンスリミット、送信アクノリッジ番号、及び送信シーケンス番号からなる群から選択されたものである、第１メモリと、
前記ＴＣＰコネクションを介してやりとりされるパケットの少なくとも２つのパケットヘッダ値を格納し同時に出力し、前記少なくとも２つのパケットヘッダ値が、受信パケットシーケンス番号、パケットペイロードサイズ、パケットアクノリッジ番号、及びパケット送信ウインドウ値からなる群から選択されたものである、第２メモリと、
前記少なくとも２つのＴＣＰ状態値及び前記少なくとも２つのパケットヘッダ値を受け取りかつそれらから例外条件が発生したか否かを表す信号を生成し、前記２以上のＴＣＰ状態値及び前記２以上のパケットヘッダ値の全てがハードウェアステートマシンに同時に供給され、クロック信号の１クロック時間内に前記少なくとも２つのＴＣＰ状態値と前記少なくとも２つのパケットヘッダ値とから前記信号を生成するハードウェアステートマシンとを有することを特徴とするＴＯＥ。
【請求項１２】
前記ハードウェアステートマシンは、前記クロック信号の１クロック時間内に、前記第１メモリ内の前記予測受信パケットシーケンス番号及び前記受信パケットシーケンスリミットの値が更新されるようにすることを特徴とする請求項１１に記載のＴＯＥ。
【請求項１３】
前記予測受信パケットシーケンス番号及び前記受信パケットシーケンスリミットの値は、前記予測受信パケットシーケンス番号の値及び前記受信パケットシーケンスリミットの値を前記第１メモリに同時に書き込むことによって更新されることを特徴とする請求項１２に記載のＴＯＥ。
【請求項１４】
前記例外条件は、前記ＴＣＰコネクションの制御が前記ＴＯＥから前記ホストに渡される結果を生ずる条件であることを特徴とする請求項１１に記載のＴＯＥ。
【請求項１５】
前記第１メモリが、第１インタフェースと第２インタフェースとを有するデュアルポートメモリであり、前記ハードウェアステートマシンは、前記第１インタフェースを介して前記第１メモリからの読み出し及び前記第１メモリへの書き込みを行い、
前記ホストから前記第１メモリへは前記第２インタフェースを介して情報が渡されることを特徴とする請求項１１に記載のＴＯＥ。
【請求項１６】
前記第１メモリは複数のＴＣＢバッファを含み、前記ＴＣＢバッファの１つは前記ＴＣＰコネクションに関連付けられており、
前記ＴＣＰコネクションに関連するメモリ記述子リストエントリが前記ＴＣＰコネクションに関連する前記ＴＣＢバッファに格納されることを特徴とする請求項１５に記載のＴＯＥ。
【請求項１７】
複数のソケット記述子を格納する第３メモリを更に有し、
前記ソケット記述子の１つが前記ＴＣＰコネクションに関連付けられていることを特徴とする請求項１１に記載のＴＯＥ。
【請求項１８】
前記第２メモリは前記２以上のパケットヘッダ値とともにパーズ値を出力し、前記パーズ値は、関連するパケットの前記トランスポート層及びネットワーク層プロトコルがＴＣＰ及びＩＰプロトコルであるか否かを示すことを特徴とする請求項１１に記載のＴＯＥ。
【請求項１９】
ＴＣＰコネクションに関連するＴＣＰプロトコル処理のタスクをホストからオフロードできるＴＣＰオフロードエンジン（ＴＯＥ）であって、
前記ＴＣＰコネクションに関連する少なくとも２つの、受信パケットシーケンス番号、パケットペイロードサイズ、パケットアクノリッジ番号、及びパケット送信ウインドウ値からなる群から選択された、ＴＣＰ状態値を同時に出力し、かつ前記ＴＣＰコネクションを介してやりとりされるパケットの少なくとも２つの、受信パケットシーケンスリミット、予測受信パケットシーケンス番号、送信シーケンスリミット、送信アクノリッジ番号、及び送信シーケンス番号からなる群から選択された、パケットヘッダ値を同時に出力するメモリと、
前記少なくとも２つのＴＣＰ状態値及び前記少なくとも２つのパケットヘッダ値を受け取り、かつそれらから例外条件が発生したか否かを表す信号を生成するための、前記少なくとも２つのＴＣＰ状態値及び前記少なくとも２つのパケットヘッダ値の全てが同時に供給される、手段とを有することを特徴とするＴＯＥ。
【請求項２０】
前記メモリが第１メモリ部分と第２メモリ部分とを有し、前記第１メモリ部分は前記少なくとも２つのＴＣＰ状態値を格納し、前記第２メモリ部分は前記少なくとも２つのパケットヘッダ値を格納することを特徴とする請求項１９に記載のＴＯＥ。
【請求項２１】
前記信号を生成する手段が、ＴＣＰ状態値を前記メモリに書き込むことによってＴＣＰ状態値の更新をも行うことを特徴とする請求項１９に記載のＴＯＥ。
【請求項２２】
前記信号を生成する手段が、順次ロジック要素を含まず、組合せロジック要素のみからなることを特徴とする請求項１９に記載のＴＯＥ。
【請求項２３】
前記信号を生成する手段が、ステートマシンの部分であることを特徴とする請求項２２に記載のＴＯＥ。
【請求項２４】
前記例外条件は、前記ＴＣＰコネクションの制御が前記ＴＯＥから前記ホストに渡される結果を生ずる条件であることを特徴とする請求項１９に記載のＴＯＥ。
【発明の詳細な説明】
【背景技術】
【０００１】
コンピュータは、ＴＣＰ／ＩＰプロトコルソフトを用いてインターネット（及び他のさまざまなネットワーク）を介して通信を行う。そのようなコンピュータは、ＴＣＰ／ＩＰパケットの形で情報をネットワークに送信し、ネットワークからＴＣＰ／ＩＰパケットの形の情報を受け取ることによって通信を行う。しかし、ＴＣＰ及びＩＰプロトコルはかなり複雑である。単純なコンピュータアーキテクチャでは、コンピュータの中央処理装置（ＣＰＵ）がネットワークを介した通信をするのに必要なＴＣＰ／ＩＰプロトコル処理を実行するために、その処理能力の多くの部分をそれにあてなければならないことがある。これによって、コンピュータの主な機能である他のタスクを行うために利用できる処理能力の量が減ることになる。
【０００２】
このため、ＴＣＰオフロードエンジン（ＴＯＥ）デバイスと呼ばれるデバイスが開発されてきた。ＴＯＥデバイスとは、１つの定義では、コンピュータのＣＰＵの処理能力を他のタスクに振り向けられるように、そのコンピュータのためにＴＣＰ及びＩＰプロトコル処理の一部または全部を行うデバイスである。ＴＯＥデバイスは、多くの場合、ネットワークインタフェースカード（ＮＩＣ）と呼ばれる拡張カード上に実現される。ある種のＴＯＥデバイスを備えたＮＩＣカードは、インテリジェントネットワークインタフェースカード（ＩＮＩＣ）と呼ばれることもある。
【０００３】
米国特許第6,247,173号には、ＴＯＥの一例が記載されている。このＴＯＥデバイスは、いくつかの他のデバイスとともにプロセッサを備える。このＴＯＥ上のプロセッサは、ＴＯＥデバイス上に格納されたファームウェア命令を実行する。ネットワーキング速度が高速化するにつれ、そのようなＴＯＥのプロセッサに求められる処理要求も高くなってきた。ＴＯＥの処理能力を高める１つの方法は、プロセッサのクロック速度を高速化することである。これによって、プロセッサが命令をフェッチ及び／または実行する速度が高まる。しかし、プロセッサのクロック速度を高めることには実用上の限界が存在する。これまでの半導体プロセシング技術の進歩によって、プロセッサのクロック速度を高速化し続けることが可能となってきたが、ネットワーク速度の高速化の度合いがより大きいことから、クロック速度の高速化の早さは将来の処理能力の必要性に追いつくには不十分であると考えられる。
【０００４】
ＴＯＥスループットが単にプロセッサのクロック速度を速めるだけでは十分に高められなくなった場合、必要なスループットの上昇を達成するために他の技術を用いる必要がでてくる。スループットを高めるための技術の１つとして、プロセッサのデータバスの幅を広げ、より広いデータバス及びＡＬＵを用いることが挙げられる。これによれば、一定のＴＯＥの機能を実施する速度を速められるかもしれないが、その他のＴＣＰ／ＩＰオフロードタスクは順次処理であるため、それらの機能の実行は依然として不満足な遅さにとどまる傾向がでてくる。使用できる他のコンピュータアーキテクチャ技術として、単位時間当たりに実行される命令の数を増やすためのマルチスレッドプロセッサ及び／又はパイプライン処理の使用が挙げられるが、これも同様にクロック速度による制限があり得る。ＴＣＰ／ＩＰプロトコル処理に特に適した特別な命令セットを実行する特定目的プロセッサを用いて、所定の実行されるべき命令をより多く処理することが可能であるが、そのようなプロセッサもやはり命令を順次フェッチする必要がある。採用され得る他の技術には、同時に複数の命令を実行するスーパスカラプロセッサの使用がある。しかしこの場合も同様に、ＴＣＰ／ＩＰプロトコル処理タスクには逐次的な方式で行われる多くの異なる機能が含まれる。特別な命令セットとスーパスカラプロセッサを用いたとしても、将来のネットワーク速度によって課されるスループット要求を満たすためには、実現可能なクロック速度よりクロック速度を高める必要が生ずる可能性がある。次世代の高速ネットワークをサポートするためには最新式のプロセッサのクロック速度を利用可能な速度より高くする必要が出てくることが予想される。ＴＯＥ上でそのような最新式の高額なプロセッサを用いることが可能であったとしても、そのようなプロセッサを使用することは、非現実的に複雑で、かつ経済面で非実用的となる可能性が高い。この問題を解決することが必要である。
【発明の開示】
【課題を解決するための手段】
【０００５】
ネットワークインタフェースデバイス（ＮＩＤ）は、ホストコンピュータからＴＣＰプロトコル処理のタスクをオフロードできる。ＮＩＤは、ＴＯＥ（ＴＣＰオフロードエンジン）デバイスと呼ばれることもある。
【０００６】
第１の態様では、前記ＮＩＤが第１メモリ、第２メモリ、及び組合せロジックを備える。第１メモリは複数のＴＣＰ状態変数を格納し、同時に出力する。これらのＴＣＰ状態変数としては、例えば、受信パケットシーケンスリミット数、予測受信パケットシーケンス番号、送信シーケンスリミット数、送信アクノリッジ（肯定応答）番号、及び送信シーケンス番号等が挙げられる。第２メモリは着信パケットのヘッダからの値を格納し、同時に出力する。これらのヘッダ値としては、例えば、受信パケットシーケンス番号、パケットペイロードサイズ数、パケットアクノジッリ番号、及びパケット送信ウインドウ数等が挙げられる。
【０００７】
組合せロジックは、（１）前記第１メモリからのＴＣＰ状態変数、及び（２）前記第メモリからのヘッダ値の全てを同時に受信する。前記組合せロジックは、２以上のＴＣＰ状態変数及び２以上のヘッダ値からフラッシュ検出信号を生成する。前記フラッシュ検出信号は、そのＴＣＰ状態変数が関連するＴＣＰコネクションに関連して例外条件（例えばエラー条件）が発生しているか否かを示す。前記組合せロジックは、例えば、ステートマシンの部分であって、該ステートマシンに状態遷移させるクロック信号の１クロック時間に前記フラッシュ検出信号をＴＣＰ状態変数及びヘッダ値から決定する、該ステートマシンの部分である。
【０００８】
メモリからのＴＣＰ状態変数の読み出しを複数回行い、その読み出し値及び変数を用いてフラッシュ条件が存在しているか否かを判定するために命令のフェッチ、命令のデコード、そして命令の実行を行う順次プロセッサとは異なり、ＮＩＤの組合せロジックは、同時に判定を行うために必要な全てのＴＣＰ状態変数及びヘッダ値を供給される。従って、ＴＣＰ状態変数及びヘッダ値を取り出すために、時間のかかる順次メモリアクセスを多数回行わずに済む。また、該ステートマシンは命令のフェッチや命令の実行は行わない。命令の順次フェッチは不要である。命令のデコードの複雑なパイプライン処理も不要である。更に、フラッシュ条件が存在するか否かの決定は、ＴＣＰ状態変数及びヘッダ値が入力として供給される高速組合せハードウェアロジックによって行われる。この判定は、個別の論理テストのシーケンスとしてソフトウェア上で行うのではなく、組合せハードウェアロジックが、ハードウェアロジックゲートの動作速度で同時並行でこれらのテストを行う。
【０００９】
第２の態様では、ＮＩＤがステートマシンを含み、該ステートマシンは、そのＴＣＢバッファにおいて複数のＴＣＰ状態変数の全てを同時に更新し、これによってこのタスクを行うための順次命令実行を不要とし、かつ複数の値のメモリ構造への順次書き込みを不要とする。狭いデータバスを通してメモリ構造へ書き込むことに伴う障害が避けられる。ＴＣＰ状態変数を保持するメモリ構造は非常に幅が広く、ＴＣＰ状態の更新が１回または非常に少ない回数のメモリ書き込み動作で行われるように全ての値を同時にメモリに書き込むことを可能としている。
【００１０】
第３の態様では、ＮＩＤがステートマシンとＤＭＡコントローラを備える。前記ステートマシンはＤＭＡコントローラを用いて情報をホストコンピュータとやりとりする。情報の移動を行うＤＭＡコントローラをセットアップするために、その情報の発信元がＤＭＡコントローラに供給され、移動する情報量がＤＭＡコントローラに供給され、その情報が配置される宛先アドレスがＤＭＡコントローラに与えられる。ＤＭＡ転送をセットアップするために複数の順次ステップが必要な順次プロセッサＮＩＣカードの設計とは異なり、この第３の態様によるＮＩＤのステートマシンは、そのステートマシン動作の１つの状態のなかで、移動する情報の発信元、移動する情報量、及びその情報が書き込まれる宛先アドレスの全てを同時にＤＭＡコントローラに供給する。
【００１１】
ＴＣＰ状態変数及びパケットヘッダをワイドメモリ構造に格納する際に、これらの変数及びヘッダがステートマシンによって同時並行で一度にアクセス・処理されるように、そして得られた更新後のＴＣＰ状態変数がワイドメモリに並行して１回でまたは非常に少ない数のメモリ書き込み操作で書き戻されるように格納するアーキテクチャの態様は、ＴＣＰコネクションの制御がＴＯＥデバイスとホストとの間で移管し合うようなシステムに適用可能であるのみならず、ＴＯＥがＴＣＰコネクションを制御し続け、ＴＣＰコネクションの制御がＴＯＥとホストとの間で移ることのないシステムにも適用可能である。本明細書に記載の新規なＴＯＥのアーキテクチャを用いることにより、最大クロック速度を速めることなく単位時間当たりに処理されるパケット数を増加させることが可能となり、或いは、単位時間当たりに処理されるパケット数が一定であるならば最大クロック速度を遅くすることもが可能となる。所定の処理スループットの量に対するクロック速度を遅くすることにより、ＴＯＥシステム全体の電力消費量が低減される。さらに、この新規なＴＯＥアーキテクチャにより、所定のパケット処理スループットの大きさに対するメモリアクセスバンド幅に関する要求を緩めることが可能となり、これによって使用されるメモリを低価格のものとしてさらにＴＯＥシステムのコストを低下させることができる。
【００１２】
他の実施形態及び詳細については以下に説明する。この発明の開示の欄は本発明を範囲を定義する趣旨で記載されたものではない。この欄の記載でなく、特許請求の範囲の記載により本発明は定義される。
【発明を実施するための最良の形態】
【００１３】
図１は、本発明を例示するための実施形態であるシステム１の略図である。システム１はパケット交換ネットワーク２に接続されている。ネットワーク２は、例えば、ローカルエリアネットワーク（ＬＡＮ）及び／またはネットワークの集合であり得る。ネットワーク２は、例えばインターネットであり得る。また、ネットワーク２は、ｉＳＣＳＩを走らせるＩＰベースのストレージエリアネットワーク（ＳＡＮ）であり得る。ネットワーク２は、例えば電気信号をやりとりする媒体を介して、光ファイバケーブルを介して、及び／または無線通信チャネルを介してシステム１に接続されてもよい。
【００１４】
システム１は、ホスト３とネットワークインタフェースデバイス（ＮＩＤ）４とを備える。ホスト３は、例えばマザーボード上に具現され得る。ＮＩＤ４は、例えば、マザーボードに接続された拡張カードであり得る。ホスト３は、中央処理装置（ＣＰＵ）５又はＣＰＵチップセットと、ある程度の大きさのストレージ６とを備える。図示された例では、ストレージ6が半導体メモリと磁気ディスクストレージの組合せを含む。ＣＰＵ５は、ストレージ６に格納されたソフトウェアを実行する。そのソフトウェアは、メディアアクセスプロトコル処理層、ＩＰプロトコル処理層、ＴＣＰプロトコル処理層、及びアプリケーション層を含むネットワークプロトコル処理スタックを有する。ＴＣＰプロトコル処理層の上のプロトコル層は、セッション層と呼ばれることもあれば、アプリケーション層と呼ばれることもある。以下の説明では、これをアプリケーション層と呼ぶものとする。
【００１５】
ＮＩＤ４は、ホストバス７、ブリッジ８、及びローカルバス９を介してホスト３に接続される。ホストバス７は、例えば、ＰＣＩバス又は他のコンピュータ拡張バスであり得る。ＮＩＤ４は、特定用途向け集積回路（ＡＳＩＣ）１０、ある程度の容量のダイナミックランダムアクセスメモリ（ＤＲＡＭ１１）、及び物理層インタフェース（ＰＨＹ）回路１２を含む。ＮＩＤ４は”ファストパス（fast-path）”処理を実現するための専用プロトコル処理アクセラレーションハードウェアを備えており、ファストパス処理では一定の種類のネットワーク通信が、他の種類のネットワーク通信に対する”スローパス（slow-path）”処理と比較して高速化される。尚、スローパス処理では、ネットワーク通信が少なくとも部分的にホスト３上で実行されるプロトコル処理スタックによって取り扱われる。本実施例では、高速処理される一定の種類のネットワーク通信は、一定のファストパス基準を満たすＴＣＰ／ＩＰ通信である。従って、ＮＩＤ４はＴＣＰオフロードエンジン（ＴＯＥ）と称されることもある。
【００１６】
ファストパス及びスローパス処理を行うシステムについての他の情報は、米国特許第6,247,060号、第6,226,680号、第6,247,173号、米国特許出願公開第2001-0021949号、第2001-0027496号、第2001-0047433号、及び米国特許出願第10/420,364号を参照されたい（上記の各特許明細書、特許出願公開、及び特許出願の内容は、引用例により本明細書の一部とする）。図１のシステム１では、上記の文献に記載された、ホストプロトコル処理スタックとネットワークインタフェースデバイスとの間でＴＣＰ／ＩＰコネクションの制御を転送するための技術が用いられている。ＴＣＰ/ＩＰコネクションの制御をホストからネットワークインタフェースデバイスに、そしてネットワークインタフェースデバイスからホストにどのように渡すかについての情報は、上記の文献の記載内容を背景技術情報として本明細書の一部とする。
【００１７】
図２は、図１のＡＳＩＣ１０のブロック図である。ＡＳＩＣ１０は、受信ＭＡＣブロック（RcvMac）２０、受信パーザブロック（RcvPrs）２１、ソケット検出ブロック（SktDet）２２、受信マネージャブロック（RcvMgr）２３、ソケットエンジンブロック（SktEng）２４、ＤＭＡコントローラ／ＰＣＩバスインタフェースユニットブロック２５、ＤＲＡＭコントローラブロック２６、ＳＲＡＭブロック２７、送信フォーマットシーケンサブロック（XmtFmtSqr）２８、及び送信ＭＡＣブロック（XmtMac）２９を有する。残りのブロックは、バッファやキューのようなメモリ構造を示す。末尾の文字がＱである符合を付されたブロックは、キューである。末尾の文字がＢｕｆである符合を付されたブロックは、バッファ及びバッファの組を示す。キュー及びバッファは、他の種々のブロック間で情報の受け渡しを行うために用いられる。
【００１８】
システム１の動作は、（１）スローパス受信シーケンスについて説明し、（２）コネクションの制御がホストからＮＩＤに渡されるコネクションハンドアウトシーケンスについて説明し、（３）渡されたコネクションを介して受信されたパケットのＴＣＰ及びＩＰプロトコル処理がＮＩＤ上で実行されるファストパス受信シーケンスについて説明し、（４）ソケットエンジンの動作について説明し、かつ（５）コネクションの制御がＮＩＤからホストに渡されるコネクションフラッシュシーケンスについて説明することによって後に詳述する。これらの説明では、図２の種々のブロックを指し示すためにニーモニックを用いる。
【００１９】
図３は、図２の種々のブロックを指し示すために用いられるニーモニックを記載した表である。図２における異なる種類のメモリブロックのそれぞれは、一定の形
図４は、図２の各メモリブロックがどのように編成されているかを記載した表である。例えば図４の第１行は、HdrIdによってアドレス指定される特定のハンドラバッファ（HdrBuf）エントリが、パーズヘッダ（PrsHd）とそれに続くパケットヘッダ（PktHd）を有することを示している。HdrBufはヘッダバッファを表すニーモニックであり、HdrIdはヘッダバッファ識別子を表すニーモニックであり、PrsHdはパーズヘッダを表すニーモニックであり、PktHdはパケットヘッダを表すニーモニックである。
【００２０】
図５は、図４の表で使用されている各ニーモニックの簡単な説明を記載した表である。図５に記載の情報の各項目は、以下の説明で「変数」と呼ぶこともある。その変数は、それ自体が複数の他の変数から構成され得る。
【００２１】
図６は、表の左欄の各変数を構成する種々の変数を記載した表である。例えば図６の第１行は、ソケットタプル（SkTpl）が送信アクノリッジ番号（XmtAckNum）、送信シーケンス番号（XmtSeqNum）、送信シーケンスリミット（XmtSeqLmt）、送信輻輳制御ウインドウサイズ（XmtCcwSz）、最大セグメントサイズ（MaxSegSz）、最大送信ウインドウ（MaxXmtWin）、受信シーケンスリミット（RcvSeqLmt）、予測受信シーケンス番号（RcvSeqExp）、予測ヘッダ長（ExpHdrLen）、及び送信制御ブロックアドレス（TcbAd）から構成されていることを示している。
【００２２】
［スローパスパケット受信シーケンス］
図７は、図２の種々のブロックがパケットのスローパス処理を行うために何を実行するかをハードウェア記述擬似コードで記載したものである。擬似コードの各行は、その行の左にある（）で囲まれた行番号によって示されている。
【００２３】
初めに、図２の矢印３０によって示されるように、ネットワーク情報のパケットがＰＨＹ１２からＡＳＩＣ１０に入力される。図７には、行７０１−７０３に、RcvMacブロック（RcvMac）２０によって行われる処理が記載されている。行７０１に示すように、RcvMac２０は着信パケットRcvPkをパーズ（構文解析）し、ネットワークに由来するプリアンブルとポストアンブルを調べる。RcvMac２０はパケットの末尾のＣＲＣ値をチェックし、パケットがRcvMac上に受信され始めた後に衝突が発生したか否かを検出し、かつ他の標準的な機能を実行する。RcvMac２０は、このチェックの結果を表す状態ワードRcvStを発生する。RcvMacは宛先リンクアドレスを調べ、この情報に基づいてＮＩＤ４を宛先としないパケットを除外する。或る実施形態では、RcvMacは、別の会社によって設計された市販の回路ブロックである。パケットがＮＩＤ４を宛先としている場合は、RcvMac２０は対応するエントリをＦＩＦＯのRcvMacQ３１に入れる。エントリの押し込みには、行７０２及び７０３に示すように、パケットRcvPkとともに状態ワードRcvStが含まれる。
【００２４】
受信パーザブロック（RcvPrs）２１はRcvMacQからエントリをポップして出す。図７において、行７０５−７０８はRcvPrsブロック２１によって行われる動作を示す。しかし、RcvPrs２１は、エントリをポップする前に、その情報が格納されるＤＲＡＭ１１の位置を特定してある。ＮＩＤ４を通過する全てのパケットは、ＤＲＡＭ１１に一時格納される。ＤＲＡＭ１１は全部で２Ｍバイトであり、１０２４個のバッファに区分されている。各バッファはそれぞれ２０４８バイトの長さを有する。従って各バッファは、そのバッファの開始アドレスを特定する１０ビットのバッファ識別子（Buffd）によって特定され得る。対応するバッファの２１ビットの開始アドレスを取得するために、Bufldの右側に１１個のゼロが加えられる。そのBufIdを、１１個の（常にゼロである）ゼロ値を除いて格納することでメモリスペースを節約する。
【００２５】
受信バッファキューRcvBufQ（図２参照）と称するキューは、RcvPrsブロック２１による使用のために解放され利用可能なＤＲＡＭバッファのBufldsに格納するキューである。RcvPrsブロック２１は、行７０５に示すように、RcvBufQをポップしてBufldを取得する。RcvPrsはBufld値を受け取り、その値を左に１１ビット分シフトしてＤＲＡＭのバッファにおける開始アドレスを得る。一旦RcvPrsがそのパケットをおく場所を有すると、RcvPrsはRcvMacQから引き出されたエントリのパーズを開始し（行７０６）、パーズヘッダPrsHdを発生する。
【００２６】
のパーズヘッダPrsHdの構成要素は図６に示されている。さらに詳細な情報については、図１８及び図１９を参照されたい。フレーム状態Ａ及びフレーム状態ＢはともにPrsHdを有する。フレーム状態Ａの２３番目のビットはアテンションビットAttnである。Attnビットは、例外及びエラー条件のうち、パケットのトランスポート及びネットワーク層プロトコルがＴＣＰ及びＩＰでないか否かを示す。
【００２７】
パーズヘッダPrsHdの構成要素の１つは、ヘッダ長コードHdrCdである。ヘッダ長コードHdrCdは、ヘッダが受信されたパケット内にどの程度深く入り込んでいるかを示す。図４に示すように、RcvMacQのエントリは、受信パケットRcvPk及び受信状態RcvStを含む。図７に戻ると、RcvPrsブロック２１はパーズヘッダPrsHdをパケットRcvPk上にプリペンドし（行７０７）、この情報を値Buffd（Bufldは行７０５においてRcvBufQからポップして出されたもの）によって特定された受信バッファRcvBuf内に書き込む。RcvPrs２１は、PrsWrDatQに書き込まれるべき情報をそこに入れ、次いでＤＲＡＭコントローラ２６への命令をPrsWrReqQに入れることによって書き込みを行う。PrsWeReqQ上の命令は、ＤＲＡＭコントローラ２６にデータをPrsWrDatQから出させて、それをＤＲＡＭ内の適当なバッファに入れさせる。このリクエスト命令は、PrsWrDatQから出すバイト数を示しているとともに、ＤＲＡＭ内の開始アドレスを示している。ＤＲＡＭコントローラ２６は、その後、PrsWrDatQからどの程度のデータをポップさせ、そのデータをどこに書き込むべきかを命ずるリクエスト命令をPrsWrDatQからポップして出す。行７０７の"write RcvBuf[Bufld] {PrsHd,RcvPk}"という表記は、値Bufldによって特定された「受信バッファ」に書き込みを行い、RcvPkにプリペンドされたパーズヘッダPrsHdを書き込むことを意味する。記号｛｝のなかには、書き込まれる情報が入る。角かっこ記号［］のなかには、書き込みがなされるのがRcvBuf内の何れの受信バッファであるかを示す値が入る。
【００２８】
次に、行７０８において、RcvPrsブロック２０はパーズイベントキューPrsEvtQ３２（図２参照）にエントリを書き込む。このエントリは、ソケット検出ブロックSktDet２２にパケットの着信を警告するパケットエンド標識PkEndと、バッファにおける書き込み可能な次の空き位置（PkEnd）とを含む。PkEndの"Packet end"は、ＤＲＡＭ内のパケットの終わり（ＤＲＡＭ内のバッファの開始アドレス＋パケットサイズ＋パーズヘッダのサイズ）を示すポインタである。ソケット検出器SktDetは、PkEndから、バッファの開始を示す元のバッファＩＤを抽出し、またパケットのサイズを抽出する。受信パーザRcvPrsは、それがPrsEvtQにプッシュしたエントリ内のソケット記述子（SktDsc）及びソケットハッシュ（SkHsh）も含む。図６に示すように、ソケット記述子SktDscは：ヘッダ長コード（HdrCd）、ＩＰ宛先アドレス（DstAd）、ＴＣＰソースポート（SrcPt）、及びＴＣＰ宛先ポート（DstPt）を含む。各ソケット記述子はDetEnビットを含む。
【００２９】
従来のＴＯＥデバイスでは、ソケット記述子及びハッシュはＤＲＡＭ内でパケットが格納された場所のパケットの前にプリペンドされていた。ＴＣＢルックアップを行うためには、それに必要なハッシュ及びソケット記述子を取得するために、初めにソケット記述子及びハッシュが格納されたパケットの前の部分をＤＲＡＭから出して転送しなければならなかった。そのような従来のＴＯＥデバイスと異なり、本発明のＴＯＥデバイスはハッシュをPrsEvtQを介して直接ソケット検出器に渡している。PrsEvtQの各エントリは、PkEnd、SkHsh及びSktDsc（行７０８参照）を含む。そのパケットはＤＲＡＭ内に残される。ハッシュとソケット記述子をソケット検出器に直接渡すことにより、ソケット検出器がＴＣＰルックアップ操作を実施可能となる前にＤＲＡＭをからパケットの前部を転送する必要がなくなる。このようにＤＲＡＭアクセスの量を減らすことにより、予備の利用可能ＤＲＡＭアクセスバンド幅を他の目的で使用することが可能となる。
【００３０】
図７の行７１０−７１２には、ソケット検出器ブロックSktDet２２の動作が示されている。SktDetブロック２２は、行７１０に示すようにPrsEvtQをポップし、取り出したハッシュSkHshを用いて取り出したソケット記述子SktDscが、ソケット記述子バッファSktDscBufに格納された最大４０９６個のソケット記述子の１つであるか否かを確認する。SktDscBuf（図２参照）は、１０２４個のバケットを有するデュアルポートメモリであり、各バケットは４つのソケット記述子バッファを有し、各バッファは１つのソケット記述子を格納し得る。ＴＣＰ／ＩＰコネクションがファストパスで処理されている場合、そのコネクションのためのソケット記述子はSktDscBufに格納される。
【００３１】
PrsEvtQからポップされたエントリから取り出されたハッシュSkHshは、１０２４個のハッシュバッファの１つを特定する。ソケット記述子ブロックSktDetはこのSkHshを用いて適切なハッシュバケットを特定し、次にそのハッシュバケットに格納された可能な４つのソケット記述子のそれぞれについて、それらの格納されたソケット記述子の１つがPrsEvtQから取り出されたソケット記述子と一致しているか否かについて調べる。
【００３２】
ここに説明した実施例では、パケットはスローパスパケットである。従って、行７１１の"test"の結果は一致なしとなる。次にソケット検出器（SktDet）はDetEvtQにスローコードSlwCd、PkEnd値、及びヘッダ長コードHdrCdを書き込む。SlwCdは、パケットがスローパスパケットである（即ちソケット記述子の一致がない）ことを示す２ビットの値である。ヘッダコードHdrCdは、RcvPrsによって生成される、ヘッダが特定のパケット内にどの程度深く入り込んでいるかを示す２ビットコードである。ヘッダは、受信したパケットの種類に応じた異なる深さでパケット内に延びる。パケットが、８０２．３ヘッダ、ｓｎａｐヘッダ、ＶＬＡＮヘッダ、ＲＤＭＡヘッダ、及びｉＳＣＳＩヘッダ等の一定のヘッダを有することもあれば、有しないこともあることから、ヘッダの長さは様々となる。HdrCdは、パケットの全ての適切なヘッダが転送されるのを確実にするべくＤＲＡＭ１１からヘッダバッファHdrBuf内にＤＭＡ転送されることが必要なパケットがどの程度の量かを示す。ＤＲＡＭ１１のバンド幅をとっておくために、ＤＲＡＭ１１からヘッダバッファHdrBufへの６４バイト、１２８バイト、１９２バイト、または２５６バイトの何れかのバイト数が転送される。転送される量は、ヘッダが転送されることになる範囲で最小の量である。ソケットエンジンSktEngブロック２４は、ヘッダを見ることのみが必要であり、パケットペイロードを見る必要はない。
【００３３】
受信マネージャRcvMgrブロック２３によって行われる操作は、図７の行７１４及び７１５に記載されている。RcvMgrはDetEvtQからエントリを引き出す。図４に示すように、DetEvtQ上のエントリは４種のフォーマットのうちの１つしか有し得ない。例えば、そのエントリは、関連パケットがスローパスで扱われることを示すスローコードSlwCdで始まるものであり得る。或いは、そのエントリは、関連パケットがファストパスで扱われることを示すファストコードFstCdで始まるものであり得る。DetEvtQエントリは、イネーブルコードEnbCdか、ディスエーブルコードDblCdで始まるものであり得る。
【００３４】
スローパスイベントキューSlwEvtQが設けられ、受信マネージャRcvMgrがスローパスイベントを更なる処理のためソケットエンジンSktEngに移す際にこれを介して行う。また、ファストパスイベントキューFstEvtQが設けられ、受信マネージャRcvMgrがファストパスイベントを更なる処理のためソケットエンジンSktEngに移す際にこれを介して行う。これらのキューのそれぞれはレディ（ready）ビットを有する。このビットは、そのキューが有するエントリをポップするソケットエンジンSktEngを示す。
【００３５】
本実施例では、RcvMgrブロック２３はDetEvtQエントリにおいてスローコードSlwCdの存在を検出する。従ってRcvMgrブロック２３はスローパスイベントキューSlwEvtQ上にそのエントリの書き込みを行うのみである。SlwEvtQ上に書き込まれるエントリの種々の変数は図４に示されている。
【００３６】
ソケットエンジンSktEngはそのアイドル状態にあり、SlwEvtQのレディビットを検出する。行７１７に示すように、ソケットエンジンはSlwEvtQのエントリをポップして出す。（ソケットエンジンの状態の説明の項で後述する、図１０の行１００１も参照されたい。）スローパス処理においては、ホストスタックがＴＣＰ／ＩＰプロトコル処理を行うことから、ポップされるエントリにおけるスローコードSlwCdから、ソケットエンジンSktEngは関連するパケットをホスト３に渡す必要があることを知る。
【００３７】
ＮＩＤ４は、メッセージバッファ機構によってホスト３に情報を渡す。この機構により、ホスト３は、ＮＩＤ４上のメッセージバッファキューMsgBufQ（図２参照）にメッセージバッファ識別子のキューを維持する。これらのメッセージバッファ識別子のそれぞれは、ホストストレージ６における使用していないメッセージバッファの開始アドレスを示す。ＮＩＤ４は、これらのメッセージバッファを用いて情報をホストスタックに渡す。
【００３８】
従って、ソケットエンジンSktEngはMsgBufQをポップして、使用していないメッセージバッファのメッセージバッファアドレスMsgAdを得る（行７１８）。（ソケットエンジンの状態の説明の項で後述する、図１０の行１０７９も参照されたい。）次にソケットエンジンSktEngは、Bufldによって特定された受信バッファからパーズヘッダPrsHdr及びパケットRcvPkを、ホストメモリHstMemのメッセージアドレスMsgAdとオフセット値MsgHdrLenによって要求されるホストメモリ上の位置にコピーする（行７１９）。ここで値BufidはPkEndから抽出される（行７１７参照）が、これはPkEndがBufldとPkLenとの連結だからである。次にスローパスパケットはメッセージバッファ内のホストメモリ６におかれる。
【００３９】
次にメッセージヘッダがホストに送信され、ホストにそのメッセージバッファがスローパスパケットを含むことを知らせる。このメッセージヘッダは、メッセージバッファの前に付加される。これを行うため（行７２０参照）、メッセージヘッダMsgHdはホストメモリにMsgAdから始めるように書き込まれ、従ってメッセージヘッダはアドレスMsgAdから開始されるメッセージバッファにおいてRcvPk及びPrsHdにプリペンドされる。（ソケットエンジンの状態の説明の項で後述する、図１０の行１０８７も参照されたい。）ＤＲＡＭ１１からパケットを出して、ネットワークから着信する他のパケットを格納するためにＤＲＡＭバッファが使用していない状態にされる。このことは、行７２１に示すように、現在使用していないＤＲＡＭバッファのBufIdを使用していないバッファのRcvBufQにプッシュするソケットエンジンSktEngによって行われる。
【００４０】
パケットとメッセージヘッダが、MsgAdによって特定されるホストメッセージバッファに一旦存在することになると、ホストスタックはホストメッセージバッファを（割込みのため、或いはホスト処理ポーリングのために）調べて、メッセージヘッダを取り出し、そのメッセージバッファがスローパスパケットを含んでいるか否かを判定し、そのパケットに対して必要なＴＣＰ及びＩＰプロトコル処理を行う。
【００４１】
［コネクションハンドアウトシーケンス］
ＮＩＤ４は、一定の種類のネットワーク通信に対して実質的に全てのＴＣＰ及びＩＰ処理を行い、これによってホストスタックからこのタスクをオフロードする。この実施例では、ＴＣＰコネクションがホスト３で実行されるプロトコルスタックによってセットアップされる。一旦ＴＣＰコネクションがセットアップされると、ＴＣＰコネクションの制御はホスト３からＮＩＤ４に渡される。ＴＣＰコネクションの制御がＮＩＤ４に渡されると、ＮＩＤ４は、一定のエラー条件が発生しない限りそのＴＣＰコネクションを介してやりとりされる後続のパケットに対して全てのＴＣＰ及びＩＰプロトコル処理を実施する。該コネクションを介して受信された後続のパケットのパケットペイロードは、ＮＩＤ４によってホスト３上のアプリケーションメモリの最終的な宛先に直接書き込まれる。そのパケットペイロードは、ＴＣＰまたはＩＰネットワークヘッダの何れかがない形で最終宛先に書き込まれる。ホスト３からＮＩＤ４に渡されるこのＴＣＰコネクションの制御のために、そのＴＣＰコネクションのための情報のＴＣＢ（ＴＣＰ制御ブロックのこと。トランザクション制御ブロック或いは送信制御ブロックと呼ばれることもある。）の制御は、ホスト３からＮＩＤ４に渡される。ＴＣＢはＴＣＰコネクションの状態についての情報を含む。この実施形態では、該コネクションのためのＴＣＢの制御の移管のために、ＴＣＢ情報の一部をホスト３からＮＩＤ４に実際に転送する。ＴＣＰコネクションの制御は、以下に説明する２段階の「コネクションハンドアウト（connection handout）」プロセスでホスト３からＮＩＤ４に渡される。
【００４２】
第１段階（スローパスパージ（消去））：
コネクションハンドアウトプロセスの第１段階では、ホスト３がＴＣＰコネクションの制御をＮＩＤ４に仮に移管する。ＮＩＤ４は、そのコネクションのためにＮＩＤ４上に受信されたスローパスパケットの流れにパージマーカを入れ、そのコネクションのためにＮＩＤ４にその後受信した着信パケットをホスト３に渡さずに保持するようにさせる。ホスト３はそのコネクションのためにスローパスパケットの流れの処理を継続して行う。ホスト３は、パージマーカを受信したとき、パケットのスローパスフローがパージされたこと、及びそのコネクションのために受信するパケットはもうないことを認識する。コネクションハンドアウトプロセスの第１段階は終了し、ホストはＴＣＰ状態をＮＩＤ４に渡すために使用されていない状態となる。
【００４３】
図８は、コネクションハンドアウトを実施するために図２の種々のブロックが何を行うかを記述した擬似コードハードウェアについて説明している。行８０１に示すように、ホスト３はホストメモリ内の位置CmdAdに、受信コマンド（即ちパージ受信コマンド）を構築する。パージ受信コマンドは、パージ受信コマンドを示し、かつコネクションのＴＣＢが格納されるホスト上のアドレスTcbAdを含むコマンドヘッダCmdHdを含む。次にホスト３は、行８０２に示すように、ＮＩＤ４上のHstEvtQにポインタ（CmdAd）とコネクションの表示（TcbId）を書き込むことによって、ＮＩＤ４にパージ受信コマンドを通知する。ポインタCmdAdは、ホストメモリ中の受信コマンドを指し示す。TcbIdは、どのコネクションのためにＮＩＤ４がパケットの保持を開始すべきかを示す。
【００４４】
ソケットエンジンSktEngブロック24は、そのアイドル状態にありHstEvtQがレディ状態にあることを検出する。従って、ソケットエンジンはホストイベントキューHstEvtQをポップし（行８０４）、コマンドアドレスCmdAdとTcbIdを取り出す（ソケットエンジンの状態の説明の項で後述する、図１０の行１０４９−１０５２も参照されたい。）。
【００４５】
ソケットエンジンSktEngは、ＤＭＡコントローラブロック２５に、コマンドアドレスCmdAdから受信コマンド（コマンドヘッダCmdHd及びTcbAd）を取り出させる。ソケットエンジンSktEngはコマンドヘッダCmdHdにおけるコマンドコードCmdCdを調べて、これが「ソケット記述子インポート」コマンド（このコマンドによればＴＣＢのソケット記述子部分がインポートされるがＴＣＢのＴＣＰ状態部分はインポートされないにも関わらず、「Tcbインポート」コマンドとも呼ばれる）であることを確認する。ソケットエンジンの状態の説明の項で後述する、図１０の行１１４４−１１４５も参照されたい。
【００４６】
ソケットエンジンSktEngはTcbAを用いて、ホストメモリHstMemにおけるＴＣＢからソケット記述子SktDsc及びそのソケット記述子SktDscをコピーし（行８０６）、TcbIdで特定されたＮＩＤ４上の特定のソケット記述子バッファSktDscBufのなかに入れる。上述のように、ＮＩＤ４によって処理されるファストパスであるTcbのそれぞれに対して、ＮＩＤ４上に１つのソケット記述子バッファが設けられる。図６に示すように、ソケット記述子SktDscは、ヘッダコードHdrCd、ＴＣＰ発信元ポート、ＴＣＰ宛先ポート、ＩＰ発信元アドレス、及びＩＰ宛先アドレス、及び検出イネーブルビットDetEnを含む（ソケットエンジンの状態の説明の項で後述する、図１０の行１１５３−１１５９も参照されたい。）。
【００４７】
一旦、そのコネクションのためのソケット記述子がＮＩＤ４上のソケット記述子バッファSktDscBufにロードされると、ソケットエンジンSktEngは検出イネーブルコマンドEnbCdをソケット検出器SktDetブロック２２に送る（行８０７）。この検出イネーブルブルコマンドEnbCdは、ソケット検出器SktDetブロック２２に対して、このコネクションのためのパケットの検出を開始するように命ずるものである。この検出イネーブルブルコマンドは、行８０７に示すように、ソケットイネーブルコードEnbCd及びTcbIdを検出コマンドキューDetCmdQに書き込むソケットエンジンSktEngによって送信される（ソケットエンジンの状態の説明の項で後述する、図１０の行１１６１−１１６２も参照されたい。）。
【００４８】
ソケット検出器SktDetブロック２２はDetCmdQをポップし（行８０９）、ソケットイネーブルコードEnbCd及びTcbIdを取り出す。次にソケット検出器SktDetは、SktDscBuf [TcbId]によって特定された特定のソケット記述子バッファにおける検出イネーブルビットDetEnを「セット」する。この検出イネーブルビットDetEnは、ソケット検出器に対して、次回それがパケットを受信し、Tcbとパケット中のヘッダ群とを比較したとき、パーズヘッダPrsHdにおいてその一致を示すことが可能であることを知らせる。検出イネーブルビットDetEnがセットされない場合、Tcbが比較対象のパケットヘッダとの比較を行ったとしてもソケット検出器は一致を表示しない（検出イネーブルビットは、無効なソケット記述子エントリとの一致が用いられたために、ソケット検出器SktDetが着信パケットがフラットパスで取り扱われるべきであると誤って判定するのを防止する。）。
【００４９】
ソケット検出器SktDetブロック２２は、イネーブルコードEnbCdパージマーカをTcbIdとともに検出イベントキューDetEvtQに書き込む（行８１１）。
【００５０】
受信マネージャRcvMgrはDetEvtQを読み出し（行８１３）、EnbCdパージマーカ及びTcbIdを取得する。RcvMgrは、EnbCd及びTcbIdをスローイベントキューSlwEvtQに書き込むことによって、EnbCdパージマーカをTcbIdによって特定されるコネクションのためのパケットの流れに入れる（行８１４）。かくして、スローパスパケットが格納されるＤＲＡＭにおけるバッファを指し示すPkEnd値を含むエントリに加えて、パージマーカのフォーマットを有するエントリもこのSlwEvtQに入り得る。EnbCdパージマーカを含むSlwEvtQエントリのよなフォーマットについては、図４を参照されたい。
【００５１】
従って、Tcbハンドアウトが受信される前に受信された受信記述子は、このTcbに対応するあらゆるパケットのために、EnbCdパージマーカの前にSlwEvtQのなかに入れられ、パージマーカがSlwEvtQからポップして出される前にホストスタックに送信されることによって通常のスローパス方式で取り扱われる。
【００５２】
一方、パージマーカの後に受信されたパケットのための受信記述子は、それをソケット受信キューSktRcvQ（図２参照）に入れることによってＮＩＤ４に保持されることになる。そのようなパケットのための受信記述子はこのSktRcvQに重ねられる。実際のパケットは、ＤＲＡＭ受信バッファにおける受信パーザRcvPrsによって通常通りに格納されるが、これらのＤＲＡＭ受信バッファはSktRcvQ上に保持された受信記述子におけるPkEnd変数によって指定される。
【００５３】
ソケットエンジンSktEngはそのアイドル状態にあり、SlwEvtQ上のエントリを検出する。従って、ソケットエンジンSktEngはSlwEvtQを読み出し（行８１６）、EnbCdパージマーカ及びTcbIdを取得する。EnbCdパージマーカは、イベントコードEvtCdの一種（EvtCd = = 1）である。ソケットエンジンSktEngがこの特定のEnbCdパージマーカを見つけると、SktEngは、（ＮＩＤ４がホスト３に送信するハンドアウトの段階１が終了したことを示すメッセージバッファMsgBufを指定する）メッセージバッファアドレスMsgAdを得る。従ってSktEngは、行８１７に示すようにMsgBufQをポップしてMsgAdを得る。SktEngブロック２４は、ＤＭＡコントローラ２５に、MsgAdで特定されたホスト上のメッセージバッファ内にメッセージヘッダMsgHdを書き込ませる。このメッセージヘッダHsgHdは、ここでイネーブルマークメッセージEnbMrkMsgを示す（ソケットエンジンの状態の説明の項で後述する、図１０の行１０９４−１１００も参照されたい。）。
【００５４】
ＮＩＤ４からホスト３への全てのメッセージは、ホストメモリにおけるメッセージバッファの仮想キューを通る。上述のように、ホスト３は使用されていないメッセージバッファの開始アドレス群をNsgBufQを介してＮＩＤ４へ渡す。ホスト３は、メッセージバッファアドレスがＮＩＤ４に渡される順番の追跡も行う。ホストスタックは正確なメッセージバッファが渡された順番でメッセージバッファを調べる。従って、パージマーカはこの仮想キューにおけるメッセージヘッダMsgHdの形でホストスタックを通して流れる。このメッセージヘッダMsgHdパージマーカは、ホスト受信コマンド（行８０５でソケットエンジンによって読み出される）がＮＩＤ４によって終了したことをホストスタックに知らせる。
【００５５】
第２段階（ロードソケット状態）：
ホスト３は、ＮＩＤ４がメッセージヘッダを置いた位置MsgAdにてMsgMemを読み出すことによってＮＩＤ４からMsgHdパージマーカを読み出す（行８２０）。コネクションハンドアウトの第１段階の終了を検出したとき、ホスト３はTcbAdによって特定されるホストメモリの部分内にソケットタプルSkTplの形でソケット状態を書き込む（行８２１）。図６に示すように、ソケットタプルSkTplはそのコネクションのためのＴＣＢの状態情報を含む。ホスト３は、CmdAdによって特定されたメッセージバッファ内にコメントヘッダCmdHd及びTcbAdの形でソケット受信コマンドSktRcvCmdの書き込みも行う（行８２２参照）。ホスト３は、ＮＩＤ４上のホストイベントキューHstEvtQ内にコマンドバッファのアドレスCmdAd及びTcbIdを含むエントリを書き込む（行８２３）。
【００５６】
ソケットエンジンSktEng２４はアイドル状態にあり、HstEvtQがレディ状態にあることを検出する。従って、ソケットエンジンはHstEvtQをポップし（行８２５）、CmdAdポインタを用いてホストコマンド（コマンドヘッダCmdHd及びTcbAd）をホストメモリのバッファから読み出す（行８２６）（ソケットエンジンの状態の説明の項で後述する、図１０の行１１３７−１１４１も参照されたい。）。
【００５７】
TcbAdはホストメモリにおけるソケットタプルの位置を特定する。このコマンドはソケットイネーブルコマンドである。従って、ソケットエンジンSktEngはTcbAdを用いて、状態情報SkTplを、ホストメモリHstMemからTcbIdによって特定されたＮＩＤ４上のTcbバッファ内にコピーする（行８２７）（ソケットエンジンの状態の説明の項で後述する、図１０の行１１７７−１１８３も参照されたい。）。
【００５８】
一旦状態がロードされると、SktEngは”アーム（特殊機能作動）”コードArmCdをMgrCmdQを介して受信マネージャに送信する（行８２８）（ソケットエンジンの状態の説明の項で後述する、図１０の行１８７も参照されたい。）。
【００５９】
受信マネージャRcvMgrは１ビット幅のMgrBufにおけるイベントイネーブルEvtEnビットを維持する（図２参照）。ＮＩＤ４によって制御される各Tcbについて１つのそのようなイベントイネーブルビットが存在する。あるTcbのためのイベントイネーブルビットEvtEnがセットされた場合、RcvMgrはそのTcbのために１つのファストパスイベントをソケットエンジンSktEngに送信するべくアーム（特殊機能作動状態に）される。SktRcvQ上にキューイングされたそのTcbのためのイベントが存在しない場合には、受信マネージャRcvMgrはSktRcvQがそのTcbIdのエントリを有するまで待機する。ktRcvQRdy [TcbId]によって示されるようにそのTcbIdのために受信記述子がSktRcvQに存在するとき、受信マネージャRcvMgrはそのTcbIdのためにSktRcvQをポップし、そのエントリを用いてソケットエンジンSktEngのための１つのファストパスイベントを発生して、そのTcbIdのための処理を行う。
【００６０】
従って、受信マネージャRcvMgrはMgrCmdQ（行８３０）をポップし、ArmCd及びTcbIdを取り出す。SktRcvQ上にこのTcbIdのための受信記述子が存在する場合には、SktRcvQRdy [TcbId]は真となる。受信マネージャRcvMgrがそのTcbのためにSktRcvQをポップし、FstEvtQ上にFstCd及びTcbIdを書き込むことによって、そのイベントをファストパスイベントキューに移動させる（行８３２）。
【００６１】
現時点でSktRcvQ上にこのTcbIdのための受信記述子が存在していない場合には、SktRcvQRdy [TcbId]は偽となる。従って、行８３４に示すように受信マネージャRcvMgrはMgrBufにおけるEvtEnビットをセットする。このEvtEnビットがセットされ、従って次回、TcbIdのための受信記述子がSktRcvQ上に見つけられたときに、受信マネージャRcvMgrがTcbIdのためにSktRcvQからそれをポップして出し、FstEvtQ上のファストイベントを発生し（図９の行９１９参照）た上でIcbIdのためのMgrBufにおけるEvtEnをクリアすることになる。
【００６２】
従って、ファストパスイベントが受信マネージャRcvMgrによってソケットエンジンSktEngに戻されたときEvtビットがクリアされるので、EvtEnビットはワンタイムアームコマンド機構をインプリメントするために必要であることが理解されよう。EvtEnビットをセットすることにより、受信マネージャRcvMgrが、ただ１つのファストパスイベントをソケットエンジンSktEngに送信するべくアームされる。このワンタイムアームコマンド機構は、ソケットエンジンSktEngが、そのファストパスコネクション上での以前のパケットの処理を終了させた後にのみ、ファストパスコネクション（TcbId）上のパケットを処理するようにするために設けられる。
【００６３】
図８に記載の操作が終了したとき、TcbIdによって特定されるＴＣＰコネクションを介した通信は、ＮＩＤ４によってファストパス方式で取り扱われている。ファストパスＴＣＰコネクション上のパケットのための受信記述子は、受信マネージャRcvMgrからファストパス処理のためのファストイベントキューFstEvtQを介してソケットエンジンSktEngに渡される。
【００６４】
［ファストパスパケット受信シーケンス］
第１のファストパスパケット受信パケット（最終的な宛先をセットアップする初めのパケット）について以下説明する。
【００６５】
図２の矢印３０によって示されるようにネットワーク情報のパケットはＰＨＹ１２からＡＳＩＣ１０に入る。受信ＭａｃブロックRcvMac２０及び受信パーザブロックRcvPrs２１を通しての処理は（図９の行９００−９０８参照）、スローパス受信シーケンスと大部分同じように生ずるが、ファストパス受信シーケンスで異なる点は、図８を参照して上述したコネクションハンドアウトシーケンスが既に発生している点である。ＴＣＰコネクションのためのソケット記述子はソケット記述子バッファSktDscBuf内に既に存在し、ＴＣＰコネクションの状態を保持するソケットタプルSkTplは既にTcbバッファに存在する。
【００６６】
ソケット検出器SktDetブロック２２がソケットハッシュSkHshを取り出し（行９１０）、SktDscBdfのテストを行ったとき（行９１１）、一致が検出される。従って、ソケット検出器SktDetはスローコードSlwCdではなくファストコードFstCdを検出イベントキューDetEvtQ内に書き込む（行９１２）。行９１２及び９１３によって示されるように、２つのエントリがDetEvtQにプッシュされ、ファストコードFstCd、ヘッダコードHdrCd、パケットエンドポインタPkEnd及びTcbIdが受信マネージャRcvMgrに渡される。２つのエントリが必要なのは、DetEvtQが３２ビットの幅しかないからである。受信マネージャRcvMgrがFastCdを受けとったとき、受信マネージャは次のエントリがTcbIdであることを認識し、従って第１のエントリとともに第２のエントリをDetEvtQから自動的にポップする。
【００６７】
行９１５及び９１６に示すように、受信マネージャRcvMgrブロック２３はDetEvtQを２回ポップし、受信パーザRcvPrsによってそこに配置されたエントリを取り出す。
【００６８】
受信マネージャRcvMgrはＦＩＦＯソケット受信キューSktRcvQを維持している。SktRcvQは実際には複数のキューであり、１つが各TcbIdに対応する。そのTcbIdのSktRcvQはそのIcbIdのための検出イベント記述子を保持している。受信マネージャRcvMgrブロック２３がファストパスイベントをソケットエンジンSktEngに送信すべくアームされておらず、かつRcvMgrがDetEvtQからイベントを受けとった場合、RcvMgrブロック２３はファストパスイベントをそのTcbIdのSktRcvQにプッシュする。従って、行９１７に示すように、この実施例において受信マネージャRcvMgrはSlwCdをそのTcbIdのためのSktRcvQに書き込む。RcvMgrはそのTcbIdのためのMgrBufをチェックし、そのTcbIdのEvtEnビットがセットされているかを確認する。EvtEnビットがセットされている場合は、RcvMgrはFstEvtQにFstCd及びTcbIdを入れて、EvtEnビットをクリアする（行９２０）。EvtEnビットがクリアされるのは、それが１回限りで、１つのファストパスイベントがソケットエンジンSktEngにフォワーディングされたばかりだからである。
【００６９】
ソケットエンジンは、それがファストイベントキューがレディ状態にあることを検出するとき、そのアイドル状態にある。従って、このソケットエンジンSktEngはFstEvtQをポップし（行９２３）、FstCd及びTcbIdを取り出す。次にソケットエンジンは、ReqCd、HdrId、及びTcbIdをその受信マネージャのためのMgrCmdQに書き込むことによってファストパスパケットのためのヘッダをリクエストする（そのTcbIdのためのTcbバッファは、状態、ＭＤＬエントリ、幾つかの作業エリア、及びヘッダを格納するためのエリアを有する。ソケットエンジンの状態の説明の項で後述する、図１０の行１１１７も参照されたい。）。
【００７０】
受信マネージャはMgrCmdQをポップし（行９２６）、ReqCd、HdrId及びTcbIdを取り出す。TcbIdを用いて、受信マネージャはSktRcvQをポップし（行９２７）、現在のTcbIdのための受信イベント記述子を取得する。次に受信マネージャは、ＤＲＡＭコントローラに、パーズヘッダPrsHd及びパケットヘッダPkHdをBufIdによって特定されたＤＲＡＭ受信バッファからHdrIdによって特定されたヘッダバッファHdrBuf内に転送させる。HdrBufはキューではない。代わりに、各TcbIdに対して１つのHdrBufが設けられる。ＤＲＡＭコントローラによってＤＲＡＭ受信バッファから転送される量は、HdrCdに基づいている。次に受信マネージャRcvMgrは、TcbIdをHdrEvtQ内ｎ書き込み（行９２９）、ソケットエンジンSktEngにヘッダがHdrBuf [TcbId]に入れられたことを知らせる。
【００７１】
同様にソケットエンジンSktEngはそのアイドル状態にあり、ヘッダイベントキューがレディ状態にあることを検出する。ソケットエンジンはHdrEvtQをポップし（行９３１）、TcbIdを取り出す。これによってソケットエンジンSktEngは、ヘッダがHdrBuf [TcbId]に存在すること、そしてそれがTcbIdによって特定されたソケットのためのパケットを有することを知らされる。ソケットエンジンSktEngはここでパケットを処理する。行９３３に示すように、ソケットエンジンはアクノリッジ、ウインドウ、シーケンサ番号をチェックする処理を同時並行で行う。パケットがこれらのテストを渡した場合は、パケットはファストパスで扱われ、ソケットエンジンSktEngはこのパケットにおけるデータの転送先を知る必要がある。
【００７２】
SktEngはデータの転送先を以下のようにして決定する。マルチパケットセッション層メッセージのための第１のＴＣＰペイロードデータは、セッション層ヘッダを有し、その後のパケットは有していない。ＮＩＤ４は、ホストスタックへの第１のＴＣＰパケットをホストメモリの仮想キューのなかにTcbIdを特定するメッセージヘッダとともに渡す。メッセージヘッダは、そのパケットがこのIcbIdのための初めの受信パケットでることをスタックに知らせる。ホストスタックはＮＩＤ４で用いられるTcbIdをホストで用いられるTcb番号に変換する。ホストスタックはそのパケットのセッション層ヘッダをホスト上で動作するアプリケーションプログラムに渡す。アプリケーションプログラムは、セッション層メッセージのデータペイロードを入れる先を示すメモリ記述子リスト（ＭＤＬ）を戻す。ＭＤＬはエントリのリストを含む、各エントリはアドレスとサイズを有する。ＭＤＬには全バイトカウントも含まれる。ホストは、適切なホストコマンドポインタをHstEvtQにプッシュすることによりＭＤＬをＮＩＤ４に渡す。ホストは、そのコマンドバッファの１つにコマンドを構築し、次にホスト上のそのコマンドバッファを指定するポインタをＮＩＤ４のHstEvtQに入れることによって、コマンドをＮＩＤ４に渡す。ＮＩＤ４はHstEvtQをポップし、ポインタを取り出し、ホストのコマンドバッファからコマンドにＤＭＡ転送をする。ここでＮＩＤ４は、第１のＭＤＬエントリのアドレスとサイズを有し、かつ全バイトカウントを有する。ＮＩＤ４は特定されたTcbId上のパケットのためにペイロードデータを受け取ったとき、ＮＩＤ４はデータペイロードを、ホストストレージ６のＭＤＬエントリで特定されたアドレスにＤＭＡ転送し、移動されたペイロードデータの分だけＭＤＬエントリのサイズ値をデクリメントする。ペイロードデータをさらに受け取るにつれ、ＭＤＬエントリはそのサイズ値がなくなるまでデクリメントされる。次に第２のＭＬＤエントリがホストメモリから取り出され、第２のＭＤＬエントリが一杯になるまで処理が進められる。この処理はＭＤＬのための全バイトカウントがゼロになるまで継続される。エントリの全ＭＤＬリストが全部使われたとき、ＮＩＤカード４はマスターイベントキューMstEvtQを介してこの事実をホストに知らせ、ホストに割込みを送信する。次にＮＩＤ４は、最初のパケットをホストスタックを通して上げてアプリケーションプログラムに渡す最初の段階に戻り、第２のＭＬＤリストを取得しなおす。
【００７３】
従って、行９３４において、ソケットエンジンSktEngは、当該TcbIdのための有効な記述子エントリが存在するかを確認するチェックを行う。各TcbIdのTcbバッファにＭＤＬ有効ビットMdlVdが存在する。ソケットエンジンSktEngはこのMdlVdビットを調べる。それがセットされている場合、行９３５−９４２に記載の動作が実行され、そうでない場合には行９４３−９６１に記載の動作が実行される。
【００７４】
有効なＭＤＬエントリが存在する場合、ソケットエンジンSktEngはHdrIdによって特定されたHdrBufからヘッダバッファIdBuffdを読み出す（行９３５）。（BuffdはパーズヘッダPrsHdの一部である。）ソケットエンジンは、このTcbIdのTcbバッファTcbBufに格納されたＭＤＬエントリ（ここではApDscと呼ばれる）を読み出す。ソケットエンジンSktEngはパケットペイロードPayLdをＤＲＡＭ受信バッファRcvBuf [BufId]からホストアプリケーションメモリHstMem [ApDsc]内にコピーする（行９３７）。ソケットエンジンSktEngは、リクエストをＤＲＡＭｔｏホストリクエストキューeD2hReqQ上に入れることによってデータ移動を行う。このリクエストにより、ＤＲＡＭコントローラ２６がペイロードをＤＲＡＭ受信バッファからＤＲＡＭｔｏホストデータキューD2hDatQ内に移動する。次にソケットエンジンSktEngは、MstWrReqQを介してＤＭＡコントローラ／ＰＤＩバスインタフェースユニットブロック２５にリクエストを渡し、パケットペイロードをD2hDatQからホストメモリのApDscによって特定された位置（即ちＭＤＬエントリ）に移動させる。
【００７５】
一旦データ転送が終了すると、ＤＭＡコントローラ／ＰＤＩバスインタフェースユニットブロック２５はマスターイベントをMstEvtQ上のソケットシーケンサに戻す。このマスターイベントはソケットエンジンSktEngに、パケットペイロードのホストメモリへの転送が終了したことを知らせる。
【００７６】
ここで単純化のため、データの転送によりＭＤＬエントリの最後のエントリが使われたと仮定する。従って、ＮＩＤ４はＭＤＬエントリがデータで一杯にされたことをホストスタックに通知しなければならない。（この通知にはＭＤＬのための第２のホスト割込みが必要となる。）第１の割込みは第１のパケットに生じて、これによりＭＤＬがＮＩＤ４に戻された。これはＭＤＬがデータで一杯になった後の第２の割込みである。
【００７７】
ホストへの通知のため、ＮＩＤ４は、使用されていないメッセージバッファのアドレスMsgAdをメッセージバッファキューMsgBufQから読み出す（行９３８）。ソケットエンジンSktEngは適切なメッセージヘッダMsgHdをメッセージバッファ内に入れる。メッセージヘッダMsgHdは、ホストスタックに対して、TcbIdのためのアプリケーションメモリ空間にデータが入れられたことを示す。データペイロードはホストメモリに移動されていることから、ＮＩＤ４上のＤＲＡＭ受信バッファはもはや不要であり、別のパケットを受信するために利用可能とされる。従って、ＤＲＡＭ受信バッファのBufIdは使用されていないバッファキューRcvBufQに再びプッシュされる（行９４０）。
【００７８】
ここで本実施例では、単純化のため、このデータペイロードの転送によって、ＭＤＬ受信コマンドが終了し、ホストが利用可能とされた全ＭＤＬリストが一杯になるものと仮定する。従って、TcbIdのために埋められる利用可能なＭＤＬエントリはもはや存在しない。従って、ＭＤＬは”無効”であり、ソケットエンジンSktEngは、行９４２に示すようにTcbBuf [TcbId]におけるMdlVdビットをクリアする。
【００７９】
ファストパスパケットが受信され、ＭＤＬ有効ビットMdlVdが偽である場合、パケットはファストパスマルチパケットセッション層メッセージの第１のパケットである可能性がある。そのような状況では、MdlVdが偽であるため、処理は行９４３−９６１に進む。ホストスタックがそのコネクションで受信した次のファストパスパケットのためのＭＤＬエントリを戻すことができるように、全パケット（ヘッダ及びデータ）はファストコードFstCdとともにホストスタックに渡される。従って、ソケットエンジンSktEngは使用されていないメッセージバッファのアドレスMsgAdをメッセージバッファキューMsgBufQから取り出す。次に全パケットペイロードPayLdがBuffdで特定されたＤＲＡＭ受信バッファRcvBufからMsgAdで特定されたホスト上の汎用メッセージバッファ内にコピーされる。メッセージヘッダMsgHdは、パケットペイロードがファストパス受信パケットであることを示し、TcbIdを示し、かつどの程度の量の情報がホストに転送されているかを示す。一旦ペイロードPayLdがＤＲＡＭ受信バッファからホストメモリにコピーされてしまうと、ＤＲＡＭ受信バッファは、ＤＲＡＭ受信バッファ識別子Bufldを使用されていない受信バッファキューRcvBufQ上に書き込むことによってリサイクルされる（行９４７）。
【００８０】
ホストスタックは、汎用ホストメッセージバッファHstMem [MsgAd]からメッセージを取り出し（行９４９）、メッセージMsgDtのペイロード（全パケット）をＩＰプロトコル処理層及びＴＣＰプトロコル処理層を通して処理し、セッション層ヘッダをアプリケーション層プログラムに供給する。アプリケーション層プログラムはＭＤＬリストを戻す。ホストスタックは第１パケットのセッション層メッセージのデータ部分をＭＤＬエントリによって特定されるホストメモリのエリア内に移動させ、ホストメモリＭＤＬエントリエリアにおけるデータの量を反映するように第１のＭＤＬエントリをデクリメントする。次にホストスタックは（そのようにデクリメントされた）第１ＭＤＬエントリを、コマンドヘッダCmdHd及びＭＤＬエントリ（ApDscと称する）をホストメモリ内の或る位置に書き込むことによってＮＩＤに供給する（行９５０）。次にホストスタックは、コマンドCmdAdの開始アドレスとTcbIdをＮＩＤ４上のホストイベントキューHstEvtQにプッシュすることによって（行９５１）、コマンドの通知をＮＩＤ４に与える。
【００８１】
ソケットエンジンSktEngはHstEvtQをポップし（行９５３）。ホストメモリにおけるコマンドのアドレスCmdAd及びTcbIdを取り出す。次にコマンドヘッダCmdHd及びコマンドデータ（この場合はApDsc）がTcbバッファTcbBuf [TcbId]内に転送される（行９５４）。ＭＤＬエントリが埋められるべくＮＩＤ４上に存在するので、ソケットエンジンSktEngはこのコネクション（TcbId）のためのTcbBufにおけるＭＤＬ有効MdlVdビットをセットする（行９５５）。次にソケットエンジンSktEngは、アームコードArmCdをTcbIdとともにマネージャコマンドキューMgrCmdQに書き込むことによって、アームコマンドを受信マネージャにか送信する。これによって、受信マネージャが、このTcbIdのために１つのファストパスイベントをソケットエンジンSktEngに送信するべくアームされる。
【００８２】
受信マネージャRcvMgrがMgrCmdQをポップし、アームコマンドArmCd及びTcbIdを取り出す（行９５８）。ソケット受信キューがこのTcbIdのためにポップされるべきエントリを有している場合（行９５９）は、受信マネージャRcvMgrは、ファストコードFstCd及びTcbIdをFstEvtQに書き込むことによって、.そのイベントをそのTcbのためのSktRcvQからファストイベントキューFstEvtQへと転送する（行９６０）。一方、そのTcbのためのソケット受信キュー上にイベントが存在していない場合には、受信マネージャRcvMgrは、将来のいずれかの時点でこのTcbIdのための受信マネージャRcvMgrによって受信イベントが受信されたときファストパスイベントをソケットエンジンSktEngに送信するように、アームされた状態のままとなる。従ってソケットエンジンSktEngは行９２２に戻り、ファストイベントキューFstEvtQをモニタして、受信マネージャRcvMgrからそこに渡されるファストパスイベントを待つ。
【００８３】
［ソケットエンジンの状態］
図１０は、ソケットエンジンSktEngステートマシンの遷移する複数の状態を記載したものである。これらの状態には、アイドル（Idle）状態、SlwRcvEvt、SlwRcvO、EnbMrkEvt、DblMrkEvt、DblMrkO、FstRcvEvt、ClrMrkEvt、ClrMrkO、SktCmdEvt、SktCmdO、SktEnbCmd、SktEnbO、SktArmCmd、SktArmO、SktRcvCmd、SktRcvO、HdrDmaEvt、HdrEvtO、FastRcv、UpdMdlEntries、及びInitRcvがある。ソケットエンジンSktEngは現在の状態変数と着信する情報に基づいてある状態から他の状態へと進む。状態遷移はステートマシンを動作させるクロック信号の１クロック時間の立ち上がりエッジのタイミングのみに行われる。以下に記載された状態の定義に含まれる全ての動作は、その状態のなかで同時に発生する。
【００８４】
アイドル状態では、ステートマシンはやるべきことを探している。スローイベントキューがポップして出されるスローイベントエントリを有する場合（即ちSlwEvtQRdyが真の場合）、行１００１−１００８に記載の動作が行なわれる。イベントコードEvtCdがゼロの場合、EvtCdはスローコードSlwCdであり、行１００２−１００９の動作が行なわれる。イベントＫ−ドEvtCdが１の場合、EvtCdはイネーブルコードEnbCdであり、行１０１１−１０１８の動作が行なわれる。イベントコードEvtCdがゼロでも１でもない場合、EvtCdはディスエーブルコードDblCdであり、行１０２０−１０２８の動作が行なわれる。イベントコードEvtCdは、ソケット検出器SktDetブロック２２によって上述のようにセットされる。アイドル状態に記載の”if then, else”ロジックとともに、SlwEvtQ {EvtCd}ビットのテストがデジタルハードウェアゲートによって実施される。
【００８５】
イベントコードEvtCdがゼロである場合（行１００１参照）、スローパスパケットの処理はホストに渡される。符号Estate、EtcbId、EcmdAd、EhdrCd、EhdrCd、EhdrAd、EbufId及びEpkLenの前のＥはソケットステートマシン内のローカルレジスタを示す。エンジン状態Estateは、ソケットエンジンが次にうつる先の状態を示す。従って、Estateはスローパス受信イベントを扱うための状態であるSlwRcvEvtである。SlwEvtQからポップされたエントリから抽出されたTcbIdはEtcbIdに書き込まれる。同様に、SlwEvtQからポップされたエントリから抽出されるヘッダHdrCdの長さ、受信バッファ番号Bufld及び受信バッファ長は、それぞれEhdrCd、EbufId、及びEpkLenにロードされる。ソケットエンジンが間違いなくパーズヘッダ、ＭＡＣヘッダ、ＩＰヘッダ、及びＴＣＰヘッダを読み出しできるようにHdrCdはヘッダの大きさがどの程度かを示す、受信パーザRcvPrsブロック２１によって生成されるコードである。図１０では、値”ｘ”がドントケア（値が決められていないこと）を表す。”ｘ”を使用することによって、ハードウェア記述コードをロジックゲートの形に合成して、得られるハードウェアを単純化するハードウェアシンセサイザを利用可能となる。EvtCdがゼロである場合の開始−終了セクション内での全ての割り当ては、１クロックトランザクションで生ずる。
【００８６】
EvtCdが１である場合（即ちEnbCdである場合）、スローイベントはイネーブルマークイベントである（行１０１０参照）。イネーブルマークイベントでは、ソケットエンジンSktEngで受信されているパージマーカEnbCdが、ソケットエンジンSktEngに対して、ソケットエンジンがその記述子をこれ以上受け取らないであろうことを知らせる。これは、表示されたコネクションのための記述子がコネクションハンドアウトの第１段階で保持されていることからである（Dscインポート）。従って、Estateは、イネーブルマークイベントを扱うための状態であるEnbMrkEvtでロードされる。他の”E”値は、上述のようなイベントコードがゼロの場合と同様にロードされる。EvtCdが１である場合の開始−終了セクション内での全ての割り当ては、１クロックトランザクションで生ずる。
【００８７】
EvtCdが０でも１でもない場合（即ちEblCdである場合）、スローイベントはディスエーブルマークイベントである（行１０１９参照）。エンジン状態Estateは、ディスエーブルマークイベントを扱うための状態であるEblMrkEvtがロードされる。
【００８８】
SlwEvtWRdyが真でない（スローイベントキューからポップして出されるスローイベントが存在しない）が、FstEvtQRdyが真である（ファストイベントキューからポップして出されるエントリが存在する）場合、ソケットエンジンSktEngはFstEvtQをポップし、イベントコードEvtCdが抽出されてチェックされる（行１０２９参照）。
【００８９】
抽出されたEvtCdがゼロである場合（行１０３０）、ファストイベントはファスト受信イベントであり、行１０３０−１０３８の動作が行なわれる。従って、Estateはファスト受信イベントを扱うための状態であるPstRcvEvtがロードされる。”Ｅ”値は示されたようにロードされる。
【００９０】
抽出されたEvtCdがゼロでない場合、ファストイベントはクリアマークイベントであり、行１０４０−１０４７の動作が行なわれる。従ってEstateはクリアマークイベントを扱うための状態であるClrMrkEvtがロードされる。”Ｅ”値は示されたようにロードされる。
【００９１】
SlwEvtQtRdy及びFstEvtQRdyの両方が偽の場合、HstEvtQRdyがチェックされる（行１０４９参照）。HstEvtRdyが真の場合、HstEvtQからエントリがポップされ、行１０５０−１０５６の動作が行なわれる。Estateはホストコマンドが扱われる状態であるSktCmdEvtがロードされる。ポップされたエントリから抽出されたTcbIdをEtcbIdに保存することに加えて、ホストメモリにおけるコマンドのアドレスがポップされたエントリから抽出され、EcmdAdに格納される。これによって、ＮＩＤ４上のＤＭＡコントローラブロック２５がホストメモリからのコマンドの取り出しと、処理のためのコマンドのＮＩＤ４へのロードとを行うことが可能となる。
【００９２】
SlwEvtQRdy、FstEvtQRdy、及びHstEvtQRdyが全て偽である場合、HdrEvtQRdyがチェックされる（行１０５８参照）。HdrEvtQRdyが真である場合、HdrEvtQがポップされる。Estateには、HdrEvtQからのエントリが扱われる状態であるHdrDmaEvtがロードされる。”Ｅ”値は示されたようにロードされる。
【００９３】
SlwEvtQRdy、FstEvtQRdy、HstEvtQRdy、及びHdrEvtQRdyが偽の場合には、実行されるべきイベントは存在せず、行１０６７−１０７５上の動作が行われる。
【００９４】
Estateには、次の状態がアイドル状態のままであるように状態Idleがロードされる。従って、ソケットステートマシンはアイドル状態で扱うイベントを探すチェックを継続する。
【００９５】
ソケットエンジンSktEngがアイドル状態にあり、SlwEvtQRdyが真になった場合、行１００２のために状態はスローパス受信イベント状態SlwRcvEvtになり、この状態では行１０７８−１０８３の動作が行われる。値EstateにはSlwRcvOがロードされ、次の状態がSlwRcvO状態となる。使用されていないホストメッセージバッファはMsgBufQから取り出され、このアドレスはEmsgAdにロードされる（行１０７９）。これによって、ソケットエンジンSktEngがスローパスパケットをホストに渡すために用いるであろう、ホストメモリ内のメッセージバッファを特定する。EbufIdは左方向に１１ビットシフトされ（行１０８０）、スローパスパケットを含む対応する２ｋ受信バッファのＤＲＡＭアドレスを生成する。その受信バッファアドレスは、ＤＲＡＭアドレスDrmAdとしてロードされる。
【００９６】
図１１は、ホストにおけるメッセージバッファを示す図である。メッセージアドレスMsgAdはホストメモリの開始を指し示す。行１０８１において、メッセージの長さMsgHdLenがメッセージアドレスMsgAdに加えられ、HstAdが得られる。HstAdは、ホストのメッセージバッファにおいてメッセージデータMsgDatが始まるアドレスである。行１０８２では、スローパスパケットEpkLenの長さがHstSz内にロードされる。ソケットエンジンSktEngは、受信バッファｔｏホストＤＭＡコマンドR2hCdをDMAコントローラブロック２５へ開始することによって、全スローパスパケットを、ＮＩＤ４上のＤＲＡＭにおける受信バッファからホスト上のメッセージバッファへ移動させる。R2hは“受信バッファｔｏホスト（受信バッファからホストへ）”を意味する。ＤＭＡコントローラブロック２５は値HstAd及びHstSzを用いてＤＭＡ操作を行う。ホストメモリへの書き込みは、ホストメッセージバッファ内のメッセージデータが始まる位置から始まる。行１０７８−１０８３の開始−終了セクション内での全ての操作は１つのクロック時間で生ずる。
【００９７】
次に処理は、行１０８５におけるスローパス受信ゼロ状態（SlwRcvO）に進む。この状態では、ソケットエンジンがスローパス受信メッセージSlwRcvMsgをエンジンｔｏホストバッファE2hBufに入れる。このメッセージは、ホストに受信されたとき、そのホストに対して、スローパス受信イベントデータがホストの汎用メッセージバッファの１つに入れられたこと、及びホストスタックがその着信データを処理する必要があることを知らせるものである。メッセージが配置されるホスト内のアドレスがセットされ（行１０８８）、同様にメッセージの長さもセットされる（行１０８９）。ソケットエンジンSktEngは、ＤＭＡコントローラ２４のためのエンジンｔｏホストコマンドE2hCdをHstDmaCmdレジスタに入れることによって（行１０９０）、メッセージをE2hBufからホストに転送させる。スローパスパケットはＮＩＤ４のＤＲＡＭ受信バッファからホスト上のメッセージバッファに移動されたとき、EBufIdで特定される受信バッファは他の受信イベントによる使用のために使用されていない状態にされ得る。従ってEbufIdは、使用されていない受信バッファキューRcvBufQにプッシュされる（行１０９１）。次のクロックでは、EstateにIdleがロードされるので処理がアイドル状態に戻る（行１０８６）。
【００９８】
ホストがコマンドをＮＩＤ４に向けて発した場合には、ホストイベント記述子エントリがホストイベントキューHstEvtQに存在することになる。ホストイベント記述子は、ホスト上のメモリにおけるホストコマンドを指定するポインタCmdAdを含む。ホストイベント記述子は、ホストコマンドが関連するTcbIdも含む。ホストがコマンドをＮＩＤ４に向けて発した場合には、ソケットエンジンSktEngがそのアイドル状態になり、HstEvtQRdyが真であることを検出する（行１０４９）。次の状態はホストコマンドイベント状態SktCmdEvtにセットされる（行１０５０）。ソケットエンジンSktEngは、ホストイベントキューHstEvtQをポップし、ポインタCmdAd及びTcbIdを抽出し、行１０５１及び１０５２に示すようにこれらの値を格納する。SktEngはホストコマンドイベント状態SktCmdEvtに進む（行１１３７−１１４１参照）。
【００９９】
ホストコマンドイベント状態SktCmdEvt（行１１３７）では、ホストイベントキューからのホストコマンドがＮＩＤ４に読み出される。次の状態はSktCmdO状態にセットされる。ホストコマンドが配置されるホスト上の開始アドレスは、値EcmdAdをHstAdにロードすることによってセットされる（行１１３９）。移動される情報の量を示すために、全てのホストコマンドについて常に同一であるヘッダ長定数CmdHdLenがHstSzにロードされる（行１１４０）。ホストＤＭＡコマンドHstDmaCmdにホストｔｏエンジンコマンドH2eCdをロードすることによって（行１１４１）、ＤＭＡコントローラブロック２５はホストｔｏＮＩＤ転送を行うように指示される。ＤＭＡコントローラはホストコマンドをH2eBuf内に移動させる。
【０１００】
ソケットエンジンSktEngは、ホストコマンドのコマンドコードCmdCdが検出されるSktCmdO状態に進む。ＮＩＤ４内に読み出されたこのホストコマンドは、次の３種類のコマンド即ち、（１）ソケットイネーブルコマンド、（２）アームコマンド、及び（３）ソケット受信コマンドSktRcvCmdのうちの１つであり得る。ソケットエンジンコマンドSktEnbCmdはＮＩＤ４に対して、そのソケットのためにパケットの保持を開始するように指示し、パージマーカをホストに戻す。ソケットアームコマンドSktArmCmdは、ＮＩＤ４がソケットの状態を制御・更新できるように、ＮＩＤ４に対して、ホストからソケット状態を取り出して、それをＮＩＤ４にロードするように命ずる。Estateは、ホストコマンド内のコマンドコードまたはその値に応じて適切な次の状態をロードされる。
【０１０１】
SktEnbCmd状態（行１１５３−１１５９）では、コネクションハンドアウトの第１段階を実行するためにソケット記述子がソケット記述子バッファSktDscBufに書き込まれる。これを行うため、EtcbIdにソケット記述子の長さが乗ぜられる。SktDscBufにおけるソケット記述子の長さは定数値である。メモリ内には４ｋの記述子バッファが存在する。これらの２つの値の積は、SktDscBufにおけるソケット記述子の開始アドレスDscBufAdである。これはロードされるソケット記述子のための宛先である。
【０１０２】
ソケット記述子の発信元はホスト上のTcbバッファである。ＮＩＤ４にＤＭＡ転送されたホストからのコマンドヘッダは、H2eBufからアクセスされて、ホストによってそこに置かれたコマンドTcbAdをコマンドから抽出する。このTcbAdはホスト上のTcb bufferの開始点を指し示す。ホスト上のホストTcbバッファは異なる複数のセクションを有し、そのなかの１つはソケット記述子を含む。従って、不変の定数SktDscIxがTcbAdに加えられて、ホストTcbバッファ内でソケット記述子が配置されるホスト上の開始アドレスHstAdが決定される。SktDscIxは、ホスト上のTcbバッファのフォーマットによって決定される定数値である。ソケット記述子のサイズSktDscLenはHstSz内にロードされて、ホストTcbバッファから移動する情報の量をセットする（行１１５７）。次にＤＭＡ移動コマンドが発せられ、ホストｔｏ記述子コマンドH2dCdをHstDmaCmd上に書き込むことによって（行１１５８）、ソケット記述子がホスト上のTcbバッファからＮＩＤ４上のソケット記述子バッファに移される。
【０１０３】
状態SktEnbO（行１１６０）では、ソケットエンジンSktEngが、EnbCdコマンドをEtcbIdとともにでくタコマンドキューDetCmdQに入れることによって、ソケットイネーブルコマンドをソケット検出器ブロック２２に送信する。このソケットイネーブルコードEnbCdは、ソケット検出器に、着信パケットと今ロードしたソケット記述子とをマッチングさせる試みを開始させる。ソケット検出器ブロック２２は、DetCmdQからEnbCdコマンドを取り出すと、TcbIdのためのEnbCdコードを調べ、そのTcbIdのためのパージマーカを検出イベントキューDetEvtQにプッシュする。TcbIdのパージマーカを受信したことに応じて、受信マネージャRcvMgrは、そのソケット受信キューSktRcvQにおいてこのTcbIdのための後続のパケットの保持を開始し、かつソケットエンジンSktEngへのパージマーカをスローイベントキューSlwEvtQを介して送信する。このパージマーカは、ソケットエンジンSktEngに対して、このTcbId上で受信された後続のパケットがソケット受信キューSktRcvQにおける受信マネージャRcvMgrによって保持されていることを知らせる。次の状態はアイドル状態にセットされる（行１１６１）。
【０１０４】
従って、ソケットエンジンSktEngはスローイベントキュー上のイベントを検出するが、今回に限って、そのイベントコードEvtCdは、パージマーカがスローイベントキュー上でソケットエンジンSktEngによって受信されたことを示すもの（行１０１０参照）である。次にソケットエンジンSktEngは、ホストがコネクションハンドアウトの第１段階が終了したことを認識するように、パージマーカをホストに戻す。従って、Tcb番号が保存され（ライン１０１２）、次の状態がイネーブルマークイベント状態EnbMrkEvtにセットされる（行１０１１）。
【０１０５】
EnbMrkEvt状態（行１０９３−１１０１）では、ソケットエンジンSktEngは使用されていないメッセージバッファアドレスを、使用されていないメッセージバッファキューMsgBufQから取り出す（行１０９６）。このメッセージバッファアドレスはHstAdにロードされ（行１０９８）、移動すべき情報の量がセットされる（行１０９９）。ソケットエンジンSktEngはイネーブルマークメッセージEnbMrkMsgをエンジンｔｏホストバッファE2hBufに書き込む（行１０９７）。ＮＩＤ４上のE2hBufからホスト上のホストメッセージバッファへのイネーブルマークメッセージのＤＭＡ移動は、エンジンｔｏホストコードE2hCdをHstDmaCmd内にロードすることによって開始される。次にＤＭＡコントローラ２５はE2hBufからホスト上のメッセージバッファへイネーブルマークメッセージを移動させる。このホストはホストメッセージバッファにおけるメッセージを調べ、そのメッセージがイネーブルマークメッセージであることを判定し、これによってコネクションハンドアウトの第１段階が終了したことを知り、かつ現時点でそのホストがコネクションハンドアウトの第２段階においてＴＣＰ状態をＮＩＤ４に転送可能であると決定する。
【０１０６】
）行１０９５により、ソケットエンジンSktEngはアイドル状態に戻る。ホストはHstEvtQを介してホストコマンド（ソケットアームコマンド）をＮＩＤ４に送信し、コネクションハンドアウトの第２段階を実行する。従って、ソケットエンジンSktEngはHstEvtQRdyを検出し（行１０４９）、ホストコマンドのTcbIdをEtcbId内に保存し、かつホストメモリ内のホストコマンドへのポインタCmdAdをEcmdAdに保存する。行１０５０を介して、処理はホストコマンドイベントSktCmdEvt状態に進む。行１１３７−１１４２の動作が発生する。ＤＭＡシーケンサブロック２５はホストメッセージバッファからE2hBufへホストコマンドを転送する。ホストコマンドのコマンドコードCmdCdが状態SktCmdOでデコードされたとき、コマンドコードCmdCdはソケットアームコマンドを示すものである。行１１４７では、SktArmCmdがEstateにロードされ、処理はソケットアームコマンド状態SktArmCmdに進む（行１１６４−１１７１）。
【０１０７】
状態SktArmCmd（行１１６５）では、ＮＩＤ４がそのコネクションのためのファストパスパケットを処理するべくアームされ得るように、そのコネクションのためのホスト上のソケット状態がＮＩＤ４上の適当なTcbBuf内にロードされる。ソケット状態が入れられるＮＩＤ４上のTcbバッファのアドレスTcbBufAdは、EtcbIdにTcbバッファ長TcbBufLenを乗ずることによって求められる（行１１６７）。ホスト上の正しいTcbのソケット状態を指し示すポインタは、固定オフセット値をホスト上のTcbバッファのアドレスTcbAdに加えることによって決定される。このオフセットは、ホスト上のTcbバッファの開始点とバッファのソケット状態（ソケットタプル）の開始位置との間の固定オフセットである。得られたポインタ（ホストのTcbバッファのソケットタプルを指し示す）はHsdAdにロードされる（行１１６８）。ソケットタプルのサイズSkTplLenはHstSzにロードされる（行１１６９）。次にＤＭＡ移動が開始されて、ホストｔｏソケットタプルコマンドH2tCdをＤＭＡコントローラ２５に向けて発することによって、ソケットタプルをホストからＮＩＤ４に移動させる。このコマンドは、ホストｔｏソケットタプルコマンドH2tCdをHstDmaCmdにロードすることによって発せられる。処理はSktArmO状態に進む。
【０１０８】
SktArmO状態（行１１７２）において、アームコード（ArmCd）はMgrCmdQ を介して受信マネージャRcvMgrに送信される（行１１７４）。このことは、ソケットエンジンに、このコネクションで取り扱うべき１つのファストパスイベントを送信させるべく受信マネージャをアーム（arm）する。ArmCdは２ビットでEtcbIdは１２ビットである。従って、マネージャコマンドキューMgrCmdQは１４ビットである。コネクションハンドアウトの第２段階はここで終了する。ソケット状態の制御はＮＩＤ４に渡されている。一旦アームコードArmCdがソケットエンジンから受信マネージャに渡されると、受信マネージャはこのコネクションのための１つのイベント記述子をファストイベントキューFstEvtQに入れることができる。
【０１０９】
ソケットエンジンはアイドル状態にある。受信マネージャRcvMgrブロック２３がFstEvtQ上にファストイベント記述子入れると、FstEvtQRdyが真となる。ファストイベントキューからポップされたファストイベント記述子におけるイベントコードEvtCdはゼロであり（行１０３０）、このことは、これがファストパス受信イベントであること意味している。TcbId及びヘッダバッファポインタHdrIdは、ファストイベント記述子から抽出される（行１０３２及び１０３５）。ソケットエンジン処理は次の状態のFstRcvEvtに進む（行１１１４−１１１８）。
【０１１０】
ファストパス受信イベント状態FstRcvEvt（行１１１４−１１１８）では、次の状態がアイドル状態にセットされ、ソケットエンジンSktEngがコマンドをMgrCmdQを介して受信マネージャに発して（行１１１７）、ファストパスパケットのヘッダをそのTcbIdのヘッダバッファHdrBuf内に入れる。これを行うために、適当なリクエストコマンドReqCd、TcbId、及びパケット識別子BufldがマネージャコマンドキューMgrCmdQ内にロードされる。BufIdはＤＲＡＭ内のパケットの位置を記述する。受信マネージャRcvMgrはEtcbIdを用いて、SktRcvQにおける正しいソケット受信キューを特定し、示されたコネクションのための次のイベント記述子をそのキューから引き出し、そのイベント記述子を用いて、パケットヘッダを（Buildによって特定された）ＤＲＡＭ受信バッファから、そのTcbIdのヘッダバッファHdrBuf内にＤＭＡ移動させる。それによってヘッダバッファに入れられるヘッダは、パーズヘッダ、リンクヘッダ、ＴＣＰ及びＩＰヘッダである。この時点でヘッダがヘッダバッファにあることをソケットエンジンSktEngに警告するために、受信マネージャRcvMgrはヘッダイベントキューHdrEvtQにヘッダイベントエントリを入れる。このエントリはTcbIdを示す。
【０１１１】
ソケットエンジンはアイドル状態に戻る。受信マネージャRcvMgrの動作により、ヘッダイベントはヘッダイベントキュー上にあり、HdrEvtQRdyは真となる。従って、ソケットエンジンは行１０５８−１０６６の動作を実行する。TcbIdはヘッダイベントキューHdrEvtQエントリから抽出され（行１０６０）、次の状態はHdrDmaEvt状態にセットされる（行１０５９）。
【０１１２】
HdrDmaEvt状態（行１１９０−１１９７）では、次の状態がHdrEvtOにセットされる。パケット長は、ヘッダバッファHdrBufのパーズヘッダから抽出され（行１１９６）、EpkLenに保存される。パケットペイロードデータが格納されているＭＲＡＭの受信バッファは、Ebuffdにも格納される（行１１９５）。ファストパス受信パケットにのせられて入ってくる情報とともに受信・送信ウインドウの現在状態を処理するためのフラッシュ検出操作FlushDetも行われる。
【０１１３】
上述のように、スローパスでは、パーズヘッダとメッセージヘッダとを有する受信パケットがメッセージバッファ内に入れられて、メッセージバッファ機構を介してホストに渡される。ファストパスでは、全てのＴＣＰ及びＩＰプロトコル処理がＮＩＤ４上で行われ、ペイロードデータのみがホスト上のＭＤＬ空間に入れられる。それでもなお、ホストは、ペイロードデータがＭＤＬに供給されたことをＮＩＤ４から通知される必要がある。この通知は、同じメッセージバッファ機構を介してホストに送信される。従って、ソケットエンジンSktEngは使用されていないメッセージバッファキューMsgBufQから使用されていないバッファアドレスを取り出し、このメッセージバッファアドレスが保存される（行１１９３）。
【０１１４】
処理はヘッダイベントゼロ状態HdrEvtOに進む（行１１９８−１２１６）。HdrEvtO状態では、フラッシュが検出された場合（Eflushが真の場合）、動作の１組が行われる（行１１９９−１２００）。フラッシュが検出されず、そして満たされるべきTcbのためのＭＤＬエントリが存在する場合には、行１２０２−１２０８の動作が行なわれる。フラッシュが検出されず、かつ満たされるべきTcbのためのＭＤＬエントリが存在しない場合には、行１２０９−１２１６の動作が行なわれる。フラッシュ条件が検出されないが、有効なＭＤＬエントリが存在しない状態は、ファストパスマルチパケットメッセージの第１パケットの受信時である。そのような場合、ＮＩＤ４は、パケットペイロードを入れるべきホストメモリ内の位置が分からず、その後TcbのMdlVdビットが偽となる。
【０１１５】
この実施例では、受信したファストパスパケットはマルチパケットメッセージの第１派えっとであり、TcbBufにはまだそのファストパスコネクションのためのＭＤＬエントリが存在しない。従って、行１２０９−１２１６の動作が行なわれる。
【０１１６】
次の状態はInitRcv状態（行１２１０）であり、第１ファストパスパケットはホストの汎用メッセージバッファ内に送信される。パケットを移動させるために、ＤＲＡＭ受信バッファのアドレスは、Ebuffdを１１ビット分シフトさせることによって決定される（行１２１１）。パケット長EpktLenはHstSz内にロードされる。パケットペイロードデータは、ホストアドレスEmsgAdとメッセージヘッダ長MsgHdLenの合計であるホスト上の或るアドレスに転送されることになる。これはメッセージヘッダの終わりにパケットデータペイロード入れるということである。ＤＭＡ移動は、受信バッファｔｏホストコマンドR2hCdをHstDmaCmd上に入れることにより開始される。これは、そのパケットをホストメッセージバッファを介してスローパスパケットのようにホストに供給されるようにするが、この初めのファストパスパケットの場合は異なる種類のメッセージヘッダ（受信リクエストメッセージヘッダ）が用いられる。このメッセージヘッダは、ホストスタックに対して、このコネクションで受信された後続のファストパスパケットのさらなるデータペイロードをどの位置に入れるべきかを示すＭＤＬリストをアプリケーションから取得するように指示する。
【０１１７】
従って、次の状態は受信リクエストメッセージがホストに送られる初期状態InitRcvである（行１２３２）。この受信リクエストメッセージは初期ファストパスパケットを含む。
【０１１８】
ホストはそのメッセージバッファから受信リクエストメッセージを取得し、（初期ファストパスパケットである）そのパケットのデータ部分を処理し、かつその初期ファストパスパケットをアプリケーションプログラムに供給する。ＴＣＰプロトコル層を含む、以下の全てのプロトコル処理はＮＩＤ４によって実行される。アプリケーションプログラムはそのコネクションのためのＭＤＬリストを戻す。ホストスタックは、適切なTcbのためTcbホストバッファ内にＭＤＬリストを書き込む。ＭＤＬとＭＤＬリストは、この時点ではＮＩＤ４に対してやりとりされていない。ＭＤＬエントリをＮＩＤ４とやりとりさせるために、ホストはホストメモリにホストコマンドを形成する。次にホストは、ホストメモリ内のホストコマンドが入れられた位置を示すポインタCmdAdをHstEvtQにプッシュする。
【０１１９】
次に、ソケットエンジンはアイドル状態に戻るが、このときそのパケットエンジンのためのHstEvtRdyが存在する。行１０５０−１０５７の動作が行われる。ソケットエンジンはHstEvtQからエントリをポップし、そのエントリからコマンドポインタCmdAd及びTcbIdを抽出する。次の状態はSktCmdEvtにセットされる。
【０１２０】
SktCmdEvt（行１１３６−１１４２）では、ソケットエンジンがＤＭＡコントローラブロック２５に、ホストコマンドをホストからH2eBufに移動させる（行１１４１参照）。SktCmdO状態では、H2eBufのなかのホストコマンドが調べられ、コマンドコードCmdCdがデコードされる。ここで、そのコマンドはSktEnbCmdでもなければSktArmCmdでもない。従ってSktEng処理（行１１５０）は、ソケット受信コマンド状態SktRcvCmdに進む。
【０１２１】
SktRcvCmd状態（行１１７６−１１８３）では、ＭＬＤリストの第２のＭＤＬエントリ（ApDscと呼ばれる）を、ホスト上のTcbバッファからＮＩＤ４上のTcbIdのためのTcbBufの適当なフィールドにロードされる。ホスト上のＭＤＬエントリが配置された発信元アドレスは、アプリケーション記述子オフセットApDscIxをホストのTcbバッファ内の開始アドレスに追加することによってセットされる（行１１８０）。Tcbバッファからホストへ移動する情報の量は、定数ApDscLenにセットされる（行１１８１）。そして、ＭＤＬエントリの移動のための宛先がセットされる（行１１７９）。ＮＩＤ４のTcbバッファの開始アドレスは、TcbId数にTcbバッファの長さTcbBufLenを乗じたものである。次にTcbバッファ内のＭＤＬエントリに対するオフセットApDscIxを開始アドレスに加えて、ＭＤＬエントリが書き込まれる宛先アドレスを求める。次にソケットエンジンSktEngは、ＤＭＡコントローラ２５に、ホストｔｏソケットタプルコマンドH2tCdをHstDmaCmdに入れることによってＭＤＬエントリをホストメモリからＮＩＤ４上のTcbBufに移動させるようにする。
【０１２２】
次に、状態SktRcvOにおいて、受信ウインドウTcbBuf {RSqMx}がインクリメントされる（行１１８６）。ホストは、データがアプリケーションによって消費されると、受信シーケンスを動かすことによってウインドウサイズを変更させる。ホストは我々にどの程度ウインドウを変化させることが可能であるかを知らせる。我々はTcbBufに進み、受信シーケンス最大値RSqMxを引出し、コマンドh2eBuf {SqInc}においてホストによって示された量を加え、更新値を新たな受信シーケンス最大値TcbBuf {RSqMx}としてTcbバッファTcbBufに戻す。（RSqMxはRcvSqLmtと表記されることもある。）フレームの送信に関連するハードウェアが存在し、そのハードウェアはウインドウ情報の一部を、我々にデータを送信した者に送信して、その送信者にどの程度の量のデータを送信者が我々に送信できるかを知らせ、我々はその送信者にウインドウサイズを知らせることによってそれを行い、そのウインドウサイズは部分的にこの受信シーケンスリミットから導き出される。従って、送信者が入ってくるこの情報を見れば、どの程度の量のデータを我々が受信できるかが分かる。従って、我々は受信シーケンスリミットを更新し、アイドル状態に戻る。
【０１２３】
ここでＭＤＬエントリがＮＩＤ４上のTcbBuf内に存在していることから、Tcbバッファ内のMＤＬ有効ビットがセットされる（行１１８８）。次にファスト受信イベントが生じたとき、既に有効ＭＤＬが存在しているので、Tcbバッファ内のＭＤＬ有効ビットはセットされ、ホストからＭＤＬエントリを取り出す初期受信シーケンスを通さずに、ファスト受信シーケンスを通して処理を進めることになる。
【０１２４】
ソケットエンジンSktEngはアイドル状態に戻る。受信マネージャRcvMgrがアームされている（armed）ことから、そのコネクション上の第２ファストパスパケットのための受信イベント記述子は、受信マネージャRcvMgrからファストイベントキューFstEvtQを介してソケットエンジンSktEngにフォワーディングされる。ソケットエンジンはFstEvtQRdyが真でり、イベントコードEvtCdがゼロであることを確認し、上述のTcbIdを抽出するプロセスを行い、FstRcvEvt状態に進む（行１１１５−１１１８）。ファストパス受信イベント状態FstRcvEvtでは、ソケットエンジンがMgrCmdQを介して受信マネージャに対して、TcbIdによって特定される第２のファストパスパケットのヘッダを供給するように命令し（行１１１７）、次いでアイドル状態に戻る。ヘッダはヘッダバッファHdrBufを通してソケットエンジンに進み、受信マネージャRcvMgrはそのTcbのためのヘッダイベントをHdrEvtQに入れる。
【０１２５】
ソケットエンジンSktEngはアイドル状態にあり、HdrEvtQRdyを検出し、そして行１０５８−１０６６の動作を行う。ヘッダイベントキューからのTcbIdはEtcbIdに保存される（行１０６０）。EtcbIdはソケットエンジンにとってローカルなレジスタである。TcbIdをEtcbIdにロードすることによって、TcbIdによって特定された特定のTcbバッファの全てのビットがソケットエンジンに利用可能となる。特定されたTcbバッファの全てのビットは一度に利用可能となる。
【０１２６】
ヘッダバッファポインタHdrIdはEhdrAd内に保存される（行１０６３）。EhdrAdはソケットエンジンにとってローカルなレジスタである。ヘッダバッファポインタをEhdrAdにロードすることによって、HdrAdで特定された特定のヘッダバッファHdrBufの全てのビットがソケットエンジンに利用可能となる。特定されたヘッダバッファの全てのビットは一度に利用可能となる。
【０１２７】
次に、HdrDmaEvt状態において（行１１９１−１１９７）、（EhdrAdtheによって特定されたヘッダバッファによる出力としての）ヘッダのビット及び（EtcbIdによって特定されたTcbバッファの出力としての）Tcbのビットを用いて、フラッシュ検出FlushDetテストを行う（行１１９４）。フラッシュイベントが存在しないと仮定すると、ソケットエンジンはHdrEvtOに遷移する。今回はMdlVd [ETcbId]が真であり（初期受信がこの状態を通して渡されるのとは異なる）、従ってＮＩＤ４はデータペイロードがホスト内のどこに入れられるべきかを認識している。バッファIdが１１ビットシフトされて、ＤＲＡＭ受信バッファ内のパケット開始位置が求められ、パケットヘッダをスキップして実データのところに進む（行１２０４）。このアドレスDrmAd,はホストに移動されるデータペイロードの発信元である。ホスト上の宛先アドレスHstAdのために、ＮＩＤ４に格納されたアプリケーション記述子ApDsc（即ちＭＤＬエントリ）が用いられる（行１２０５）。移動するペイロードデータの量は、パケット長EpkLenからヘッダの量HdrLenを差し引いた量である。ＮＩＤ４上のＤＲＡＭ受信バッファからＭＤＬエントリによって特定されたホスト上のアドレスへのパケットペイロードの移動は、受信バッファｔｏホストコマンドR2hCdをHstDmaCrndにプッシュすることによって開始される。ＤＭＡシーケンサブロック２５はこの移動を実行する。
【０１２８】
一旦データペイロードがホスト上にコピーされると、ソケットエンジンはファスト受信状態FastRcvに進む（行１２１７−１２２５）。この例では、ペイロードデータのＭＤＬエントリへの移動がＭＤＬエントリを全て使う。従ってファスト受信メッセージが準備されてホストスタックに送信され、ホストスタックに対して、特定のＭＤＬエントリが全て使われてそのホストの受信コマンドが終了したことを知らせる。（ここには示していないが、或る状態（図示せず）では、ＭＤＬエントリのバイトカウントが、データペイロードの移動量に従ってデクリメントされて、ＭＤＬエントリが全て使われたことを確認し、ＭＤＬエントリが全部使われた場合には、処理はFastRcv状態に進み、そうでない場合には、更新されたＭＤＬ値が元のTcbBufにロードされ、ソケットエンジンがアイドル状態に戻して別のファストパス受信イベントを探す。）ファスト受信メッセージFstRcvMsgは同じ上述のストメッセージバッファ技術を用いて渡される。ソケットエンジンは、ＤＭＡシーケンサ２５に、E2hCdコマンドをHstDmaCmdに入れることによって、メッセージをＮＩＤ４からホスト上メッセージバッファへと移動させる（行１２２２）。TcbBufに格納されたソケットにおけるコネクション状態はTplUpdに更新される（行１２２４）。このタプル更新TplUpd値は図６に記載されている。行１２２４のTplUpdは、Tcbバッファ値が以下の式、即ち
TcbBuf [TcbId] {ExpRcvSeq} < = TplUpd {NxtSeqExp}
TcbBuftTcbId] {XmtAckNum} < = TplUpd {PktXmtAck}
TcbBuf [TcbId] {XmtSeqLmt} < = TplUpd {NxtXmtLmt}
TcbBuf [TcbId] {XmtCcwSz} < = TplUpd{NxtXmtCcw}
に記載のように更新されることを示している。
【０１２９】
ここでソケットエンジンによるこの第２のファストパスパケットの処理は終了することから、ソケットエンジンは、受信マネージャRcvMgrを、そのコネクションのための別のイベント記述子を送信するべくアームする（行１２２５）。
【０１３０】
処理は状態更新ＭＤＬエントリUpdMdlEntriesに進む。ホストにより供給されたＭＤＬエントリが全部使われた場合、ＮＩＤ４上のTcbバッファにおけるＭＤＬ有効ビットはクリアされる（行１２２９）。次の状態はFastRcvにセットされる（行１２３１）。
【０１３１】
［コネクションフラッシュシーケンス］
図１２は、コネクション上でフラッシュ条件が検出された後にコネクションをＮＩＤ４からホスト３に渡す際の、図２に示す種々のハードウェアのブロックが行う動作を示した図である。ファストパス受信状態では、ソケットエンジンSktEngがファストパス受信イベント状態FstRcvEvtに入る）（図１０の行１１１４−１１１８参照）。ソケットエンジンSktEngは次の状態をアイドル状態にセットし（行１１１６）、受信マネージャRcvMgrにソケットエンジンにヘッダを共有するように指令する（行１１１７）。従って、ソケットエンジンSktEngはアイドル状態にあり、ヘッダイベントHdrEvtQRdyは真になる（行１０５８）。行１０５９のために、ソケットエンジンSktEngはヘッダＤＭＡイベントHdrDmaEvt状態になり（行１１９１−１１９７参照）、次いでHdrEvtO状態となる（行１１９８−１２１６）。そこでフラッシュ検出条件が検出されると（行１１９４）、１ビット値FlushDetがEflushにロードされる。Eflushは真であり（行１１９８）、次にHdrEvtO状態にあるとき、ソケットエンジンSktEngは”プッシュ”コードPshCd（行１２００）を受信マネージャのコマンドキューMgrCmdQにプッシュする。
【０１３２】
図１２を参照すると、受信マネージャRcvMgrはMgrCmdQをポップし（行１５０３）、プッシュコードPshCd及びTcbIdを取り出す。このプッシュコードは、受信マネージャRcvMgrがSktRcvQから最後の記述子をポップする効果を取り消させるようにする。プッシュコードPshCdは、RcvMgrがソケット受信キューSktRcvQのための読み出しポイントを、１つの記述子エントリに戻す形で”プッシュ”するようにする。そのTcbIdのためのソケット受信キューSktRcvQは読み出しポインタ及び書き込みポインタを有する。記述子がソケット受信キューSktRcvQからポップされたとき、その記述子は実際にメモリから消去されるわけではなくキューメモリに残され、次回にSktRcvQがキュー上の次のエントリが読み出されるように読み出しポインタが前に進められる。しかし、受信マネージャRcvMgrがプッシュコードPshCdを受信する場合、読み出しポインタは１つの記述子エントリにバックアップされ、前に進められない。以前にポップされた受信記述子はキューメモリ内に以前として残ってることから、読み出しポインタをプッシュバックすることで、最後にポップされた記述子がキューからポップされなかったのようにSktRcvQも元の状態に戻る。
【０１３３】
受信マネージャRcvMgrは、パージマーカClrCd及びTcbIdをファストパスイベントキューFstEvtQに書き込むことによって、ClrCdをそのTcbIdのファストパス受信記述子の流れに挿入することも行う。その後、ソケットエンジンがこのTcbIdのための受信記述子をファストパスイベントキューから出して処理したとき、ソケットエンジンはそのClrCdを検出する。ClrCdを検出することで、ソケットエンジンには、エラーによりそのTcbIdのためのファストパスイベントがこれ以上存在しないことが知らされる。しかし、パージマーカClrCdの前のファストパスイベントキューFstEvtQにおけるファストパスパケット記述子は、ファストパスで扱われる。パケットがFlushDetを真にする前にファストパスパケットをファストパスモードで扱うことで、フラッシュ条件の取り扱いにおける待ち時間が短縮される。
【０１３４】
受信マネージャRcvMgrはMgrBufにおけるイベントイネーブルビットEvtEnをクリアして（行１５０５）、ファストパス受信記述子がこれ以上受信マネージャRcvMgrからこのTcbIdのためのソケットエンジンに送信されないようにする。これで、コネクションフラッシュ動作の第１段階（ファストパスイベントパージ段階）が終了する。
【０１３５】
FstEvtQRdyが真であることが検出されるとき、ソケットエンジンSktEngはアイドル状態にある（行１０２９参照）。そのSktEngはファストパスイベントキューFstEvtQを読み出し（行１５０７）、イベントコードEvtCdを取り出す。イベントコードEvtCdはパージマーカClrCd（”クリアマークイベント”コードとも称する）である。このイベントコードがクリアマークイベントであることで、ソケットエンジンSktEngに対して、ファストパスイベント受信キューFstEvtQにおいて、TcbIdで特定されたコネクションのためのファストパス受信イベント記述子がクリアされていることを知らせる。TcbIdｈは、ファストパス受信キューFstEvtQからポップされたエントリから抽出される（行１０４１参照）。EvtCdがクリアマークイベントであることで、ソケットエンジンが状態ClrMrkEvtに遷移させられる（行１１２０−１１２８）。
【０１３６】
状態ClrMrkEvtでは、ソケットエンジンSktEngが、そのソケット検出器SktDetのための検出コマンドキューDetCmdQに、ディスエーブルコードDblCd及びEtcbIdを入れる（行１１２７）。ソケットエンジンSktEngは、そのClrMrkO状態で将来使用するために、メッセージバッファキューMsgBufQからメッセージバッファアドレスを得る（行１１２２）。ソケットエンジンSktEngは、そのコネクションの現在のソケット状態SkTplのTcbバッファTcbBuf [TcbId]からホストメモリのTcbバッファHstMem [TcbAd]への移動をセットアップする（行１５０８参照）。ソケットエンジンは、タプルｔｏホストコマンドT2hCdをHstDmaCmdに入れることによってこれを行う。ＤＭＡコントローラ２５はT2hCdを受け取り、ソケットタプル情報を示されたホストメッセージバッファに移動させる。さらなる詳細については図１０の行１１２０−１１２６を参照されたい。
【０１３７】
ソケットエンジンSktEngは状態ClrMrkOに遷移し、ホストに対して、ＴＣＰ状態情報を有するソケットタプルSkTplが、このコネクションのためのホストTcbバッファに戻されたことを知らせる。ソケットエンジンは、使用されていないメッセージバッファアドレスをMsgBufQから取り出し（行１５０９）、次いで状態エクスポートメッセージExportMsgをエンジンｔｏホストバッファE2hBufに書き込む（行１１３１）ことによって、これを行う。ＤＭＡ操作の宛先は、メッセージバッファアドレスEmsgAdにセットされる。ＤＭＡ転送の長さは、メッセージヘッダの長さMsgHdLenにセットされる（行１１３３）。次にソケットエンジンSktEngは、エンジンｔｏホストコマンドをHstDmaCmdに入れることによってＤＭＡを生じさせる（行１１３４）。次にＤＭＡコントローラ２５は、状態エクスポートメッセージをＮＩＤ４からホスト上のメッセージバッファへと移動させる。これで、コネクションフラッシュ操作の第２段階（ソケット状態保存）が終了する。
【０１３８】
コネクションフラッシュ動作の第３段階（ファストパスキューパージ）では、この後のパケットがホスト上のＴＣＰ処理のためにホストに渡されることから、ソケットエンジンSktEngがソケット検出器SktDetにこのTcbIdのためのパケットの検出を停止するように命ずる。状態ClrMrkEvtでは、ソケットエンジンSktEngがディスエーブルコマンドDblCd及びEtcbIdをソケット検出器コマンドキューDetCmdQに書き込む（図１２の行１５１１）。図１０の行１１２７も参照されたい。
【０１３９】
ソケット検出器SktDet２２は、検出器コマンドキューDetCmdQ上にディスエーブルコマンドDblCdを見つけるまで、このコネクション上のパケットの検出を行う。ディスエーブルコマンドDblCdはソケット検出器に、パケット検出を停止するように指示する。ソケット検出器SktDetはDetCmdQを読み出し（行１５１３）、ディスエーブルコマンドDblCd及び示されたTcbIdを得る。次にソケット検出器SktDetはTcbIdのためのソケット記述子バッファSktDscBufにおける検出イネーブルビットDetEnをクリアし（行１５１４）、パージマーカDblCdを検出イベントキューDetEvtQに書き込むことによってパージマーカをDblCdを受信マネージャRcvMgrに送る（行１５１５）。これによって、DblCdパージマーカの後に検出イベントキューDetEvtQにおいてそのTcbのために存在するものがファストパスになることはなく、ソケット検出器がそのTcbIdのためにディスエーブルにされていることからスローパスになるということが確実となる。DblCdパージマーカはDetEvtQを通して受信マネージャRcvMgrに流れる。受信マネージャRcvMgrはパージマーカDblCdとTcbIdを受信し（行１５１７）、SktRcvQからそのTcbIdのための全ての記述子を取り出し、それをスローイベントキューSlwEvtQに入れる（行１５１８−１５１９）。それを行ったとき、受信マネージャRcvMgrはパージマーカDblCdをスローイベントキューSlwEvtQに入れる（行１５２０）。
【０１４０】
一方、ソケットエンジンSktEngは、それがアイドル状態にあり、スローイベントキューSlwEvtQを読み出してパージマーカDblCdを取得するまで、SlwEvtQからスローパスイベントを引き出している（行１５２２）。図１０の行１０２０も参照されたい。ソケットエンジンSktEngはパージマーカDblCdを得ると、ソケットエンジンSktEngはDblMrkEvt状態に進む（図１０の行１１０３−１１０６）。パージメッセージはホストに送られて、ホストに、そのソケット検出器が該TcbIdのためにディスエーブルにされたことを知らせる。ソケットエンジンSktEngは、ホストからメッセージバッファアドレスを得て（行１１０５）、ディスエーブルマークメッセージをエンジンｔｏホストバッファに入れ（行１１０９）、次にＤＭＡコントローラ２５にエンジンｔｏホストコマンドE2hCdをHstDmaCmdに入れることで（行１１１２）メッセージをＮＩＤ４からホストに転送させることによって、この操作を行う。ホストがそのメッセージバッファ内にディスエーブルマークメッセージを見つけると、ホストは示されたソケット記述子がもう使用されていないこと、該TcbIdのためのソケット受信キューが空であること、そしてホストが異なるソケット記述子をソケット検出器SktDetに入れて、別のソケット上でのファストパス処理を可能とすることができることを知ることとなる。
【０１４１】
［フラッシュ検出］
上記のプロセスでは、１ビットのFlushDet値によって示されるフラッシュ条件の検出（行１１９４参照）が、ソケットエンジンSktEngステートマシンに供給されるクロック信号の１クロックサイクルに行われる。図１３乃至図１６には、フラッシュ検出FlushDetの決定方法が示されている。図１３乃至図１６では、イタリック体で表示された値がTcbIdにより特定された特定のTcbバッファTcbBuからの値であり、下線を付された値はHdrIdによって特定されたヘッダバッファHdrBufから出力される着信するパケットのヘッダからの値である。両方の種類の値（TcbBuf値とHdrBuf値）は、ソケットエンジンSktEngの上に受信される。イタリックTcbIdでもなく下線も付されていない値は、他の値からソケットエンジンSktEng内で求められた値である。
【０１４２】
FlushDet信号は、図１５の行1712-1713に示すように決定される。FlushDet信号は、現在ウインドウオーバーフローCurWinOvr ＯＲ（（ＮＯＴ予測シーケンス検出!ExpSeqDet）ＡＮＤ（ＮＯＴ前シーケンス検出!OldSeqDet））ＯＲ（次ウインドウ縮小NxtWinShr）ＯＲ（（ＮＯＴ転送ａｃｋ有効!XmtAckVld）ＡＮＤ（ＮＯＴ転送ａｃｋ前!XmtAckOld））の条件を満たす場合に真となる。図において縦線は論理ＯＲを示す。エクスクラメーションマークは論理ＮＯＴを示す。記号”＆”は論理ＡＮＤを表す。引用符は定められた定数を示す。”＝＝”は「〜と等しいならば（if equal to）」を意味する。Ａ？Ｂ：Ｃという形の式は、「ＡならばＢ、ＡでなければＣ」を意味する。記号”！＝”は「〜と等しくない」を意味する。記号”！＜”は「（右辺）以上」（not less than）を意味する。記号”！＞”は「（右辺）以下」（not greater than）を意味する。記号”＜＝”は、右辺の式の値を左辺に代入することを表す。記号”＜＜”は、左にシフトすることを示し、シフトの回数はこの記号の右の値で示される。
【０１４３】
例えば、現在ウインドウオーバーフロー値CurWinOvrは、RcvSeqLmt、NxtSeqExp、及びQuadrantから式１７０８で示されるように決定される１ビットの値である。RcvSeqLmt−NxtSeqExpが定数Quadrant以上である場合、現在ウインドウのオーバーランが存在し、CurWinOvrは１にセットされる。RcvSeqLmtはTcb Bufから得られる３２ビット値である。Tcbバッファの内容については図４及び図６を参照されたい。NxtSeqExpは、３２ビット値PktRcvSeqを減じ、それに１６ビット値PktPaySzを加えることによって計算される３２ビット値である。PktRcvSeqはヘッダバッファに格納される値である。値PktPaySzは、ヘッダバッファ値PktRcvSeq及びNxtSeqExpから得られる値である。Quadrantは１６進法で40000000である、３２ビットの値である。
【０１４４】
同様に、現在ウインドウオーバーラン値CurWinOvrは、図１３乃至図１６の式に従って計算され、行１７１２及び１７１３の式の右辺に現れる他の全ての値についても同様である。
【０１４５】
行１７１２の式（!ExpSeqSet & !OldSeqDet）は、パケットの３２ビットのシーケンス番号が先の時点でのシーケンス番号である場合に真となる。例えば二重パケットのような古いパケットは、予測シーケンス番号より小さい（即ち古い）シーケンス番号を有し得る。そのような古いパケットはフラッシュ検出を生じさせない。古いパケットは二重パケットであり得、そのような二重パケットはＮＩＤにコネクションのフラッシュを生じさせることなくホストに渡されることになるからである。そのような場合、ホストは、その選択に応じてコネクションの制御をホストに戻すことができる。従って、予測シーケンス番号より小さい（即ち古い）シーケンス番号を有するパケットを受信した場合、FlushDet信号は真とならない。パケットのシーケンス番号が予測シーケンス番号である場合には、そのパケットはそれが有するべきシーケンス番号を有しており、フラッシュ検出はなされない。一方、受信されたパケットが予測シーケンス番号より大きいシーケンス番号を有する場合には、そのパケットはそれが受け取られるべき時点よりも先に受け取られた将来の時点のパケットであり、エラーが生じている可能性が高い。従って、パケットのシーケンス番号が予測シーケンス番号でない場合で、かつシーケンス番号が古いシーケンス番号でない場合に、フラッシュ検出は真となる（行１７１２参照）。
【０１４６】
行１７１２の式で用いられている予測シーケンス番号検出値ExpSeqDetは行１７０３に示すように計算される。予測シーケンス番号検出値ExpSeqDetは、ヘッダバッファに格納されたパケットのシーケンス番号PktRcvSeqがTcbバッファに格納された予測受信シーケンス番号ExpRcvSeqと等しい場合に真となる。ExpRcvSeqは、そのコネクションで受信されるべき次のパケットのシーケンス番号である。パケットが受信されると、ExpRcvSeqはその前に受信されたパケットのデータペイロードの量だけ大きくされる。従って、次のExpRcvSeqを取得するには、現パケットのペイロードサイズPktPaySzがペットシーケンス番号PktRcvSeqに加えれられ、その合計が予測される次のシーケンス番号NxtSeqExpとなる。パケットペイロードPktPaySzの単位は、データのバイト数である。そのパケットが処理された後、NxtSeqExpはTcbバッファに格納される予測シーケンス番号ExpRcvSeqとなる。
【０１４７】
行１７１３の式NxtWinShrは、ＮＩＤ４からデータを受信したマシンがそのＴＣＰ受信ウインドウを縮小させた場合に真となる。ＴＣＰ受信ウインドウの縮小は、ＴＣＰプロトコルでは行われないようにされている。ＮＩＤ４からデータを受け取ったマシンは、ＮＩＤ４に送り返す次のパケットで、それが受け取ったデータのアクノリッジメントPktXmtAckを戻す。そのデータを受け取ったマシンは、戻しパケットにウインドウサイズPktXmtWinをも含める。ＮＩＤ４は戻しパケットを受け取り、前記２つの値を用いて他のマシンがその受信ウインドウを縮小しているか否かを決定する（行１６１８）。縮小ＴＣＰ受信ウインドウは、現在の送信リミットXmtSeqLmtが次の送信リミットNxtXmtLmtより大きいか否かを判定することによって検出される。
【０１４８】
現在の送信シーケンスリミットXmtSeqLmtは、ＮＩＤ４上のソケットタプルに格納されたシーケンス番号値である。ＮＩＤ４は、XmtSeqLmtシーケンス番号値を用いて、それが他のマシンに送信可能なデータ量を求める。他のマシンはこの値を制御するが、それを減らすことはできない。
【０１４９】
次の送信リミットNxtXmtLmtは、PktXmtAckをウインドウサイズPktXmtWinに加えることによりＮＩＤ４が決定する（行１６０６）。
【０１５０】
ＮＩＤが送信を許可されているNxtXmtLmtは、前にＮＩＤによる送信が許可された前の送信リミットXmtSeqLmtより小さい場合には、他のマシンはその受信ウインドウを縮小する。これは違反状態である。ＮＩＤ４は既にパケットを送信しており、ＮＩＤが送信したばかりのパケットが大きすぎることを通知するａｃｋを受け取ったとき、そのパケットは送信中であることが生じ得るからである。従って、次のウインドウ縮小NxtWinShrの値は、次の送信リミットNxtXmtLmtが前の送信リミットXmtSeqLmtより小さい場合に真となる。
【０１５１】
番号NxtXmtLmt及びXmtSeqLmtは、循環する、符号なしの３２ビットの数である。そのような符号なしの循環数どうしの比較は複雑なものとなり得る。行１６１８において、２つの符号なし数が、その２つの数同士の差と最大シーケンス番号（１Ｇ）の４分の１とを比較することによって比較されている。
【０１５２】
行１７１３の次の式（! XmtAckVld & ExmtAckOld）では、受信したパケットのアクノリッジ番号が将来のアクノリッジ番号であるか否かを決定するために、そのパケットのアクノリッジ番号をチェックしている。従って、この式は、受信したアクノリッジ番号が有効でなく（行１６１１参照）、かつそのアクノリッジ番号が古いアクノリッジ番号でない場合（行１６１２参照）に真となる。
【０１５３】
値FlushDetは、行１７１２及び１７１３に示すようにこれらの４つの式の論理ＯＲをとったものである。この論理ＯＲ演算は、ソケットエンジンSktEngに供給されるクロック信号の１クロック周期において組合せハードウェアロジックによって実施される。組合せハードウェアロジックへの入力として供給される値は、（１）EtcbIdによって特定されるTcbバッファTcbBufからの出力値、及び（２）EhdrAdによって特定されるヘッダバッファHdrBufからの出力値である。FlushDetを求めるために用いられる特定のTcbバッファ値は、（１）RcvSeqLmt（３２ビット）、（２）ExpRcvSeq（３２ビット）、（３）XmtSeqLmt（３２ビット）、（４）XmtAckNum（３２ビット）、及び（５）XmtSeqNum（３２ビット）である。FlushDetを求めるために用いられる特定のHdrBuf値は、（１）PktRcvSeq（３２ビット）（２）PktPaySz（１６ビット）、（３）PktXmtAck（３２ビット）、及び（４）PktXmtWin（１６ビット）である。
【０１５４】
図１３乃至図１６の式において、各論理演算子の演算は、独立したＡＬＵタイプのハードウェアデジタルロジックのブロックによって行われる。一例として、”＋”演算は、論理ゲートで構成されたデジタル加算器によって行われ得る。”−”演算は、デジタルゲートで構成されたデジタル減算器によって行われ得る。”＝”演算は、デジタルゲードによって構成されたデジタル比較器によって行われ得る。
【０１５５】
TcbBufは、特定の１つのTcbバッファの全ビットが同時に出力されるようにTcbのビット数と同じ幅を有するように編成されたデュアルポートメモリ構造である。なお、Tcbバッファはアドレス値EtcbIdによって特定される。図２の例では、TcbBufが２５６バイトの幅を有する。ＤＭＡコントローラ２５は３２ビット幅のポート及び複数の書き込みストローブを介してTcbBufに書き込みを行い、TcbBufは２５６バイト幅のポートを介してソケットエンジンSktEngにインタフェースする。
【０１５６】
HdrBufは、特定の１つのヘッダバッファのビット数と同じ幅を有するように編成されたデュアルポートメモリ構造である。なお、ヘッダバッファはアドレス値EHdrAdによって特定される。図２の例では、HdrBufが１２８バイトの幅を有する。ＤＭＡコントローラ２６は３２ビット幅のポート及び複数の書き込みストローブを介してHdrBufに書き込みを行い、HdrBufは１２８バイト幅の読み出し／書き込みポートを介してソケットエンジンSktEngにインタフェースする。
【０１５７】
［状態更新］
コネクション状態の更新は、Tcbバッファメモリのさまざまな場所への一連の値の書き込みとして順次Tcbバッファにおけるコネクション状態を更新するのでなく、ソケットエンジンSktEngステートマシンに供給されるクロック信号の１クロック時間で行われる。コネクション状態の更新は、図１０の行１２２４にあるように、全てのタプル更新TplUpd値（図６参照）が、EtcbIdで示されるコネクションのためのTcbバッファの適切なフィールドにロードされる。ロードされる値は、ソケットエンジンSktEngについての上記の説明及び図１０の行１２２４に記載されている。このタプル更新動作を容易にするため、Tcbバッファメモリ構造は、全てのTplUpdビットがTcbバッファに同時に並行して書き込まれるように、特定の１つのTcbバッファのビット数以上の幅を有するように編成される。
【０１５８】
［マルチスレッドソケットエンジン］
上述のソケットエンジンSktEngの説明では、ソケットエンジンがＤＭＡコントローラ移動をセットアップし、その移動は、次のステートマシンクロック時にその移動が既に生じているかのようにステートマシンが別の状態に遷移し得るように即座に生ずる。或る実施形態では、ＤＭＡコントローラ移動が終了するまでに、１つのステートマシンクロックサイクルより長い時間をかける。移動が完了するまで待機するソケットエンジンSktEngではなく、ソケットエンジンSktEngは、第１のスレッドを処理し、ＤＭＡコントローラには転送を行うように指示してＤＭＡコントローラが転送を完了するまで第１スレッドの処理を停止し、ＤＭＡコントローラが転送を行っている間に第２スレッドを処理し、ＤＭＡコントローラが転送を終了したとき第１スレッドの処理の戻ることが可能なマルチスレッドステートマシンである。スレッドからスレッドにジャンプするために、ソケットエンジンの内部レジスタの内容は１つのコンテキストの形式で格納され得る。各スレッドに対してそのようなコンテキストが存在する。第１スレッドから第２スレッドへ移動するために、ソケットエンジンの内部レジスタの内容は、第１のコンテキストにロードされて、第２のコンテキストの内容はソケットエンジンの内部レジスタにロードされる。ソケットエンジンがマルチスレッドであるか否かとは無関係に、ソケットエンジンSktEngはステートマシンのある１つの状態においてＤＭＡコントローラ移動をセットアップする。従ってSktEngステートマシンは、移動の発信元アドレスをＤＭＡコントローラに供給し、移動データ量をＤＭＡコントローラに供給し、宛先アドレスをＤＭＡコントローラに供給し、かつ移動を開始するために複数の命令を実行し、いくつかの順次操作を行わなければならなかった従来型のシーケンサプロセッサよりも速度が向上している。
【０１５９】
本発明について特定の実施例に関連付けて説明してきたが、本発明はその実施例に限定されない。ＮＩＤの機能は、ホストコンピュータに接続された拡張カード上にインプリメントされる必要はない。ＮＩＤの機能を、ＣＰＵチップセット内に実現することも可能である。例えば、ペンティアム（登録商標）チップセットのノースブリッジまたはサウスブリッジチップにＮＩＤの機能を持たせてもよい。或る実施形態では、メモリに接続するための第１のインタフェースとＣＰＵに接続するための第２のインタフェースとを有するメモリコントローラ集積回路にＮＩＤの機能が実現される。別の実施形態では、ＣＰＵに接続するための第１のインタフェースとＩ／Ｏデバイスに接続するための他のインタフェースとを有するＩ／Ｏコントローラ集積回路にＮＩＤの機能が実現される。例示のためステートマシンについてはパケットの受信に関連して説明してきたが、追加のステートマシンは、ＴＣＰプロトコルのサポートに関連するタイマー及び送信機能を果たす。ＴＣＰ状態変数及びパケットヘッダをワイドメモリ構造に格納する際に、これらの変数及びヘッダがステートマシンによって同時並行で一度にアクセス・処理されるように、そして得られた更新後のＴＣＰ状態変数がワイドメモリに並行して１回でまたは非常に少ない数のメモリ書き込み操作で書き戻されるように格納することは、ＴＣＰコネクションの制御がＴＯＥデバイスとホストとの間で移管し合うようなシステムに適用可能であるのみならず、ＴＯＥがＴＣＰコネクションを制御し続け、ＴＣＰコネクションの制御がＴＯＥとホストとの間で移ることのないシステムにも適用可能である。上述の実施例では、Tcb情報及びパケットヘッダは別々のメモリに格納されていたが、Tcbバッファとヘッダバッファは同じメモリの２つの部分でもよい。この１つのメモリは、TcbIdによってアドレス指定され得る。設計上、複数のパケットヘッダがTcbnoためにキューに入れられることが許容されるならば、メモリは複数のパケットヘッダを収容するべくより広く作られてもよい。Tcbがメモリの第１の部分に格納され、パケットヘッダはメモリの対応する他の複数の部分に格納される。Tcbと関連するパケットヘッダは、１つのメモリから同時並行で全部が出力される。Tcbのためのパケットヘッダのうちどれがソケットエンジンに供給されるかは、マルチプレクサによって決定される。HdrIdはマルチプレクサの選択値としての役目を果たす。従って、特許請求の範囲に記載された本発明の範囲から逸脱することなく、上述の実施例の各特徴に対して様々な変更や改変を加えたり、幾つかの特徴を組合せて実施することが可能である。
【図面の簡単な説明】
【０１６０】
【図１】本発明によるネットワークインタフェースデバイス（ＮＩＤ）が動作するシステムを示す図。
【図２】図１のＮＩＤの特定用途向け集積回路（ＡＳＩＣ）の簡略ブロック図。本図には、ここに記載するデータ転送を実行するために必要な種々のブロック間の全ての制御信号並びに全ての読み出し・書き込みストローブ信号が記載されているわけではない。これらの信号を含めることは説明されるべき情報の流れを不明確にし、印刷された特許文書において読みにくい大きい図となってしまうからである。
【図２Ａ】図２を構成する一部である。
【図２Ｂ】図２の構成する一部である。
【図３】図２の種々のブロックを参照するために用いられるニーモニックを記述した表。
【図４】図３の各ブロックがどのように編成されているかを記述した表。
【図５】図４の表で用いられる各ニーモニックの簡単な説明を記述した表。
【図６】左欄の各変数を構成する種々の変数を記述した表。
【図７】パケットのスローパス受信処理を行うために図２の各ブロックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図８】コネクションハンドアウトシーケンスにおいて図２の各ブロックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図９】パケットのファストパス受信処理を行うために図２の各ブロックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図９Ａ】図９を構成する一部である。
【図９Ｂ】図９を構成する一部である。
【図１０】図２のソケットエンジンSktEngステートマシンの各状態において何が生ずるかをハードウェア記述擬似コードで記述したものを示す図。
【図１０Ａ】図１０を構成する一部である。
【図１０Ｂ】図１０を構成する一部である。
【図１０Ｃ】図１０を構成する一部である。
【図１０Ｄ】図１０を構成する一部である。
【図１０Ｅ】図１０を構成する一部である。
【図１１】ホストメッセージバッファの編成を示した図。
【図１２】コネクションフラッシュシーケンスにおいて図２の各ブロックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図１３】着信アクノリッジ（ＡＣＫ）処理を行うためにソケットエンジンSktEngステートマシンの組合せロジックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図１４】図１３で用いられている変数間のさまざまな関係を示す図。
【図１５】着信データ処理を行うためにソケットエンジンSktEngステートマシンの組合せロジックが何を実行するかをハードウェア記述擬似コードで記述したものを示す図。
【図１６】図１３で用いられている変数間のさまざまな関係を示す図。
【図１７】ヘッダバッファのフォーマットを記述した図。
【図１８】図１７のヘッダバッファのフレーム状態Ａ要素のさまざまな部分を記述した図。
【図１８Ａ】図１８を構成する一部である。
【図１８Ｂ】図１８を構成する一部である。
【図１９】図１７のヘッダバッファのフレーム状態Ｂ要素のさまざまな部分を記述した図。
【図２０】ＴＣＢバッファに格納されたＴＣＢを構成するさまざまな要素値を記述した図。
【図２０Ａ】図２０を構成する一部である。
【図２０Ｂ】図２０を構成する一部である。
【図１】
2007517286.tif 000003
【図２】
2007517286.tif 000004
【図２Ａ】
2007517286.tif 000005
【図２Ｂ】
2007517286.tif 000006
【図３】
2007517286.tif 000007
【図４】
2007517286.tif 000008
【図５】
2007517286.tif 000009
【図６】
2007517286.tif 000010
【図７】
2007517286.tif 000011
【図８】
2007517286.tif 000012
【図９】
2007517286.tif 000013
【図９Ａ】
2007517286.tif 000014
【図９Ｂ】
2007517286.tif 000015
【図１０】
2007517286.tif 000016
【図１０Ａ】
2007517286.tif 000017
【図１０Ｂ】
2007517286.tif 000018
【図１０Ｃ】
2007517286.tif 000019
【図１０Ｄ】
2007517286.tif 000020
【図１０Ｅ】
2007517286.tif 000021
【図１１】
2007517286.tif 000022
【図１２】
2007517286.tif 000023
【図１３】
2007517286.tif 000024
【図１４】
2007517286.tif 000025
【図１５】
2007517286.tif 000026
【図１６】
2007517286.tif 000027
【図１７】
2007517286.tif 000028
【図１８】
2007517286.tif 000029
【図１８Ａ】
2007517286.tif 000030
【図１８Ｂ】
2007517286.tif 000031
【図１９】
2007517286.tif 000032
【図２０】
2007517286.tif 000033
【図２０Ａ】
2007517286.tif 000034
【図２０Ｂ】
2007517286.tif 000035
【国際調査報告】
2007517286.tif 000036