"エラーについてデータ転送を検査する方法であって、伝送制御プロトコルTCPペイロードの最初の2バイトがマーカ付きプロトコルデータユニット整列MPAプロトコルフレームの長さフィールドを含むという第1の想定に基づいて、前記データ転送の境界を識別するステップと、前記第1の想定、および、前記データ転送が少なくとも1つの整列直接データ配置DDPセグメントを含むという第2の想定に基づいて巡回冗長検査CRC値を計算し、該CRC値の計算と並行してTCPチェックサム値を計算するステップと、を含む方法。前記識別するステップが、接続コンテキストから初期シーケンス番号をフェッチし、前記初期シーケンス番号とデータ転送シーケンス番号との差を求めることを含む、請求項1に記載の方法。MPA要求/応答フレームが、前記データ転送の初期シーケンス番号をワード整列にするために必要なバイト数を含む補正ファクタを含む、請求項1に記載の方法。前記識別するステップが、512を法とするシーケンス番号プロセスを実施することを含む、請求項3に記載の方法。前記MPAフレームの最初のワードがゼロに等しいか否かを判定するステップと、前記最初のワードがゼロに等しい場合に前記MPA長フィールドを次のワードから読み取るステップと、前記最初のワードがゼロに等しくない場合に前記MPA長フィールドを前記第1のワードから読み取るステップと、を更に含む、請求項1に記載の方法。前記データ転送がMPAマーカを含まない、請求項1に記載の方法。データ転送を処理するためのネットワークインタフェースコントローラNICであって、前記データ転送をリアセンブリのためにストアするための第1のストレージ手段と、前記データ転送を宛先バッファに対して直接データ配置するためにストアするための第2のストレージ手段と、前記データ転送を受信するための手段であって、前記データ転送が第1のタイプおよび第2のタイプの一方として示される、手段と、前記データ転送について巡回冗長検査CRCを計算するための手段と、伝送制御プロトコルTCPセグメントの長さと、マーカ付きプロトコルデータユニット整列MPAフレームの長さとの比較、および、前記データ転送内の直接データ配置DDPセグメントのCRCの妥当性に基づいて、c1前記データ転送をドロップし受信を確認しないこと、c2前記データ転送を前記第1のストレージ手段に配置すること、c3前記データ転送を、宛先バッファに直接データ配置するため、前記第2のストレージ手段に配置すること、のうち1つを実行するための手段と、を含む、NIC。前記データ転送が前記第1のタイプである場合に、前記実行する手段がc2を実行する、請求項7に記載のNIC。前記データ転送が単一または複数の直接データ配置DDPセグメントを含むことを判定するための手段を更に含む、請求項7に記載のNIC。前記データ転送が複数のDDPセグメントを含み、全てのDDPセグメントが有効CRCを有し、TCPセグメントに完全に含まれる場合に、前記実行する手段がc3を実行する、請求項9に記載のNIC。前記データ転送が複数のDDPセグメントを含み、第1のDDPセグメントが無効CRCを有し、前記第1のDDPセグメントのDDPヘッダが以前のDDPセグメントに関連したMPA長によって参照される場合に、前記実行する手段がc1を実行する、請求項9に記載のNIC。前記データ転送が複数のDDPセグメントを含み、第1のDDPセグメントが無効CRCを有し、前記第1のDDPセグメントのDDPヘッダが以前のDDPセグメントに関連したMPA長によって参照されない場合に、前記DDPヘッダがMPAマーカによって参照される場合にはc1を実行し、前記DDPヘッダが前記MPAマーカによって参照されない場合にはc2を実行する、請求項9に記載のNIC。前記データ転送が複数のDDPセグメントを含み、最後のDDPセグメントが前記TCPセグメントの境界の外側まで延出する場合、前記実行する手段がc1を実行し、前記データ転送が複数のDDPセグメントを含み、最後のDDPセグメントが前記TCPセグメントの境界の外側まで延出しない場合、前記実行する手段がc2を実行する、請求項9に記載のNIC。前記データ転送が単一のDDPセグメントを含み、前記単一のDDPセグメントに関連したMPA長が前記データ転送の伝送制御プロトコルTCPセグメント長よりも大きい場合、前記実行する手段がc2を実行する、請求項9に記載のNIC。前記データ転送が単一のDDPセグメントを含み、このセグメントが、TCPセグメント長に等しい前記単一DDPセグメントに関連したMPA長および有効CRCを有する場合、前記実行する手段がc3を実行する、請求項9に記載のNIC。前記データ転送が単一のDDPセグメントを含み、このセグメントが、TCPセグメント長に等しい前記単一DDPセグメントに関連したMPA長、無効CRC、および以前のDDPセグメントに関連したMPA長によって参照されるDDPヘッダを有する場合、前記実行する手段がc1を実行する、請求項9に記載のNIC。前記単一のDDPセグメントが、TCPセグメント長に等しい前記単一DDPセグメントに関連したMPA長、無効CRC,およびMPAマーカによって参照されないDDPヘッダを有する場合、前記実行する手段が、前記DDPヘッダがMPAマーカによって参照される場合、c1を実行し、前記DDPヘッダがMPAマーカによって参照されない場合、c2を実行する、請求項16に記載のNIC。前記実行する手段がc2を実行する場合、前記データ転送タイプを前記第1のタイプにセットするための手段を更に含む、請求項7に記載のNIC。接続コンテキストにおいてTCPホール情報をクリアし、前記実行するための手段がc3を実行するアウトオブオーダのデータ転送の報告の受信を停止させるための手段を更に含む、請求項7に記載のNIC。前記データ転送がDDPセグメントを含み、前記計算する手段が前記データ転送の全DDPセグメントについて共にCRCを計算する、請求項7に記載のNIC。前記データ転送がMPAマーカを含まない、請求項7に記載のNIC。エラーを含む各データ転送について、再送信試行の回数をストアするための第3のストレージ手段と、最大のシーケンス番号をストアするための第4のストレージ手段と、を含む、請求項7に記載のNIC。前記データ転送についてCRCが無効であることは、前記データ転送が新たに受信されたエラーを含むデータ転送であることを示し、この場合、前記再送信試行の回数が前記データ転送についての最大再送信試行回数を超えた場合、前記新たに受信したエラーを含むデータ転送に対して、前記実行する手段がc2を実行し、前記再送信試行の回数が前記データ転送についての最大再送信試行回数を超えていない場合、前記新たに受信したエラーを含むデータ転送に対して、前記実行する手段がc1を実行し、前記NICが、前記実行する手段がc1を実行する場合、前記新たに受信したエラーを含むデータ転送についての前記再送信試行回数を1だけ増やすための手段と、前記実行する手段がc1を実行する場合、前記第4のストレージ手段を更新して、少なくとも1つの以前に受信したエラーを含むデータ転送と前記新たに受信したエラーを含むデータ転送との間の最大のシーケンス番号を保持するための手段と、を含む、請求項22に記載のNIC。インオーダのデータ転送について前記CRCが有効であり、前記インオーダのデータ転送のシーケンス番号が前記ストアされた最大のシーケンス番号よりも大きい場合、前記再送信試行回数をリセットするための手段を更に含み、前記実行する手段が、aインオーダのデータ転送について前記CRCが有効であり、前記インオーダのデータ転送の前記シーケンス番号が前記ストアされた最大のシーケンス番号以下である場合、およびb前記リセットする手段が前記再送信試行回数をリセットする場合、c3を実行する、請求項22に記載のNIC。3.課題ハードウェア設定においてRDMAおよびDDPを用いてTCP/IPを効率的に実施することに伴う1つの課題は、標準的なTCP/IPオフロードエンジンTOE実施において、アウトオブオーダの受信TCPストリームを配列させるためのリアセンブリバッファが受信ロジック内に含まれ、このためにコピー動作が増えることである。更に、受信器のデータバッファに対する直接データ配置を完了させるために、RNICは、到着するTCPセグメントペイロード127の各々について宛先バッファの位置を特定することができなければならない。この結果、全てのTCPセグメントは、それらがインオーダinorderであり宛先バッファの位置を特定可能であることを保証するために、リアセンブリバッファにセーブされる。この問題に対処するため、iWARP仕様では、送信RNICに対して、RDMAメッセージのセグメント化を実行する際に、生成されるDDPセグメントがTCPセグメントに対して整列するように行うことが強く推薦される。それにもかかわらず、多くの場合、特にデータ転送が多数の相互接続を通過する場合には、非整列のnonalignedDDPセグメントは避けられない。図2を参照すると、整列が意味するのは、TCPヘッダ126のすぐ後にDDPセグメント112がありすなわちMPAヘッダがTCPヘッダの次にあり、次いでDDPヘッダがある、DDPセグメント112が完全に1つのTCPセグメント106内に含まれることである。更に具体的には、各TCPセグメント106は、TCPヘッダ126およびTCPペイロード/TCPデータ127を含む。TCPホール130は、TCPデータストリーム内の欠落したTCPセグメント複数のセグメントである。MPAマーカ110が提供するデータは、アウトオブオーダのTCPセグメント106が受信されて、TCPセグメント106内のMPAフレーム109がTCPセグメント106に対して整列しているか否かを受信器が知りたい場合のためのものである。各マーカ110は、特定の接続の初期シーケンス番号で始まるTCPストリーム内において等しい間隔512バイトで配置され、それが含まれるMPAフレーム109のDDP/RDMAヘッダ124を指し示す。第1のTCPセグメント106には、第1の順次識別番号が割り当てられ、以降のTCPセグメント106内の各初期シーケンス番号は、増分されたシーケンス番号を含む。図2において、実線は整列したデータ転送の一例を示し、TCPヘッダ126のすぐ後にMPA長フィールド114およびDDP/RDMAヘッダ124があり、DDPセグメント112は完全にTCPセグメント106内に含まれている。DDPプロトコル120のレイヤにおける点線は、非整列のDDPセグメント112NAを示し、TCPヘッダ126のすぐ後にはMPA長フィールド114およびDDP/RDMAヘッダ124が存在しない。非整列のDDPセグメントは、例えば、送信器のRNICおよび受信器のRNIC間にあり得る中間ボックスによる再セグメント化、または実行中の最大セグメントサイズMSS:maximumsegmentsizeの縮小の結果として生じる場合がある。送信器のRNICは、DDPセグメント化を変えるTCPストリーム内のDDPヘッダの位置を変えることはできないので、最初のDDPセグメントが大きなMSSによって作成されたのにもかかわらず、再送信動作では、新しい小さくしたMSSが必要となり得る。いずれの場合であっても、コピー動作が増えることによって速度および効率が低下する。従って、当技術分野においては、非整列DDPセグメントの配置および配信とは異なる方法で整列DDPセグメントの配置および配信を扱う方法が必要とされている。非整列DDPセグメント112NAの処理に関する別の課題は、何によって非整列が生じているかの判断が難しいことが多いという事実によって生じる。例えば、単一の非整列DDPセグメント112NAは、2つ以上のTCPセグメント106間で分割される可能性があり、それらのうち一方は到着するが他方は到着しない場合がある。別のケースでは、いくつかのDDPセグメント112NAがMPAマーカ110の間に位置し、ヘッダが欠落したり、またはセグメント末端部が欠落したりする後者の場合、セグメントが部分的に配置され、残りの部分が到着した場合にどこにそれを配置するかを理解するために何らかの情報を保持する必要があり得る等の可能性がある。この後者の場合に関して、図3は、1つ以上の非整列DDPセグメント112NAについて、MPAマーカ参照に関して起こり得る状況をブロック図で示す。ケースAは、新たに受信したDDPセグメント162のDDPセグメンドヘッダ160が、以前に処理したDDPセグメント166のMPA長フィールド164によって参照されている状況を示す。ケースBは、新たに受信したDDPセグメント162のヘッダ160が、新たに受信したDDPセグメント162内に位置するマーカ168によって参照されている状況を示す。すなわち、マーカ168は、新たに受信したDDPセグメント162の開始を指し示している。ケースCは、マーカ168が新たに受信したDDPセグメント162内に位置するがセグメントの外を指し示す状況を示す。ケースDは、マーカ168が新たに受信したDDPセグメント162内に位置してセグメント内を指し示す状況を示す。ケースEは、新たに受信したDDPセグメント162内に位置するマーカが存在しない状況を示す。いずれの場合であっても、DDPセグメントの非整列の原因を判定することができない場合、RNICは直接データ配置を行うことができない。なぜなら、ケースが多すぎて適切に対処することができず、情報/部分セグメントが多すぎて中間ストレージ内に保持することもできないからである。従って、整列および非整列DDPセグメントの異なる処理を提供する解決策はいずれも、非整列を発生させ得る様々な状況に対処しなければならない。4.DDP/RDMA動作フローこれより、図4から図8を参照して、後の記載のために、DDP/RDMA動作フローの簡単な概要を説明する。特にDDPプロトコル120図2に関して述べると、DDPは、タグ付きメッセージおよびタグなしメッセージと称する2つのタイプのメッセージを提供する。図4を参照すると、タグ付きメッセージにおいて、各DDPセグメント112図2は、DDP/RDMAヘッダ124内に、データを直接配置することができる受信器上の宛先バッファ内のメモリ領域/ウインドウ例えば図7のメモリ領域232を識別するステアリングタグSTag:steeringtag、この領域/ウインドウ内のターゲットオフセットTO、およびセグメントペイロード図示せずを保持する。この場合、宛先バッファの可用性は、STagを介して発表される。図5を参照すると、タグなしメッセージは、遠隔の送信器が受信器におけるバッファを知らず、キューIDQN、メッセージシーケンス番号MSN、およびメッセージオフセットMOを用いてメッセージを送信するものであり、これらが受信器によって用いられて、適切なバッファを判定することができる。図6から図8を参照すると、RDMAプロトコルは、4つのタイプのメッセージを規定する。すなわち、送信200、書き込み202、読み取り204、および読み取り応答206である。図1に戻ると、バーブインタフェースverbinterface7は、RNIC4をコンシューマconsumerに提示し、RNIC4リソースの割り当ておよび割り当て解除を行うため、ならびに、ワーク要求WR:workrequest208をRNIC4にポストするための方法を含む。バーブインタフェース7は、通常、2つの部分を有するバーブライブラリ8によって実施される。すなわち、ユーザ空間コンシューマのためのユーザ空間ライブラリ9A、および、カーネル空間コンシューマのためのカーネルモジュール9Bである。バーブインタフェース7は、特定のRNIC用のソフトウェアであり、RNIC4のハードウェアおよびファームウェアと共に動作する。バーブインタフェース7バーブライブラリ8、ハードウェア、およびファームウェアにおいて何を実施しなければならないかに関して、厳密な規定はない。バーブインタフェース7は、RNIC4のサービスをコンシューマに提供する単一のパッケージと考えることができるので、コンシューマは主に2つのタイプの動作を実行することができる。すなわち、RNIC4のリソース管理割り当ておよび割り当て解除、ならびに、RNIC4へのワーク要求複数の要求WRのポスティングである。RNIC4のリソース管理の例は、キュー対の割り当ておよび割り当て解除、完了キュー以降、CQcompletionqueueと称するの割り当ておよび割り当て解除、またはメモリ領域の割り当ておよび割り当て解除である。これらの管理タスクについては、以下で更に詳細に説明する。図6から図8に示すように、コンシューマは、ワーク要求208をポストするキュー対を割り当てる。キュー対queuepair以降、QPと称するは、TCP接続に関連付けられ、1対のワークキューworkqueue例えば送信および受信210、212、ならびに、各キューごとのポスティング機構図示せずを含む。各ワークキュー210、212は、ワークキュー要素WQE:workqueueelements216のリストであり、各WQEは1つのワーク要求WR208を記述する何らかの制御情報を保持し、コンシューマバッファを示すまたは指し示す。コンシューマは、ワーク要求WR208をワークキュー210、212にポストして、バーブインタフェース7図1およびRNIC4図1に、ポストしたワーク要求WR208を実行させる。更に、読み取りキュー214図8およびワークキュー要素WQE216等、コンシューマが直接インタラクトしないQPを構成することができるリソースがある。WQE216によって保持することができる典型的な情報は、コンシューマワーク要求WRのタイプすなわち、送信WR208Sでは、RDMA送信、RDMA書き込み、RDMA読み取り等とすることができ、受信WR208Rでは、RDMA受信のみとすることができる、および、送信するためのデータを保持するか、または受信データのための位置を表すコンシューマバッファの記述である。WQE216は、常に、単一のRDMAメッセージを記述する/単一のRDMAメッセージに対応する。例えば、コンシューマがRDMA書き込みタイプの送信ワーク要求WR208Sをポストした場合、バーブライブラリ8図1は、RDMA書き込みメッセージを用いて、WQE216Sを構築し、データを取得し応答側に送信する必要があるコンシューマバッファを記述する。別のケースでは、受信ワーク要求WR208R図6が存在する。この場合、バーブライブラリ図1は、受信した送信メッセージ200のペイロードを配置するために用いられるコンシューマバッファを保持する受信キューRQ212に、WQE216Rを追加する。バーブライブラリ8図1が、新しいWQE216を送信キューSQ210または受信キューRQ212に追加すると、バーブライブラリ8は、RNIC4図1に、新しいWQE216が送信キューSQ/受信キューRQにそれぞれ追加されたことを知らせるここでは呼び鈴を鳴らすと言う。この呼び鈴を鳴らす動作は通常、RNICメモリ空間に対する書き込みであり、これはRNICハードウェアによって検出されて復号される。従って、呼び鈴を鳴らすことによって、RNICに、特定のSQ/RQについてそれぞれ実行する必要がある新たなワークがあることを知らせる。RNIC4図1は、待ち状態のポストされたWQE216を有する送信キューSQ210のリストを保持する。更に、RNICは、それらの送信キューSQ210間のアービトレーションを行い、それらを一つずつ処理する。RNIC4が処理対象の送信キューSQ210を選ぶと、処理対象の次のWQE216を読み出しWQEはコンシューマによってポストされた順序でRNICによって処理される、要求されたRDMAメッセージに属する1つ以上のDDPセグメント220を作成する。ここで、図6から図8を参照して、特定のタイプのRDMAメッセージの処理について説明する。図6に示すように、RNIC要求側は、特定の送信キューSQ210Sを処理することを選択する。RNICは、送信キューSQ210SからWQE216Sを読み取る。このWQE216SがRDMA送信要求に相当する場合、RNICは送信メッセージを作成し、このメッセージをピアのRNIC応答側に送信する。作成したメッセージは、例えば、3つのDDPセグメント220を含む場合がある。RNIC応答側は、送信メッセージを受信すると、受信キューRQ212からWQE216Rを読み取り、受信したDDPメッセージ220のペイロードを、そのWQE216Rが参照するコンシューマバッファすなわち応答側Rxバッファ230に配置する。送信メッセージ200がインオーダで受信された場合、RNICは、受信キューRQ212から、第1の未使用のWQE216Rを選択する。WQE216Rは、コンシューマによってポストされた順序で要求キューRQ212内に連鎖されているchained。タグなしDDPメッセージに関しては、送信メッセージ200は、メッセージシーケンス番号MSN図5を保持する。これは1に初期化され、送信側によって単調に増分される。送信された各DDPメッセージ220は、同じDDPキューに属する。タグ付きメッセージについては、以下でRDMA書き込みメッセージ202に関連付けて説明する。DDPキューは、DDPヘッダ内のキュー番号QN図5によって識別される。RDMAプロトコルは、3つのDDPキューを規定する。すなわち、インバウンドRDMA送信についてQN0、インバウンドRDMA読み取り要求についてQN1、インバウンド終了についてQN2である。従って、送信メッセージ200がアウトオブオーダで到着した場合、RNIC4は、そのメッセージのMSNを用いて、その送信メッセージ200に対応するWQE216Rを見つけることができる。1つの受信された送信メッセージ200は、受信キューRQ212から、1つのWQE216Rを消費する。ポストされたWQEが無いこと、またはメッセージデータ長がWQEバッファの長さを超えることは、重大なエラーと見なされ、接続終了となる。これより、図7および図8を参照して、タグ付き動作を用いたRDMA書き込みメッセージ202、およびRDMA読み取りメッセージ204の一部について説明する。タグ付き動作を用いるために、コンシューマはメモリ領域232を登録する必要がある。メモリ領域232は、受信器すなわち図7の応答側のピンメモリpinnedmemoryの仮想連続領域である。メモリ領域232は、その開始仮想アドレスVA、長さ、アクセス許可、およびそのメモリ領域232に関連した物理ページのリストによって記述される。メモリ領域232を登録した結果、コンシューマはステアリングタグSTagを再び受信し、これを用いてその登録メモリ領域232にアクセスすることができる。遠隔コンシューマ例えば図7の要求側によるメモリ領域232のアクセスは、RNIC4によって実行され、ローカルなコンシューマ例えば図7の応答側とのインタラクションは行われない。コンシューマが遠隔メモリ232にアクセスしたい場合、RDMA書き込みまたはRDMA読み取りタイプの送信ワーク要求WR208Wまたは208R図8をそれぞれポストする。バーブライブラリ8図1は、対応するWQE216W図7または216R図8を、送信キューSQ210Wまたは210Rにそれぞれ追加し、RNIC4に通知する。接続がアービトレーションで使用権を得た場合、RNIC4はWQE216Wまたは216Rを読み、RDMA書き込みメッセージ202またはRDMA読み取りメッセージ204をそれぞれ作成する。特にRDMA書き込みメッセージ202について説明すると、図7に示すように、RDMA書き込みメッセージ202がRNIC4によって受信されると、RNICは、そのメッセージに属するDDPセグメントのヘッダ内のSTagおよびTO図4および長さを用いて、登録されたメモリ領域232を探し出し、RDMA書き込みメッセージ202のペイロードをメモリ232に配置する。受信器のソフトウェアまたはCPUすなわち図示する応答側は、データ配置動作には関与せず、この動作が行われていることを認識しない。特にRDMA読み取りメッセージ204について説明すると、図8に示すように、メッセージがRNIC4図1によって受信されると、RNICは、RDMA読み取り応答メッセージ206を作成し、これを、遠隔ホストすなわち図示するような要求側に返信する。この場合、受信キューを読み取りキュー214と呼ぶ。また、RDMA読み取り応答206の作成は、ローカルなコンシューマすなわち応答側の関与なしに行われ、コンシューマはこの動作が行われていることを認識しない。RDMA読み取り応答206が受信されると、RNIC4図1は、このメッセージを、RDMA書き込みメッセージ204と同様に処理する。すなわち、要求側のメモリ領域232に書き込みを行う。コンシューマワーク要求の処理に加えて、RNIC4図1は、図6から図8に示すように、それらの要求の完了についてコンシューマに通知する。完了通知は、完了キュー240を用いて行われる。これは、別のRNICリソースであり、コンシューマによってバーブライブラリ8が提供する専用の機能を介して割り当てられる。完了キュー240は、完了キュー要素CQE:completionqueueelements242を含む。RNIC4図1がコンシューマワーク要求WR208S、208W、208RRの完了を報告した場合、RNIC4は、CQE242を完了キューCQ240に配置する。各ワークキューすなわち送信キューSQ210、受信キューRQ212は、関連する完了キューCQ240を有する。注:読み取りキュー214はハードウェアによって維持される内部キューであり、ソフトウェアには見えない。従って、CQ240はこのキューに関連付けられず、コンシューマはこのキューを割り当てず、その存在について知らない。しかしながら、同一の完了キューCQ240を、2つ以上の送信キューSQ210および受信キューRQ212に関連付けることが可能であることに留意すべきである。関連付けは、キュー対QPの割り当て時に行われる。動作において、コンシューマがワーク要求WR208を送信キューSQ210にポストする際に、この要求が完了した場合に通知を受け取りたいか否かを指定することができる。コンシューマが完了通知を要求した場合、RNIC4は、ワーク要求WRの完了時に、送信キューSQ210に関連付けられた関連完了キューCQ240に完了キュー要素CQE242を配置する。RDMAプロトコルでは、送信キューSQ210にポストされたワーク要求WR208について、極めて単純な完了順序付けが規定されている。具体的には、RDMA送信ワーク要求WR208SおよびRDMA書き込みワーク要求WR208Wは、それらが高い信頼性で送信された場合に完了する。RDMA読み取りワーク要求WR208Rは、対応するRDMA読み取り応答メッセージ206が受信されてメモリ領域232に配置された場合に完了する。コンシューマのワーク要求WRは、それらが送信キューSQ210にポストされた順序で完了する。図6を参照すると、受信キューRQ212にポストされた各ワーク要求WRも完了通知を必要とする。従って、RNIC4図1は、受信した送信メッセージ200の配置を終えると、受信キューRQ212に関連付けた完了キューCQ240に完了キュー要素CQE242を配置する。前述のことを考慮すると、当技術分野において、非整列DDPセグメントの配置および配信とは異なる方法で整列DDPセグメントの配置および配信を処理する方法が必要とされている。本発明が含むRNIC実施は、特定の接続の全ての受信DDPセグメントが整列している場合にはメモリに直接データ配置を行い、特定の接続のいくつかのDDPセグメントが非整列である場合にはリアセンブリバッファを通してデータを移動させる。リアセンブリバッファにアクセスすることなくカットスルーを行う接続のタイプを高速Fast接続と称し、他方のタイプを低速Slow接続と称する。コンシューマは、接続を確立する場合、接続タイプを指定する。例えば、インターネットを介して別の大陸へと至る接続は、整列したセグメントで宛先に到着する可能性が低く、従って、コンシューマによって低速接続タイプとして指定されるはずである。これに対して、1つのストレージエリアネットワークSAN内で2つのサーバが接続されている接続は、全てのDDPセグメントが整列している可能性が高く、従って、コンシューマによって高速接続タイプとして指定されるであろう。接続タイプは、高速から低速に、およびその逆に変更することができる。本発明は、メモリ帯域幅、待ち時間、TCP再送信を用いたエラー回復を少なくし、空の受信キュー、すなわち、受信キューが、インバウンドのタグなしDDPセグメントについて、ポストされたワークキュー要素WQEを有しない場合に、適切な回復を行うことができる。従来の実施では、接続が終了することになる。これに対して、本発明による高速接続では、かかるセグメントをドロップし、TCP再送信プロセスを用いて、この状況から回復し、接続の終了を回避する。また、この実施では、高速接続において、インバウンドDDPセグメントの大部分について巡回冗長検査CRCの妥当性確認を行い、その後でセグメント受信を確認するTCP肯定応答Ackを送信することができる。これによって、TCPの信頼性の高いサービスを用いて、CRC検査で検出されたデータ破損から効率的に回復することができる。本発明の第1の態様は、エラーについてデータ転送を検査する方法に関する。この方法は、伝送制御プロトコルTCPペイロードの最初の2バイトがマーカ付きプロトコルデータユニット整列MPAプロトコルフレームの長さフィールドを含むという第1の想定に基づいて、前記データ転送の境界を識別するステップと、前記第1の想定、および、前記データ転送が少なくとも1つの整列直接データ配置DDPセグメントを含むという第2の想定に基づいて巡回冗長検査CRC値を計算し、該CRC値の計算と並行してTCPチェックサム値を計算するステップと、を含む。本発明の第2の態様は、エラーについてデータ転送を検査するためのシステムに関する。このシステムは、伝送制御プロトコルTCPペイロードの最初の2バイトがマーカ付きプロトコルデータユニット整列MPAプロトコルフレームの長さフィールドを含むという第1の想定に基づいて、前記データ転送の境界を識別する手段と、前記第1の想定、および、前記データ転送が少なくとも1つの整列直接データ配置DDPセグメントを含むという第2の想定に基づいて巡回冗長検査CRC値を計算し、該CRC値の計算と並行してTCPチェックサム値を計算する手段と、を含む。本発明の第3の態様は、エラーについてデータ転送を検査するための再送信試行回数を制限するためのコンピュータ読み取り可能プログラムコードが埋め込まれたコンピュータ使用可能媒体を含むコンピュータプログラムに関する。このプログラムは、伝送制御プロトコルTCPペイロードの最初の2バイトがマーカ付きプロトコルデータユニット整列MPAプロトコルフレームの長さフィールドを含むという第1の想定に基づいて、前記データ転送の境界を識別するように構成されたプログラムコードと、前記第1の想定、および、前記データ転送が少なくとも1つの整列直接データ配置DDPセグメントを含むという第2の想定に基づいて巡回冗長検査CRC値を計算し、該CRC値の計算と並行してTCPチェックサム値を計算するように構成されたプログラムコードと、を含む。本発明の前述およびその他の特徴は、本発明の実施形態の以下の更に具体的な説明から明らかとなろう。図面を参照して、本発明の実施形態を詳細に説明する。図面において、同様の名称は同様の要素を表す。以下の概略は、整理する目的のみのため与える。すなわち、I.概要、II.インロジック、III.アウトロジック、IV.結論である。I.概要A.環境添付図面を参照すると、図9は、本発明の一実施形態によるデータ転送環境10のブロック図である。データ転送環境10は、データソース12すなわちピアを含み、これは、データ転送14Aを、1つ以上の遠隔メモリデータアクセスRDMA対応ネットワークインタフェースコントローラ複数のコントローラRNIC16を介して、データ転送14Bを受信するデータシンク18すなわちピアに送信する。説明の目的のため、データ転送を開始するエンティティを、本明細書において要求側と称し、データ転送に応答するものを、本明細書において応答側と称する。同様に、データを伝送するエンティティを、本明細書において送信側と称し、データ転送を受信するものを、本明細書において受信側と称する。データソース12およびデータシンク18の各々は、異なる時点で、データの送信側もしくは受信側、または要求側もしくは応答側になる場合があり、ソースおよびシンクという表示は、転送するデータを保持するエンティティを最初に表す目的のためにのみ与えることを認識すべきである。また、以下の説明は、上述のエンティティの1つをコンシューマと示す場合がありRNIC16のリソースを消費するので、この場合、これより具体的な表示は必要ない。宛先バッファは、受信側においてデータを最終的に受信するデータストレージ、すなわちデータソース12またはデータシンク18のデータバッファ50を示す。データソース12およびデータシンク18は、各々、データをストアするためのデータバッファ50を含む。ハードウェアに関して説明すると、RNIC16は、iWARPおよびバーブ機能性を有するネットワークI/Oアダプタまたは埋め込みコントローラ等、いずれかのネットワークインタフェースコントローラである。また、RNIC16は、バーブインタフェース20、アクセス制御30、RNIC入力ロジック以下ではインロジックと呼ぶ32、リアセンブリバッファ34、内部データバッファ38、RNIC出力ロジック以下ではアウトロジックと呼ぶ40、接続コンテキスト42、妥当性確認ユニット44、および他のコンポーネント46を含む。バーブインタフェース20は、コンシューマに対するRNIC16の提示であり、RNIC16ハードウェアおよびRNICドライバ図示せずの組み合わせによって実施されて動作を実行する。バーブインタフェース20は、バーブライブラリ22を含み、これは2つの部分、すなわちユーザ空間ライブラリ24およびカーネルモジュール26を含む。アクセス制御30は、インロジック32に対するアクセスを制御するためのいずれかの現在既知のロジックまたは後に開発されるロジックを含むことができる。リアセンブリバッファ34は、データ転送14A、14Bに関するデータを一時的にストアするためのいずれかの機構を含む場合がある。特に、リアセンブリバッファ34は、一般に、アウトオブオーダのTCPストリームを一時的にストアするために用いられる。これについては、以下で更に詳細に説明する。他のコンポーネント46は、RNIC16の動作のために必要な他のいずれかのロジック、ハードウェア、ソフトウェア等を含む場合があるが、本明細書において特に説明は行わない。図10を参照すると、接続コンテキスト42は、接続に特定的なデータをストアするための多数のフィールドを含む。他のコンテキストデータ60は、接続に特定的なデータを提供し、これは、本明細書において特に説明しないが、当業者には認められるものである。本発明によれば、2つの接続タイプが規定される。すなわち、高速以降FASTと呼ぶ接続および低速以降SLOWと呼ぶ接続である。高速および低速という言葉は、接続が整列DDPセグメントを配信する可能性を示す。接続タイプは、接続タイプ62と呼ぶ接続コンテキストフィールドにおいて識別される。SLOW接続は、SLOW接続として生成されたか、または、インバウンドデータの処理中にRNIC16によって格下げされたdowngradedRDMA接続のために用いることができる。これについては、以下で更に詳細に説明する。図10に示す他のフィールドについては、本開示中の他の節において、関連する処理に基づいて説明する。図11を参照すると、妥当性確認ユニット44は、妥当性確認処理の必要性に応じて、巡回冗長検査CRCロジック64、TCPチェックサムロジック66、および蓄積交換storeandforwardバッファ68を含む。B.RNICの全体的な動作図9に戻ると、動作において、RNIC16は、インロジック32に対するアクセスを制御するアクセス制御30を介して、データ転送14Aを受信する。接続を維持するための情報は、従来のように、他のコンテキストデータ60図10に保持されている。インロジック32は、データ転送14AにおけるインバウンドTCPセグメントを処理し、TCPチェックサムロジック66図11によって受信したTCPセグメントの妥当性確認を実行し、CRCロジック64図11によってMPACRCを計算し、FAST接続データストリームをSLOW接続データストリームから分離する。後者の機能に関して、以下で更に充分に説明するインロジック32は、SLOW接続でRNIC16が受信した全てのデータをリアセンブリバッファ34に送出し、FAST接続を多数の異なる方法で処理する。FAST接続に関して説明すると、インロジック32が整列の違反を検出したすなわち、TCPヘッダのすぐ後にDDPヘッダがなく、DDPセグメントが完全に1つのTCPセグメント内に含まれていない場合、接続はSLOW接続に格下げされ、データはリアセンブリバッファ34に送出される。これに対して、整列の違反が存在しない場合、インロジック32は、整列したインバウンドDDPストリームを、内部データバッファ38に、次いでアウトロジック40に送出して、宛先データバッファ50に直接配置する。あるいは、TCPセグメント106がドロップされ、肯定応答Ackが送信されず、このためセグメントの再送信を必要とする場合がある。アウトロジック40は、FAST接続およびSLOW接続の間のアービトレーションを行い、双方の接続タイプのストリームをデータシンク18のデータバッファ50に対してデータ配置する。FAST接続上の整列したDDPセグメントが内部データバッファ38に送出され、宛先バッファに直接配置されるという状況を、カットスルーモードと呼ぶ。なぜなら、整列DDPセグメントを有するFAST接続は、直接アウトロジック40によって配置され、リアセンブリバッファ34を無視するからである。しかしながら、接続タイプの双方で、インオーダの受信データストリームのみが、アウトロジック40を介してデータシンク18に配信される。II.インロジック図12を参照して、本発明によるインロジック32図9およびそのデータ転送14Aの処理のフロー図を更に詳細に記載する。上述したように、インロジック32は、インバウンドTCPセグメントを処理し、受信したセグメントのTCP妥当性確認を実行し、MPACRCを計算し、SLOW接続データストリームからFAST接続データストリームを分離する。特に注記しない限り、Sが付かない参照番号は、図9から図11に示す構造を示す。第1のステップS1において、インロジック32は、RNIC16接続に属するデータ転送14AのTCPセグメント106をフィルタリングし、受信したセグメントについて妥当性確認ユニット44によって計算したCRC妥当性確認の結果と共にパケットを取得する。CRC妥当性確認は、インロジック32決定処理の前に行わなければならないことに留意すべきである。また、CRC妥当性確認は、ステップS2においてTCPセグメント106をFAST接続に属するものとして識別する前に、TCPチェックサム計算と同時に実行可能である。ステップS2において、インロジック32は、TCPセグメント106がSLOW接続に属するか否かを判定する。この場合、インロジック32は、送信側がどのように接続をラベリングしたかを判定する。YESの場合、TCPセグメント106はリアセンブリバッファ34に送出され、ステップS3において、TCPロジックはこのセグメントの受信が成功したと見なす。NOの場合、インロジック32は先に進み、ステップS4において、TCPセグメント106長が、提示stateされたMPAセグメント長より大きいか否かを判定する。すなわち、TCPヘッダ126において提示されているTCPセグメント106長が、MPA長フィールド114において提示されているMPA長よりも長いか否かが判定される。YESの場合、これは、TCPセグメント106が多数のDDPセグメント112を含むことを示す。その処理については以下で説明する。NOの場合、これは、TCPセグメント106が単一のDDPセグメント112または112NAを含むことを示す。この後者の場合、ステップS5において、インロジック32は、MPA長がTCPセグメント106長より大きいか否かを判定する。YESの場合、これは、3つの状況のうち1つを示す。1単一のDDPセグメント112NAがTCPセグメント106に整列しておらず、MPA長フィールドと想定されたフィールドは長さフィールドではない。2単一のDDPセグメント112の最初の部分がTCPセグメント106に整列しているが、単一のDDPセグメントの長さがTCPセグメント106のペイロードサイズを超えている。3受信した単一のDDPセグメント112がTCPセグメント106に整列しているが、そのMPA長フィールド114が破損している。最初の2つの場合1および2は、非整列の単一DDPセグメント112NAがFAST接続上で受信され、従って、ステップ3において、接続をSLOW接続に格下げしなければならないことを示す。第3の場合3は、接続の格下げを必要としない。しかしながら、MPAフレーム109の長さがTCPセグメント106の長さを超えている理由は識別および確認することができないので、かかるTCPセグメント106のドロップすなわち取り消しおよび非転送は得策ではない。なぜなら、これはデッドロックを生じる恐れがあるからである上述のケース2。すなわち、かかるTCPセグメントが実際に非整列DDPセグメントを保持する場合、送信側は同一の非整列DDPセグメントを再送信するが、これは同じフローに従うので、受信側によって繰り返しドロップされて、デッドロックを生じる。従って、インロジック32は、ステップS3において、TCPセグメント106のデータ転送をリアセンブリバッファ34に送出し、Ackをスケジューリングして、TCPセグメント106の受信が成功したことを確認し、接続をSLOW接続に格下げするすなわち、図10における接続タイプフィールド62を高速から低速に切り替える。以下で説明するように、MPA長フィールド114が破損している場合上述のケース3、これはアウトロジック40によって検出され、妥当性確認ユニット44が検出するCRCエラーのために、接続は閉じられる。従って、ステップS3における接続の格下げでは、整列DDPセグメント112におけるデータ破損のためにFAST接続を永続的にSLOW接続にするわけではない。ステップS5に戻ると、MPA長がTCP長より大きくない場合、すなわちNOの場合、これは、MPAフレーム109長がTCPセグメント106長に一致する等しいことを示す。インロジック32は、ステップS6に進み、このTCPセグメント106についてCRC妥当性確認の結果が有効であるか否か、すなわち、CRCロジック64が有効という指示を戻したか否かを判定する。YESの場合、これは、単一のDDPセグメント112がTCPセグメント106の境界にちょうど適合しすなわち長さが互いに等しい、このセグメントについてデータ破損が検出されていないことを示す。この結果、ステップS7では、受信したTCPセグメント106を、RNIC16の内部データバッファ38に配置し、アウトロジック40によって処理することによって、単一のDDPセグメント112を高速経路モードで処理する。これによって、例えばデータシンク18のような受信側の宛先データバッファ50に、受信したTCPセグメント106を直接配置する。更に、このTCPセグメント106の受信成功を確認するように、Ackをスケジューリングする。CRCロジック64が無効という指示を返した場合、すなわちステップS6においてNOの場合、これは、本発明に従って判定可能である5つの起こり得るケースのうち1つが存在することを示す。図3は、5つの起こり得るケースを示し、ステップS8からステップS10は、どのようにインロジック32が各ケースを処理するかを示す。いずれの場合でも、処理の目的は、1送信側によってFAST接続として宣言されたものであっても、非整列接続の終了を回避すること、2FAST接続に属する整列DDPセグメントにおけるデータ破損による接続終了の可能性を低くすること、および3別個に処理されるケースの数を最小限に抑えながら、可能な限りインロジック32を単純にすること、である。ステップS8において、インロジック32は、図3のケースAに示すように、新たに受信したDDPセグメント162のDDPセグメントヘッダ160が、以前に処理したDDPセグメント166のMPA長フィールド164によって参照されているか否かを判定する。この場合、以前に処理したDDPセグメント166のMPA長は、新たに受信したDDPセグメント162のMPACRCの妥当性確認中にチェックされたので、次のセグメント内のDDPヘッダ160の正しい位置を示す。ステップS6において、ケースAについてCRCが無効であったことは、単一のDDPセグメント162のデータまたはヘッダ160が破損していることを意味する。この問題は、新たに受信したセグメント162のTCP再送信によって解決される。従って、ステップS9において、TCPセグメント106をドロップし、セグメント受信は確認されていないと見なされる。新たに受信したDDPセグメント162のヘッダ160が、以前に処理したDDPセグメント166のMPA長フィールド164によって参照されていない場合ステップS8においてNO、インロジック32はステップS10に進み、図3のケースBに示すように、新たに受信したDDPセグメント162のヘッダ160が、新たに受信したDDPセグメント162の内部に位置するマーカ168によって参照されているか否かを判定する。すなわち、マーカ168は、新たに受信したDDPセグメント162の最初の部分を示している。この場合、ステップS6においてCRCが無効であることは、次のいずれかを示す。1マーカ168が正しい値を保持し、新たに受信したDDPセグメント162が有するDDPヘッダ160またはデータが破損している、または、2新たに受信したDDPセグメント162の内部のマーカ168が破損している。双方の場合で、この問題は、新たに受信したDDPセグメント162を再送信することによって解決される。従って、ステップS9において、TCPセグメントをドロップし、セグメント受信は確認されない。新たに受信したDDPセグメント162のヘッダ160が、新たに受信したDDPセグメント162内部に位置するマーカ168によって参照されない場合、すなわちステップS10においてNOの場合、3つのケースのうち1つが存在する。第1に、図3のケースCに示すように、マーカ168は新たに受信したDDPセグメント162内に位置するが、セグメントの外部を指し示す。第2に、図3のケースDに示すように、マーカ168は新たに受信したDDPセグメント162に位置するが、セグメント内部を指し示す。第3に、図3のケースEに示すように、新たに受信したDDPセグメント162内に位置するマーカは存在しない。ケースC、D、およびEにおいて、CRCロジック64が無効という指示を戻す理由は明らかでなく、非整列DDPセグメント112NA図2のデータ破損あるいは受信またはその両方の結果である可能性がある。かかるセグメントを無制限に再送信すると、非整列DDPセグメント112NAの場合にデッドロックを生じる恐れがある。起こり得るデッドロックを回避するために、インロジック32は、ステップS3に示すように、新たに受信したDDPセグメント162をリアセンブリバッファ34に送出し、セグメントの受信成功を確認するようにAckをスケジューリングし、接続をSLOW接続に格下げすることによって、ケースC、D、およびEを処理する。CRCロジック64が無効という指示を戻す理由が、整列DDPセグメント112におけるデータ破損であった場合、以下で説明するように、このエラーはアウトロジック40によって検出され、この場合、SLOW接続のデータ処理および接続は終了する。その他の場合、接続は永続的にSLOW接続のままである。しかしながら、以下で説明するように、有限再送信試行モードLimitedRetransmissionAttemptModeによって、この問題を防ぐことができる。図3のステップS4に戻り、インロジック32が、TCPセグメント106長がMPAフレーム109長より大きいと判定した場合、これは、TCPセグメント106が多数のDDPセグメント112を含むことを示す。この場合、ステップS11において、第1から最後までのDDPセグメント112において、CRCロジック64の妥当性確認結果を順次検査する。全てのDDPセグメント112が有効CRCを有する場合、すなわちYESの場合、全てのDDPセグメント112は完全にTCPセグメント106に含まれ、全て有効な、適切に整列されたDDPセグメント112である。この場合、ステップS7において、インロジック32は、受信したTCPセグメント106をRNIC16の内部データバッファ38に配置し、アウトロジック40によって処理することによって、高速経路モードでDDPセグメント112を処理する。これにより、受信したTCPセグメント106を、例えばデータシンク18のデータバッファ50のような宛先データバッファに配置する。更に、このTCPセグメント106の受信成功を確認するように、Ackをスケジューリングする。第1の故障が検出された場合、インロジック32は、CRC妥当性確認結果の検査を停止する。その処理について、ステップS12からS13に関連付けて説明する。ステップS12において、インロジック32は、第1のDDPセグメント112が無効CRCを有することがCRCロジック64によって判定されたか否かを判定する。YESの場合、インロジック32は、第1のDDPセグメント112を、単一のDDPセグメントの無効CRCの場合と同様に処理するステップS8。すなわち、インロジック32は、無効CRCを有する第1のDDPセグメント112を単一DDPセグメント112として扱い、更に先に進んで、何がCRCの無効を引き起こしたか、すなわち図3のケースAからEのどれが当てはまるか、および、どのようにこのケースを適切に扱うかを判断する。ステップS12の結果がNOである場合、すなわち第1のDDPセグメント112が有効CRCを有する場合、インロジック32は先に進んで、ステップS13において、中間または最後のDDPセグメント112を検査した場合にCRC無効が検出されたか否かを判定する。YESの場合、インロジック32図1はステップS9に進む。なぜなら、このエラーは、CRC無効を引き起こしたDDPセグメント112のデータまたはヘッダが破損していることを示すからであるすなわち、有効CRCを有する以前のDDPセグメントの長さ。すなわち、CRCエラーは、同一のTCPセグメント106内の中間または最後のDDPセグメント112上で検出された。これが意味するのは、先行するDDPセグメントが有効CRCを有し、従って、先行するDDPセグメントの長さは、無効CRCを有するセグメントのヘッダを指し示すということである。これは、ケースA図1の説明に一致する。従って、ケースAに示すように、ヘッダの位置は既知であり、このため、CRCエラーはデータ破損またはヘッダ破損のいずれかによって引き起こされたことがわかる。従って、この問題は、全TCPセグメントの再送信によって解決され、デッドロック状況が生じる危険はない。ステップS9において、TCPセグメントはドロップされ、セグメント受信は確認されない。ステップS13の結果がNOである場合、すなわち、中間または最後のDDPセグメント112がCRC無効を引き起こしたのではない場合、これは、最後のDDPセグメント112のMPA長フィールド114がTCPセグメント106境界を超えていること、すなわち、最後のDDPセグメントがTCPセグメント106境界の外にあることすなわち長すぎることを示す。この場合、インロジック32は、単一のDDPセグメントが長すぎるのと同じ状況として処理を行う。具体的には、インロジック32は、ステップS3に進んで、TCPセグメント106のデータ転送14Aをリアセンブリバッファ34に送出し、TCPセグメント106の受信が成功したことを確認するようにAckをスケジューリングし、接続をSLOW接続に格下げする。このようにして、デッドロックを回避する。RNIC16が、TCPセグメント106に含まれる多数のDDPセグメント112の1つをドロップすることを決めた場合、全TCPセグメント106はドロップされ、これによって、実施を簡略化し、処理する必要のあるケースの数を減らす。先に明確には論じていないが、インロジック32の上述の動作に関連付けて、他のデータ転送処理も実行可能であることは認められよう。例えば、TCPチェックサムロジック66図11によるチェックサム妥当性確認を含めて、RNIC16接続に属するTCPセグメントのフィルタリング、および、受信したセグメントのTCP/IP妥当性確認を行うことができる。また、インバウンドTCPセグメント106の処理は、MPACRCの計算、およびCRCロジック64図11によるこのCRCの妥当性確認を含む場合がある。CRC計算および妥当性確認の1つの具体的な実施形態については、以下で更に説明する。A.有限再送信試行モード検出されたエラーの原因の不明確さに関連した代替的な実施形態として例えば、図12のステップS10においてNOの場合は、かかる状況を生じる結果となり得る1つの例示的な判定である、有限再送信試行モードを実施して、再送信試行の回数を制限して、デッドロックを回避し、不必要にSLOW接続に変えられるFAST接続の数を減らすことができる。具体的には、上述のように、ケースC、D、およびEが表すいくつかの例では、検出されたエラーの原因が不明確であるために、接続をSLOW接続に格下げしステップS3、DDPセグメント112の整列が損なわれたためでなくデータ破損によってエラーが生じた場合には、接続が終了する可能性があるアウトロジック40によって。再送信試行の回数を制限するため、本発明は、接続コンテキスト42図10に追加のフィールドを提供して、接続を格下げする前にある回数の再送信を可能とする。具体的には、図10に示すように、接続コンテキスト42は1組のフィールド290を含む。これは、回復試行回数フィールドRecoveryAttemptsNum292、最後の回復シーケンス番号フィールドLastRecoverySN294、および最大回復試行回数フィールドMaxRecoveryAttemptsNum296を含む。RecoveryAttemptsNumフィールド292は、最後の更新以来、接続に対して実行された回復試行の回数を維持する。LastRecoverySNフィールド294は、最後に開始された回復動作のシーケンス番号SNを維持する。MaxRecoveryAttempsNumフィールド296は、接続を格下げする前にインロジック32が実行しなければならない回復試行の最大回数を規定する。図13を参照すると、動作において、インロジック32が、新しいインオーダ受信データ転送がエラーを含むことを検出した場合図13のステップS101として一般的に示す、接続をSLOW接続にすぐに格下げするのではなく図12のステップS3、インロジック32は、そのエラーを含むデータ転送について、ある回数の再送信を行うことになっている。ステップS101は、非整列のDDPセグメント112NAまたはデータ破損のいずれかによって引き起こされる多数のエラー判定について当てはまることは認められようステップS101は、例えば図12のステップS5のYESまたは図12のステップS10のNOに当てはまる。ステップS102において、インロジックは次に、このエラーを含むデータ転送についてこの送信試行を記録し、ステップS102において、RecoveryAttemptsNumを1だけ増やす。更に、インロジックは、LastRecoverySnを更新して、以前にストアしたシーケンス番号と新たに受信したがドロップしたデータ転送のものとのうち最大のシーケンス番号をストアする。すなわち、インロジックは、LastRecoverySNを更新して、少なくとも1つの以前に受信したエラーを含むデータ転送と新たに受信したエラーを含むがドロップしたデータ転送とのうち最大のシーケンス番号をストアする。新たに受信したエラーを含むデータ転送のシーケンス番号を、ストアされた最大のシーケンス番号と比較することによって、新たに受信したエラーを含むデータ転送が、最大のシーケンス番号より大きいシーケンス番号を有することが判定される。LastRecoverySnの記録の重要性は、以下で明らかになる。次に、ステップS103において、インロジック32は、RecoveryAttemptsNumフィールド292がMaxRecoveryAttemptsNumフィールド296より大きいか否かを判定する。NOの場合、ステップS104において、インロジック32はTCPセグメント106をドロップし、受信成功を確認せず、これによってTCPセグメントの再送信が行われる。次いで、処理はステップS1図12に戻る。TCPセグメント106が破損していた場合、再送信によって破損を修復し、データ転送14AがFAST接続としてメモリに直接配置されるようにする図12のステップS7。あるいは、処理が引き続き他のエラー検出へと戻る場合図12のステップS10、RecoveryAttemptsNumフィールド292は、最終的にMaxRecoveryAttemptsNumフィールド296より大きくなり、結果としてステップS103でYESになる。この場合、インロジック32はステップS105に進み、ここでインロジック32は接続をSLOW接続に格下げし、エラーを含むデータ転送14Aをリアセンブリバッファ34に配置し、このTCPセグメントの受信成功を確認するAckをスケジューリングする。上述のプロセスは、エラーを含むデータ転送の各々について行われる。図14は、有限再送信試行モードの別のコンポーネントを表す。これは、データ破損が通常は多数の連続したTCPセグメントにおいて発生するのでなく、非整列セグメントはいくつかの以降のTCPセグメントに影響を与え得るという事実に対処するものである。例えば、FAST接続は、例えば5時間のような長い時間期間にわたって維持される場合があり、例えば1時間に1度のように時々データ破損が生じ、CRC妥当性確認が失敗する恐れがある。これが起こると、エラーを含むデータ転送すなわち破損したセグメントがドロップされるたびに、RecoveryAttemptsNumフィールド292が増えることがある。このプロセスは、異なるセグメントが異なる時間期間でデータ破損のためにドロップされ、いくつかのおそらくは1つの再送信動作の後に、これらのセグメントが受信成功し、メモリに配置されるという状況に対処する。従って、これらのセグメントのための回復動作は正常に完了しており、回復されるデータ破損のケース、すなわち新たな誤ったセグメントの受信によって新たな回復モードに入る場合は、カウントされない。有限再送信試行モードから出るためには、ステップS105において、新たに受信したインオーダのデータ転送のTCPセグメントシーケンス番号SNすなわちInOrderTCPSegmentSNが、LastRecoveryシーケンス番号SN図10のフィールド294より大きいか否かについての判定を行う。すなわち、FAST接続に属する新たに受信したインオーダの各TCPセグメントのシーケンス番号を、1つ以上の以前に受信したエラーを含むデータ転送から選択されたストアされた最大シーケンス番号と比較する。もっと大きいSNを有するアウトオブオーダのセグメントの受信は、エラー回復が完了したことを意味しないことに留意すべきである。しかしながら、回復が完了していることを示す1つの指示は、回復モードに入らせたセグメント複数のセグメントの後に送信されたTCPセグメントが受信されることである。この状況は、InOrderTCPSegmentSNをLastRecoverySNと比較することによって判定することができる。この判定は、この接続のために受信されたTCPセグメントの処理中の実質的にどの段階においても行うことができる。例えば、図12のステップS9の後、または図13のステップS102の前である。インオーダセグメントSNがLastRecoverySnより大きい場合、すなわち新たなTCPセグメントが受信された場合、および、ステップS105においてYESが判定された場合、ステップS106において、RecoveryAttemptsNum図10のフィールド292はリセットされる、すなわちゼロにセットされる。上述の例に関連して、ステップS105は、例えば5時間のような長い時間期間の後、FAST接続をSLOW接続に不必要に格下げすることすなわちRecoveryAttemptsNumがMaxRecoveryAttemptsNumを超えるのでを防ぐ。この場合、ドロップしたセグメントは、データ破損のためにドロップしており、送信側がセグメントを再送信した後で正常に受信され、整列セグメントとして処理された。ステップS105においてNOである場合、またはS106の後、セグメント処理は通常のように、例えば図12のステップS1に進む。上述の処理を用いて、許可される再送信の回数は、MaxRecoveryAttemptsNumフィールド296を設定することによってユーザが規定することができる。有限再送信試行モードは、図13から図14および図12のステップS10においてエラー検出に関して上述したが、有限再送信試行モードは、ステップS10のエラー検出だけでなく適用可能であり、以下で更に説明することは認められよう。有限再送信試行モードは、以下で説明するD.TCP再送信プロセスの高速化において、有利に使用可能であることに留意すべきである。この場合、ULPの問題点のためにセグメントがドロップした場合、即座に複製AckDuplicateAckを送信する。B.接続の格下げこれより、図15を参照して、高速経路モードにおいて1つ以上のアウトオブオーダの受信DDPセグメント112を宛先データバッファ50に配置した後に接続を格下げする図12のステップS3という独特の状況の処理について説明する。図15に示すように、パケットPktと標示された4つのTCPセグメントは、アウトオブオーダで、すなわち3、4、1、2の順序で受信される。接続をSLOW接続に格下げすると、格下げの時点で受信された全てのデータはリアセンブリバッファ34に配置され、インオーダに、すなわちPkt1、2、3、4にリアセンブルされる。この場合、TCPプロトコルに従って、インロジック32はそれらのセグメントが受信されたことの記録を維持する。まれではあるが、例えばPkt3斜線を付けているのようなセグメント複数のセグメントが宛先データバッファ50に直接配置されるという状況が生じ得る。この状況では、インロジック32が全てのデータが受信されたと見なしたとしても、リアセンブリバッファ34内で通常はパケット3Pct3を保持する位置が、無意味なデータ、すなわち隙間または穴で埋められることになる。処理が正しくないまま継続することができた場合、アウトロジック40がリアセンブリバッファ34を宛先データバッファ50に転送すると、高速経路モードで先に転送されたパケット3Pkt3は、無意味なデータによって上書きされ、データを破損させてしまう。ハードウェアの複雑さを増すことなくこの問題を解決するため、代替的な実施形態では、接続がFAST接続である場合に受信したアウトオブオーダのセグメントすなわち図15のPkt3について忘れるように、インロジック32がTCPロジックに指示する。具体的には、インロジック32は、ステップS3において接続がSLOW接続に格下げされる場合図12にアウトオブオーダで配置されたデータ転送についてのTCPホールをクリアするように構成され、受信を停止し、これらのパケットを受信したことを送信側に報告するSACKオプション。この結果、送信側は、宛先データバッファ50に直接配置されたアウトオブオーダのセグメント複数のセグメントすなわちPkt3を含めて、全ての承認されていないデータを再送信する。再送信されたデータを受信すると、これはリアセンブリバッファ34に書き込まれて、アウトロジック40がリアセンブリバッファ34からデータを転送すると、宛先データバッファ50において、アウトオブオーダの直接配置されたセグメントは全て上書きされる。この機能性が効果的に示すのは、この接続において、RNIC16が、宛先データバッファ50にアウトオブオーダで配置されたセグメントをドロップするということである。かかる手法によって、リアセンブリバッファ34においてインオーダのストリームに隙間があいているというケースがなくなり、かかる挙動に至るまれな状況のために目に見える性能劣化が生じることを防ぐ。C.接続の格上げ別の代替的な実施形態として、本発明は、図16に示すような接続格上げ手順を含むことができる。上述の高速経路モード手法の目的は、整列DDPセグメント112を保持する接続について、リアセンブリバッファ34の回避を可能とすることである。しかしながら、FAST接続においても、データソース12または中間ネットワークデバイスは、間欠的な非整列DDPセグメント112NAを発生する可能性があり、これによって、FAST接続は上述の技法に従ってSLOW接続に格下げされる。間欠的な挙動は、例えば、TCP再送信の間に最大セグメントサイズMSSが変化すること、または他の単発的な状況によって生じる場合がある。図16に示すように、この状況から回復するために、本発明は、例えばステップS3図12における先行する格下げの後に、SLOW接続からFAST接続へと接続の格上げを提供することができる。格上げに対応するためには、多数の状況が存在しなければならない。代替的な実施形態の第1のステップS31では、インロジック32は、リアセンブリバッファ34が空であるか否かを判定する。NOの場合、ステップS32において、格上げを行わない。ステップS31においてYESが判定されると、次いでステップS33において、インロジック32は、整列DDPセグメント112が受信されているか否かを判定する。NOの場合、ステップS32において、格上げを行わない。ステップS33においてYESが判定されると、次いでステップS34において、インロジック32は、接続が、例えばデータソース12のような送信側によってFAST接続として始められたか否かを判定する。ステップS34においてNOが判定されると、ステップS32において、格上げを行わない。ステップS34においてYESが判定されると、ステップS35において、接続はFAST接続に格上げされる。D.TCP再送信プロセスの高速化別の代替的な実施形態では、TCPセグメント106が受信されるが、例えばDDPセグメントの破損、無効なCRC等のようなRDMAまたはULPの問題点のためにドロップされるという状況に対処する。上述の手順に従って、TCPセグメント106が受信されてTCPチェックサムを通過するが、セグメントをカバーするTCPAckを送信することなくインロジック32によってドロップされるすなわち図12のステップS9ということは数多い。従来の手順では、次いで、それらのパケットの再送信試行が行われる。具体的には、基本的な方式いわゆるRenoプロトコルでは、TCP送信側は、3つの複写Ackすなわち、インオーダで受信されたデータのシーケンス番号を進めないAckを得た場合、高速再送信モードを開始する。例えば、2つのTCPセグメントAおよびBを想定し、TCPオーダにおいてセグメントBがセグメントAの次に来ると想定する。セグメントAがドロップされると、受信側は、セグメントBを受信した場合にのみ複写Ackを送信する。この複写Ackが示すのは、私はセグメントAを待っているが、別のセグメントを受信したということ、すなわちセグメントBである。Renoプロトコルのもとでの高速再送信モードでは、送信側は、1つのセグメントを送信し、次いで別の3つの複写Ackを待って、別のパケットを再送信する。もっと進んだ方式いわゆるNew-Renoプロトコルのようなでは、高速回復モードにおいて受信した複写の各々について、セグメントの再送信が可能である。このプロセスの背後にある論理は、1つのセグメントがネットワークから出ると、送信側は別のパケットをネットワークに置くことができるということである。再送信を容易にするために、本発明の代替的な実施形態に従って、インロジック32は、TCPによって有効と判定され上位レイヤプロトコルULPの決定例えば図12のステップS9に基づいてTCPによってドロップされた受信TCPセグメントをカバーする第1の複写TCP肯定応答Ackを発生し、この複写TCPAckを送信する。上述のように、ULPは、MPAプロトコル、DDPプロトコル、およびRDMAプロトコルのうち1つ以上を含むことができる。TCPセグメントがインオーダかアウトオブオーダかに関わらず、次のインオーダTCPセグメントが受信されていない場合でも、TCPセグメントについて第1の複写TCPAckを発生する。また、インロジック32は、次のアウトオブオーダ受信TCPセグメントをカバーする第2の複写TCP肯定応答Ackを発生し、この第2の複写TCPAckを送信することができる。この上述の処理が効果的に示すのは、次のインオーダのセグメント例えば上述の例ではセグメントBがまだ受信されていない場合があるとしても、複写Ack例えば上述の例ではセグメントAのためのを発生するということであり、このため、上述の再送信ルールのもとで送信側を再び高速経路モードにするプロセスを高速化しなければならない。更に具体的には、セグメントBが受信されていない場合であっても、送信側は、セグメントAすなわち有効TCPセグメントが受信され、ULPの問題点のためにドロップされたことを知っている。この結果、再送信開始の前に多数の複写Ackを受信しなければならない場合、追加の複写Ackは、もっと早期に送信側に再送信手順を開始させる。この手法は、TCPの原理に反する。なぜなら、TCPセグメント106はULPに正常に配信され、ULPの問題点無効CRCのためにドロップされたからである。従って、このパケットはドロップされず、IPプロトコルによる再順序付けもされなかった。この手法は、図13に概要を示したように、RNIC16が有限再送信試行モードを実施する場合、すなわちステップS104でAckを送信する場合、特に有益である。E.CRC計算および妥当性確認入来するイーサネットフレームの従来の処理は、フィルタリングプロセスから始まる。フィルタリングの目的は、有効なイーサネットフレームを無効なものを分離することである。無効フレームは、破損したフレームではなく、RNIC16によって受信してはならないフレームである。例えば、MACフィルタリングすなわちMACアドレスに基づくフレーム選択、仮想ローカルエリアネットワークVLANフィルタリングすなわちVLADタグに基づくフレーム選択等である。有効フレームは、RNIC16内に入ることができ、異なるタイプに分離される。これらのタイプの1つがTCPセグメントである。フィルタリングプロセスは実行中に行われ、全イーサネットフレームの蓄積交換処理を行う必要はない。TCPセグメント処理の次のステップは、TCPチェックサムの計算および妥当性確認である。チェックサムの計算は、エラーなしでデータが送信されたか否かを判定するものであり、通常はデータブロックにおける二進値を用いて送信時の値を計算し、何らかのアルゴリズムを用いて、その結果と共にデータをストアし、受信時に同じように計算した値と比較する。チェックサムの計算および妥当性確認には、全TCPセグメントペイロードをカバーするために、全TCPセグメントの蓄積交換処理が必要である。従来、巡回冗長検査CRCの計算および妥当性確認は、通常、TCPチェックサム妥当性確認の後に行われる。すなわち、接続をRDMA接続として認識した後、および、DDPセグメントの境界を、以前のDDPセグメント長またはMPAマーカのいずれかを用いて検出した後である。CRCの計算および妥当性確認は、正確にデータを送信したか否かを判定するため、メッセージを所定の長さに分割し、これは被除数として用いられ、固定の除数で除算される。計算の剰余は、メッセージに追加されて、受信側によって行われる同一の計算により比較される。また、CRCの計算および妥当性確認には、全DDPセグメントの蓄積交換が必要であり、これは待ち時間を増大させ、ストアのために大きなデータバッファを必要とする。CRC計算の1つの要件は、DDPセグメント境界を知ることであり、これは、先行するDDPセグメント長を用いること、またはMPCマーカ110図2を用いることのいずれかによって求められる。マーカに基づいた決定は、多くの例外およびコーナーケースcornercaseが多いので、極めて複雑である。また、部分的に受信したDDPセグメントのCRC計算は、複雑なプロセスである。上述の問題に対処するため、図11に示すように、本発明は、TCPチェックサムロジック66によるTCPチェックサム計算および妥当性確認と平行して、同じ蓄積交換バッファ68を用いて、CRCロジック64によってCRC計算および妥当性確認を行う。更に、本発明は、DDPセグメント境界の位置をすぐに特定してその後にDDPセグメントCRCを計算し妥当性確認するのではない。本発明は、CRCを計算し、その後にDDP境界を求めることによって、動作の順序を切り替える。この切り替えを行うため、CRCロジック64は、各TCPセグメントがセグメントがRDMA接続に属することがわかる前に整列DDPセグメントで開始すると想定する。更に、本発明は、TCPペイロード127図2の最初の2バイトが、MPAフレームのMPA長フィールド114図2であると想定する。次いで、この長さを用いて、DDPセグメント境界を識別し、そのセグメントのCRCを計算する。妥当性確認ユニット44が、TCPセグメント106において最初の可能なDDPセグメント112の境界を識別した後、これは、TCPセグメントペイロード127のその部分についてのチェックサム計算と同時に、そのDDPセグメントのCRCを計算し妥当性確認し、次いで、同じTCPセグメント106に含まれる次の存在し得るDDPセグメント112存在する場合に進む。TCPセグメント106において発見される各存在する可能性のあるDDPセグメントでは、CRC妥当性確認の結果は、有効、無効、または長すぎるという場合がある。CRC妥当性確認の結果はストアされて、図12に関して上述したように用いられる。上述のようにCRCを実際に計算するために、TCPセグメント106のペイロードを処理する場合、インロジック32は、TCPセグメント106内のどこにMPAマーカ110があるのかを知る必要がある。図2に関して上述したように、MPAマーカ110は、TCPセグメント106において512バイトごとに配置され、第1のMPAマーカは、接続コンテキスト42のStartNumフィールド248図10としてストアされているTCPヘッダ126図2における初期シーケンス番号から512バイトである。しかしながら、各MPAマーカ110を評価することでは、StartNum248図10に対するその位置は明らかにならない。更に、MPAマーカ110は、CRCデータ116によってカバーされているが、MPA長フィールド114には含まれず、これはMPAフレームのペイロードのみを含む。従って、MPAマーカ110を識別するためには、RNIC16は、StartNum248図10を知る必要があり、これを接続コンテキスト42からフェッチしなければならない。しかしながら、接続コンテキスト42の読み取りは、TCP処理の間に行うのは極めて不便である。これは、処理において極めて早期に行われ、パケット処理を分解するかまたは停止させるからである。接続コンテキスト42のフェッチを低減するまたは削除するために、本発明は、4つの代替案を提示して、DDPセグメント112長のMPACRCを計算し妥当性確認するために必要であるDDPセグメント112長の正確な計算を可能とする。これらのオプションについて、以下の節で述べる。1.接続コンテキストプリフェッチprefetch方法DDPセグメント112長を正確に計算するための第1の代替的な実施形態は、StartNumフィールド248図10としてストアされている初期シーケンス番号の接続コンテキスト42のプリフェッチを実施することを含む。ここでは、MPA仕様の変更は提示しない。現在のMPA仕様では、TCPセグメント106内のMPAマーカ110の位置を識別するために、初期シーケンス番号StartNumを知ることが必要である。初期シーケンス番号は、TCP接続属性であり、これは接続ごとに異なり、接続確立時に取り決められる。従って、StartNum248図10は、接続ごとに維持される。MPAマーカ110の位置を識別するため、CRCロジック64図11は、512を法とした特定のセグメントのシーケンス番号SeqNumおよびStartNumの差SeqNumStartNumがゼロであることを調べる。すなわち、各TCPセグメント106のヘッダがそのペイロードの第1のバイトのシーケンス番号を保持するので、CRCロジック64は、特定のセグメントのシーケンス番号とStartNum248との間の差を取り、次いでこの位置から始めて、512バイトごとにマーカを位置付けることによって、どこでマーカを探すべきかを判定することができる。MPA仕様は、上述のマーカ検出方法を定義する。このように、ハッシュ照合TCPタプルに基づくおよび接続コンテキスト42のプリフェッチを、TCPチェックサム妥当性確認を行う前に実行することができる。これは、通常の接続コンテキスト42のフェッチフローである。RNIC16が接続コンテキスト42を取得したい場合、まず、このコンテキストがどこに位置付けられているかを理解するか、または接続IDを得る必要がある。TCPセグメント106ヘッダは、TCPタプルIPアドレスソースおよび宛先ならびにTCPポートソースおよび宛先を保持する。タプルは、ハッシュ関数に対する入力である。ハッシュ関数の出力は接続IDである。むろん、異なるタプルに対して同じ接続IDを使う結果となる場合があり、これは衝突と呼ばれる。衝突を処理するために、RNIC16は、接続コンテキスト42を読み取り、接続コンテキスト42におけるタプルをパケット内のタプルと照合し、一致しない場合、RNIC16は次の接続コンテキスト42に対するポインタを取得する。RNIC16は、一致を見出すまで、またはセグメントが既知の接続のどれにも属さないと認識されるまで、タプル照合を続ける。このプロセスによって、TCPストリーム内でMPAマーカ110の位置を特定することができる。この結果、CRC計算および妥当性確認は、TCPチェックサム妥当性確認と同時に行うことができる。2.初期シーケンス番号取り決め方法第2の代替的な実施形態では、MPA仕様に多数の変更を行うことによって、接続コンテキストのフェッチを行うことなく、DPセグメント長を正確に計算することができる。第1に、MPA仕様におけるMPAマーカ110の配置の定義を変更する。上述の接続コンテキストプリフェッチ方法の1つの欠点は、TCPセグメント106においてMPAフレーム109の境界を識別するために、ハッシュ照合および接続コンテキスト42のプリフェッチを行う必要があるということである。これを防ぐため、本発明は、MPAマーカ110を512バイトごとに配置し、初期シーケンス番号SNStartNum248としてセーブされているで開始する512バイトごとこれは、上述の512を法としたSNStartNum処理を必要とするには配置しない。このように、MPAマーカ110の位置は、MPAマーカ110の位置を特定するための512を法としたシーケンス番号プロセスによって求めることができ、接続コンテキスト42のフェッチは必要ない。本実施形態によるMPA仕様の第2の変更は、1つのマーカが2つのDDPセグメント112間で分割される状況、すなわち、初期シーケンス番号がワードに整列していない状況を回避するように機能する。結果として、512を法とするシーケンス番号のプロセスは、全ての環境で機能するわけではない可能性がある。なぜなら、標準的なTCP実施では、初期SNは、ランダムに発生したバイトに整列した値を有することができるからである。すなわち、初期シーケンス番号がワード整列であるか否かは、RNIC16によって制御することはできない。このため、所与の接続についてのTCPストリームは、必ずしもMPAマーカ110で開始するわけではない。従って、CRCロジック64が、単に512を法とするシーケンス番号プロセスを用いることによってマーカ110の位置を選ぶ場合、得られるマーカはバイト整列位置に配置されている可能性があるが、これは許容できない。この状況を回避するため、本発明は、MPA取り決め段階の間に交換されるMPAフレームに、パディング、すなわち、いわゆるMPA要求/応答フレームを追加して、RDMAモードに移行する場合のRDMA接続の初期SNをワードに整列させる。すなわち、図17に示すように、初期SNをワードに整列させるために必要なバイト数を含むTCPセグメント106のMPA要求/応答フレーム152に、補正ファクタ150を挿入する。補正ファクタ150の正確な位置を図示する必要がないことは認められよう。このように、CRCロジック64は、512を法とするシーケンス番号プロセスを実施して、接続コンテキストフェッチを行うことなく、TCPストリーム内でのMPAマーカ110の正確な位置を得ることができる。MPA仕様の上述の変更を用いて、本発明は、接続コンテキスト42のプリフェッチを行うことなく、MPAマーカ110の位置を特定し、MPAセグメントの長さを適正に計算することができる。3.MPA長フィールド変更方法接続コンテキストフェッチを行うことなくDDPセグメント112長を正確に計算するための第3の代替的な実施形態では、MPA仕様におけるMPA長フィールド114の定義を変更する。従来、MPA長フィールド114は、各MPAフレーム109のULPペイロードの長さを保持するように規定され、MPAレイヤによって追加されたマーカ110、パディング121図2、CRCデータ116は除く。しかしながら、この情報では、TCPセグメント106が提供する情報を用いてMPAフレーム境界の位置を特定することができない。これに対処するため、この代替的な実施形態によれば、MPA仕様におけるMPA長の定義を変更して、次のものを含む全MPAフレーム109の長さを明記する。すなわち、MPA長フィールド114の最上位14ビットMSB、ULPペイロード118長、MPAマーカ110、CRCデータ116、MPAG長フィールド114の最下位2ビットLSB、およびパディング121における有効ビットである。この修正した定義によって、そのMPAフレームに埋め込まれた全てのMPAマーカ110の位置を特定することなく、MPA長フィールド114を用いて、MPAフレーム109の境界を検出することができる。MPAレイヤプロトコルは、マーカ110、CRCデータ116、およびパディング121を取り除く役割があり、ULPDDPレイヤにULPペイロード長を提供する。図18を参照すると、このMPA長の定義を用いて、CRCロジック64は、以下のプロセスによってMPAフレーム109の境界の位置を特定する。ステップS100において、CRCロジック64は、MPAフレーム109の最初のワードがゼロに等しいか否かを判定する。YESの場合、インロジック32図9は、ステップS102において、次のワードからMPA長フィールド114を読み取る。これは、マーカ110が2つのMPAフレーム109間にある場合に当てはまる。この状況では、ステップ104に示すように、対のワード内にMPA長フィールド114の位置を特定する。ステップS100においてNOと判定された場合、このワードはMPA長フィールド114を保持する。ステップS106において、MPA長を用いて、このMPAフレーム109をカバーするCRCデータ116の位置を探し出す。次いで、上述のプロセスは繰り返し、TCPセグメント106に埋め込まれた他のMPAフレーム109の位置を特定する。この実施形態によって、接続コンテキスト42からの追加の情報を用いずに、MPAフレーム109の境界の位置を特定することができる。4.マーカなしのカットスルー実施第4の代替的な実施形態では、CRC計算および妥当性確認に関して、マーカなしのカットスルー実施を用いる。これについて以下で説明する。DDPセグメント長を正確に計算するための上述の3つの代替的な実施形態の欠点は、各々が、MPA仕様の変更または接続コンテキスト42のプリフェッチを必要とすることである。この実施形態は、到着するMPAフレームのCRCを計算するために接続コンテキスト42のプリフェッチを行うことなく、更に、MPA仕様に対する追加の変更を行うことなく、インバウンドセグメントのカットスルー処理を実施する。更に、この実施形態は、MPAマーカを用いることなく、アウトオブオーダの直接データ配置を可能とする。この実施形態は、MPA仕様の新しい更新バージョンに従って、所与の接続についてマーカなしのオプションを取り決めることができる受信側の能力に部分的に基づいている。具体的には、更新されたMPA仕様によって、MPA受信側は、所与の接続についてマーカを用いるか否かを決定することができ、送信側は受信側の決定を尊重しなければならない。この実施形態は、妥当性確認ユニット44ロジックを変更して、TCPチェックサム計算と同時に、接続コンテキスト42のプリフェッチを行うことなく、実行中にCRC計算を行うことを可能とする。CRC計算は、マーカを用いた場合について説明したのと全く同様に行う。すなわち、本発明は、TCPセグメントが整列DDPセグメントで開始することを想定し、MPA長フィールドを用いてCRCの位置を探し出し、次いでCRCを計算し妥当性確認する。しかしながら、この実施形態における相違は、MPAヘッダのMPA長フィールドが与えられれば、DDPセグメント長を計算する場合にマーカを考慮する必要がないということである。図19を参照すると、この実施形態の第1の代替案に関連したインロジック32の機能性を示すフロー図が示されている。インロジック32の機能性の多くは、図12に関して上述したものとほぼ同様であることは認められよう。明確さの目的のため、インロジック32の機能性が図12に関して上述したものとほぼ同様である場合、ステップを破線で示す枠内で繰り返し示す。更新したMPA仕様のもとで、受信側は、接続初期化の時点で特定の接続についてマーカなしオプションを取り決める。図19に示すように、この実施形態では、ステップS201において、インロジック32は、インバウンドTCPセグメント106がマーカ110を含むか否かを判定する。YESの場合、インロジック32は図12に示すような処理に進み、上述のように、他の何らかのCRC計算および妥当性確認の方法を用いる。NOの場合、ステップS202において、インバウンドMPAフレーム109は、TCPチェックサムロジック66と同じ蓄積交換バッファ68を用いて実行中にCRCの計算および妥当性確認を行うが、接続コンテキスト42のフェッチは行わない。また、図12に示すのと同様のステップS2およびS3で、接続がSLOW接続であるか否かの判定を行うことができる。CRC妥当性確認の結果は、以下のうちの1つであり得る。1MPAフレーム109の長さがTCPセグメント106の長さに一致し、MPAフレーム109が有効MPACRCを有する。2MPAフレーム109の長さがCGPセグメント106の長さに一致するが、MPAフレーム109は無効CRCを有する。3MPAフレーム109の長さがTCPセグメントの長さより大きい、4MPAフレーム109の長さがTCPセグメント106の長さよりも小さい。1の場合、インロジック32は、図12のステップS4からS7とほぼ同様に動作する。すなわち、MPAフレーム109がTCPセグメント106と同じ長さを有し図12のステップS4およびS5、かつ有効MPACRCを保持するステップS6場合、フレームは有効MPAフレームと見なされ、更に別の処理のために、内部データバッファ38を介してアウトロジック40に渡され、更に、高速経路モードで宛先データバッファ50に渡される。2において、MPAフレーム109はTCPセグメント106と同じ長さを有する図12のステップS4およびS5が、無効CRCを有する図12のステップS6場合、インロジック32は、図12に関して説明したのとは異なる方法で動作する。具体的には、受信したMPAフレーム109がMPAマーカ110を含まないので、図12のステップS10におけるようにマーカ関連情報を回復のために用いることができない。これによって、対処する必要があるケースは2つのみ生じる。ケースA、すなわち、MPAフレーム109が以前に受信したセグメントおよび妥当性確認されたMPAフレーム109の長さによって参照される場合図12のステップS8において判定したように、および、ケースB、すなわち他の全ての場合である。ケースAでは、MPAフレーム109は破損し、ケースBでは、MPAフレーム109は破損しているかまたは整列していない可能性がある。双方の場合で、受信したTCPセグメント106はドロップされ図12のステップS9、受信は確認されない。この場合、図13に関連して述べた有限再送信試行モードを実施して、そのTCPセグメント106のドロップから回復することができる。これによって、送信側は、ドロップしたTCPセグメント106を再送信し、いずれかのあり得るデータ破損を解決することができる。MPAフレーム109がTCPセグメント106に整列していなかった場合、上述のように、有限再送信試行モードは、接続をSLOW接続に格下げして終了することになる。3において、MPAフレーム109の長さがTCPセグメント106の長さを超えている図12のステップS5場合、MPAフレーム109はTCPセグメント106に整列していないか、または、その長さが破損している。この場合、受信したTCPセグメント106はドロップされ図12のステップS9、TCPは受信を確認しない。この場合も、図13に関して説明した有限再送信試行モードを実施して、そのTCPセグメント106から回復することができる。これによって、送信側は、ドロップしたTCPセグメントを再送信し、いずれかのあり得るデータ破損を解決することができる。ここでも、MPAフレーム109がTCPセグメント106に整列していない場合、上述のように、有限再送信試行モードは、接続をSLOW接続に格下げして終了することになる。4において、MPAフレーム109の長さがTCPセグメント106より小さい図12のステップS4か、またはTCPセグメント106が多数のMPAフレーム109を保持する可能性がある送信側がパッキングオプションを実行する場合、インロジック32は、受信したTCPセグメント106に埋め込まれた全てのDDPセグメント112のCRCを順次チェックする図12のステップS11からS13。全てのDDPセグメント112が有効CRCを有する場合、インロジック32は、そのTCPセグメント106の受信を承認し、全てのMPAフレームは、更に別の処理のために、高速経路モードで転送される図12のステップS7。DDPセグメント112のうち1つが無効CRCを有する場合、または最後のセグメントが完全にはTCPセグメントに含まれていない場合図12のステップS12からS13、全TCPセグメントはドロップされ図12のステップS9、インロジック32はそのTCPセグメントの受信を確認しない。上述のように、図13に関連して述べた有限再送信試行モードを実施して、そのTCPセグメント106から回復することができ、これによって、送信側は、ドロップしたTCPセグメントを再送信し、いずれかのあり得るデータ破損を解決することができる。MPAフレーム109がTCPセグメント106に整列していなかった場合、上述のように、有限再送信試行モードは、接続がSLOW接続に格下げして終了することになる。図20に移ると、この実施形態に関連したインロジック32の機能性を示し、有限再送信試行モードおよびTCP再送信高速化の態様を含む別の代替的なフロー図が示されている。図19とは異なり、インロジック32の機能性は、図12に比べて大幅に簡略化されている。明確さの目的のため、インロジック32の機能性が図12に関連して上述したものとほぼ同様である場合、ステップを破線で示す枠内で繰り返し示す。図20において、ステップS151からS153は、図12のステップS1からS3とほぼ同一である。ステップS154において、インロジック32は、CRC妥当性確認が合格したか否かを判定する。この評価は、図12のステップS4とは異なり、DDPセグメントごとに指示を与えるのではなく、CRCロジック54はCRCValidationPassedビットを提供する。これは、受信したTCPセグメント内の全DDPセグメントのCRC妥当性確認の成功または失敗を示す。受信したTCPセグメントに含まれる全てのDDPセグメントについてCRC妥当性確認が合格した場合には、このビットがセットされ、セグメントの1つについてCRC妥当性確認が不合格であった場合または最後の唯一のセグメントが長すぎた場合には、このビットはクリアされる。NOの場合、インロジック32はステップS155に進み、RecoveryAttemptsNum図10のフィールド292が、MaxRecoveryAttemptsNum図10のフィールド296より大きいか否かを判定する。YESの場合、インロジックはステップS153に進み、DDPセグメントをリアセンブリバッファ34に配置し、Ackを送信し、接続をこれがFAST接続であった場合SLOW接続に格下げする。ステップS155においてNOの場合、次いでステップS156において、TCPセグメント106をドロップし、確認はスケジューリングされない。更に、RecoveryAttemptNum図10のフィールド292を1だけ増分し、LastRecoverySN図10のフィールド294を更新する。ステップS154に戻り、判定結果がYESの場合、インロジック32は、ステップS157に進み、新たに受信したインオーダのデータ転送シーケンス番号インオーダSNがLastRecoverySN図2のフィールド294より大きいか否かを判定する。YESの場合、次いでステップS158において、インロジック32は、RecoveryAttemptsNum図2のフィールド292をクリアする、すなわちこれをゼロにセットする。ステップS157においてNOの場合、またはステップS158の次に、ステップS159において、セグメントを宛先データバッファ50に配置することによって、セグメントを高速経路モードで処理する。また、ステップS159は、TCP再送信高速化オプションに関連付けて述べたように、複写Ackの実施を含むことができる。上述の図20の実施形態は、本発明のカットスルーモードおよび有限再送信試行モードおよびTCP再送信高速化オプションを、MPAマーカを用いることなく実施する。III.アウトロジックアウトロジック40図9は、RDMAメッセージごとの情報を保持することなく、RDMAメッセージのインオーダ配信を実行する。対処される状況は2つある。すなわち、1送信メッセージを除く全てのRDMAメッセージについて、および、2RDMA送信メッセージ、である。図6から図8に戻って、アウトロジック40図9の動作を説明する。アウトロジックは、上述のように、高速経路モードで配置された内部データバッファ38図9からの整列DDPセグメント220を処理し、整列DDPセグメントのデータ配置および受信側データバッファへの配信を行う。本明細書中で用いる場合、配置は、データを実際にバッファ内に置くプロセスを示し、配信は、データ転送の完了を確認するプロセスを示す。配置は、セグメントおよびメッセージの双方に適用可能であるが、配信はメッセージのみに適用される。RDMAプロトコルのもとで、整列DDPセグメントは、アウトオブオーダで配置される場合があるが、配信は、整列DDPセグメントの全てがインオーダに配置されるまで行われない。例えば、3つの整列DDPセグメント1、2、および3について、セグメント2および3が最初にセグメント1なしで配置される場合、セグメント1が配置されるまで配信は行われない。A.配置配置に関して、アウトロジック40は、RDMA読み取りメッセージを除いて、RDMAメッセージの従来の配置を行う。これについて、以下で述べる。タグ付きDDPセグメントに関して、例えば図4に戻ると、RDMAプロトコルに従って、タグ付きDDPセグメントのヘッダ124は、受信側の以前に登録したメモリ領域例えば図7のメモリ領域232のアドレスを保持する。上述したように、このアドレスは、メモリ領域/ウインドウ例えばRDMA書き込みメッセージについて図7のメモリ領域232内にある宛先バッファを示す開始タグSTag、この領域/ウインドウにおけるターゲットオフセットTO、およびトランザクション長セグメントペイロードを含む。この場合、データ配置は、従来の方法でアウトロジック40によって行われ、接続コンテキスト42図9から何ら追加情報を検索しない。従来のアドレス翻訳および保護ATP:AddressTranslationandProtectionプロセスは、STagおよびTOを、宛先データバッファを記述するメモリ領域の物理バッファのリストに変換するものであり、これは、アウトロジック40によるデータ配置より前に行われる。RDMA読み取りメッセージ等のタグなしDDPセグメントに関して、図8を参照すると、RDMAプロトコルは、待ち状態のインバウンド読み取り要求222の最大数を規定する。これは、交渉時に交換される。各RDMA読み取りメッセージ204は、単一のDDPセグメント222を消費する。RNIC16がRDMA読み取りメッセージ204を受信すると、これは、RDMA読み取り応答WQE216RRを読み取りキュー214にポストする。別の例では、図6を参照すると、各送信メッセージ200は、例えばデータシンク18図9のような応答側の受信キューRQ212に配置される。上述のように、各受信キューRQ212は、制御命令が配置されるバッファであり、ペイロードが配置されるWQE216Rを含む。受信キューRQ212は、WQE216Rを含む。各WQE216Rは、コンシューマによってポストされた受信WR208Rを記述する制御情報を保持する。また、各WQE216Rは、そのWR208Rにおいてポストされたコンシューマバッファ複数のバッファを指し示す。それらのバッファを用いて、ペイロードを配置する。従って、各メッセージ200は、WQE216Rを消費する。図21を参照すると、図8と同様のRDMA読み取りメッセージ204およびRDMA読み取り応答206が表されている。しかしながら、本発明によれば、読み取りキュー414は、循環バッファとして実施される特別なワークキューWQとして設けられ、この循環バッファの各エントリは、送信ロジックによって作成する必要があるRDMA読み取り応答を記述するWQE216RRである。これによって、アウトオブオーダのRDMA読み取り要求222を容易かつ効率的に配置することができる。なぜなら、各インバウンドRDMA読み取り要求ごとに、読み取りキュー414内に周知の位置すなわちWQE216RRがあるからである。例えば、RDMA読み取りメッセージ3が受信され、RDMA読み取りメッセージ2が失われた場合、RDMA読み取りメッセージ3は配置される。この配置は、RDMA読み取り要求メッセージ222、すなわち要求側の読み取りWR208Rのポスティングにより送信されたメッセージの受信時に行われる。読み取りキュー414におけるWQE216RRの位置は、RDMA読み取りメッセージヘッダ124図4内のMSNによって識別される。B.配信RDMAプロトコルによって、アウトオブオーダのデータ配置が可能となるが、配信はインオーダである必要がある。従って、従来の実施では、メモリに全体的にまたは部分的に配置されたがまだ配信されていない各メッセージに関する情報を維持する必要がある。しかしながら、単一のTCPセグメントが失われると、多くのアウトオブオーダのRDMAメッセージが受信されることになる恐れがあり、これは宛先バッファに配置され、失われたセグメントが再送信されてメモリに正常に配置されるまで完了しない。従来の環境のもとでは、アウトオブオーダのストリームをストアするために限られたリソースを利用可能であり、アウトオブオーダのストリームを受信した後に、ある数のみの以降のメッセージをストアすることができるようになっている。しかしながら、本発明によれば、配信されていないRDMAメッセージごとにある情報を保持し、従ってサポートされるアウトオブオーダの受信メッセージの数を制限するのではなく、TCPホールごとに情報をストアすることによって、無限の数の配信されないRDMAメッセージをサポートする。TCPホールは、アウトオブオーダのTCPセグメントを受信した結果としてTCPストリーム内に生成される空きを表す言葉である。図22を参照すると、白いブロックは、TCPホール130Aから130Cを形成する失われたTCPセグメント400を示し、陰影を付けた/グレーのブロック402は、連続して受信されるTCPストリームを示す。TCPホール130A~130Cごとの情報は、接続コンテキスト42図10にストアされる。限られた数のTCPホール130Aから130Cのサポートは、TCPプロトコルの実施から引き継がれた特徴である。具体的には、TCPプロトコルは通常、サポートするTCPホール130Aから130Cの数を、例えば1、2、または3のホールに制限する。通常、限られた数のTCPホール130Aから130Cのサポートによって効果的に示されるのは、アウトオブオーダのTCPセグメントが到着し、新たなTCPホールを開くと、このセグメントがTCPロジックによってドロップされるということである。図22は、3TCPホールの実施を示す。この場合、下部TCPホール130C、すなわち2つの下部の失われたセグメント400の後に、新たなセグメントが到着した場合、このセグメントは第4のホールを開くが、これはサポートされない。この結果、そのセグメントはドロップされる。この状況に対処するため、本発明は、アウトオブオーダのメッセージ/セグメントの追跡ではなく、接続コンテキスト42図9および図10によって、TCPホール130図22の追跡を実施する。具体的には、図10に示すように、本発明は、PendingReadResponseNumフィールド300をストアして、完了したRDMA読み取り要求をカウントし、CompletedSendsNumフィールド302ストアして、完了した送信メッセージをカウントし、CompletedReadResponseNumフィールド306をストアして、完了したRDMA読み取り応答をカウントする。当業者によって認められるように、各ホールごとに他のフィールドが必要とされる場合があるが、簡潔にするためにその説明は行わない。この手法によって、無限の数のアウトオブオーダの受信RDMAメッセージが、完了およびインオーダの配信を待つことができる。この手法は、何ら制限なく、受信キュー212および送信キュー210の双方によって完了キュー240図6から図8を共有する能力を制限しない。これより、特定のタイプのメッセージの処理の詳細について説明する。第1に、RDMA書き込みメッセージ202図7の配信では、動作の性質のため、応答側にいかなる報告も行われず、他のハードウェアロジックにいかなる通知も行われないことに留意すべきである。従って、このタイプのRDMAメッセージに関しては、配信の問題は存在しない。第2に、図21に戻ると、RDMA読み取り応答メッセージ206に関して、この動作は、待ち状態のRDMA読み取りメッセージ204の完了を表す。この場合、待ち状態のRDMA読み取りワーク要求208Rを完了するための充分な情報を要求側の完了処理ロジックに与えるためには、TCPホール130ごとにある数の完了したRDMA読み取り応答メッセージ206を含む接続コンテキスト42においてCompletedReadResponseNumフィールド306図10をストアすることで充分である。TCPホールが閉じると、このホールに関連したある数の完了RDMA読み取り応答は、要求側の完了処理ロジックに報告されて、待ち状態のRDMA読み取りワーク要求208Rの完了を示す。RDMA読み取り要求に関して、WQE216RRポストの動作は、2つのステップを含む。すなわち、WQE216RRを読み取りキュー414に配置すること、および、通知すなわち呼び鈴を鳴らして、このWQEを処理可能であることをRNIC16に通知することである。WQE216RRの配置は、アウトオブオーダで行うことができる。しかしながら、上述のように、WQE処理の開始従って、呼び鈴を鳴らすことは、RDMA順序付けルールに従わなければならない。すなわち、RDMAプロトコルは、全ての以前に送信したあらゆる種類のRDMAメッセージが完了するまで、インバウンドRDMA読み取りメッセージ204の処理を遅延させなければならない。従って、呼び鈴を鳴らすこと、すなわち通知は、全てのインオーダの先行するRDMA読み取りメッセージ204が完了するまで、遅延させなければならない。単一の呼び鈴を鳴らす動作すなわち通知は、いくつかのWQE216RRのポスティングを意味する場合がある。上述の問題を解決するため、本発明によるRNIC16は、接続コンテキスト42においてPendingReadResponseNumフィールド300図10、各TCPホール130ごとに図2、呼び鈴を鳴らすこと通知を待っているポストされたRDMA読み取り応答WQE216RRの数をストアする。TCPホール130を閉じた場合、RNIC16は、呼び鈴を鳴らして通知、読み取りキュー214に対するPendingReadResponseNumWQE216RRのポスティングを確認する。これは、全ての先行する読み取りメッセージ204が完了したことを示し、RNIC16は、ポストされた読み取り応答WQE216RRの処理を開始することができる。図23を参照すると、RDMA送信メッセージ500は、独特の状況を表す。具体的には、完了した送信メッセージの配信は、CQ540にCQE542を配置することを含む。CQE542は、完了したメッセージを記述する情報例えば長さ、STagの無効化等を保持する。この情報は、メッセージに特定的な情報であり、従って待ち状態の送信メッセージ500ごとに保持しなければならない。RNIC16は、送信メッセージ500が完了する前にCQE542を配置することができない受信した読み取りワーク要求508RにおけるRDMA読み取り応答WQE508RRの配置と同様。なぜなら、CQ540は、いくつかの送信キュー510および受信キュー512によって共有することができるからである。この問題を、追加のRNICリソースを消費することなく解決し、スケーラブルな実施を提供するため、本発明によるアウトロジック40は、CQE542に含まなければならない全ての情報を、その送信メッセージ500によって消費されるWQE516Rに配置する。次いで、この情報は、完了のためのポーリング要求の際に、バーブインタフェース20図9によってWQE516Rから検索される。RNIC16は、接続コンテキスト42にTCPホール130ごとの完了した送信メッセージ500の数をCompletedSendsNumフィールド302に維持しなければならない。これは、対応するTCPホールが閉じた場合に、CQE542をCQ540にポストするために用いられる。TCPホール130が閉じると、RNIC16は、CQE542をCQ540に配置する。配置されるCQE542の数は、このホールについてカウントされる完了送信メッセージ500の数に等しい。この手法は、2N回の書き込み動作を伴う。ここで、Nは、完了した送信メッセージ500の数である。RDMA送信メッセージ500の配信に関連して上述した手法の1つの欠点は、RNIC16によって行われる書き込み動作の数が二倍になることである。すなわち、各完了送信メッセージ500ごとに、WQE516Rに1回の書き込みおよびCQE542の1回の書き込みが行われる。この問題に対処するため、図24に示すように、本発明の代替的な実施形態によれば、CQE542の内容を変更して、特定のCQE542が完了させるWQE516Rの参照カウンタ544を保持する。参照カウンタ544は、RNIC16によって、所与のTCPホール130のために完了した送信メッセージ500の数に初期化される。バーブインタフェース20は、各完了のためのポーリング動作ごとに、参照カウンタ544を減らし、カウンタがゼロになった場合にのみCQ540からCQE542を除去する。更に、RNIC16は、完了を待っている送信メッセージ500を超過する閾値Mより大きい場合にのみ、WQE516Sを更新する。Mは構成可能なパラメータであり、待ち状態のインバウンド送信メッセージ500の情報を保持するために割り当てられた内部リソース量を示す。Mがゼロに等しい場合、アウトオブオーダで受信された送信メッセージ500はいずれも、WQE516Rの更新を伴うインオーダで受信された送信メッセージ500では更新は必要ない。また、この実施形態は、2種類のCQE542を規定すること、および、CQE542をインジケータ546に与えることを含み、CQEがCQEの本体に全ての完了データを保持するものであるか、または完了データの一部を保持し、完了情報の残りは1つ以上のRDMA送信メッセージに関連するWQE516Rにストアされているものであるかを示す。この代替的な実施形態は、書き込み動作の回数をN1に減らす。ここで、Nは、TCPホール130が閉じる前に待ち状態であった、完了した送信メッセージ500の数である。IV.結論先の考察において、この方法ステップは、本発明の機能タスクの1つ以上を実行するための専門のハードウェアを含む特定のユーザコンピュータ、すなわち有限状態マシンによって実行されることが好ましい。しかしながら、この方法ステップは、メモリにストアされたプログラムの命令を実行するCPU等のプロセッサによっても実行可能である。本明細書中で記載した様々なデバイス、モジュール、機構、およびシステムは、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせによって実現可能であり、図示したもの以外に区分化することができることは理解されよう。それらは、本明細書中に記載した方法を実行するために適合されたいずれかのタイプのコンピュータシステムまたは他の装置によって実施可能である。ハードウェアおよびソフトウェアの典型的な組み合わせは、コンピュータプログラムを有する汎用コンピュータシステムであり、このプログラムがロードされて実行されると、コンピュータシステムを制御して、本明細書中に記載した方法を実行するようになっている。また、本発明は、コンピュータプログラムに埋め込むことも可能である。このプロダクトは、本明細書中に記載した方法および機能の実施を可能とする全ての特徴を含み、コンピュータシステムにロードされた場合、これらの方法および機能を実行することができる。このコンテキストにおいて、コンピュータプログラム、ソフトウェアプログラム、プログラム、またはソフトウェアは、いずれの言語、記号体系、または表記においても、1組の命令の表現を意味し、直接に、または、a別の言語、符号体系、または表記への変換、あるいはb異なる材料形態での再生、またはその両方の後に、情報処理機能を有するシステムに特定の機能を実行させるように意図されている。本発明について、上述の具体的な実施形態に関連付けて説明したが、当業者には、多くの代替、変更、および変形が明らかであろう。従って、上述の本発明の実施形態は、限定でなく例示のために意図されたものである。特許請求の範囲において規定される本発明の精神および範囲から逸脱することなく、様々な変更を行うことができる。特に、記載したステップの順序は、異なる1組のステップによって与えられ、本発明の範囲から逸脱しないある状況または機能において、変更することができる。"