JP4508195B2 - アウト・オブ・オーダのｒｄｍａ送信メッセージの配信に関する書き込み動作の回数の減少 - Google Patents

Description

本発明は、一般に、データ転送に関し、更に具体的には、整列（aligned）ＤＤＰセグメントのためのカットスルー（cut-through）実施を用いたＲＤＭＡ対応ネットワーク・インタフェース・コントローラ（ＲＮＩＣ：RDMA enabled network interface controller）に関する。

１．概要
図１を参照すると、従来のデータ転送環境１のブロック図が示されている。データ転送環境１は、データ・ソース２（すなわちピア（peer））を含み、これは、データ転送３Ａを、１つ以上の遠隔メモリ・データ・アクセス（ＲＤＭＡ：remote memory data access）対応ネットワーク・インタフェース・コントローラ（複数のコントローラ）（ＲＮＩＣ）４を介して、データ転送３Ｂを受信するデータ・シンク（data sink）５（すなわちピア）に送信する。ＲＮＩＣ４は、とりわけ（更に以下で説明する）、リアセンブリ・バッファ６を含む。最近、ネットワーキング通信速度は、毎秒１０メガビット（Ｍｂｐｓ）から１００Ｍｂｐｓを経て毎秒１ギガビット（Ｇｂｐｓ）まで著しく高速化し、今や１０Ｇｂｐｓの範囲の速度に近付いている。しかしながら、現在、通信帯域幅の拡大は、中央演算処理装置（ＣＰＵ）がデータを効率的に処理することができる速度を上回り始めており、結果として、例えばＲＮＩＣ４のようなサーバ・プロセッサにおけるネックになっている。例えば、一般的な１Ｇｂｐｓネットワーク通信は、いっぱいに利用された場合、２ＧＨｚのＣＰＵに対して大きな負担となり得る。特に、このようなＣＰＵは、その処理能力の約半分を拡張して、ネットワーク・カードから来るデータから低レベルの伝送制御プロトコル（ＴＣＰ：transmission control protocol）処理を扱うことができるだけである。

この問題を解決するための１つの手法は、ＣＰＵが処理するソフトウェアとしてでなく、ハードウェア有限状態マシン（ＦＳＭ：finite state machine）において伝送制御およびインターネット・プロトコル（ＴＣＰ／ＩP：transmission controland Internet protocol）スタックを実施することである。この手法によって、極めて高速のパケット処理が可能となり、結果として、バック・トゥー・バック（back-to-back）・ショート・パケットをワイヤ・スピードで処理することができる。更に、この手法は、非常にコンパクトかつ強力な解決策を低コストで提供する。しかしながら、ＴＣＰ／ＩＰスタックは、ソフトウェアにおける実施のために定義され開発されたので、ハードウェアでＴＣＰ／ＩＰスタックを作成すると、様々な新しい問題が生じることになる。発生する問題とは、例えば、ソフトウェア・ベースのプロトコルをどのようにハードウェアＦＳＭにおいて実施し、どのように性能向上を達成するかということ、上位レイヤのプロトコル（ＵＬＰ：upper layer protocol）（例えばアプリケーション・プロトコル）に対する便利で効率的なインタフェースをどのように設計してＵＬＰの高速実施を可能とするかということ、および、スケールアップした実施における新しいネックをどのように回避するかということである。

これらの新しい問題に対処するために、従来のＵＬＰとＴＣＰ／ＩＰスタックとの間に配するための新しい通信レイヤが開発されている。しかしながら、ＴＣＰ／ＩＰスタック上に置かれるプロトコルは、通常、多くのコピー動作を必要とする。なぜなら、ＵＬＰは間接的なデータ配置のためのバッファを提供しなければならないからである。これによって待ち時間が増し、多くのＣＰＵおよびメモリ・リソースが消費される。コピー動作の量を減らすために、ｉＷＡＲＰと呼ばれる新しいプロトコル・スイートが開発されている。

２．プロトコル
これより、図２を参照して、ｉＷＡＲＰを含む様々なプロトコルの簡単な概要、および、データ転送フォーマット構造について説明する。図に見られるように、各データ転送は、多数の異なるプロトコルに関連する情報を含む場合があり、その各々がデータ転送に関する異なる機能性を提供する。例えば、図２に示すように、イーサネット・プロトコル１００は、ＩＥＥＥ規格８０２．３によって規定されているようなローカル・エリア・ネットワーク（ＬＡＮ）アクセスを提供する。インターネット・プロトコル（ＩＰ）１０２は、必要なネットワーク・ルーティング情報を追加する。転送制御プロトコル（ＴＣＰ）１０４は、アウトバウンドＴＣＰセグメント１０６のスケジュールを設定し、配信保証を満足させる。プロトコル・データ・ユニット（ＰＤＵ）整列プロトコルを有するマーカ（ＭＰＡ）１０８は、ＭＰＡフレーム１０９を提供し、これは、ＤＤＰセグメント１１２（１つのみ図示するが、ストリームである場合がある）間に、固定間隔で（すなわち５１２バイトごとに）、後方ＭＰＡマーカ（複数のマーカ）１１０を含み、さらに、各ＭＰＡフレーム１０９に対して、長さフィールド１１４および巡回冗長検査（ＣＲＣ）フィールド１１６を追加する。更に、直接データ配置（ＤＤＰ：direct data placement）プロトコル１２０は、アウトバウンド・メッセージを１つ以上のＤＤＰセグメント１１２に分け、１つ以上のＤＤＰセグメントをＤＤＰメッセージ１１３へとリアセンブルする（組み立て直す）。遠隔データ・メモリ・アクセス（ＲＤＭＡ）プロトコル１２２は、ＤＤＰメッセージ内に／ＤＤＰメッセージから、ＲＤＭＡの書き込み、読み取り、送信を変換する。明確さのため、ＤＤＰセグメント１１２は１つのみ図示するが、各ＴＣＰセグメント１０６に多数のＤＤＰセグメント１１２を提供可能であることは認められよう。

特にＲＤＭＡプロトコル１２２に関して説明すると、ＲＤＭＡコンソーシアムによって開発されたこのプロトコルは、あるコンピュータが直接他のコンピュータ・メモリに情報を置くことを可能とすることによって、データ・コピー動作を不要とすると共に待ち時間を短縮化する。その際に、メモリ・バス帯域幅に対する要求および中央演算処理装置（ＣＰＵ）の処理オーバーヘッドは最小限に抑えられ、一方でメモリ保護方式（semantics）は維持される。ＴＣＰ／ＩＰ上でＲＤＭＡを用いると、プロセッサおよびメモリに対するオーバーヘッドの負担が減ることによって、データ・センタ内でいっそう効率的かつスケーラブルなコンピューティングおよびデータ転送が期待される。このため、ユーザ・アプリケーション等の他の作業にプロセッサ・リソースを用いることができ、インフラストラクチャの利用が改善される。この場合、より大きく高価なシステムにおける集中化作業とは対照的に、ネットワークが効率化すると、ネットワーク中でタスクを共有することによって、アプリケーションがいっそうスケーラブルになることができる。ＲＤＭＡ機能を用いると、送信器は、フレーミングを用いてイーサネット・バイト・ストリーム上にヘッダを置くことができるので、受信器において、それらのバイト・ストリームをアウト・オブ・オーダ（out-of-order）モードで容易に復号および実行することができる。これによって、特にインターネット周辺機器接続インタフェース（ｉＳＣＳＩ：Internet Small Computer System Interface）および他のストレージ・トラヒック・タイプにおいて性能が向上する。ＲＤＭＡが提供する別の利点は、より少数の種類の相互接続を介してデータ・センタに機能を集める能力である。より少数の相互接続を介して機能を集めることによって、結果として得られるインフラストラクチャは、複雑さが軽減され、管理が容易であり、アーキテクチャ上の冗長性が得られる可能性があり、これによりシステムの回復力が改善する。

特にＤＤＰプロトコルに関して説明すると、このプロトコルによって導入される機構により、中間バッファなしで直接データを上位レイヤ・プロトコル（ＵＬＰ）の受信バッファに置くことができる。ＤＤＰは、インバウンドのＴＣＰセグメントを処理する場合に、ＲＤＭＡ対応ネットワーク・インタフェース・コントローラ（ＲＮＩＣ）が実行する（リアセンブリ・バッファへの、またはリアセンブリ・バッファからの）追加的なコピーを少なくし、場合によっては不要とする。

３．課題
ハードウェア設定においてＲＤＭＡおよびＤＤＰを用いてＴＣＰ／ＩＰを効率的に実施することに伴う１つの課題は、標準的なＴＣＰ／ＩＰオフロード・エンジン（ＴＯＥ）実施において、アウト・オブ・オーダの受信ＴＣＰストリームを配列させるためのリアセンブリ・バッファが受信ロジック内に含まれ、このためにコピー動作が増えることである。更に、受信器のデータ・バッファに対する直接データ配置を完了させるために、ＲＮＩＣは、到着するＴＣＰセグメント・ペイロード１２７の各々について宛先バッファの位置を特定することができなければならない。この結果、全てのＴＣＰセグメントは、それらがイン・オーダ（in-order）であり宛先バッファの位置を特定可能であることを保証するために、リアセンブリ・バッファにセーブされる。この問題に対処するため、ｉＷＡＲＰ仕様では、送信ＲＮＩＣに対して、ＲＤＭＡメッセージのセグメント化を実行する際に、生成されるＤＤＰセグメントがＴＣＰセグメントに対して「整列」するように行うことが強く推薦される。それにもかかわらず、多くの場合、特にデータ転送が多数の相互接続を通過する場合には、非整列の（non-aligned）ＤＤＰセグメントは避けられない。

図２を参照すると、「整列」が意味するのは、ＴＣＰヘッダ１２６のすぐ後にＤＤＰセグメント１１２があり（すなわちＭＰＡヘッダがＴＣＰヘッダの次にあり、次いでＤＤＰヘッダがある）、ＤＤＰセグメント１１２が完全に１つのＴＣＰセグメント１０６内に含まれることである。更に具体的には、各ＴＣＰセグメント１０６は、ＴＣＰヘッダ１２６およびＴＣＰペイロード／ＴＣＰデータ１２７を含む。「ＴＣＰホール」１３０は、ＴＣＰデータ・ストリーム内の欠落したＴＣＰセグメント（複数のセグメント）である。ＭＰＡマーカ１１０が提供するデータは、アウト・オブ・オーダのＴＣＰセグメント１０６が受信されて、ＴＣＰセグメント１０６内のＭＰＡフレーム１０９がＴＣＰセグメント１０６に対して整列しているか否かを受信器が知りたい場合のためのものである。各マーカ１１０は、特定の接続の初期シーケンス番号で始まるＴＣＰストリーム内において等しい間隔（５１２バイト）で配置され、それが含まれるＭＰＡフレーム１０９のＤＤＰ／ＲＤＭＡヘッダ１２４を指し示す。第１のＴＣＰセグメント１０６には、第１の順次識別番号が割り当てられ、以降のＴＣＰセグメント１０６内の各初期シーケンス番号は、増分されたシーケンス番号を含む。

図２において、実線は整列したデータ転送の一例を示し、ＴＣＰヘッダ１２６のすぐ後にＭＰＡ長フィールド１１４およびＤＤＰ／ＲＤＭＡヘッダ１２４があり、ＤＤＰセグメント１１２は完全にＴＣＰセグメント１０６内に含まれている。ＤＤＰプロトコル１２０のレイヤにおける点線は、非整列のＤＤＰセグメント１１２ＮＡを示し、ＴＣＰヘッダ１２６のすぐ後にはＭＰＡ長フィールド１１４およびＤＤＰ／ＲＤＭＡヘッダ１２４が存在しない。非整列のＤＤＰセグメントは、例えば、送信器のＲＮＩＣおよび受信器のＲＮＩＣ間にあり得る中間ボックスによる再セグメント化、または実行中の最大セグメント・サイズ（ＭＳＳ：maximum segment size）の縮小の結果として生じる場合がある。送信器のＲＮＩＣは、ＤＤＰセグメント化を変える（ＴＣＰストリーム内のＤＤＰヘッダの位置を変える）ことはできないので、最初のＤＤＰセグメントが大きなＭＳＳによって作成されたのにもかかわらず、再送信動作では、新しい小さくしたＭＳＳが必要となり得る。いずれの場合であっても、コピー動作が増えることによって速度および効率が低下する。従って、当技術分野においては、非整列ＤＤＰセグメントの配置および配信とは異なる方法で整列ＤＤＰセグメントの配置および配信を扱う方法が必要とされている。

非整列ＤＤＰセグメント１１２ＮＡの処理に関する別の課題は、何によって非整列が生じているかの判断が難しいことが多いという事実によって生じる。例えば、単一の非整列ＤＤＰセグメント１１２ＮＡは、２つ以上のＴＣＰセグメント１０６間で分割される可能性があり、それらのうち一方は到着するが他方は到着しない場合がある。別のケースでは、いくつかのＤＤＰセグメント１１２ＮＡがＭＰＡマーカ１１０の間に位置し、ヘッダが欠落したり、またはセグメント末端部が欠落したりする（後者の場合、セグメントが部分的に配置され、残りの部分が到着した場合にどこにそれを配置するかを理解するために何らかの情報を保持する必要があり得る）等の可能性がある。この後者の場合に関して、図３は、１つ以上の非整列ＤＤＰセグメント１１２ＮＡについて、ＭＰＡマーカ参照に関して起こり得る状況をブロック図で示す。ケースＡは、新たに受信したＤＤＰセグメント１６２のＤＤＰセグメンド・ヘッダ１６０が、以前に処理したＤＤＰセグメント１６６のＭＰＡ長フィールド１６４によって参照されている状況を示す。ケースＢは、新たに受信したＤＤＰセグメント１６２のヘッダ１６０が、新たに受信したＤＤＰセグメント１６２内に位置するマーカ１６８によって参照されている状況を示す。すなわち、マーカ１６８は、新たに受信したＤＤＰセグメント１６２の開始を指し示している。ケースＣは、マーカ１６８が新たに受信したＤＤＰセグメント１６２内に位置するがセグメントの外を指し示す状況を示す。ケースＤは、マーカ１６８が新たに受信したＤＤＰセグメント１６２内に位置してセグメント内を指し示す状況を示す。ケースＥは、新たに受信したＤＤＰセグメント１６２内に位置するマーカが存在しない状況を示す。いずれの場合であっても、ＤＤＰセグメントの非整列の原因を判定することができない場合、ＲＮＩＣは直接データ配置を行うことができない。なぜなら、ケースが多すぎて適切に対処することができず、情報／部分セグメントが多すぎて中間ストレージ内に保持することもできないからである。従って、整列および非整列ＤＤＰセグメントの異なる処理を提供する解決策はいずれも、非整列を発生させ得る様々な状況に対処しなければならない。

４．ＤＤＰ／ＲＤＭＡ動作フロー
これより、図４から図８を参照して、後の記載のために、ＤＤＰ／ＲＤＭＡ動作フローの簡単な概要を説明する。特にＤＤＰプロトコル１２０（図２）に関して述べると、ＤＤＰは、タグ付きメッセージおよびタグなしメッセージと称する２つのタイプのメッセージを提供する。図４を参照すると、「タグ付きメッセージ」において、各ＤＤＰセグメント１１２（図２）は、ＤＤＰ／ＲＤＭＡヘッダ１２４内に、データを直接配置することができる受信器上の宛先バッファ内のメモリ領域／ウインドウ（例えば図７のメモリ領域２３２）を識別するステアリング・タグ（「ＳＴａｇ」：steering tag）、この領域／ウインドウ内のターゲット・オフセット（ＴＯ）、およびセグメント・ペイロード（図示せず）を保持する。この場合、宛先バッファの可用性は、ＳＴａｇを介して「発表」される。図５を参照すると、「タグなしメッセージ」は、遠隔の送信器が受信器におけるバッファを知らず、キューＩＤ（ＱＮ）、メッセージ・シーケンス番号（ＭＳＮ）、およびメッセージ・オフセット（ＭＯ）を用いてメッセージを送信するものであり、これらが受信器によって用いられて、適切なバッファを判定することができる。

図６から図８を参照すると、ＲＤＭＡプロトコルは、４つのタイプのメッセージを規定する。すなわち、送信２００、書き込み２０２、読み取り２０４、および読み取り応答２０６である。図１に戻ると、バーブ・インタフェース（verb interface）７は、ＲＮＩＣ４をコンシューマ（consumer）に提示し、ＲＮＩＣ４リソースの割り当ておよび割り当て解除を行うため、ならびに、ワーク要求（ＷＲ：work request）２０８をＲＮＩＣ４にポストするための方法を含む。バーブ・インタフェース７は、通常、２つの部分を有するバーブ・ライブラリ８によって実施される。すなわち、ユーザ空間コンシューマのためのユーザ空間ライブラリ９Ａ、および、カーネル空間コンシューマのためのカーネル・モジュール９Ｂである。バーブ・インタフェース７は、特定のＲＮＩＣ用のソフトウェアであり、ＲＮＩＣ４のハードウェアおよびファームウェアと共に動作する。バーブ・インタフェース７（バーブ・ライブラリ８）、ハードウェア、およびファームウェアにおいて何を実施しなければならないかに関して、厳密な規定はない。バーブ・インタフェース７は、ＲＮＩＣ４のサービスをコンシューマに提供する単一のパッケージと考えることができるので、コンシューマは主に２つのタイプの動作を実行することができる。すなわち、ＲＮＩＣ４のリソース管理（割り当ておよび割り当て解除）、ならびに、ＲＮＩＣ４へのワーク要求（複数の要求）（ＷＲ）のポスティングである。ＲＮＩＣ４のリソース管理の例は、キュー対の割り当ておよび割り当て解除、完了キュー（以降、「ＣＱ（completion queue）」と称する）の割り当ておよび割り当て解除、またはメモリ領域の割り当ておよび割り当て解除である。これらの管理タスクについては、以下で更に詳細に説明する。

図６から図８に示すように、コンシューマは、ワーク要求２０８をポストするキュー対を割り当てる。「キュー対（queue pair）」（以降、「ＱＰ」と称する）は、ＴＣＰ接続に関連付けられ、１対のワーク・キュー（work queue）（例えば送信および受信）２１０、２１２、ならびに、各キューごとのポスティング機構（図示せず）を含む。各ワーク・キュー２１０、２１２は、ワーク・キュー要素（ＷＱＥ：work queue elements）２１６のリストであり、各ＷＱＥは１つのワーク要求（ＷＲ）２０８を記述する何らかの制御情報を保持し、コンシューマバッファを示す（または指し示す）。コンシューマは、ワーク要求（ＷＲ）２０８をワーク・キュー２１０、２１２にポストして、バーブ・インタフェース７（図１）およびＲＮＩＣ４（図１）に、ポストしたワーク要求（ＷＲ）２０８を実行させる。更に、読み取りキュー２１４（図８）およびワーク・キュー要素（ＷＱＥ）２１６等、コンシューマが直接インタラクトしないＱＰを構成することができるリソースがある。

ＷＱＥ２１６によって保持することができる典型的な情報は、コンシューマワーク要求（ＷＲ）のタイプ（すなわち、送信ＷＲ２０８Ｓでは、ＲＤＭＡ送信、ＲＤＭＡ書き込み、ＲＤＭＡ読み取り等とすることができ、受信ＷＲ２０８Ｒでは、ＲＤＭＡ受信のみとすることができる）、および、送信するためのデータを保持するか、または受信データのための位置を表すコンシューマバッファの記述である。ＷＱＥ２１６は、常に、単一のＲＤＭＡメッセージを記述する／単一のＲＤＭＡメッセージに対応する。例えば、コンシューマがＲＤＭＡ書き込みタイプの送信ワーク要求（ＷＲ）２０８Ｓをポストした場合、バーブ・ライブラリ８（図１）は、ＲＤＭＡ書き込みメッセージを用いて、ＷＱＥ２１６Ｓを構築し、データを取得し応答側に送信する必要があるコンシューマバッファを記述する。別のケースでは、受信ワーク要求（ＷＲ）２０８Ｒ（図６）が存在する。この場合、バーブ・ライブラリ（図１）は、受信した送信メッセージ２００のペイロードを配置するために用いられるコンシューマバッファを保持する受信キュー（ＲＱ）２１２に、ＷＱＥ２１６Ｒを追加する。

バーブ・ライブラリ８（図１）が、新しいＷＱＥ２１６を送信キュー（ＳＱ）２１０または受信キュー（ＲＱ）２１２に追加すると、バーブ・ライブラリ８は、ＲＮＩＣ４（図１）に、新しいＷＱＥ２１６が送信キュー（ＳＱ）／受信キュー（ＲＱ）にそれぞれ追加されたことを知らせる（ここでは「呼び鈴を鳴らす」と言う）。この「呼び鈴を鳴らす」動作は通常、ＲＮＩＣメモリ空間に対する書き込みであり、これはＲＮＩＣハードウェアによって検出されて復号される。従って、呼び鈴を鳴らすことによって、ＲＮＩＣに、特定のＳＱ／ＲＱについてそれぞれ実行する必要がある新たなワークがあることを知らせる。

ＲＮＩＣ４（図１）は、待ち状態の（ポストされた）ＷＱＥ２１６を有する送信キュー（ＳＱ）２１０のリストを保持する。更に、ＲＮＩＣは、それらの送信キュー（ＳＱ）２１０間のアービトレーションを行い、それらを一つずつ処理する。ＲＮＩＣ４が処理対象の送信キュー（ＳＱ）２１０を選ぶと、処理対象の次のＷＱＥ２１６を読み出し（ＷＱＥはコンシューマによってポストされた順序でＲＮＩＣによって処理される）、要求されたＲＤＭＡメッセージに属する１つ以上のＤＤＰセグメント２２０を作成する。

ここで、図６から図８を参照して、特定のタイプのＲＤＭＡメッセージの処理について説明する。図６に示すように、ＲＮＩＣ（要求側）は、特定の送信キュー（ＳＱ）２１０Ｓを処理することを選択する。ＲＮＩＣは、送信キュー（ＳＱ）２１０ＳからＷＱＥ２１６Ｓを読み取る。このＷＱＥ２１６ＳがＲＤＭＡ送信要求に相当する場合、ＲＮＩＣは送信メッセージを作成し、このメッセージをピアのＲＮＩＣ（応答側）に送信する。作成したメッセージは、例えば、３つのＤＤＰセグメント２２０を含む場合がある。ＲＮＩＣ（応答側）は、送信メッセージを受信すると、受信キュー（ＲＱ）２１２からＷＱＥ２１６Ｒを読み取り、受信したＤＤＰメッセージ２２０のペイロードを、そのＷＱＥ２１６Ｒが参照するコンシューマバッファ（すなわち応答側Ｒｘバッファ）２３０に配置する。送信メッセージ２００がイン・オーダで受信された場合、ＲＮＩＣは、受信キュー（ＲＱ）２１２から、第１の未使用のＷＱＥ２１６Ｒを選択する。ＷＱＥ２１６Ｒは、コンシューマによってポストされた順序で要求キュー（ＲＱ）２１２内に連鎖されている（chained）。タグなしＤＤＰメッセージに関しては、送信メッセージ２００は、メッセージ・シーケンス番号（ＭＳＮ）（図５）を保持する。これは１に初期化され、送信側によって単調に増分される。送信された各ＤＤＰメッセージ２２０は、同じＤＤＰキューに属する。（タグ付きメッセージについては、以下でＲＤＭＡ書き込みメッセージ２０２に関連付けて説明する）。ＤＤＰキューは、ＤＤＰヘッダ内のキュー番号（ＱＮ）（図５）によって識別される。ＲＤＭＡプロトコルは、３つのＤＤＰキューを規定する。すなわち、インバウンドＲＤＭＡ送信についてＱＮ＃０、インバウンドＲＤＭＡ読み取り要求についてＱＮ＃１、インバウンド終了についてＱＮ＃２である。従って、送信メッセージ２００がアウト・オブ・オーダで到着した場合、ＲＮＩＣ４は、そのメッセージのＭＳＮを用いて、その送信メッセージ２００に対応するＷＱＥ２１６Ｒを見つけることができる。１つの受信された送信メッセージ２００は、受信キュー（ＲＱ）２１２から、１つのＷＱＥ２１６Ｒを消費する。ポストされたＷＱＥが無いこと、またはメッセージ・データ長がＷＱＥバッファの長さを超えることは、重大なエラーと見なされ、接続終了となる。

これより、図７および図８を参照して、タグ付き動作を用いたＲＤＭＡ書き込みメッセージ２０２、およびＲＤＭＡ読み取りメッセージ２０４の一部について説明する。タグ付き動作を用いるために、コンシューマはメモリ領域２３２を登録する必要がある。メモリ領域２３２は、受信器すなわち図７の応答側のピン・メモリ（pinned memory）の仮想連続領域である。メモリ領域２３２は、その開始仮想アドレス（ＶＡ）、長さ、アクセス許可、およびそのメモリ領域２３２に関連した物理ページのリストによって記述される。メモリ領域２３２を登録した結果、コンシューマはステアリング・タグ（ＳＴａｇ）を再び受信し、これを用いてその登録メモリ領域２３２にアクセスすることができる。遠隔コンシューマ（例えば図７の要求側）によるメモリ領域２３２のアクセスは、ＲＮＩＣ４によって実行され、ローカルなコンシューマ（例えば図７の応答側）とのインタラクションは行われない。コンシューマが遠隔メモリ２３２にアクセスしたい場合、ＲＤＭＡ書き込みまたはＲＤＭＡ読み取りタイプの送信ワーク要求（ＷＲ）２０８Ｗまたは２０８Ｒ（図８）をそれぞれポストする。バーブ・ライブラリ８（図１）は、対応するＷＱＥ２１６Ｗ（図７）または２１６Ｒ（図８）を、送信キュー（ＳＱ）２１０Ｗまたは２１０Ｒにそれぞれ追加し、ＲＮＩＣ４に通知する。接続がアービトレーションで使用権を得た場合、ＲＮＩＣ４はＷＱＥ２１６Ｗまたは２１６Ｒを読み、ＲＤＭＡ書き込みメッセージ２０２またはＲＤＭＡ読み取りメッセージ２０４をそれぞれ作成する。

特にＲＤＭＡ書き込みメッセージ２０２について説明すると、図７に示すように、ＲＤＭＡ書き込みメッセージ２０２がＲＮＩＣ４によって受信されると、ＲＮＩＣは、（そのメッセージに属する）ＤＤＰセグメントのヘッダ内のＳＴａｇおよびＴＯ（図４）および長さを用いて、登録されたメモリ領域２３２を探し出し、ＲＤＭＡ書き込みメッセージ２０２のペイロードをメモリ２３２に配置する。受信器のソフトウェアまたはＣＰＵ（すなわち図示する応答側）は、データ配置動作には関与せず、この動作が行われていることを認識しない。

特にＲＤＭＡ読み取りメッセージ２０４について説明すると、図８に示すように、メッセージがＲＮＩＣ４（図１）によって受信されると、ＲＮＩＣは、ＲＤＭＡ読み取り応答メッセージ２０６を作成し、これを、遠隔ホストすなわち図示するような要求側に返信する。この場合、受信キューを読み取りキュー２１４と呼ぶ。また、ＲＤＭＡ読み取り応答２０６の作成は、ローカルなコンシューマ（すなわち応答側）の関与なしに行われ、コンシューマはこの動作が行われていることを認識しない。ＲＤＭＡ読み取り応答２０６が受信されると、ＲＮＩＣ４（図１）は、このメッセージを、ＲＤＭＡ書き込みメッセージ２０４と同様に処理する。すなわち、要求側のメモリ領域２３２に書き込みを行う。

コンシューマワーク要求の処理に加えて、ＲＮＩＣ４（図１）は、図６から図８に示すように、それらの要求の完了についてコンシューマに通知する。完了通知は、完了キュー２４０を用いて行われる。これは、別のＲＮＩＣリソースであり、コンシューマによって（バーブ・ライブラリ８が提供する専用の機能を介して）割り当てられる。完了キュー２４０は、完了キュー要素（ＣＱＥ：completion queue elements）２４２を含む。ＲＮＩＣ４（図１）がコンシューマワーク要求（ＷＲ）２０８Ｓ、２０８Ｗ、２０８ＲＲの完了を報告した場合、ＲＮＩＣ４は、ＣＱＥ２４２を完了キュー（ＣＱ）２４０に配置する。各ワーク・キュー（すなわち送信キュー（ＳＱ）２１０、受信キュー（ＲＱ）２１２）は、関連する完了キュー（ＣＱ）２４０を有する。（注：読み取りキュー２１４はハードウェアによって維持される内部キューであり、ソフトウェアには見えない。従って、ＣＱ２４０はこのキューに関連付けられず、コンシューマはこのキューを割り当てず、その存在について知らない）。しかしながら、同一の完了キュー（ＣＱ）２４０を、２つ以上の送信キュー（ＳＱ）２１０および受信キュー（ＲＱ）２１２に関連付けることが可能であることに留意すべきである。関連付けは、キュー対（ＱＰ）の割り当て時に行われる。動作において、コンシューマがワーク要求ＷＲ２０８を送信キュー（ＳＱ）２１０にポストする際に、この要求が完了した場合に通知を受け取りたいか否かを指定することができる。コンシューマが完了通知を要求した場合、ＲＮＩＣ４は、ワーク要求（ＷＲ）の完了時に、送信キュー（ＳＱ）２１０に関連付けられた関連完了キュー（ＣＱ）２４０に完了キュー要素（ＣＱＥ）２４２を配置する。ＲＤＭＡプロトコルでは、送信キュー（ＳＱ）２１０にポストされたワーク要求（ＷＲ）２０８について、極めて単純な完了順序付けが規定されている。具体的には、ＲＤＭＡ送信ワーク要求（ＷＲ）２０８ＳおよびＲＤＭＡ書き込みワーク要求（ＷＲ）２０８Ｗは、それらが高い信頼性で送信された場合に完了する。ＲＤＭＡ読み取りワーク要求（ＷＲ）２０８Ｒは、対応するＲＤＭＡ読み取り応答メッセージ２０６が受信されてメモリ領域２３２に配置された場合に完了する。コンシューマのワーク要求（ＷＲ）は、それらが送信キュー（ＳＱ）２１０にポストされた順序で完了する。図６を参照すると、受信キュー（ＲＱ）２１２にポストされた各ワーク要求（ＷＲ）も完了通知を必要とする。従って、ＲＮＩＣ４（図１）は、受信した送信メッセージ２００の配置を終えると、受信キュー（ＲＱ）２１２に関連付けた完了キュー（ＣＱ）２４０に完了キュー要素（ＣＱＥ）２４２を配置する。

前述のことを考慮すると、当技術分野において、非整列ＤＤＰセグメントの配置および配信とは異なる方法で整列ＤＤＰセグメントの配置および配信を処理する方法が必要とされている。

本発明が含むＲＮＩＣ実施は、特定の接続の全ての受信ＤＤＰセグメントが整列している場合にはメモリに直接データ配置を行い、特定の接続のいくつかのＤＤＰセグメントが非整列である場合にはリアセンブリ・バッファを通してデータを移動させる。リアセンブリ・バッファにアクセスすることなくカットスルーを行う接続のタイプを「高速（Fast）」接続と称し、他方のタイプを「低速（Slow）」接続と称する。コンシューマは、接続を確立する場合、接続タイプを指定する。例えば、インターネットを介して別の大陸へと至る接続は、整列したセグメントで宛先に到着する可能性が低く、従って、コンシューマによって「低速」接続タイプとして指定されるはずである。これに対して、１つのストレージ・エリア・ネットワーク（ＳＡＮ）内で２つのサーバが接続されている接続は、全てのＤＤＰセグメントが整列している可能性が高く、従って、コンシューマによって「高速」接続タイプとして指定されるであろう。接続タイプは、高速から低速に、およびその逆に変更することができる。本発明は、メモリ帯域幅、待ち時間、ＴＣＰ再送信を用いたエラー回復を少なくし、空の受信キュー、すなわち、受信キューが、インバウンドのタグなしＤＤＰセグメントについて、ポストされたワーク・キュー要素（ＷＱＥ）を有しない場合に、「適切な」回復を行うことができる。従来の実施では、接続が終了することになる。これに対して、本発明による高速接続では、かかるセグメントをドロップし、ＴＣＰ再送信プロセスを用いて、この状況から回復し、接続の終了を回避する。また、この実施では、高速接続において、インバウンドＤＤＰセグメントの大部分について巡回冗長検査（ＣＲＣ）の妥当性確認を行い、その後でセグメント受信を確認するＴＣＰ肯定応答（Ａｃｋ）を送信することができる。これによって、ＴＣＰの信頼性の高いサービスを用いて、ＣＲＣ検査で検出されたデータ破損から効率的に回復することができる。

本発明の第１の態様は、アウト・オブ・オーダのＲＤＭＡ送信メッセージの配信に関連した書き込み動作の回数を減らす方法に関する。この方法は、参照カウンタに完了キュー要素（ＣＱＥ）を供給するステップと、参照カウンタを、選択したＴＣＰホールについて完了したＲＤＭＡ送信メッセージの数にセットするステップと、ＲＤＭＡバーブ・インタフェースによって行われる各完了のためのポーリングごとに、参照カウンタを１だけ減らすステップと、カウンタがゼロになった場合に、ＣＱＥを各完了キュー（ＣＱ）から除去するステップと、を含む。

本発明の第２の態様は、アウト・オブ・オーダのＲＤＭＡ送信メッセージの配信に関連した書き込み動作の回数を減らすためのシステムに関する。このシステムは、完了キュー要素（ＣＱ）の参照カウンタを、選択したＴＣＰホールについて完了したＲＤＭＡ送信メッセージの数にセットするための手段と、ＲＤＭＡバーブ・インタフェースによって行われる各完了のためのポーリングごとに、参照カウンタを１だけ減らすための手段と、カウンタがゼロになった場合に、ＣＱＥを各完了キュー（ＣＱ）から除去するための手段と、を含む。

本発明の第３の態様は、アウト・オブ・オーダのＲＤＭＡ送信メッセージの配信に関連した書き込み動作の回数を減らすためのコンピュータ読み取り可能プログラム・コードが埋め込まれたコンピュータ使用可能媒体を含むコンピュータ・プログラムに関する。このコンピュータ・プログラムは、完了キュー要素（ＣＱＥ）に関連した参照カウンタを、選択したＴＣＰホールについて完了したＲＤＭＡ送信メッセージの数にセットするように構成されたプログラム・コードと、ＲＤＭＡバーブ・インタフェースによって行われる各完了のためのポーリングごとに、参照カウンタを１だけ減らすように構成されたプログラム・コードと、カウンタがゼロになった場合に、ＣＱＥを各完了キュー（ＣＱ）から除去するように構成されたプログラム・コードと、を含む。

本発明の前述およびその他の特徴は、本発明の実施形態の以下の更に具体的な説明から明らかとなろう。

図面を参照して、本発明の実施形態を詳細に説明する。図面において、同様の名称は同様の要素を表す。

以下の概略は、整理する目的のみのため与える。すなわち、Ｉ．概要、ＩＩ．イン・ロジック、ＩＩＩ．アウト・ロジック、ＩＶ．結論である。

Ｉ．概要
Ａ．環境
添付図面を参照すると、図９は、本発明の一実施形態によるデータ転送環境１０のブロック図である。データ転送環境１０は、データ・ソース１２（すなわちピア）を含み、これは、データ転送１４Ａを、１つ以上の遠隔メモリ・データ・アクセス（ＲＤＭＡ）対応ネットワーク・インタフェース・コントローラ（複数のコントローラ）（ＲＮＩＣ）１６を介して、データ転送１４Ｂを受信するデータ・シンク１８（すなわちピア）に送信する。説明の目的のため、データ転送を開始するエンティティを、本明細書において「要求側」と称し、データ転送に応答するものを、本明細書において「応答側」と称する。同様に、データを伝送するエンティティを、本明細書において「送信側」と称し、データ転送を受信するものを、本明細書において「受信側」と称する。データ・ソース１２およびデータ・シンク１８の各々は、異なる時点で、データの送信側もしくは受信側、または要求側もしくは応答側になる場合があり、「ソース」および「シンク」という表示は、転送するデータを保持するエンティティを最初に表す目的のためにのみ与えることを認識すべきである。また、以下の説明は、上述のエンティティの１つを「コンシューマ」と示す場合があり（ＲＮＩＣ１６のリソースを消費するので）、この場合、これより具体的な表示は必要ない。「宛先バッファ」は、受信側においてデータを最終的に受信するデータ・ストレージ、すなわちデータ・ソース１２またはデータ・シンク１８のデータ・バッファ５０を示す。データ・ソース１２およびデータ・シンク１８は、各々、データをストアするためのデータ・バッファ５０を含む。

ハードウェアに関して説明すると、ＲＮＩＣ１６は、ｉＷＡＲＰおよびバーブ機能性を有するネットワークＩ／Ｏアダプタまたは埋め込みコントローラ等、いずれかのネットワーク・インタフェース・コントローラである。また、ＲＮＩＣ１６は、バーブ・インタフェース２０、アクセス制御３０、ＲＮＩＣ入力ロジック（以下では「イン・ロジック」と呼ぶ）３２、リアセンブリ・バッファ３４、内部データ・バッファ３８、ＲＮＩＣ出力ロジック（以下では「アウト・ロジック」と呼ぶ）４０、接続コンテキスト４２、妥当性確認ユニット４４、および他のコンポーネント４６を含む。バーブ・インタフェース２０は、コンシューマに対するＲＮＩＣ１６の提示であり、ＲＮＩＣ１６ハードウェアおよびＲＮＩＣドライバ（図示せず）の組み合わせによって実施されて動作を実行する。バーブ・インタフェース２０は、バーブ・ライブラリ２２を含み、これは２つの部分、すなわちユーザ空間ライブラリ２４およびカーネル・モジュール２６を含む。アクセス制御３０は、イン・ロジック３２に対するアクセスを制御するためのいずれかの現在既知のロジックまたは後に開発されるロジックを含むことができる。リアセンブリ・バッファ３４は、データ転送１４Ａ、１４Ｂに関するデータを一時的にストアするためのいずれかの機構を含む場合がある。特に、リアセンブリ・バッファ３４は、一般に、アウト・オブ・オーダのＴＣＰストリームを一時的にストアするために用いられる。これについては、以下で更に詳細に説明する。他のコンポーネント４６は、ＲＮＩＣ１６の動作のために必要な他のいずれかのロジック、ハードウェア、ソフトウェア等を含む場合があるが、本明細書において特に説明は行わない。

図１０を参照すると、接続コンテキスト４２は、接続に特定的なデータをストアするための多数のフィールドを含む。他のコンテキストデータ６０は、接続に特定的なデータを提供し、これは、本明細書において特に説明しないが、当業者には認められるものである。本発明によれば、２つの接続タイプが規定される。すなわち、高速（以降「ＦＡＳＴ」と呼ぶ）接続および低速（以降「ＳＬＯＷ」と呼ぶ）接続である。「高速」および「低速」という言葉は、接続が整列ＤＤＰセグメントを配信する可能性を示す。接続タイプは、接続タイプ６２と呼ぶ接続コンテキストフィールドにおいて識別される。ＳＬＯＷ接続は、ＳＬＯＷ接続として生成されたか、または、インバウンド・データの処理中にＲＮＩＣ１６によって格下げされた（downgraded）ＲＤＭＡ接続のために用いることができる。これについては、以下で更に詳細に説明する。図１０に示す他のフィールドについては、本開示中の他の節において、関連する処理に基づいて説明する。図１１を参照すると、妥当性確認ユニット４４は、妥当性確認処理の必要性に応じて、巡回冗長検査（ＣＲＣ）ロジック６４、ＴＣＰチェックサム・ロジック６６、および蓄積交換（store-and-forward）バッファ６８を含む。

Ｂ．ＲＮＩＣの全体的な動作
図９に戻ると、動作において、ＲＮＩＣ１６は、イン・ロジック３２に対するアクセスを制御するアクセス制御３０を介して、データ転送１４Ａを受信する。接続を維持するための情報は、従来のように、他のコンテキストデータ６０（図１０）に保持されている。イン・ロジック３２は、データ転送１４ＡにおけるインバウンドＴＣＰセグメントを処理し、ＴＣＰチェックサム・ロジック６６（図１１）によって受信したＴＣＰセグメントの妥当性確認を実行し、ＣＲＣロジック６４（図１１）によってＭＰＡ ＣＲＣを計算し、ＦＡＳＴ接続データ・ストリームをＳＬＯＷ接続データ・ストリームから分離する。後者の機能に関して、以下で更に充分に説明するイン・ロジック３２は、ＳＬＯＷ接続でＲＮＩＣ１６が受信した全てのデータをリアセンブリ・バッファ３４に送出し、ＦＡＳＴ接続を多数の異なる方法で処理する。ＦＡＳＴ接続に関して説明すると、イン・ロジック３２が整列の違反を検出した（すなわち、ＴＣＰヘッダのすぐ後にＤＤＰヘッダがなく、ＤＤＰセグメントが完全に１つのＴＣＰセグメント内に含まれていない）場合、接続はＳＬＯＷ接続に格下げされ、データはリアセンブリ・バッファ３４に送出される。これに対して、整列の違反が存在しない場合、イン・ロジック３２は、整列したインバウンドＤＤＰストリームを、内部データ・バッファ３８に、次いでアウト・ロジック４０に送出して、宛先データ・バッファ５０に直接配置する。あるいは、ＴＣＰセグメント１０６がドロップされ、肯定応答（Ａｃｋ）が送信されず、このためセグメントの再送信を必要とする場合がある。

アウト・ロジック４０は、ＦＡＳＴ接続およびＳＬＯＷ接続の間のアービトレーションを行い、双方の接続タイプのストリームをデータ・シンク１８のデータ・バッファ５０に対してデータ配置する。ＦＡＳＴ接続上の整列したＤＤＰセグメントが内部データ・バッファ３８に送出され、宛先バッファに直接配置されるという状況を、「カットスルー・モード」と呼ぶ。なぜなら、整列ＤＤＰセグメントを有するＦＡＳＴ接続は、直接アウト・ロジック４０によって配置され、リアセンブリ・バッファ３４を無視するからである。しかしながら、接続タイプの双方で、イン・オーダの受信データ・ストリームのみが、アウト・ロジック４０を介してデータ・シンク１８に配信される。

ＩＩ．イン・ロジック
図１２を参照して、本発明によるイン・ロジック３２（図９）およびそのデータ転送１４Ａの処理のフロー図を更に詳細に記載する。上述したように、イン・ロジック３２は、インバウンドＴＣＰセグメントを処理し、受信したセグメントのＴＣＰ妥当性確認を実行し、ＭＰＡ ＣＲＣを計算し、ＳＬＯＷ接続データ・ストリームからＦＡＳＴ接続データ・ストリームを分離する。特に注記しない限り、「Ｓ」が付かない参照番号は、図９から図１１に示す構造を示す。

第１のステップＳ１において、イン・ロジック３２は、ＲＮＩＣ１６接続に属するデータ転送１４ＡのＴＣＰセグメント１０６をフィルタリングし、受信したセグメントについて（妥当性確認ユニット４４によって）計算したＣＲＣ妥当性確認の結果と共にパケットを取得する。（ＣＲＣ妥当性確認は、イン・ロジック３２決定処理の前に行わなければならないことに留意すべきである。また、ＣＲＣ妥当性確認は、ステップＳ２においてＴＣＰセグメント１０６をＦＡＳＴ接続に属するものとして識別する前に、ＴＣＰチェックサム計算と同時に実行可能である。）

ステップＳ２において、イン・ロジック３２は、ＴＣＰセグメント１０６がＳＬＯＷ接続に属するか否かを判定する。この場合、イン・ロジック３２は、送信側がどのように接続をラベリングしたかを判定する。ＹＥＳの場合、ＴＣＰセグメント１０６はリアセンブリ・バッファ３４に送出され、ステップＳ３において、ＴＣＰロジックはこのセグメントの受信が成功したと見なす。

ＮＯの場合、イン・ロジック３２は先に進み、ステップＳ４において、ＴＣＰセグメント１０６長が、提示（state）されたＭＰＡセグメント長より大きいか否かを判定する。すなわち、ＴＣＰヘッダ１２６において提示されているＴＣＰセグメント１０６長が、ＭＰＡ長フィールド１１４において提示されているＭＰＡ長よりも長いか否かが判定される。ＹＥＳの場合、これは、ＴＣＰセグメント１０６が多数のＤＤＰセグメント１１２を含むことを示す。その処理については以下で説明する。ＮＯの場合、これは、ＴＣＰセグメント１０６が単一のＤＤＰセグメント１１２または１１２ＮＡを含むことを示す。

この後者の場合、ステップＳ５において、イン・ロジック３２は、ＭＰＡ長がＴＣＰセグメント１０６長より大きいか否かを判定する。ＹＥＳの場合、これは、３つの状況のうち１つを示す。（１）単一のＤＤＰセグメント１１２ＮＡがＴＣＰセグメント１０６に整列しておらず、ＭＰＡ長フィールドと想定されたフィールドは長さフィールドではない。（２）単一のＤＤＰセグメント１１２の最初の部分がＴＣＰセグメント１０６に整列しているが、単一のＤＤＰセグメントの長さがＴＣＰセグメント１０６のペイロード・サイズを超えている。（３）受信した単一のＤＤＰセグメント１１２がＴＣＰセグメント１０６に整列しているが、そのＭＰＡ長フィールド１１４が破損している。最初の２つの場合（（１）および（２））は、非整列の単一ＤＤＰセグメント１１２ＮＡがＦＡＳＴ接続上で受信され、従って、ステップ３において、接続をＳＬＯＷ接続に格下げしなければならないことを示す。第３の場合（３）は、接続の格下げを必要としない。しかしながら、ＭＰＡフレーム１０９の長さがＴＣＰセグメント１０６の長さを超えている理由は識別および確認することができないので、かかるＴＣＰセグメント１０６のドロップ（すなわち取り消しおよび非転送）は得策ではない。なぜなら、これはデッドロックを生じる恐れがあるからである（上述のケース（２））。すなわち、かかるＴＣＰセグメントが実際に非整列ＤＤＰセグメントを保持する場合、送信側は同一の非整列ＤＤＰセグメントを再送信するが、これは同じフローに従うので、受信側によって繰り返しドロップされて、デッドロックを生じる。従って、イン・ロジック３２は、ステップＳ３において、ＴＣＰセグメント１０６のデータ転送をリアセンブリ・バッファ３４に送出し、Ａｃｋをスケジューリングして、ＴＣＰセグメント１０６の受信が成功したことを確認し、接続をＳＬＯＷ接続に格下げする（すなわち、図１０における接続タイプ・フィールド６２を高速から低速に切り替える）。以下で説明するように、ＭＰＡ長フィールド１１４が破損している場合（上述のケース（３））、これはアウト・ロジック４０によって検出され、妥当性確認ユニット４４が検出するＣＲＣエラーのために、接続は閉じられる。従って、ステップＳ３における接続の格下げでは、整列ＤＤＰセグメント１１２におけるデータ破損のためにＦＡＳＴ接続を永続的にＳＬＯＷ接続にするわけではない。

ステップＳ５に戻ると、ＭＰＡ長がＴＣＰ長より大きくない場合、すなわちＮＯの場合、これは、ＭＰＡフレーム１０９長がＴＣＰセグメント１０６長に一致する（等しい）ことを示す。イン・ロジック３２は、ステップＳ６に進み、このＴＣＰセグメント１０６についてＣＲＣ妥当性確認の結果が有効であるか否か、すなわち、ＣＲＣロジック６４が「有効」という指示を戻したか否かを判定する。ＹＥＳの場合、これは、単一のＤＤＰセグメント１１２がＴＣＰセグメント１０６の境界にちょうど適合し（すなわち長さが互いに等しい）、このセグメントについてデータ破損が検出されていないことを示す。この結果、ステップＳ７では、受信したＴＣＰセグメント１０６を、ＲＮＩＣ１６の内部データ・バッファ３８に配置し、アウト・ロジック４０によって処理することによって、単一のＤＤＰセグメント１１２を「高速経路モード」で処理する。これによって、例えばデータ・シンク１８のような受信側の宛先データ・バッファ５０に、受信したＴＣＰセグメント１０６を直接配置する。更に、このＴＣＰセグメント１０６の受信成功を確認するように、Ａｃｋをスケジューリングする。

ＣＲＣロジック６４が「無効」という指示を返した場合、すなわちステップＳ６においてＮＯの場合、これは、本発明に従って判定可能である５つの起こり得るケースのうち１つが存在することを示す。図３は、５つの起こり得るケースを示し、ステップＳ８からステップＳ１０は、どのようにイン・ロジック３２が各ケースを処理するかを示す。いずれの場合でも、処理の目的は、（１）送信側によってＦＡＳＴ接続として宣言されたものであっても、非整列接続の終了を回避すること、（２）ＦＡＳＴ接続に属する整列ＤＤＰセグメントにおけるデータ破損による接続終了の可能性を低くすること、および（３）別個に処理されるケースの数を最小限に抑えながら、可能な限りイン・ロジック３２を単純にすること、である。

ステップＳ８において、イン・ロジック３２は、図３のケースＡに示すように、新たに受信したＤＤＰセグメント１６２のＤＤＰセグメント・ヘッダ１６０が、以前に処理したＤＤＰセグメント１６６のＭＰＡ長フィールド１６４によって参照されているか否かを判定する。この場合、以前に処理したＤＤＰセグメント１６６のＭＰＡ長は、新たに受信したＤＤＰセグメント１６２のＭＰＡ ＣＲＣの妥当性確認中にチェックされたので、次のセグメント内のＤＤＰヘッダ１６０の正しい位置を示す。ステップＳ６において、ケースＡについてＣＲＣが無効であったことは、単一のＤＤＰセグメント１６２のデータまたはヘッダ１６０が破損していることを意味する。この問題は、新たに受信したセグメント１６２のＴＣＰ再送信によって解決される。従って、ステップＳ９において、ＴＣＰセグメント１０６をドロップし、セグメント受信は確認されていないと見なされる。

新たに受信したＤＤＰセグメント１６２のヘッダ１６０が、以前に処理したＤＤＰセグメント１６６のＭＰＡ長フィールド１６４によって参照されていない場合（ステップＳ８においてＮＯ）、イン・ロジック３２はステップＳ１０に進み、図３のケースＢに示すように、新たに受信したＤＤＰセグメント１６２のヘッダ１６０が、新たに受信したＤＤＰセグメント１６２の内部に位置するマーカ１６８によって参照されているか否かを判定する。すなわち、マーカ１６８は、新たに受信したＤＤＰセグメント１６２の最初の部分を示している。この場合、ステップＳ６においてＣＲＣが無効であることは、次のいずれかを示す。（１）マーカ１６８が正しい値を保持し、新たに受信したＤＤＰセグメント１６２が有するＤＤＰヘッダ１６０またはデータが破損している、または、（２）新たに受信したＤＤＰセグメント１６２の内部のマーカ１６８が破損している。双方の場合で、この問題は、新たに受信したＤＤＰセグメント１６２を再送信することによって解決される。従って、ステップＳ９において、ＴＣＰセグメントをドロップし、セグメント受信は確認されない。

新たに受信したＤＤＰセグメント１６２のヘッダ１６０が、新たに受信したＤＤＰセグメント１６２内部に位置するマーカ１６８によって参照されない場合、すなわちステップＳ１０においてＮＯの場合、３つのケースのうち１つが存在する。第１に、図３のケースＣに示すように、マーカ１６８は新たに受信したＤＤＰセグメント１６２内に位置するが、セグメントの外部を指し示す。第２に、図３のケースＤに示すように、マーカ１６８は新たに受信したＤＤＰセグメント１６２に位置するが、セグメント内部を指し示す。第３に、図３のケースＥに示すように、新たに受信したＤＤＰセグメント１６２内に位置するマーカは存在しない。

ケースＣ、Ｄ、およびＥにおいて、ＣＲＣロジック６４が無効という指示を戻す理由は明らかでなく、非整列ＤＤＰセグメント１１２ＮＡ（図２）のデータ破損あるいは受信またはその両方の結果である可能性がある。かかるセグメントを無制限に再送信すると、非整列ＤＤＰセグメント１１２ＮＡの場合にデッドロックを生じる恐れがある。起こり得るデッドロックを回避するために、イン・ロジック３２は、ステップＳ３に示すように、新たに受信したＤＤＰセグメント１６２をリアセンブリ・バッファ３４に送出し、セグメントの受信成功を確認するようにＡｃｋをスケジューリングし、接続をＳＬＯＷ接続に格下げすることによって、ケースＣ、Ｄ、およびＥを処理する。ＣＲＣロジック６４が無効という指示を戻す理由が、整列ＤＤＰセグメント１１２におけるデータ破損であった場合、以下で説明するように、このエラーはアウト・ロジック４０によって検出され、この場合、ＳＬＯＷ接続のデータ処理および接続は終了する。その他の場合、接続は永続的にＳＬＯＷ接続のままである。しかしながら、以下で説明するように、有限再送信試行モード（Limited Retransmission Attempt Mode）によって、この問題を防ぐことができる。

図３のステップＳ４に戻り、イン・ロジック３２が、ＴＣＰセグメント１０６長がＭＰＡフレーム１０９長より大きいと判定した場合、これは、ＴＣＰセグメント１０６が多数のＤＤＰセグメント１１２を含むことを示す。この場合、ステップＳ１１において、第１から最後までのＤＤＰセグメント１１２において、ＣＲＣロジック６４の妥当性確認結果を順次検査する。全てのＤＤＰセグメント１１２が有効ＣＲＣを有する場合、すなわちＹＥＳの場合、全てのＤＤＰセグメント１１２は完全にＴＣＰセグメント１０６に含まれ、全て有効な、適切に整列されたＤＤＰセグメント１１２である。この場合、ステップＳ７において、イン・ロジック３２は、受信したＴＣＰセグメント１０６をＲＮＩＣ１６の内部データ・バッファ３８に配置し、アウト・ロジック４０によって処理することによって、高速経路モードでＤＤＰセグメント１１２を処理する。これにより、受信したＴＣＰセグメント１０６を、例えばデータ・シンク１８のデータ・バッファ５０のような宛先データ・バッファに配置する。更に、このＴＣＰセグメント１０６の受信成功を確認するように、Ａｃｋをスケジューリングする。第１の故障が検出された場合、イン・ロジック３２は、ＣＲＣ妥当性確認結果の検査を停止する。その処理について、ステップＳ１２からＳ１３に関連付けて説明する。

ステップＳ１２において、イン・ロジック３２は、第１のＤＤＰセグメント１１２が無効ＣＲＣを有することがＣＲＣロジック６４によって判定されたか否かを判定する。ＹＥＳの場合、イン・ロジック３２は、第１のＤＤＰセグメント１１２を、単一のＤＤＰセグメントの無効ＣＲＣの場合と同様に処理する（ステップＳ８）。すなわち、イン・ロジック３２は、無効ＣＲＣを有する第１のＤＤＰセグメント１１２を単一ＤＤＰセグメント１１２として扱い、更に先に進んで、何がＣＲＣの無効を引き起こしたか、すなわち図３のケースＡからＥのどれが当てはまるか、および、どのようにこのケースを適切に扱うかを判断する。

ステップＳ１２の結果がＮＯである場合、すなわち第１のＤＤＰセグメント１１２が有効ＣＲＣを有する場合、イン・ロジック３２は先に進んで、ステップＳ１３において、中間または最後のＤＤＰセグメント１１２を検査した場合にＣＲＣ無効が検出されたか否かを判定する。ＹＥＳの場合、イン・ロジック３２（図１）はステップＳ９に進む。なぜなら、このエラーは、ＣＲＣ無効を引き起こしたＤＤＰセグメント１１２のデータまたはヘッダが破損していることを示すからである（すなわち、有効ＣＲＣを有する以前のＤＤＰセグメントの長さ）。すなわち、ＣＲＣエラーは、同一のＴＣＰセグメント１０６内の中間または最後のＤＤＰセグメント１１２上で検出された。これが意味するのは、先行するＤＤＰセグメントが有効ＣＲＣを有し、従って、先行するＤＤＰセグメントの長さは、無効ＣＲＣを有するセグメントのヘッダを指し示すということである。これは、ケースＡ（図１）の説明に一致する。従って、ケースＡに示すように、ヘッダの位置は既知であり、このため、ＣＲＣエラーはデータ破損またはヘッダ破損のいずれかによって引き起こされたことがわかる。従って、この問題は、全ＴＣＰセグメントの再送信によって解決され、デッドロック状況が生じる危険はない。ステップＳ９において、ＴＣＰセグメントはドロップされ、セグメント受信は確認されない。

ステップＳ１３の結果がＮＯである場合、すなわち、中間または最後のＤＤＰセグメント１１２がＣＲＣ無効を引き起こしたのではない場合、これは、最後のＤＤＰセグメント１１２のＭＰＡ長フィールド１１４がＴＣＰセグメント１０６境界を超えていること、すなわち、最後のＤＤＰセグメントがＴＣＰセグメント１０６境界の外にあることすなわち長すぎることを示す。この場合、イン・ロジック３２は、単一のＤＤＰセグメントが長すぎるのと同じ状況として処理を行う。具体的には、イン・ロジック３２は、ステップＳ３に進んで、ＴＣＰセグメント１０６のデータ転送１４Ａをリアセンブリ・バッファ３４に送出し、ＴＣＰセグメント１０６の受信が成功したことを確認するようにＡｃｋをスケジューリングし、接続をＳＬＯＷ接続に格下げする。このようにして、デッドロックを回避する。ＲＮＩＣ１６が、ＴＣＰセグメント１０６に含まれる多数のＤＤＰセグメント１１２の１つをドロップすることを決めた場合、全ＴＣＰセグメント１０６はドロップされ、これによって、実施を簡略化し、処理する必要のあるケースの数を減らす。

先に明確には論じていないが、イン・ロジック３２の上述の動作に関連付けて、他のデータ転送処理も実行可能であることは認められよう。例えば、ＴＣＰチェックサム・ロジック６６（図１１）によるチェックサム妥当性確認を含めて、ＲＮＩＣ１６接続に属するＴＣＰセグメントのフィルタリング、および、受信したセグメントのＴＣＰ／ＩＰ妥当性確認を行うことができる。また、インバウンドＴＣＰセグメント１０６の処理は、ＭＰＡ ＣＲＣの計算、およびＣＲＣロジック６４（図１１）によるこのＣＲＣの妥当性確認を含む場合がある。ＣＲＣ計算および妥当性確認の1つの具体的な実施形態については、以下で更に説明する。

Ａ．有限再送信試行モード
検出されたエラーの原因の不明確さに関連した代替的な実施形態として（例えば、図１２のステップＳ１０においてＮＯの場合は、かかる状況を生じる結果となり得る１つの例示的な判定である）、「有限再送信試行モード」を実施して、再送信試行の回数を制限して、デッドロックを回避し、不必要にＳＬＯＷ接続に変えられるＦＡＳＴ接続の数を減らすことができる。具体的には、上述のように、ケースＣ、Ｄ、およびＥが表すいくつかの例では、検出されたエラーの原因が不明確であるために、接続をＳＬＯＷ接続に格下げし（ステップＳ３）、ＤＤＰセグメント１１２の整列が損なわれたためでなくデータ破損によってエラーが生じた場合には、接続が終了する可能性がある（アウト・ロジック４０によって）。

再送信試行の回数を制限するため、本発明は、接続コンテキスト４２（図１０）に追加のフィールドを提供して、接続を格下げする前にある回数の再送信を可能とする。具体的には、図１０に示すように、接続コンテキスト４２は１組のフィールド２９０を含む。これは、回復試行回数フィールド（RecoveryAttemptsNum）２９２、最後の回復シーケンス番号フィールド（LastRecoverySN）２９４、および最大回復試行回数フィールド（MaxRecoveryAttemptsNum）２９６を含む。RecoveryAttemptsNumフィールド２９２は、最後の更新以来、接続に対して実行された回復試行の回数を維持する。LastRecoverySNフィールド２９４は、最後に開始された回復動作のシーケンス番号（ＳＮ）を維持する。MaxRecoveryAttempsNumフィールド２９６は、接続を格下げする前にイン・ロジック３２が実行しなければならない回復試行の最大回数を規定する。

図１３を参照すると、動作において、イン・ロジック３２が、新しいイン・オーダ受信データ転送がエラーを含むことを検出した場合（図１３のステップＳ１０１として一般的に示す）、接続をＳＬＯＷ接続にすぐに格下げするのではなく（図１２のステップＳ３）、イン・ロジック３２は、そのエラーを含むデータ転送について、ある回数の再送信を行うことになっている。ステップＳ１０１は、非整列のＤＤＰセグメント１１２ＮＡまたはデータ破損のいずれかによって引き起こされる多数のエラー判定について当てはまることは認められよう（ステップＳ１０１は、例えば図１２のステップＳ５のＹＥＳまたは図１２のステップＳ１０のＮＯに当てはまる）。ステップＳ１０２において、イン・ロジックは次に、このエラーを含むデータ転送についてこの送信試行を記録し、ステップＳ１０２において、RecoveryAttemptsNumを１だけ増やす。更に、イン・ロジックは、LastRecoverySnを更新して、以前にストアしたシーケンス番号と新たに受信した（がドロップした）データ転送のものとのうち最大のシーケンス番号をストアする。すなわち、イン・ロジックは、LastRecoverySNを更新して、少なくとも１つの以前に受信したエラーを含むデータ転送と新たに受信したエラーを含む（がドロップした）データ転送とのうち最大のシーケンス番号をストアする。新たに受信したエラーを含むデータ転送のシーケンス番号を、ストアされた最大のシーケンス番号と比較することによって、新たに受信したエラーを含むデータ転送が、最大のシーケンス番号より大きいシーケンス番号を有することが判定される。LastRecoverySnの記録の重要性は、以下で明らかになる。

次に、ステップＳ１０３において、イン・ロジック３２は、RecoveryAttemptsNum（フィールド２９２）がMaxRecoveryAttemptsNum（フィールド２９６）より大きいか否かを判定する。ＮＯの場合、ステップＳ１０４において、イン・ロジック３２はＴＣＰセグメント１０６をドロップし、受信成功を確認せず、これによってＴＣＰセグメントの再送信が行われる。次いで、処理はステップＳ１（図１２）に戻る。ＴＣＰセグメント１０６が破損していた場合、再送信によって破損を修復し、データ転送１４ＡがＦＡＳＴ接続としてメモリに直接配置されるようにする（図１２のステップＳ７）。あるいは、処理が引き続き他のエラー検出へと戻る場合（図１２のステップＳ１０）、RecoveryAttemptsNum（フィールド２９２）は、最終的にMaxRecoveryAttemptsNum（フィールド２９６）より大きくなり、結果としてステップＳ１０３でＹＥＳになる。この場合、イン・ロジック３２はステップＳ１０５に進み、ここでイン・ロジック３２は接続をＳＬＯＷ接続に格下げし、エラーを含むデータ転送１４Ａをリアセンブリ・バッファ３４に配置し、このＴＣＰセグメントの受信成功を確認するＡｃｋをスケジューリングする。上述のプロセスは、エラーを含むデータ転送の各々について行われる。

図１４は、有限再送信試行モードの別のコンポーネントを表す。これは、データ破損が通常は多数の連続したＴＣＰセグメントにおいて発生するのでなく、非整列セグメントはいくつかの以降のＴＣＰセグメントに影響を与え得るという事実に対処するものである。例えば、ＦＡＳＴ接続は、例えば５時間のような長い時間期間にわたって維持される場合があり、例えば１時間に１度のように時々データ破損が生じ、ＣＲＣ妥当性確認が失敗する恐れがある。これが起こると、エラーを含むデータ転送（すなわち破損したセグメント）がドロップされるたびに、RecoveryAttemptsNum（フィールド２９２）が増えることがある。このプロセスは、異なるセグメントが異なる時間期間でデータ破損のためにドロップされ、いくつかの（おそらくは１つの）再送信動作の後に、これらのセグメントが受信成功し、メモリに配置されるという状況に対処する。従って、これらのセグメントのための回復動作は正常に完了しており、回復されるデータ破損のケース、すなわち新たな誤ったセグメントの受信によって新たな回復モードに入る場合は、カウントされない。

有限再送信試行モードから出るためには、ステップＳ１０５において、新たに受信したイン・オーダのデータ転送のＴＣＰセグメント・シーケンス番号（ＳＮ）（すなわちInOrderTCPSegmentSN）が、LastRecoveryシーケンス番号（ＳＮ）（図１０のフィールド２９４）より大きいか否かについての判定を行う。すなわち、ＦＡＳＴ接続に属する新たに受信したイン・オーダの各ＴＣＰセグメントのシーケンス番号を、１つ以上の以前に受信したエラーを含むデータ転送から選択されたストアされた最大シーケンス番号と比較する。（もっと大きいＳＮを有するアウト・オブ・オーダのセグメントの受信は、エラー回復が完了したことを意味しないことに留意すべきである）。しかしながら、回復が完了していることを示す１つの指示は、回復モードに入らせたセグメント（複数のセグメント）の後に送信されたＴＣＰセグメントが受信されることである。この状況は、InOrderTCPSegmentSNをLastRecoverySNと比較することによって判定することができる。この判定は、この接続のために受信されたＴＣＰセグメントの処理中の実質的にどの段階においても行うことができる。例えば、図１２のステップＳ９の後、または図１３のステップＳ１０２の前である。イン・オーダ・セグメントＳＮがLastRecoverySnより大きい場合、すなわち新たなＴＣＰセグメントが受信された場合、および、ステップＳ１０５においてＹＥＳが判定された場合、ステップＳ１０６において、RecoveryAttemptsNum（図１０のフィールド２９２）はリセットされる、すなわちゼロにセットされる。上述の例に関連して、ステップＳ１０５は、例えば５時間のような長い時間期間の後、ＦＡＳＴ接続をＳＬＯＷ接続に不必要に格下げすること（すなわちRecoveryAttemptsNumがMaxRecoveryAttemptsNumを超えるので）を防ぐ。この場合、ドロップしたセグメントは、データ破損のためにドロップしており、送信側がセグメントを再送信した後で正常に受信され、整列セグメントとして処理された。ステップＳ１０５においてＮＯである場合、またはＳ１０６の後、セグメント処理は通常のように、例えば図１２のステップＳ１に進む。

上述の処理を用いて、許可される再送信の回数は、MaxRecoveryAttemptsNumフィールド２９６を設定することによってユーザが規定することができる。有限再送信試行モードは、図１３から図１４および図１２のステップＳ１０においてエラー検出に関して上述したが、有限再送信試行モードは、ステップＳ１０のエラー検出だけでなく適用可能であり、以下で更に説明することは認められよう。有限再送信試行モードは、以下で説明する「Ｄ．ＴＣＰ再送信プロセスの高速化」において、有利に使用可能であることに留意すべきである。この場合、ＵＬＰの問題点のためにセグメントがドロップした場合、即座に複製Ａｃｋ（Duplicate Ack）を送信する。

Ｂ．接続の格下げ
これより、図１５を参照して、高速経路モードにおいて１つ以上のアウト・オブ・オーダの受信ＤＤＰセグメント１１２を宛先データ・バッファ５０に配置した後に接続を格下げする（図１２のステップＳ３）という独特の状況の処理について説明する。図１５に示すように、パケット（Ｐｋｔ）と標示された４つのＴＣＰセグメントは、アウト・オブ・オーダで、すなわち３、４、１、２の順序で受信される。接続をＳＬＯＷ接続に格下げすると、格下げの時点で受信された全てのデータはリアセンブリ・バッファ３４に配置され、イン・オーダに、すなわちＰｋｔ１、２、３、４にリアセンブルされる。この場合、ＴＣＰプロトコルに従って、イン・ロジック３２はそれらのセグメントが受信されたことの記録を維持する。

まれではあるが、例えばＰｋｔ＃３（斜線を付けている）のようなセグメント（複数のセグメント）が宛先データ・バッファ５０に直接配置されるという状況が生じ得る。この状況では、イン・ロジック３２が全てのデータが受信されたと見なしたとしても、リアセンブリ・バッファ３４内で通常はパケット３（Ｐｃｔ＃３）を保持する位置が、「無意味な」データ、すなわち隙間または穴で埋められることになる。処理が正しくないまま継続することができた場合、アウト・ロジック４０がリアセンブリ・バッファ３４を宛先データ・バッファ５０に転送すると、高速経路モードで先に転送されたパケット３（Ｐｋｔ＃３）は、「無意味な」データによって上書きされ、データを破損させてしまう。

ハードウェアの複雑さを増すことなくこの問題を解決するため、代替的な実施形態では、接続がＦＡＳＴ接続である場合に受信したアウト・オブ・オーダのセグメント（すなわち図１５のＰｋｔ＃３）について忘れるように、イン・ロジック３２がＴＣＰロジックに指示する。具体的には、イン・ロジック３２は、ステップＳ３において接続がＳＬＯＷ接続に格下げされる場合（図１２）にアウト・オブ・オーダで配置されたデータ転送についてのＴＣＰホールをクリアするように構成され、受信を停止し、これらのパケットを受信したことを送信側に報告する（ＳＡＣＫオプション）。この結果、送信側は、宛先データ・バッファ５０に直接配置されたアウト・オブ・オーダのセグメント（複数のセグメント）すなわちＰｋｔ＃３を含めて、全ての承認されていないデータを再送信する。再送信されたデータを受信すると、これはリアセンブリ・バッファ３４に書き込まれて、アウト・ロジック４０がリアセンブリ・バッファ３４からデータを転送すると、宛先データ・バッファ５０において、アウト・オブ・オーダの直接配置されたセグメントは全て上書きされる。この機能性が効果的に示すのは、この接続において、ＲＮＩＣ１６が、宛先データ・バッファ５０にアウト・オブ・オーダで配置されたセグメントを「ドロップする」ということである。かかる手法によって、リアセンブリ・バッファ３４においてイン・オーダのストリームに「隙間があいている」というケースがなくなり、かかる挙動に至るまれな状況のために目に見える性能劣化が生じることを防ぐ。

Ｃ．接続の格上げ
別の代替的な実施形態として、本発明は、図１６に示すような接続格上げ手順を含むことができる。上述の高速経路モード手法の目的は、整列ＤＤＰセグメント１１２を保持する接続について、リアセンブリ・バッファ３４の回避を可能とすることである。しかしながら、ＦＡＳＴ接続においても、データ・ソース１２または中間ネットワーク・デバイスは、間欠的な非整列ＤＤＰセグメント１１２ＮＡを発生する可能性があり、これによって、ＦＡＳＴ接続は上述の技法に従ってＳＬＯＷ接続に格下げされる。間欠的な挙動は、例えば、ＴＣＰ再送信の間に最大セグメント・サイズ（ＭＳＳ）が変化すること、または他の単発的な状況によって生じる場合がある。

図１６に示すように、この状況から回復するために、本発明は、例えばステップＳ３（図１２）における先行する格下げの後に、ＳＬＯＷ接続からＦＡＳＴ接続へと接続の格上げを提供することができる。格上げに対応するためには、多数の状況が存在しなければならない。代替的な実施形態の第１のステップＳ３１では、イン・ロジック３２は、リアセンブリ・バッファ３４が空であるか否かを判定する。ＮＯの場合、ステップＳ３２において、格上げを行わない。ステップＳ３１においてＹＥＳが判定されると、次いでステップＳ３３において、イン・ロジック３２は、整列ＤＤＰセグメント１１２が受信されているか否かを判定する。ＮＯの場合、ステップＳ３２において、格上げを行わない。ステップＳ３３においてＹＥＳが判定されると、次いでステップＳ３４において、イン・ロジック３２は、接続が、例えばデータ・ソース１２のような送信側によってＦＡＳＴ接続として始められたか否かを判定する。ステップＳ３４においてＮＯが判定されると、ステップＳ３２において、格上げを行わない。ステップＳ３４においてＹＥＳが判定されると、ステップＳ３５において、接続はＦＡＳＴ接続に格上げされる。

Ｄ．ＴＣＰ再送信プロセスの高速化
別の代替的な実施形態では、ＴＣＰセグメント１０６が受信されるが、例えばＤＤＰセグメントの破損、無効なＣＲＣ等のようなＲＤＭＡまたはＵＬＰの問題点のためにドロップされるという状況に対処する。上述の手順に従って、ＴＣＰセグメント１０６が受信されてＴＣＰチェックサムを通過するが、セグメントをカバーするＴＣＰ Ａｃｋを送信することなくイン・ロジック３２によってドロップされる（すなわち図１２のステップＳ９）ということは数多い。従来の手順では、次いで、それらのパケットの再送信試行が行われる。具体的には、基本的な方式（いわゆる「Ｒｅｎｏプロトコル」）では、ＴＣＰ送信側は、３つの複写Ａｃｋ（すなわち、イン・オーダで受信されたデータのシーケンス番号を進めないＡｃｋ）を得た場合、「高速再送信」モードを開始する。例えば、２つのＴＣＰセグメントＡおよびＢを想定し、ＴＣＰオーダにおいてセグメントＢがセグメントＡの次に来ると想定する。セグメントＡがドロップされると、受信側は、セグメントＢを受信した場合にのみ複写Ａｃｋを送信する。この複写Ａｃｋが示すのは、「私はセグメントＡを待っているが、別のセグメントを受信した」ということ、すなわちセグメントＢである。Ｒｅｎｏプロトコルのもとでの「高速再送信」モードでは、送信側は、１つのセグメントを送信し、次いで別の３つの複写Ａｃｋを待って、別のパケットを再送信する。もっと進んだ方式（いわゆる「Ｎｅｗ−Ｒｅｎｏプロトコル」のような）では、「高速回復」モードにおいて受信した複写の各々について、セグメントの再送信が可能である。このプロセスの背後にある論理は、１つのセグメントがネットワークから出ると、送信側は別のパケットをネットワークに置くことができるということである。

再送信を容易にするために、本発明の代替的な実施形態に従って、イン・ロジック３２は、ＴＣＰによって有効と判定され上位レイヤ・プロトコル（ＵＬＰ）の決定（例えば図１２のステップＳ９）に基づいてＴＣＰによってドロップされた受信ＴＣＰセグメントをカバーする第１の複写ＴＣＰ肯定応答（Ａｃｋ）を発生し、この複写ＴＣＰ Ａｃｋを送信する。上述のように、ＵＬＰは、ＭＰＡプロトコル、ＤＤＰプロトコル、およびＲＤＭＡプロトコルのうち１つ以上を含むことができる。ＴＣＰセグメントがイン・オーダかアウト・オブ・オーダかに関わらず、次のイン・オーダＴＣＰセグメントが受信されていない場合でも、ＴＣＰセグメントについて第１の複写ＴＣＰ Ａｃｋを発生する。また、イン・ロジック３２は、次のアウト・オブ・オーダ受信ＴＣＰセグメントをカバーする第２の複写ＴＣＰ肯定応答（Ａｃｋ）を発生し、この第２の複写ＴＣＰ Ａｃｋを送信することができる。

この上述の処理が効果的に示すのは、次のイン・オーダのセグメント（例えば上述の例ではセグメントＢ）がまだ受信されていない場合があるとしても、複写Ａｃｋ（例えば上述の例ではセグメントＡのための）を発生するということであり、このため、上述の再送信ルールのもとで送信側を再び高速経路モードにするプロセスを高速化しなければならない。更に具体的には、セグメントＢが受信されていない場合であっても、送信側は、セグメントＡすなわち有効ＴＣＰセグメントが受信され、ＵＬＰの問題点のためにドロップされたことを知っている。この結果、再送信開始の前に多数の複写Ａｃｋを受信しなければならない場合、追加の複写Ａｃｋは、もっと早期に送信側に再送信手順を開始させる。この手法は、ＴＣＰの原理に反する。なぜなら、ＴＣＰセグメント１０６はＵＬＰに正常に配信され、ＵＬＰの問題点（無効ＣＲＣ）のためにドロップされたからである。従って、このパケットはドロップされず、ＩＰプロトコルによる再順序付けもされなかった。この手法は、図１３に概要を示したように、ＲＮＩＣ１６が有限再送信試行モードを実施する場合、すなわちステップＳ１０４でＡｃｋを送信する場合、特に有益である。

Ｅ．ＣＲＣ計算および妥当性確認
入来するイーサネット・フレームの従来の処理は、フィルタリング・プロセスから始まる。フィルタリングの目的は、有効なイーサネット・フレームを無効なものを分離することである。「無効フレーム」は、破損したフレームではなく、ＲＮＩＣ１６によって受信してはならないフレームである。例えば、ＭＡＣフィルタリングすなわちＭＡＣアドレスに基づくフレーム選択、仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）フィルタリングすなわちＶＬＡＤタグに基づくフレーム選択等である。有効フレームは、ＲＮＩＣ１６内に入ることができ、異なるタイプに分離される。これらのタイプの１つがＴＣＰセグメントである。フィルタリング・プロセスは実行中に行われ、全イーサネット・フレームの蓄積交換処理を行う必要はない。

ＴＣＰセグメント処理の次のステップは、ＴＣＰチェックサムの計算および妥当性確認である。チェックサムの計算は、エラーなしでデータが送信されたか否かを判定するものであり、通常はデータ・ブロックにおける二進値を用いて送信時の値を計算し、何らかのアルゴリズムを用いて、その結果と共にデータをストアし、受信時に同じように計算した値と比較する。チェックサムの計算および妥当性確認には、全ＴＣＰセグメント・ペイロードをカバーするために、全ＴＣＰセグメントの蓄積交換処理が必要である。従来、巡回冗長検査（ＣＲＣ）の計算および妥当性確認は、通常、ＴＣＰチェックサム妥当性確認の後に行われる。すなわち、接続をＲＤＭＡ接続として認識した後、および、ＤＤＰセグメントの境界を、以前のＤＤＰセグメント長またはＭＰＡマーカのいずれかを用いて検出した後である。ＣＲＣの計算および妥当性確認は、正確にデータを送信したか否かを判定するため、メッセージを所定の長さに分割し、これは被除数として用いられ、固定の除数で除算される。計算の剰余は、メッセージに追加されて、受信側によって行われる同一の計算により比較される。また、ＣＲＣの計算および妥当性確認には、全ＤＤＰセグメントの蓄積交換が必要であり、これは待ち時間を増大させ、ストアのために大きなデータ・バッファを必要とする。ＣＲＣ計算の１つの要件は、ＤＤＰセグメント境界を知ることであり、これは、先行するＤＤＰセグメント長を用いること、またはＭＰＣマーカ１１０（図２）を用いることのいずれかによって求められる。マーカに基づいた決定は、多くの例外およびコーナー・ケース（corner case）が多いので、極めて複雑である。また、部分的に受信したＤＤＰセグメントのＣＲＣ計算は、複雑なプロセスである。

上述の問題に対処するため、図１１に示すように、本発明は、ＴＣＰチェックサム・ロジック６６によるＴＣＰチェックサム計算および妥当性確認と平行して、同じ蓄積交換バッファ６８を用いて、ＣＲＣロジック６４によってＣＲＣ計算および妥当性確認を行う。更に、本発明は、ＤＤＰセグメント境界の位置をすぐに特定してその後にＤＤＰセグメントＣＲＣを計算し妥当性確認するのではない。本発明は、ＣＲＣを計算し、その後にＤＤＰ境界を求めることによって、動作の順序を切り替える。この切り替えを行うため、ＣＲＣロジック６４は、各ＴＣＰセグメントが（セグメントがＲＤＭＡ接続に属することがわかる前に）整列ＤＤＰセグメントで開始すると想定する。更に、本発明は、ＴＣＰペイロード１２７（図２）の最初の２バイトが、ＭＰＡフレームのＭＰＡ長フィールド１１４（図２）であると想定する。次いで、この長さを用いて、ＤＤＰセグメント境界を識別し、そのセグメントのＣＲＣを計算する。妥当性確認ユニット４４が、ＴＣＰセグメント１０６において最初の可能なＤＤＰセグメント１１２の境界を識別した後、これは、ＴＣＰセグメント・ペイロード１２７のその部分についてのチェックサム計算と同時に、そのＤＤＰセグメントのＣＲＣを計算し妥当性確認し、次いで、同じＴＣＰセグメント１０６に含まれる次の存在し得るＤＤＰセグメント１１２（存在する場合）に進む。ＴＣＰセグメント１０６において発見される各「存在する可能性のある」ＤＤＰセグメントでは、ＣＲＣ妥当性確認の結果は、有効、無効、または長すぎるという場合がある。ＣＲＣ妥当性確認の結果はストアされて、図１２に関して上述したように用いられる。

上述のようにＣＲＣを実際に計算するために、ＴＣＰセグメント１０６のペイロードを処理する場合、イン・ロジック３２は、ＴＣＰセグメント１０６内のどこにＭＰＡマーカ１１０があるのかを知る必要がある。図２に関して上述したように、ＭＰＡマーカ１１０は、ＴＣＰセグメント１０６において５１２バイトごとに配置され、第１のＭＰＡマーカは、接続コンテキスト４２のStartNumフィールド２４８（図１０）としてストアされているＴＣＰヘッダ１２６（図２）における初期シーケンス番号から５１２バイトである。しかしながら、各ＭＰＡマーカ１１０を評価することでは、StartNum２４８（図１０）に対するその位置は明らかにならない。更に、ＭＰＡマーカ１１０は、ＣＲＣデータ１１６によってカバーされているが、ＭＰＡ長フィールド１１４には含まれず、これはＭＰＡフレームのペイロードのみを含む。従って、ＭＰＡマーカ１１０を識別するためには、ＲＮＩＣ１６は、StartNum２４８（図１０）を知る必要があり、これを接続コンテキスト４２からフェッチしなければならない。しかしながら、接続コンテキスト４２の読み取りは、ＴＣＰ処理の間に行うのは極めて不便である。これは、処理において極めて早期に行われ、パケット処理を分解するかまたは停止させるからである。

接続コンテキスト４２のフェッチを低減するまたは削除するために、本発明は、４つの代替案を提示して、ＤＤＰセグメント１１２長のＭＰＡ ＣＲＣを計算し妥当性確認するために必要であるＤＤＰセグメント１１２長の正確な計算を可能とする。これらのオプションについて、以下の節で述べる。

１．接続コンテキストプリフェッチ（prefetch）方法
ＤＤＰセグメント１１２長を正確に計算するための第１の代替的な実施形態は、StartNumフィールド２４８（図１０）としてストアされている初期シーケンス番号の接続コンテキスト４２のプリフェッチを実施することを含む。ここでは、ＭＰＡ仕様の変更は提示しない。現在のＭＰＡ仕様では、ＴＣＰセグメント１０６内のＭＰＡマーカ１１０の位置を識別するために、初期シーケンス番号（StartNum）を知ることが必要である。初期シーケンス番号は、ＴＣＰ接続属性であり、これは接続ごとに異なり、接続確立時に取り決められる。従って、StartNum２４８（図１０）は、接続ごとに維持される。ＭＰＡマーカ１１０の位置を識別するため、ＣＲＣロジック６４（図１１）は、５１２を法とした特定のセグメントのシーケンス番号（SeqNum）およびStartNumの剰余（SeqNum-StartNum）がゼロであることを調べる。すなわち、各ＴＣＰセグメント１０６のヘッダがそのペイロードの第１のバイトのシーケンス番号を保持するので、ＣＲＣロジック６４は、特定のセグメントのシーケンス番号とStartNum２４８との間の差を取り、次いでこの位置から始めて、５１２バイトごとにマーカを位置付けることによって、どこでマーカを探すべきかを判定することができる。ＭＰＡ仕様は、上述のマーカ検出方法を定義する。このように、ハッシュ照合（ＴＣＰタプルに基づく）および接続コンテキスト４２のプリフェッチを、ＴＣＰチェックサム妥当性確認を行う前に実行することができる。これは、通常の接続コンテキスト４２のフェッチ・フローである。ＲＮＩＣ１６が接続コンテキスト４２を取得したい場合、まず、このコンテキストがどこに位置付けられているかを理解するか、または接続ＩＤを得る必要がある。ＴＣＰセグメント１０６ヘッダは、ＴＣＰタプル（ＩＰアドレス（ソースおよび宛先）ならびにＴＣＰポート（ソースおよび宛先））を保持する。タプルは、ハッシュ関数に対する入力である。ハッシュ関数の出力は接続ＩＤである。むろん、異なるタプルに対して同じ接続ＩＤを使う結果となる場合があり、これは「衝突」と呼ばれる。衝突を処理するために、ＲＮＩＣ１６は、接続コンテキスト４２を読み取り、接続コンテキスト４２におけるタプルをパケット内のタプルと照合し、一致しない場合、ＲＮＩＣ１６は次の接続コンテキスト４２に対するポインタを取得する。ＲＮＩＣ１６は、一致を見出すまで、またはセグメントが既知の接続のどれにも属さないと認識されるまで、タプル照合を続ける。このプロセスによって、ＴＣＰストリーム内でＭＰＡマーカ１１０の位置を特定することができる。この結果、ＣＲＣ計算および妥当性確認は、ＴＣＰチェックサム妥当性確認と同時に行うことができる。

２．初期シーケンス番号取り決め方法
第２の代替的な実施形態では、ＭＰＡ仕様に多数の変更を行うことによって、接続コンテキストのフェッチを行うことなく、ＤＰセグメント長を正確に計算することができる。第１に、ＭＰＡ仕様におけるＭＰＡマーカ１１０の配置の定義を変更する。上述の接続コンテキストプリフェッチ方法の１つの欠点は、ＴＣＰセグメント１０６においてＭＰＡフレーム１０９の境界を識別するために、ハッシュ照合および接続コンテキスト４２のプリフェッチを行う必要があるということである。これを防ぐため、本発明は、ＭＰＡマーカ１１０を５１２バイトごとに配置し、初期シーケンス番号（ＳＮ）（StartNum２４８としてセーブされている）で開始する５１２バイトごと（これは、上述の５１２を法としたSN-StartNum処理を必要とする）には配置しない。このように、ＭＰＡマーカ１１０の位置は、ＭＰＡマーカ１１０の位置を特定するための５１２を法としたシーケンス番号プロセスによって求めることができ、接続コンテキスト４２のフェッチは必要ない。

本実施形態によるＭＰＡ仕様の第２の変更は、１つのマーカが２つのＤＤＰセグメント１１２間で分割される状況、すなわち、初期シーケンス番号がワードに整列していない状況を回避するように機能する。結果として、５１２を法とするシーケンス番号のプロセスは、全ての環境で機能するわけではない可能性がある。なぜなら、標準的なＴＣＰ実施では、初期ＳＮは、ランダムに発生したバイトに整列した値を有することができるからである。すなわち、初期シーケンス番号がワード整列であるか否かは、ＲＮＩＣ１６によって制御することはできない。このため、所与の接続についてのＴＣＰストリームは、必ずしもＭＰＡマーカ１１０で開始するわけではない。従って、ＣＲＣロジック６４が、単に５１２を法とするシーケンス番号プロセスを用いることによってマーカ１１０の位置を選ぶ場合、得られるマーカはバイト整列位置に配置されている可能性があるが、これは許容できない。この状況を回避するため、本発明は、ＭＰＡ取り決め段階の間に交換されるＭＰＡフレームに、パディング、すなわち、いわゆる「ＭＰＡ要求／応答フレーム」を追加して、ＲＤＭＡモードに移行する場合のＲＤＭＡ接続の初期ＳＮをワードに整列させる。すなわち、図１７に示すように、初期ＳＮをワードに整列させるために必要なバイト数を含むＴＣＰセグメント１０６のＭＰＡ要求／応答フレーム１５２に、補正ファクタ１５０を挿入する。補正ファクタ１５０の正確な位置を図示する必要がないことは認められよう。このように、ＣＲＣロジック６４は、５１２を法とするシーケンス番号プロセスを実施して、接続コンテキストフェッチを行うことなく、ＴＣＰストリーム内でのＭＰＡマーカ１１０の正確な位置を得ることができる。ＭＰＡ仕様の上述の変更を用いて、本発明は、接続コンテキスト４２のプリフェッチを行うことなく、ＭＰＡマーカ１１０の位置を特定し、ＭＰＡセグメントの長さを適正に計算することができる。

３．ＭＰＡ長フィールド変更方法
接続コンテキストフェッチを行うことなくＤＤＰセグメント１１２長を正確に計算するための第３の代替的な実施形態では、ＭＰＡ仕様におけるＭＰＡ長フィールド１１４の定義を変更する。従来、ＭＰＡ長フィールド１１４は、各ＭＰＡフレーム１０９のＵＬＰペイロードの長さを保持するように規定され、ＭＰＡレイヤによって追加されたマーカ１１０、パディング１２１（図２）、ＣＲＣデータ１１６は除く。しかしながら、この情報では、ＴＣＰセグメント１０６が提供する情報を用いてＭＰＡフレーム境界の位置を特定することができない。これに対処するため、この代替的な実施形態によれば、ＭＰＡ仕様におけるＭＰＡ長の定義を変更して、次のものを含む全ＭＰＡフレーム１０９の長さを明記する。すなわち、ＭＰＡ長フィールド１１４の最上位１４ビット（ＭＳＢ）、ＵＬＰペイロード１１８長、ＭＰＡマーカ１１０、ＣＲＣデータ１１６、ＭＰＡＧ長フィールド１１４の最下位２ビット（ＬＳＢ）、およびパディング１２１における有効ビットである。

この修正した定義によって、そのＭＰＡフレームに埋め込まれた全てのＭＰＡマーカ１１０の位置を特定することなく、ＭＰＡ長フィールド１１４を用いて、ＭＰＡフレーム１０９の境界を検出することができる。ＭＰＡレイヤ・プロトコルは、マーカ１１０、ＣＲＣデータ１１６、およびパディング１２１を取り除く役割があり、ＵＬＰ（ＤＤＰレイヤ）にＵＬＰペイロード長を提供する。

図１８を参照すると、このＭＰＡ長の定義を用いて、ＣＲＣロジック６４は、以下のプロセスによってＭＰＡフレーム１０９の境界の位置を特定する。ステップＳ１００において、ＣＲＣロジック６４は、ＭＰＡフレーム１０９の最初のワードがゼロに等しいか否かを判定する。ＹＥＳの場合、イン・ロジック３２（図９）は、ステップＳ１０２において、次のワードからＭＰＡ長フィールド１１４を読み取る。これは、マーカ１１０が２つのＭＰＡフレーム１０９間にある場合に当てはまる。この状況では、ステップ１０４に示すように、対のワード内にＭＰＡ長フィールド１１４の位置を特定する。ステップＳ１００においてＮＯと判定された場合、このワードはＭＰＡ長フィールド１１４を保持する。ステップＳ１０６において、ＭＰＡ長を用いて、このＭＰＡフレーム１０９をカバーするＣＲＣデータ１１６の位置を探し出す。次いで、上述のプロセスは繰り返し、ＴＣＰセグメント１０６に埋め込まれた他のＭＰＡフレーム１０９の位置を特定する。この実施形態によって、接続コンテキスト４２からの追加の情報を用いずに、ＭＰＡフレーム１０９の境界の位置を特定することができる。

４．マーカなしのカットスルー実施
第４の代替的な実施形態では、ＣＲＣ計算および妥当性確認に関して、マーカなしのカットスルー実施を用いる。これについて以下で説明する。ＤＤＰセグメント長を正確に計算するための上述の３つの代替的な実施形態の欠点は、各々が、ＭＰＡ仕様の変更または接続コンテキスト４２のプリフェッチを必要とすることである。この実施形態は、到着するＭＰＡフレームのＣＲＣを計算するために接続コンテキスト４２のプリフェッチを行うことなく、更に、ＭＰＡ仕様に対する追加の変更を行うことなく、インバウンド・セグメントのカットスルー処理を実施する。更に、この実施形態は、ＭＰＡマーカを用いることなく、アウト・オブ・オーダの直接データ配置を可能とする。この実施形態は、ＭＰＡ仕様の新しい更新バージョンに従って、所与の接続について「マーカなし」のオプションを取り決めることができる受信側の能力に部分的に基づいている。具体的には、更新されたＭＰＡ仕様によって、ＭＰＡ受信側は、所与の接続についてマーカを用いるか否かを決定することができ、送信側は受信側の決定を尊重しなければならない。この実施形態は、妥当性確認ユニット４４ロジックを変更して、ＴＣＰチェックサム計算と同時に、接続コンテキスト４２のプリフェッチを行うことなく、実行中にＣＲＣ計算を行うことを可能とする。

ＣＲＣ計算は、マーカを用いた場合について説明したのと全く同様に行う。すなわち、本発明は、ＴＣＰセグメントが整列ＤＤＰセグメントで開始することを想定し、ＭＰＡ長フィールドを用いてＣＲＣの位置を探し出し、次いでＣＲＣを計算し妥当性確認する。しかしながら、この実施形態における相違は、ＭＰＡヘッダのＭＰＡ長フィールドが与えられれば、ＤＤＰセグメント長を計算する場合にマーカを考慮する必要がないということである。

図１９を参照すると、この実施形態の第１の代替案に関連したイン・ロジック３２の機能性を示すフロー図が示されている。イン・ロジック３２の機能性の多くは、図１２に関して上述したものとほぼ同様であることは認められよう。明確さの目的のため、イン・ロジック３２の機能性が図１２に関して上述したものとほぼ同様である場合、ステップを破線で示す枠内で繰り返し示す。

更新したＭＰＡ仕様のもとで、受信側は、接続初期化の時点で特定の接続について「マーカなし」オプションを取り決める。図１９に示すように、この実施形態では、ステップＳ２０１において、イン・ロジック３２は、インバウンドＴＣＰセグメント１０６がマーカ１１０を含むか否かを判定する。ＹＥＳの場合、イン・ロジック３２は図１２に示すような処理に進み、上述のように、他の何らかのＣＲＣ計算および妥当性確認の方法を用いる。ＮＯの場合、ステップＳ２０２において、インバウンドＭＰＡフレーム１０９は、ＴＣＰチェックサム・ロジック６６と同じ蓄積交換バッファ６８を用いて実行中にＣＲＣの計算および妥当性確認を行うが、接続コンテキスト４２のフェッチは行わない。また、図１２に示すのと同様のステップＳ２およびＳ３で、接続がＳＬＯＷ接続であるか否かの判定を行うことができる。ＣＲＣ妥当性確認の結果は、以下のうちの１つであり得る。（１）ＭＰＡフレーム１０９の長さがＴＣＰセグメント１０６の長さに一致し、ＭＰＡフレーム１０９が有効ＭＰＡ ＣＲＣを有する。（２）ＭＰＡフレーム１０９の長さがＣＧＰセグメント１０６の長さに一致するが、ＭＰＡフレーム１０９は無効ＣＲＣを有する。（３）ＭＰＡフレーム１０９の長さがＴＣＰセグメントの長さより大きい、（４）ＭＰＡフレーム１０９の長さがＴＣＰセグメント１０６の長さよりも小さい。

（１）の場合、イン・ロジック３２は、図１２のステップＳ４からＳ７とほぼ同様に動作する。すなわち、ＭＰＡフレーム１０９がＴＣＰセグメント１０６と同じ長さを有し（図１２のステップＳ４およびＳ５）、かつ有効ＭＰＡ ＣＲＣを保持する（ステップＳ６）場合、フレームは有効ＭＰＡフレームと見なされ、更に別の処理のために、内部データ・バッファ３８を介してアウト・ロジック４０に渡され、更に、高速経路モードで宛先データ・バッファ５０に渡される。

（２）において、ＭＰＡフレーム１０９はＴＣＰセグメント１０６と同じ長さを有する（図１２のステップＳ４およびＳ５）が、無効ＣＲＣを有する（図１２のステップＳ６）場合、イン・ロジック３２は、図１２に関して説明したのとは異なる方法で動作する。具体的には、受信したＭＰＡフレーム１０９がＭＰＡマーカ１１０を含まないので、（図１２のステップＳ１０におけるように）マーカ関連情報を回復のために用いることができない。これによって、対処する必要があるケースは２つのみ生じる。ケースＡ、すなわち、ＭＰＡフレーム１０９が以前に受信したセグメント（および妥当性確認された）ＭＰＡフレーム１０９の長さによって参照される場合（図１２のステップＳ８において判定したように）、および、ケースＢ、すなわち他の全ての場合である。ケースＡでは、ＭＰＡフレーム１０９は破損し、ケースＢでは、ＭＰＡフレーム１０９は破損しているかまたは整列していない可能性がある。双方の場合で、受信したＴＣＰセグメント１０６はドロップされ（図１２のステップＳ９）、受信は確認されない。この場合、図１３に関連して述べた有限再送信試行モードを実施して、そのＴＣＰセグメント１０６のドロップから回復することができる。これによって、送信側は、ドロップしたＴＣＰセグメント１０６を再送信し、いずれかのあり得るデータ破損を解決することができる。ＭＰＡフレーム１０９がＴＣＰセグメント１０６に整列していなかった場合、上述のように、有限再送信試行モードは、接続をＳＬＯＷ接続に格下げして終了することになる。

（３）において、ＭＰＡフレーム１０９の長さがＴＣＰセグメント１０６の長さを超えている（図１２のステップＳ５）場合、ＭＰＡフレーム１０９はＴＣＰセグメント１０６に整列していないか、または、その長さが破損している。この場合、受信したＴＣＰセグメント１０６はドロップされ（図１２のステップＳ９）、ＴＣＰは受信を確認しない。この場合も、図１３に関して説明した有限再送信試行モードを実施して、そのＴＣＰセグメント１０６から回復することができる。これによって、送信側は、ドロップしたＴＣＰセグメントを再送信し、いずれかのあり得るデータ破損を解決することができる。ここでも、ＭＰＡフレーム１０９がＴＣＰセグメント１０６に整列していない場合、上述のように、有限再送信試行モードは、接続をＳＬＯＷ接続に格下げして終了することになる。

（４）において、ＭＰＡフレーム１０９の長さがＴＣＰセグメント１０６より小さい（図１２のステップＳ４）か、またはＴＣＰセグメント１０６が多数のＭＰＡフレーム１０９を保持する可能性がある（送信側がパッキング・オプションを実行する）場合、イン・ロジック３２は、受信したＴＣＰセグメント１０６に埋め込まれた全てのＤＤＰセグメント１１２のＣＲＣを順次チェックする（図１２のステップＳ１１からＳ１３）。全てのＤＤＰセグメント１１２が有効ＣＲＣを有する場合、イン・ロジック３２は、そのＴＣＰセグメント１０６の受信を承認し、全てのＭＰＡフレームは、更に別の処理のために、高速経路モードで転送される（図１２のステップＳ７）。ＤＤＰセグメント１１２のうち１つが無効ＣＲＣを有する場合、または最後のセグメントが完全にはＴＣＰセグメントに含まれていない場合（図１２のステップＳ１２からＳ１３）、全ＴＣＰセグメントはドロップされ（図１２のステップＳ９）、イン・ロジック３２はそのＴＣＰセグメントの受信を確認しない。上述のように、図１３に関連して述べた有限再送信試行モードを実施して、そのＴＣＰセグメント１０６から回復することができ、これによって、送信側は、ドロップしたＴＣＰセグメントを再送信し、いずれかのあり得るデータ破損を解決することができる。ＭＰＡフレーム１０９がＴＣＰセグメント１０６に整列していなかった場合、上述のように、有限再送信試行モードは、接続がＳＬＯＷ接続に格下げして終了することになる。

図２０に移ると、この実施形態に関連したイン・ロジック３２の機能性を示し、有限再送信試行モードおよびＴＣＰ再送信高速化の態様を含む別の代替的なフロー図が示されている。図１９とは異なり、イン・ロジック３２の機能性は、図１２に比べて大幅に簡略化されている。明確さの目的のため、イン・ロジック３２の機能性が図１２に関連して上述したものとほぼ同様である場合、ステップを破線で示す枠内で繰り返し示す。

図２０において、ステップＳ１５１からＳ１５３は、図１２のステップＳ１からＳ３とほぼ同一である。ステップＳ１５４において、イン・ロジック３２は、ＣＲＣ妥当性確認が合格したか否かを判定する。この評価は、図１２のステップＳ４とは異なり、ＤＤＰセグメントごとに指示を与えるのではなく、ＣＲＣロジック５４はCRCValidationPassedビットを提供する。これは、受信したＴＣＰセグメント内の全ＤＤＰセグメントのＣＲＣ妥当性確認の成功または失敗を示す。受信したＴＣＰセグメントに含まれる全てのＤＤＰセグメントについてＣＲＣ妥当性確認が合格した場合には、このビットがセットされ、セグメントの１つについてＣＲＣ妥当性確認が不合格であった場合または最後の（唯一の）セグメントが長すぎた場合には、このビットはクリアされる。ＮＯの場合、イン・ロジック３２はステップＳ１５５に進み、RecoveryAttemptsNum（図１０のフィールド２９２）が、MaxRecoveryAttemptsNum（図１０のフィールド２９６）より大きいか否かを判定する。ＹＥＳの場合、イン・ロジックはステップＳ１５３に進み、ＤＤＰセグメントをリアセンブリ・バッファ３４に配置し、Ａｃｋを送信し、接続を（これがＦＡＳＴ接続であった場合）ＳＬＯＷ接続に格下げする。ステップＳ１５５においてＮＯの場合、次いでステップＳ１５６において、ＴＣＰセグメント１０６をドロップし、確認はスケジューリングされない。更に、RecoveryAttemptNum（図１０のフィールド２９２）を１だけ増分し、LastRecoverySN（図１０のフィールド２９４）を更新する。

ステップＳ１５４に戻り、判定結果がＹＥＳの場合、イン・ロジック３２は、ステップＳ１５７に進み、新たに受信したイン・オーダのデータ転送シーケンス番号（イン・オーダＳＮ）がLastRecoverySN（図２のフィールド２９４）より大きいか否かを判定する。ＹＥＳの場合、次いでステップＳ１５８において、イン・ロジック３２は、RecoveryAttemptsNum（図２のフィールド２９２）をクリアする、すなわちこれをゼロにセットする。ステップＳ１５７においてＮＯの場合、またはステップＳ１５８の次に、ステップＳ１５９において、セグメントを宛先データ・バッファ５０に配置することによって、セグメントを「高速経路モード」で処理する。また、ステップＳ１５９は、ＴＣＰ再送信高速化オプションに関連付けて述べたように、複写Ａｃｋの実施を含むことができる。

上述の図２０の実施形態は、本発明のカットスルー・モードおよび有限再送信試行モードおよびＴＣＰ再送信高速化オプションを、ＭＰＡマーカを用いることなく実施する。

ＩＩＩ．アウト・ロジック
アウト・ロジック４０（図９）は、ＲＤＭＡメッセージごとの情報を保持することなく、ＲＤＭＡメッセージのイン・オーダ配信を実行する。対処される状況は２つある。すなわち、（１）送信メッセージを除く全てのＲＤＭＡメッセージについて、および、（２）ＲＤＭＡ送信メッセージ、である。

図６から図８に戻って、アウト・ロジック４０（図９）の動作を説明する。アウト・ロジックは、上述のように、高速経路モードで配置された内部データ・バッファ３８（図９）からの整列ＤＤＰセグメント２２０を処理し、整列ＤＤＰセグメントのデータ配置および受信側データ・バッファへの配信を行う。本明細書中で用いる場合、「配置」は、データを実際にバッファ内に置くプロセスを示し、「配信」は、データ転送の完了を確認するプロセスを示す。「配置」は、セグメントおよびメッセージの双方に適用可能であるが、「配信」はメッセージのみに適用される。ＲＤＭＡプロトコルのもとで、整列ＤＤＰセグメントは、アウト・オブ・オーダで配置される場合があるが、配信は、整列ＤＤＰセグメントの全てがイン・オーダに配置されるまで行われない。例えば、３つの整列ＤＤＰセグメント１、２、および３について、セグメント２および３が最初にセグメント１なしで配置される場合、セグメント１が配置されるまで配信は行われない。

Ａ．配置
配置に関して、アウト・ロジック４０は、ＲＤＭＡ読み取りメッセージを除いて、ＲＤＭＡメッセージの従来の配置を行う。これについて、以下で述べる。

タグ付きＤＤＰセグメントに関して、例えば図４に戻ると、ＲＤＭＡプロトコルに従って、タグ付きＤＤＰセグメントのヘッダ１２４は、受信側の以前に登録したメモリ領域（例えば図７のメモリ領域２３２）のアドレスを保持する。上述したように、このアドレスは、メモリ領域／ウインドウ（例えばＲＤＭＡ書き込みメッセージについて図７のメモリ領域２３２）内にある宛先バッファを示す開始タグ（ＳＴａｇ）、この領域／ウインドウにおけるターゲット・オフセット（ＴＯ）、およびトランザクション長（セグメント・ペイロード）を含む。この場合、データ配置は、従来の方法でアウト・ロジック４０によって行われ、接続コンテキスト４２（図９）から何ら追加情報を検索しない。従来のアドレス翻訳および保護（ＡＴＰ：Address Translation and Protection）プロセスは、ＳＴａｇおよびＴＯを、宛先データ・バッファを記述するメモリ領域の物理バッファのリストに変換するものであり、これは、アウト・ロジック４０によるデータ配置より前に行われる。

ＲＤＭＡ読み取りメッセージ等のタグなしＤＤＰセグメントに関して、図８を参照すると、ＲＤＭＡプロトコルは、待ち状態のインバウンド読み取り要求２２２の最大数を規定する。これは、交渉時に交換される。各ＲＤＭＡ読み取りメッセージ２０４は、単一のＤＤＰセグメント２２２を消費する。ＲＮＩＣ１６がＲＤＭＡ読み取りメッセージ２０４を受信すると、これは、ＲＤＭＡ読み取り応答ＷＱＥ２１６ＲＲを読み取りキュー２１４にポストする。別の例では、図６を参照すると、各送信メッセージ２００は、例えばデータ・シンク１８（図９）のような応答側の受信キュー（ＲＱ）２１２に配置される。上述のように、各受信キュー（ＲＱ）２１２は、制御命令が配置されるバッファであり、ペイロードが配置されるＷＱＥ２１６Ｒを含む。受信キュー（ＲＱ）２１２は、ＷＱＥ２１６Ｒを含む。各ＷＱＥ２１６Ｒは、コンシューマによってポストされた受信ＷＲ２０８Ｒを記述する制御情報を保持する。また、各ＷＱＥ２１６Ｒは、そのＷＲ２０８Ｒにおいてポストされたコンシューマバッファ（複数のバッファ）を指し示す。それらのバッファを用いて、ペイロードを配置する。従って、各メッセージ２００は、ＷＱＥ２１６Ｒを消費する。

図２１を参照すると、図８と同様のＲＤＭＡ読み取りメッセージ２０４およびＲＤＭＡ読み取り応答２０６が表されている。しかしながら、本発明によれば、読み取りキュー４１４は、循環バッファとして実施される特別なワーク・キュー（ＷＱ）として設けられ、この循環バッファの各エントリは、送信ロジックによって作成する必要があるＲＤＭＡ読み取り応答を記述するＷＱＥ２１６ＲＲである。これによって、アウト・オブ・オーダのＲＤＭＡ読み取り要求２２２を容易かつ効率的に配置することができる。なぜなら、各インバウンドＲＤＭＡ読み取り要求ごとに、読み取りキュー４１４内に周知の位置すなわちＷＱＥ２１６ＲＲがあるからである。例えば、ＲＤＭＡ読み取りメッセージ＃３が受信され、ＲＤＭＡ読み取りメッセージ＃２が失われた場合、ＲＤＭＡ読み取りメッセージ＃３は配置される。この配置は、ＲＤＭＡ読み取り要求メッセージ２２２、すなわち要求側の読み取りＷＲ２０８Ｒのポスティングにより送信されたメッセージの受信時に行われる。読み取りキュー４１４におけるＷＱＥ２１６ＲＲの位置は、ＲＤＭＡ読み取りメッセージ・ヘッダ１２４（図４）内のＭＳＮによって識別される。

Ｂ．配信
ＲＤＭＡプロトコルによって、アウト・オブ・オーダのデータ配置が可能となるが、配信はイン・オーダである必要がある。従って、従来の実施では、メモリに（全体的にまたは部分的に）配置されたがまだ配信されていない各メッセージに関する情報を維持する必要がある。しかしながら、単一のＴＣＰセグメントが失われると、多くのアウト・オブ・オーダのＲＤＭＡメッセージが受信されることになる恐れがあり、これは宛先バッファに配置され、失われたセグメントが再送信されてメモリに正常に配置されるまで完了しない。従来の環境のもとでは、アウト・オブ・オーダのストリームをストアするために限られたリソースを利用可能であり、アウト・オブ・オーダのストリームを受信した後に、ある数のみの以降のメッセージをストアすることができるようになっている。

しかしながら、本発明によれば、配信されていないＲＤＭＡメッセージごとにある情報を保持し、従ってサポートされるアウト・オブ・オーダの受信メッセージの数を制限するのではなく、ＴＣＰホールごとに情報をストアすることによって、無限の数の配信されないＲＤＭＡメッセージをサポートする。「ＴＣＰホール」は、アウト・オブ・オーダのＴＣＰセグメントを受信した結果としてＴＣＰストリーム内に生成される空きを表す言葉である。

図２２を参照すると、白いブロックは、ＴＣＰホール１３０Ａから１３０Ｃを形成する失われたＴＣＰセグメント４００を示し、陰影を付けた／グレーのブロック４０２は、連続して受信されるＴＣＰストリームを示す。ＴＣＰホール１３０Ａ〜１３０Ｃごとの情報は、接続コンテキスト４２（図１０）にストアされる。限られた数のＴＣＰホール１３０Ａから１３０Ｃのサポートは、ＴＣＰプロトコルの実施から引き継がれた特徴である。具体的には、ＴＣＰプロトコルは通常、サポートするＴＣＰホール１３０Ａから１３０Ｃの数を、例えば１、２、または３のホールに制限する。通常、限られた数のＴＣＰホール１３０Ａから１３０Ｃのサポートによって効果的に示されるのは、アウト・オブ・オーダのＴＣＰセグメントが到着し、新たなＴＣＰホールを開くと、このセグメントがＴＣＰロジックによってドロップされるということである。図２２は、３ＴＣＰホールの実施を示す。この場合、下部ＴＣＰホール１３０Ｃ、すなわち２つの下部の失われたセグメント４００の後に、新たなセグメントが到着した場合、このセグメントは第４のホールを「開く」が、これはサポートされない。この結果、そのセグメントはドロップされる。

この状況に対処するため、本発明は、アウト・オブ・オーダのメッセージ／セグメントの追跡ではなく、接続コンテキスト４２（図９および図１０）によって、ＴＣＰホール１３０（図２２）の追跡を実施する。具体的には、図１０に示すように、本発明は、PendingReadResponseNum フィールド３００をストアして、完了したＲＤＭＡ読み取り要求をカウントし、CompletedSendsNumフィールド３０２ストアして、完了した送信メッセージをカウントし、CompletedReadResponseNumフィールド３０６をストアして、完了したＲＤＭＡ読み取り応答をカウントする。当業者によって認められるように、各ホールごとに他のフィールドが必要とされる場合があるが、簡潔にするためにその説明は行わない。この手法によって、無限の数のアウト・オブ・オーダの受信ＲＤＭＡメッセージが、完了およびイン・オーダの配信を待つことができる。この手法は、何ら制限なく、受信キュー２１２および送信キュー２１０の双方によって完了キュー２４０（図６から図８）を共有する能力を制限しない。これより、特定のタイプのメッセージの処理の詳細について説明する。

第１に、ＲＤＭＡ書き込みメッセージ２０２（図７）の配信では、動作の性質のため、応答側にいかなる報告も行われず、他のハードウェア・ロジックにいかなる通知も行われないことに留意すべきである。従って、このタイプのＲＤＭＡメッセージに関しては、配信の問題は存在しない。

第２に、図２１に戻ると、ＲＤＭＡ読み取り応答メッセージ２０６に関して、この動作は、待ち状態のＲＤＭＡ読み取りメッセージ２０４の完了を表す。この場合、待ち状態のＲＤＭＡ読み取りワーク要求２０８Ｒを完了するための充分な情報を要求側の完了処理ロジックに与えるためには、ＴＣＰホール１３０ごとにある数の完了したＲＤＭＡ読み取り応答メッセージ２０６を含む接続コンテキスト４２においてCompletedReadResponseNumフィールド３０６（図１０）をストアすることで充分である。ＴＣＰホールが閉じると、このホールに関連したある数の完了ＲＤＭＡ読み取り応答は、要求側の完了処理ロジックに報告されて、待ち状態のＲＤＭＡ読み取りワーク要求２０８Ｒの完了を示す。

ＲＤＭＡ読み取り要求に関して、ＷＱＥ２１６ＲＲポストの動作は、２つのステップを含む。すなわち、ＷＱＥ２１６ＲＲを読み取りキュー４１４に配置すること、および、通知すなわち呼び鈴を鳴らして、このＷＱＥを処理可能であることをＲＮＩＣ１６に通知することである。ＷＱＥ２１６ＲＲの配置は、アウト・オブ・オーダで行うことができる。しかしながら、上述のように、ＷＱＥ処理の開始（従って、呼び鈴を鳴らすこと）は、ＲＤＭＡ順序付けルールに従わなければならない。すなわち、ＲＤＭＡプロトコルは、全ての以前に送信したあらゆる種類のＲＤＭＡメッセージが完了するまで、インバウンドＲＤＭＡ読み取りメッセージ２０４の処理を遅延させなければならない。従って、呼び鈴を鳴らすこと、すなわち通知は、全てのイン・オーダの先行するＲＤＭＡ読み取りメッセージ２０４が完了するまで、遅延させなければならない。単一の呼び鈴を鳴らす動作すなわち通知は、いくつかのＷＱＥ２１６ＲＲのポスティングを意味する場合がある。

上述の問題を解決するため、本発明によるＲＮＩＣ１６は、接続コンテキスト４２において（PendingReadResponseNumフィールド３００（図１０））、各ＴＣＰホール１３０ごとに（図２）、呼び鈴を鳴らすこと（通知）を待っているポストされたＲＤＭＡ読み取り応答ＷＱＥ２１６ＲＲの数をストアする。ＴＣＰホール１３０を閉じた場合、ＲＮＩＣ１６は、呼び鈴を鳴らして（通知）、読み取りキュー２１４に対するPendingReadResponseNumＷＱＥ２１６ＲＲのポスティングを確認する。これは、全ての先行する読み取りメッセージ２０４が完了したことを示し、ＲＮＩＣ１６は、ポストされた読み取り応答ＷＱＥ２１６ＲＲの処理を開始することができる。

図２３を参照すると、ＲＤＭＡ送信メッセージ５００は、独特の状況を表す。具体的には、完了した送信メッセージの配信は、ＣＱ５４０にＣＱＥ５４２を配置することを含む。ＣＱＥ５４２は、完了したメッセージを記述する情報（例えば長さ、ＳＴａｇの無効化等）を保持する。この情報は、メッセージに特定的な情報であり、従って待ち状態の送信メッセージ５００ごとに保持しなければならない。ＲＮＩＣ１６は、送信メッセージ５００が完了する前にＣＱＥ５４２を配置することができない（受信した読み取りワーク要求５０８ＲにおけるＲＤＭＡ読み取り応答ＷＱＥ５０８ＲＲの配置と同様）。なぜなら、ＣＱ５４０は、いくつかの送信キュー５１０および受信キュー５１２によって共有することができるからである。

この問題を、追加のＲＮＩＣリソースを消費することなく解決し、スケーラブルな実施を提供するため、本発明によるアウト・ロジック４０は、ＣＱＥ５４２に含まなければならない全ての情報を、その送信メッセージ５００によって消費されるＷＱＥ５１６Ｒに配置する。次いで、この情報は、完了のためのポーリング要求の際に、バーブ・インタフェース２０（図９）によってＷＱＥ５１６Ｒから検索される。ＲＮＩＣ１６は、接続コンテキスト４２にＴＣＰホール１３０ごとの完了した送信メッセージ５００の数を（CompletedSendsNumフィールド３０２に）維持しなければならない。これは、対応するＴＣＰホールが閉じた場合に、ＣＱＥ５４２をＣＱ５４０にポストするために用いられる。ＴＣＰホール１３０が閉じると、ＲＮＩＣ１６は、ＣＱＥ５４２をＣＱ５４０に配置する。配置されるＣＱＥ５４２の数は、このホールについてカウントされる完了送信メッセージ５００の数に等しい。この手法は、２Ｎ回の書き込み動作を伴う。ここで、Ｎは、完了した送信メッセージ５００の数である。

ＲＤＭＡ送信メッセージ５００の配信に関連して上述した手法の１つの欠点は、ＲＮＩＣ１６によって行われる書き込み動作の数が二倍になることである。すなわち、各完了送信メッセージ５００ごとに、ＷＱＥ５１６Ｒの１回の書き込みおよびＣＱＥ５４２の１回の書き込みが行われる。この問題に対処するため、図２４に示すように、本発明の代替的な実施形態によれば、ＣＱＥ５４２の内容を変更して、特定のＣＱＥ５４２が完了させるＷＱＥ５１６Ｒの参照カウンタ５４４を保持する。参照カウンタ５４４は、ＲＮＩＣ１６によって、所与のＴＣＰホール１３０のために完了した送信メッセージ５００の数に初期化される。バーブ・インタフェース２０は、完了のためのポーリング動作（完了ポーリング動作）ごとに、参照カウンタ５４４を１だけ減らし、カウンタがゼロになったＣＱ５４０からＣＱＥ５４２を除去する。更に、ＲＮＩＣ１６は、完了を待っている送信メッセージ５００の数がその閾値（Ｍ）より大きい場合にのみ、ＷＱＥ５１６Ｓを更新する。Ｍは構成可能なパラメータであり、待ち状態のインバウンド送信メッセージ５００の情報を保持するために割り当てられた内部リソース量を示す。Ｍがゼロに等しい場合、アウト・オブ・オーダで受信された送信メッセージ５００はいずれも、ＷＱＥ５１６Ｒの更新を伴う（イン・オーダで受信された送信メッセージ５００では更新は必要ない）。

また、この実施形態は、２種類のＣＱＥ５４２を規定すること、および、ＣＱＥ５４２をインジケータ５４６に与えることを含み、ＣＱＥがＣＱＥの本体に全ての完了データを保持するものであるか、または完了データの一部を保持し、完了情報の残りは１つ以上のＲＤＭＡ送信メッセージに関連するＷＱＥ５１６Ｒにストアされているものであるかを示す。この代替的な実施形態は、書き込み動作の回数をＮ＋１に減らす。ここで、Ｎは、ＴＣＰホール１３０が閉じる前に待ち状態であった、完了した送信メッセージ５００の数である。

ＩＶ．結論
先の考察において、この方法ステップは、本発明の機能タスクの１つ以上を実行するための専門のハードウェアを含む特定のユーザ・コンピュータ、すなわち有限状態マシンによって実行されることが好ましい。しかしながら、この方法ステップは、メモリにストアされたプログラムの命令を実行するＣＰＵ等のプロセッサによっても実行可能である。本明細書中で記載した様々なデバイス、モジュール、機構、およびシステムは、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせによって実現可能であり、図示したもの以外に区分化することができることは理解されよう。それらは、本明細書中に記載した方法を実行するために適合されたいずれかのタイプのコンピュータ・システムまたは他の装置によって実施可能である。ハードウェアおよびソフトウェアの典型的な組み合わせは、コンピュータ・プログラムを有する汎用コンピュータ・システムであり、このプログラムがロードされて実行されると、コンピュータ・システムを制御して、本明細書中に記載した方法を実行するようになっている。また、本発明は、コンピュータ・プログラムに埋め込むことも可能である。このプロダクトは、本明細書中に記載した方法および機能の実施を可能とする全ての特徴を含み、コンピュータ・システムにロードされた場合、これらの方法および機能を実行することができる。このコンテキストにおいて、コンピュータ・プログラム、ソフトウェア・プログラム、プログラム、またはソフトウェアは、いずれの言語、記号体系、または表記においても、１組の命令の表現を意味し、直接に、または、（ａ）別の言語、符号体系、または表記への変換、あるいは（ｂ）異なる材料形態での再生、またはその両方の後に、情報処理機能を有するシステムに特定の機能を実行させるように意図されている。

本発明について、上述の具体的な実施形態に関連付けて説明したが、当業者には、多くの代替、変更、および変形が明らかであろう。従って、上述の本発明の実施形態は、限定でなく例示のために意図されたものである。特許請求の範囲において規定される本発明の精神および範囲から逸脱することなく、様々な変更を行うことができる。特に、記載したステップの順序は、異なる１組のステップによって与えられ、本発明の範囲から逸脱しないある状況または機能において、変更することができる。

本発明は、コンピュータ・プログラミングおよび情報技術の分野において有用である。

従来のデータ転送環境およびＲＮＩＣのブロック図を示す。 ＴＣＰ／ＩＰデータ転送構造上の従来のＭＰＡ／ＲＤＭＡ／ＤＤＰのブロック図を示す。 １つ以上のＤＤＰセグメントについて可能なＭＰＡマーカ参照のブロック図を示す。 従来のタグ付きＤＤＰヘッダのブロック図を示す。 従来のタグなしＤＤＰヘッダのブロック図を示す。 従来のＲＤＭＡメッセージ・データ転送のブロック図を示す。 従来のＲＤＭＡメッセージ・データ転送のブロック図を示す。 従来のＲＤＭＡメッセージ・データ転送のブロック図を示す。 本発明によるデータ転送環境およびＲＮＩＣのブロック図を示す。 図９のＲＮＩＣの接続コンテキストのブロック図を示す。 図９のＲＮＩＣの妥当性確認ユニットのブロック図を示す。 ＲＮＩＣ入力ロジック（すなわちイン・ロジック）機能のフロー図を示す。 図１２のイン・ロジックの有限再送信試行モードの実施形態のフロー図を示す。 図１２のイン・ロジックの有限再送信試行モードの実施形態のフロー図を示す。 代替的な実施形態による接続格下げの後のＴＣセグメントの処理を示すブロック図を示す。 図１２のイン・ロジックの接続格上げの実施形態のフロー図を示す。 巡回冗長検査（ＣＲＣ）の計算および妥当性確認のための初期シーケンス番号取り決め実施と共に用いるＭＰＡ要求／応答フレームを示す。 ＣＲＣ計算および妥当性確認のための代替的な変更ＭＰＡ長実施のためのフロー図を示す。 ＣＲＣ計算および妥当性確認のためのマーカなしカットスルー実施を用いたイン・ロジックの第１の代替的な実施形態のフロー図を示す。 ＣＲＣ計算および妥当性確認のためのマーカなしカットスルー実施を用いたイン・ロジックの第２の代替的な実施形態のフロー図を示す。 本発明による読み取りキューを含むＲＤＭＡ読み取りおよび読み取り応答メッセージ・データ転送のブロック図を示す。 ＲＮＩＣ出力ロジック（すなわちアウト・ロジック）が処理するメッセージのためのワーク・キュー要素（ＷＱＥ）およびＴＣＰホールのブロック図を示す。 本発明による完了キュー要素（ＣＱＥ）を含むＲＤＭＡ送信メッセージ・データ転送のブロック図を示す。 図２３のＣＱＥのブロック図を示す。

Claims (14)

1. アウト・オブ・オーダの遠隔メモリ・データ・アクセス（ＲＤＭＡ）送信メッセージの配信において受信キューへのワーク・キュー要素（ＷＱＥ）の書き込み動作及び完了キューへの完了キュー要素（ＣＱＥ）の書き込み動作の回数を減らす方法であって、システムに下記ステップを実行させることを含み、前記完了キューはＣＱＥを格納し、前記ＣＱＥは当該ＣＱＥが完了させるＷＱＥの参照カウンタを保持し、
   前記ステップは、
   アウト・オブ・オーダのＴＣＰセグメントを受信した結果としてＴＣＰストリーム内に生成される空きのために完了されたＲＤＭＡ送信メッセージの数に前記参照カウンタをセットするステップと、
   完了ポーリング動作ごとに、前記参照カウンタを１だけ減らすステップと、
   前記参照カウンタがゼロになった完了キューからＣＱＥを除去するステップと
   を含む、前記方法。
2. 前記システムに、
   待ち状態のＲＤＭＡ送信メッセージの数がその閾値の数より大きい場合にのみ送信キューのＷＱＥを更新するステップを更に実行させることを含む、請求項１に記載の方法。
3. 前記閾値が、待ち状態のＲＤＭＡ送信メッセージについての情報をストアするために割り当てられたリソースの数である、請求項２に記載の方法。
4. 前記システムに、
   前記ＣＱＥに完了データの少なくとも一部を含ませるステップを更に実行させることを含む、請求項１に記載の方法。
5. 前記完了データの残りが、１つ以上のＲＤＭＡ送信メッセージに関連付けられたＷＱＥに含まれる、請求項４に記載の方法。
6. 前記システムに、
   （１）前記ＣＱＥが全ての完了データを含むこと、および、（２）ＣＱＥ完了データが、１つ以上のＲＤＭＡ送信メッセージに関連付けられたＷＱＥに少なくとも部分的に含まれること、の一方を示すステップを更に実行させることを含む、請求項４に記載の方法。
7. 書き込み動作の回数がＮ＋１に等しく、ここで、Ｎは、前記空きが閉じる前に待ち状態であった完了されたＲＤＭＡ送信メッセージの数である、請求項１に記載の方法。
8. アウト・オブ・オーダの遠隔メモリ・データ・アクセス（ＲＤＭＡ）送信メッセージの配信において受信キューへのワーク・キュー要素（ＷＱＥ）の書き込み動作及び完了キューへの完了キュー要素（ＣＱＥ）の書き込み動作の回数を減らすためのシステムであって、
   ＣＱＥを格納する完了キューであって、前記ＣＱＥは当該ＣＱＥが完了させるＷＱＥの参照カウンタを保持する、前記完了キューと、
   アウト・オブ・オーダのＴＣＰセグメントを受信した結果としてＴＣＰストリーム内に生成される空きのために完了されたＲＤＭＡ送信メッセージの数に前記参照カウンタをセットする手段と、
   完了ポーリング動作ごとに、前記参照カウンタを１だけ減らす手段と、
   前記参照カウンタがゼロになった完了キューからＣＱＥを除去する手段と
   を備えている、前記システム。
9. 待ち状態のＲＤＭＡ送信メッセージの数がその閾値の数より大きい場合にのみ送信キューのＷＱＥを更新する手段を更に備えている、請求項８に記載のシステム。
10. 前記閾値が、待ち状態のＲＤＭＡ送信メッセージについての情報をストアするために割り当てられたリソースの数である、請求項９に記載のシステム。
11. 前記ＣＱＥに完了データの少なくとも一部をストアし、前記完了データの残りを１つ以上のＲＤＭＡ送信メッセージに関連付けられたＷＱＥにストアする手段を更に備えている、請求項８に記載のシステム。
12. （１）前記ＣＱＥが全ての完了データを含むこと、および、（２）ＣＱＥ完了データが、１つ以上のＲＤＭＡ送信メッセージに関連付けられたＷＱＥに少なくとも部分的に含まれること、の一方を示す手段を更に備えている、請求項１１に記載のシステム。
13. 書き込み動作の回数がＮ＋１に等しく、ここで、Ｎは、前記空きが閉じる前に待ち状態であった完了したＲＤＭＡ送信メッセージの数である、請求項８に記載のシステム。
14. アウト・オブ・オーダの遠隔メモリ・データ・アクセス（ＲＤＭＡ）送信メッセージの配信において受信キューへのワーク・キュー要素（ＷＱＥ）の書き込み動作及び完了キューへの完了キュー要素（ＣＱＥ）の書き込み動作の回数を減らすためのコンピュータ・プログラムであって、コンピュータに、請求項１〜７のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images