(57)【要約】【課題】  （例えば、ＴＣＰ／ＩＰオフロードエンジン（ＴＯＥ）における）伝送制御プロトコル（ＴＣＰ）受信器による完了合体のための方法およびシステムを提供する。【解決手段】  本方法は、インバウンドＴＣＰセグメントを処理するステップと、インバウンドＴＣＰセグメントの処理とは独立して、受信ＴＣＰ  ＡＣＫおよびＲＤＭＡ読み出し要求の一方または両方の完了処理を行うステップとを含む。【選択図】  図１
2007518360.tif 000002
【特許請求の範囲】
【請求項１】
完了処理のための方法であって、
インバウンドＴＣＰセグメントを処理するステップと、
前記インバウンドＴＣＰセグメントの処理とは独立して、受信ＴＣＰ  ＡＣＫの完了処理を行うステップと
を含む、方法。
【請求項２】
完了処理を行うステップは、
完了合体リストを使用して、各受信ＴＣＰ  ＡＣＫの完了処理をスケジュールするステップをさらに含む、請求項１に記載の方法。
【請求項３】
完了合体リストを使用して、受信ＴＣＰ  ＡＣＫを合体するステップをさらに含む、請求項２に記載の方法。
【請求項４】
各受信ＴＣＰ  ＡＣＫに対応する完了情報を、完了合体リストを介して完了ハンドラへ渡すステップをさらに含む、請求項２に記載の方法。
【請求項５】
各受信ＴＣＰ  ＡＣＫに対応する完了情報は、完了合体リスト内の接続コンテキストを介して完了ハンドラヘ渡される、請求項４に記載の方法。
【請求項６】
接続コンテキストを完了合体リストに連鎖するステップをさらに含む、請求項５に記載の方法。
【請求項７】
接続コンテキストに対応する接続が保留完了要求を有しない場合にのみ、当該接続コンテキストが完了合体リストに連鎖される、請求項６に記載の方法。
【請求項８】
接続コンテキストに対応する接続が保留完了要求を有する場合には、当該接続コンテキスト内の情報を更新する、請求項７に記載の方法。
【請求項９】
接続コンテキストにおける更新された情報は、最終確認シーケンス番号（ＬａｓｔＡｃｋｅｄＳＮ）を含む、請求項８に記載の方法。
【請求項１０】
完了合体リストを選択的にバイパスして、完了情報を完了処理のために完了ハンドラヘ直接送るステップをさらに含む、請求項４に記載の方法。
【請求項１１】
完了合体リストを選択的にバイパスするステップが再送信動作に応答して実行される、請求項１０に記載の方法。
【請求項１２】
ＲＤＭＡ読み出し応答の受信の際に、完了合体リストを使用してＲＤＭＡ読み出し要求の完了を処理するステップをさらに含む、請求項２に記載の方法。
【請求項１３】
ＲＤＭＡ読み出し要求に対応する接続コンテキストを完了合体リストに連鎖するステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
完了合体リストを選択的にバイパスして、ＲＤＭＡ読み出し要求を完了処理のために完了ハンドラヘ直接送るステップを含む、請求項１２に記載の方法。
【請求項１５】
完了合体リストを選択的にバイパスするステップは、読み出しキューがＲＤＭＡ読み出し要求を置くのに充分な空きスペースを有しないことに応答して実行される、請求項１４に記載の方法。
【請求項１６】
記録可能な媒体上に記憶されたコンピュータプログラム製品であって、実行されると請求項１に記載の方法を実行する、コンピュータプログラム製品。
【請求項１７】
完了処理のためのシステムであって、
インバウンドＴＣＰセグメントを処理するためのＴＣＰ論理と、
インバウンドＴＣＰセグメントの処理とは独立して、受信ＴＣＰ  ＡＣＫの完了処理を行うためのシステムと
を備える、システム。
【請求項１８】
各受信ＴＣＰ  ＡＣＫの完了処理をスケジュールするための完了合体リストをさらに備える、請求項１７記載のシステム。
【請求項１９】
完了合体リストは、受信されたＴＣＰ  ＡＣＫを合体する、請求項１８に記載のシステム。
【請求項２０】
各受信ＴＣＰ  ＡＣＫの完了処理のための完了ハンドラをさらに備え、各受信ＴＣＰ  ＡＣＫに対応する完了情報が、完了合体リスト内の接続コンテキストを介して完了ハンドラへ渡される、請求項１８に記載のシステム。
【請求項２１】
ＴＣＰ論理は、接続コンテキストを完了合体リストに連鎖する、請求項２０に記載のシステム。
【請求項２２】
接続コンテキストに対応する接続が保留完了要求を有しない場合にのみ、ＴＣＰ論理は、当該接続コンテキストを完了合体リストに連鎖する、請求項２１に記載のシステム。
【請求項２３】
接続コンテキストに対応する接続が保留完了要求を有する場合には、ＴＣＰ論理は、当該接続コンテキスト内の情報を更新する、請求項２２に記載のシステム。
【請求項２４】
接続コンテキストにおける更新された情報は、最終確認シーケンス番号（ＬａｓｔＡｃｋｅｄＳＮ）を含む、請求項２３に記載のシステム。
【請求項２５】
完了処理のために完了情報を完了ハンドラへ直接送るための送信／再送信ハンドラをさらに備え、それにより、完了合体リストを選択的にバイパスする、請求項２０に記載のシステム。
【請求項２６】
ＴＣＰ論理によって要求された再送信動作に応答して、完了情報は、完了ハンドラへ直接送られて、送信／再送信ハンドラによる完了処理が行われる、請求項２５に記載のシステム。
【請求項２７】
受信されたＲＤＭＡメッセージを処理し、完了処理のために、ＲＤＭＡ読み出し要求を、該ＲＤＭＡ読み出し要求に対応する接続コンテキストを完了合体リストへ連鎖することによってスケジュールするためのＲＤＭＡ論理をさらに備える、請求項１８に記載のシステム。
【請求項２８】
各ＲＤＭＡ読み出し要求の完了処理のための完了ハンドラをさらに備え、各ＲＤＭＡ読み出し要求に対応する完了情報が、完了合体リスト内の接続コンテキストを介して完了ハンドラへ渡される、請求項２７に記載のシステム。
【請求項２９】
ＲＤＭＡ論理は、完了合体リストを選択的にバイパスして、ＲＤＭＡ読み出し要求を完了処理のために完了ハンドラへ直接送るように構成される、請求項２８に記載のシステム。
【請求項３０】
完了合体リストは、読み出しキューがＲＤＭＡ読み出し要求を置くのに充分な空きスペースを有しないことに応答して選択的にバイパスされる、請求項２９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、伝送制御プロトコル（ＴＣＰ）システムに関する。より特定的には、本発明は、（例えば、ＴＣＰ／ＩＰオフロードエンジン（ＴＯＥ）内の）ＴＣＰ受信器による完了合体のための方法、システム、およびコンピュータプログラム製品を提供する。
【背景技術】
【０００２】
当該分野において知られているように、ＴＣＰは、信頼性のあるサービスを提供するための肯定応答およびタイムアウト機構を使用するデータ転送プロトコルである。この点で、ＴＣＰは、送信される各バイトに対してシーケンス番号を割り当て、受信ＴＣＰからの肯定的な確認応答（ＡＣＫ）を期待する。ＴＣＰ  ＡＣＫがタイムアウト期間内に受信されない場合には、データは再送信される。より進んだ他の再送信手法も使用され、これは、複数（例えば３つ）の複製ＡＣＫ（複製ＡＣＫは、ＴＣＰウィンドウの左端を変化させないＡＣＫである）を受信すると再送信処理を開始させるものである。
【０００３】
肯定応答機構の使用は、専用ＴＣＰ  ＡＣＫセグメント、またはデータセグメントのＴＣＰヘッダ内のピギーバックＴＣＰ  ＡＣＫ情報を送ることに基づいている。しかしながら、専用ＴＣＰ  ＡＣＫセグメントまたはピギーバックＴＣＰ  ＡＣＫ情報の処理は、ネットワークに対して明らかなオーバヘッドである。ＴＣＰがこのオーバヘッドを削減しようとするやり方の１つに、遅延ＴＣＰ  ＡＣＫ方式を使用することによるものがある。この方式により、単一のＴＣＰ  ＡＣＫを各２つ（以上）の受信ＴＣＰセグメントに対して送ることができる。
【０００４】
追加のＴＣＰ  ＡＣＫ処理オーバヘッドが、各受信ＴＣＰ  ＡＣＫセグメントまたは新たなＴＣＰ  ＡＣＫ情報を保持するデータセグメントの完了処理から生じる。当該分野で知られているように、そのような完了処理は、例えば、通知コンシューマ要求の読み出しおよび処理（例えば、記述子読み出し）を伴い、この要求が完了したかどうかを識別する。ＴＣＰの１つの主要な問題は、ＴＣＰシーケンス番号をコンシューマ要求にマッピングする簡単な方法をＴＣＰは提供しないということである。例えば、インフィニバンド（ＩｎｆｉｎｉＢａｎｄ）においては、肯定応答セグメントは、バイトシーケンス番号だけでなく、メッセージシーケンス番号をも保持する。これにより、ＡＣＫ  ＳＮをコンシューマ要求にマッピングするための情報を収集する必要なく、ＡＣＫ処理および完了処理を行うことができる。しかしながら、ＴＣＰにおいては、ＡＣＫはそのような情報を保持していない。このように、ＴＣＰにおいては、ＡＣＫ  ＳＮをコンシューマ要求にマッピングするための情報を収集しなければならない。必要な情報を収集するやり方の１つとして、コンシューマ要求の読み出しおよび処理が挙げられる。したがって、そのような時間のかかる動作を各受信ＴＣＰ  ＡＣＫ毎に行うことは、ネットワークリソースおよび処理リソースを消費するばかりでなく、インバウンドＴＣＰセグメントの論理処理に対して、次のＴＣＰセグメントの処理の前に、各受信ＴＣＰ  ＡＣＫの完了処理が終了するのを強制的に待たせることになる。よって、完了処理オーバヘッドは、完了動作自体のオーバヘッドと、インバウンドＴＣＰセグメント処理論理と完了処理論理の結合という、２つの部分を含む。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、完了処理とは独立して、（ＡＣＫを含む）インバウンドＴＣＰセグメントを処理するための方法、システム、およびコンピュータプログラム製品に対する必要性がある。これにより、各受信ＴＣＰ  ＡＣＫの完了処理が終了するのを待たずに、インバウンドＴＣＰセグメントの処理を継続することができる。また、遅延された別個の完了処理により、本発明は、ＡＣＫの合体を行うことができる（すなわち、ＡＣＫ毎に１つの完了動作を行うのではなく、複数のＡＣＫについて１つの完了動作を行うことができる）。同じやり方を、ＲＤＭＡ読み出し要求の完了処理に適用してもよい。
【課題を解決するための手段】
【０００６】
本発明は、完了処理とは独立して、（ＡＣＫを含む）インバウンドＴＣＰセグメントを処理するための方法およびシステムを提供する。特に、（専用のまたはデータセグメントによって保持された）各受信ＴＣＰ  ＡＣＫは、インバウンドセグメント処理論理によって即座には処理されず、その代わりに完了合体リストを使用する処理のためにスケジュールされる。完了処理のための接続のスケジューリングは、接続コンテキスト内のＴＣＰ  ＡＣＫ情報を更新して、接続コンテキストを完了合体リストに追加することによって行われる。
【０００７】
本発明の第１の局面は、完了処理のための方法に向けられており、インバウンドＴＣＰセグメントを処理するステップと、インバウンドＴＣＰセグメントの処理とは独立して、受信ＴＣＰ  ＡＣＫの完了処理を行うステップとを含む。
【０００８】
本発明の第２の局面は、完了処理のためのシステムに向けられており、インバウンドＴＣＰセグメントを処理するためのＴＣＰ論理と、インバウンドＴＣＰセグメントの処理とは独立して、受信ＴＣＰ  ＡＣＫの完了処理を行うためのシステムとを備える、
【０００９】
本発明の第３の局面は、本発明の方法を実行するためのコンピュータプログラム製品に向けられている。
【００１０】
本発明の上述の特徴および他の特徴は、本発明の実施形態の以下のより具体的な説明から明らかになるだろう。
【００１１】
本発明の実施形態を、図面を参照して詳細に説明する。図面において、同様の名称は、同様の要素を示す。
【発明を実施するための最良の形態】
【００１２】
本発明は、伝送制御プロトコル（ＴＣＰ）受信器による完了合体のための方法、システム、およびコンピュータプログラム製品を提供する。
【００１３】
図１を参照すると、本発明に係る完了合体システム１０のブロック図が示されている。本説明の目的のために、読者は、ＴＣＰについて当業者相応に理解しているものとする。したがって、ＴＣＰの詳細な説明は、本明細書においては提供されていない。
【００１４】
完了合体システム１０は、ＴＣＰ論理１２と、送信／再送信ハンドラ１４と、完了ハンドラ１６と、完了合体リスト１８とを含む。本発明によれば、（専用またはデータセグメントによって保持された）各受信ＴＣＰ  ＡＣＫについての完了動作は、ＴＣＰ論理１２によって即座には処理されず、その代わりに完了合体リスト１８を使用する処理のためにスケジュールされる。しかしながら、ＴＣＰ  ＡＣＫは、ＴＣＰ論理１２によって即座に処理される。
【００１５】
ＴＣＰ論理１２は、受信（Ｒｘ）ＴＣＰ論理２０と、送信（Ｔｘ）ＴＣＰ論理２２とを含む。ＲｘＴＣＰ論理２０は、受信ＴＣＰセグメントを処理する。これには、例えば、ＴＣＰデータストリームの最終確認バイトのシーケンス番号（すなわち、ＬａｓｔＡｃｋｅｄＳＮ）のようなＴＣＰ  ＡＣＫ情報を、受信ＴＣＰセグメントから抽出することが含まれる。この情報（すなわち、ＬａｓｔＡｃｋｅｄＳＮ）は、完了要求２４として完了ハンドラ１６へ渡される。この完了情報を（すなわち、完了要求４を介して）完了ハンドラ１６へ渡すため、本発明は、完了合体リスト１８を使用する。完了情報は、完了合体リスト１８内の接続コンテキストを介して渡される（ＬａｓｔＡｃｋｅｄＳＮは、直近の受領確認されたＳＮを保持する接続コンテキストのフィールドである）。接続コンテキスト自体は、当該接続が保留完了要求を有していない場合にのみ、完了合体コンテキスト１８に連鎖される。接続が完了合体リスト１８内で完了処理を既に待っている場合には（すなわち、接続が既に保留完了要求を有する場合には）、接続コンテキスト内の情報は更新されて、より新しいＬａｓｔＡｃｋｅｄＳＮを保持する。これにより、ＲｘＴＣＰ論理２０（または、受信ＴＣＰセグメントの取り扱い／処理）を、比較的遅いバースト的な完了処理から分離する。
【００１６】
ＴＣＰ論理１２のＴｘＴＣＰ論理２２は、所定の接続のために何を送信すべきかを決定する。ＴｘＴＣＰ２２の論理は、新たなＴＣＰセグメントの送信を行うことを決定してもよいし、前に送信したＴＣＰセグメントの再送信を行うことを決定してもよい。再送信は、例えば、タイムアウトによって、またはＴｘＴＣＰ論理２２によって実装される他の高速回復方法によって生じさせることができる。ＴｘＴＣＰ論理２２は、送信／再送信動作を行うための要求２６を送信／再送信ハンドラ１４へ渡し、送信／再送信ハンドラ１４は、要求された動作を行う。
【００１７】
完了合体リスト１８は、接続の、より詳細には、接続コンテキストのリストである。接続コンテキストは、特定の接続に関するデータを記憶するデータ構造である（すなわち、データ、ポインタ、フィールド、ビット、フラグなどを含む）。完了合体リスト１８は、接続コンテキスト内のポインタを使用して接続コンテキストを連鎖することによって実装される単一方向のリンク・リストである。完了合体リスト１８は、処理すべき保留完了要求を有する接続に対応する接続コンテキストを保持する。ＴＣＰ  ＡＣＫの受信は、例えば、接続コンテキストを完了合体リスト１８に追加することになるであろうトリガの１つである（すなわち、ＴＣＰ  ＡＣＫは、完了ハンドラ１６による完了処理のために完了合体リスト１８内の接続コンテキストをスケジュールするためのトリガである）。各接続は、完了合体リスト１８内に１度だけ出現する。接続に対応する接続コンテキストが完了合体リスト１８に既に連鎖されている場合には、その接続コンテキストは、最新情報を保持するように更新されて、完了合体リスト１８内で最初に連鎖された場所と同一の場所に保持される。
【００１８】
図２に示すように、完了合体リスト１８は、各接続コンテキスト３０に保持されたポインタ２８を使用して実装される。この点で、各接続コンテキスト３０は、ポインタ２８を介して完了合体リスト１８内の次の接続コンテキスト３０をポイントするフィールド３２を有する。ＴＣＰ論理１２のＲｘＴＣＰ論理２０からの要求（すなわち、完了要求）によって完了合体リスト１８の末尾３６に接続が追加され、完了ハンドラ１６によって完了合体リスト１８の先頭３４から接続が除去される。
【００１９】
図１を再び参照すると、再送信動作を行うために、送信／再送信ハンドラ１４は、当該接続に関するすべての以前の完了要求が完了していることを確認する必要があることに注意すべきである。この理由は、再送信動作は、一般的には、ＴＣＰデータストリームの最後の未完了バイトから（または、コンシューマの最後の未完了要求から、またはその内部で）開始するからである。したがって、完了動作は、再送信の処理に先行しなければならない。完了要求２４は、通常、即座には処理されず、その代わりに完了ハンドラ１６によって完了合体リスト１８を介して処理されるので、完了ハンドラ１６による完了処理に先立って、所与の接続が完了合体リスト１８内で待機していないことを確認する必要がある。当該接続について完了動作ができるだけ早く完了することを確実にするために、送信／再送信ハンドラ１４は、高優先度の完了要求２４ＨＰを完了ハンドラ１６に送って、所与の接続について完了ハンドラ１６が完了処理をできるだけ早く行う（すなわち、完了合体リスト１８をバイパスする）ように要求する。その後、送信／再送信ハンドラ１４は、この動作の完了を待って、その後にのみ、再送信動作を行う。
【００２０】
完了ハンドラ１６は、完了合体リスト１８の先頭３４（図２）から１つずつ接続コンテキスト３０を取り出す（すなわち、引き出す）ように構成され、引き出した各接続コンテキスト３０内の完了情報を使用して、当該分野において既知の方法で完了動作を行う。上述のように、完了ハンドラ１６は、高優先度の完了要求２４ＨＰを送信／再送信ハンドラ１４の論理から受信して、指定された接続について「緊急」完了動作を行ってもよい。そのような場合には、完了ハンドラ１６は、現在の完了動作を終了し、送信／再送信ハンドラ１４によって要求された完了動作を行う。
【００２１】
上述のように、接続コンテキスト３０は、各接続コンテキスト３０のフィールド３２に保持されたポインタ２８を使用して、完了合体リスト１８に連鎖される。より正確には、接続コンテキスト３０は、接続コンテキスト３０内のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２を使用して、完了合体リスト１８に連鎖される。
【００２２】
接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２は、完了合体リスト１８を形成する接続コンテキスト３０のチェーンにおける次の接続コンテキスト３０の接続番号を保持する（すなわち、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２は、チェーンにおける次の接続コンテキスト３０へのポインタ２８を事実上提供する）。新たな接続コンテキスト３０をチェーンに追加する場合（例えば、新たなＴＣＰ  ＡＣＫを受信したとき）には、新たに追加された接続コンテキスト３０を参照するように、チェーンの最後の接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２が更新される。このことを、図３のＡおよびＢに簡単に示す。具体的には、図３Ａにおいて、完了合体リスト１８は、連鎖された２つの接続コンテキスト３０１および３０２を含み、接続コンテキスト３０１のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２１は、完了合体リスト１８内の最後の接続コンテキスト（すなわち、接続コンテキスト３０２）をポイント（ポインタ２８１）している。（例えば、新たなＴＣＰ  ＡＣＫを受信して）新たな接続コンテキスト３０３がチェーンの末尾３６に追加されると、接続コンテキスト３０２のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２２は、完了合体リスト１８の末尾３６に現在位置する新たに追加された接続コンテキスト３０３を参照する（ポインタ２８２）ように、更新される。
【００２３】
新たなＴＣＰ  ＡＣＫが到着すると、ＴＣＰ論理１２のＲｘＴＣＰ論理２０は、まず、受信ＴＣＰセグメントによって保持されたＴＣＰ  ＡＣＫ情報を、接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールド３８を使用して更新する（例えば、図３Ｂの接続コンテキスト３０３のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールド３８３を参照）。図３Ｂには図示されていないが、各接続コンテキスト３０は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールド３８を含む。接続コンテキスト３０のフィールドであるＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮ３８は、ＴＣＰデータストリームの最終確認バイトのシーケンス番号を示す。
【００２４】
接続コンテキスト３０は、接続コンテキストが有効な完了処理要求を有しているかどうかを示すビットも保持している。このビットは、接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑフィールド４０内に与えられる（例えば、接続コンテキスト３０３内のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑフィールド４０３を参照）。図３Ｂには図示されていないが、各接続コンテキスト３０は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑフィールド４０を含む。このビットは、接続コンテキスト３０が完了合体リスト１８に既に連鎖されているかどうかを示すものでもある。接続コンテキスト３０が既に完了合体リスト１８に連鎖されていれば（すなわち、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑがセットされていれば）、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮの更新は、受信ＴＣＰ  ＡＣＫに対応する接続コンテキスト３０内のＡＣＫ情報の合体を事実上意味する。
【００２５】
接続コンテキスト３０（例えば、新たなＴＣＰ  ＡＣＫに対応する接続コンテキスト）がいかなる保留完了要求も有していない場合、すなわち、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑがクリアである場合には、接続コンテキスト３０は、完了合体リスト１８の末尾３６に追加され、完了合体リスト１８内の最終の接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールドが、新たに追加された接続コンテキスト３０を（すなわち、チェーン内の次の接続コンテキスト３０の接続番号を介して）参照するように、更新される。
【００２６】
完了合体リスト１８内の完了要求は、完了ハンドラ１６によって対処される。完了ハンドラ１６は、送信／受信ハンドラ１４およびＲｘＴＣＰ論理２０とは非同期的に（すなわち、独立して、または並行的に）動作する。これにより、完了処理を、通知送信要求およびインバウンドＴＣＰトラフィックから分離することができる。
【００２７】
完了ハンドラ１６は、完了合体リスト１８の先頭３４から接続コンテキスト３０をデキューし、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールドを使用して、当該分野において既知のやり方で完了処理を行う。完了要求の処理後、完了ハンドラ１６は、対応する接続コンテキスト３０についてのＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑビットをクリアする。接続コンテキスト３０は、完了処理中に新たな完了要求で更新されている場合があるので、完了ハンドラ１６は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールドが処理されたＬａｓｔＡｃｋｅｄＳＮと等しいかどうかを、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑビットをクリアする前に判断する。Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮフィールドが処理されたＬａｓｔＡｃｋｅｄＳＮと等しくない場合には、完了ハンドラ１６は、更新されたＬａｓｔＡｃｋｅｄＳＮを使用して完了処理を行う。これは、完了処理中のＬａｓｔＡｃｋｅｄＳＮの更新を解決する１つの方法である。他には、完了合体リスト１８の終わりに当該接続を戻して、その完了を処理するための後のサービスサイクルを待つ方法もあろう。
【００２８】
完了合体システム１０による完了合体リスト１８および完了ハンドラ１６の使用によって、従来の完了処理手法に比べて完了処理オーバヘッドが減少する。各完了要求の処理は１つ以上の記述子読み出し動作という、システム構成（例えば、記述子の位置、記述子読み出し動作の待ち時間など）に大きく依存する処理コストを有する動作を伴うものの、本発明の完了合体システム１０の使用によって、必要な完了要求処理動作の数は減少し、取り出された記述子をより有効に活用することができる。したがって、完了動作を行うのに必要な接続コンテキストの側での追加の読み出しにもかかわらず、本発明の完了合体システム１０は、全体的なシステム性能を向上させる。本発明の完了合体の手法によって提供されるさらに大きな利点は、ＴＣＰ受信動作からの完了動作の分離である。これにより、本発明の完了合体システム１０は、完了処理がどんなに遅くても、新たなＴＣＰセグメントを継続して受信することができる。
【００２９】
本発明の完了合体システム１０によって提供される他の改良点は、インバウンドＴＣＰセグメントの処理を完了ハンドラ１６から分離することである。これも、完了ハンドラ１６からの処理要求を減少させ、完了処理の優先度を減少させる。完了処理は、自己調整機構となって、さらに多くの接続が完了処理を待ち、さらに積極的な完了合体となり、完了処理によって費やされる時間および帯域幅が少なくなる。
【００３０】
上述の完了合体リストは、インバウンドＲＤＭＡ読み出し要求の送付時に保留ＲＤＭＡ読み出し要求の処理を完了するのに適用されてもよい。この説明の目的のために、読者は、ＲＤＭＡプロトコルおよびＲＮＩＣ環境におけるその実装について当業者相応に理解しているものとする。ＲＤＭＡプロトコルは、例えばウェブ上の＜ｗｗｗ．ｒｄｍａｃｏｎｓｏｒｔｉｕｍ．ｃｏｍ＞に詳細に記録されており、入手可能である。
【００３１】
保留ＲＤＭＡ読み出し要求の完了を処理することができる、本発明の他の実施形態に係る完了合体システム１００を図４に示す。図示のように、完了合体システム１００は、ＴＣＰ論理１２（ＲｘＴＣＰ論理２０と、ＴｘＴＣＰ論理２２とを含む）と、送信／再送信ハンドラ１４と、完了ハンドラ１６と、完了合体リスト１８とを含み、これらは、完了合体システム１０の対応構成要素に関して上述したように動作する。加えて、完了合体システム１００は、受信ＲＤＭＡメッセージを処理するためのＲＤＭＡ論理１０２を含む。
【００３２】
ＲＤＭＡプロトコルは、例えば、すべてのＲＤＭＡ要求はコンシューマが通知した順序どおりに完了しなければならないというような、特別な完了順序付け規則（例えば、図５を参照）を規定する。ＲＤＭＡは、以下の３種類の要求を有する。
【００３３】
１）単一のＲＤＭＡメッセージからなるＲＤＭＡ動作（例えば、送出、書き込み）。これらの動作は、ローカルからリモートホストへデータを転送するのに使用され、リモートからローカルホストへ送られた単一のＲＤＭＡメッセージを含む。
【００３４】
２）いくつか（例えば、２つ）のＲＤＭＡメッセージからなるＲＤＭＡ動作（例えば、読み出し）。読み出し動作では、リモートメモリからデータを読み出すことになっている。そのような動作は、読み出し要求および読み出し応答という２つのＲＤＭＡメッセージからなる。読み出し要求は、要求発信者によってリモートのデータソースへ送られるメッセージである。読み出し要求メッセージは、リモートメモリからのデータの読み出し、および応答メッセージの構築に必要なすべての情報を保持している。リモートホストによって生成される応答メッセージが読み出し応答である。読み出し応答メッセージは、要求者のメモリへ書き込まれるべきデータを保持しており、また、データが書き込まれるべき位置の記述を含む。読み出し動作を図６に概略的に示す。
【００３５】
３）ローカルＲＤＭＡ動作（例えば、バインド、高速登録など）。これらの動作は、いかなるデータ（例えば、ＴＣＰセグメント）も送信することはない。
【００３６】
ローカルＲＤＭＡ動作は、その処理がＲＤＭＡネットワークインターフェースカード（ＲＮＩＣ）によって終了した場合に完了したものとみなされる。送出および書き込み動作は、ＲＤＭＡメッセージ内のすべてのＴＣＰセグメントがＴＣＰ接続の他方のエンドポイントへ確実に送信されるであろうことをＲＮＩＣが保証できる場合に、完了したものとみなされる。読み出し動作は、ＲＤＭＡ読み出し応答メッセージが読み出し開始者によって正常に受信された場合に完了したものとみなされる。
【００３７】
完了順序付け規則の一部は、ＲＤＭＡ読み出し応答メッセージが受信された場合にのみ、ＲＤＭＡ読み出し要求が完了するように要求する。したがって、ＲＤＭＡプロトコルをサポートするためには、完了ハンドラ１６は、ＲＤＭＡ読み出し応答１０４の受信という、追加の完了指示が必要である（これは、対応するＲＤＭＡ読み出し要求の完了を事実上意味する）。よって、ＲＤＭＡ論理１０２は、ＲＤＭＡ読み出し応答１０４を受信すると、完了要求１０６を完了合体リスト１８に通知する。それに応じて、完了ハンドラ１６は、完了合体リスト１８の接続コンテキストに提供されている、ＴＣＰ  ＡＣＫからの情報と、受信ＲＤＭＡ読み出し応答からの情報の両方を使用して、完了動作を行う。
【００３８】
受信ＴＣＰ  ＡＣＫの完了処理に関して上述したのと同様の手法を、インバウンドＲＤＭＡ読み出し応答の送付による保留ＲＤＭＡ読み出し要求の完了処理に使用できる。この点で、ＲＤＭＡ読み出し要求に対応する接続コンテキスト３０が、完了合体リスト１８に連鎖される。完了したＲＤＭＡ読み出し要求の合体を可能にするために、接続コンテキスト３０は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔＮｕｍフィールド内に完了したＲＤＭＡ読み出し要求の数を保持する。
【００３９】
ＲＤＭＡ論理１０２の受信論理がインバウンドＲＤＭＡ読み出し応答１０４を送出する場合に、完了したＲＤＭＡ読み出し要求の数を増加させて、それに応じて、接続コンテキスト３０内のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔＮｕｍフィールドを更新する。接続が完了合体リスト１８にまだ連鎖されていない、
すなわち、（Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔＮｕｍが０に等しく、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑがクリアである）場合には、コンテキストは、完了合体リスト１８内の最後の接続コンテキスト３０のＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＩｎＡｃｋＬｉｓｔフィールド３２を更新して、新たに追加された接続コンテキスト３０をポイントすることによって、完了合体リスト１８に連鎖される（例えば、図３に示す処理を参照）。加えて、新たに追加された接続コンテキスト３０を完了合体リストに連鎖すると、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｉｏｎＲｅｑビットもセットされなければならない。
【００４０】
いくつかの動作は、完了要求の事前処理を必要とする。例えば、（上述の）再送信要求およびインバウンドＲＤＭＡ読み出し要求のような動作は、完了要求の事前処理を必要とする場合がある。例えば、ＲＤＭＡ読み出し要求は、読み出しキューに要求を置く場所がない場合にのみ、事前完了処理を必要とする。この場合に、ＲＤＭＡ論理１０２は、ＲＤＭＡ読み出し要求を処理する前に、まず読み出しキュー内である程度のスペースを解放しなければならない（この処理は、以下にさらに詳細に説明する）。いずれの場合も、完了要求の処理は、遅延できず、要求の処理前に行われなくてはならない。これらの場合に、合体バイパスが行われ、完了ハンドラ１６は、所与の接続についての完了を行うための別個の要求１０８を受信する。この場合、完了要求の処理は、完了合体リスト１８内の完了コンテキスト３０の位置とは無関係に行われる。完了処理後、元の要求（再送信、インバウンドＲＤＭＡ読み出し応答）の処理を再開することができる。
【００４１】
ＲＤＭＡ論理１２４から来るであろう他の完了要求は、所与の接続についての「高優先度」完了動作を行う要求である。この要求は、完了ハンドラ１６へ送信／再送信論理１４によって送られた完了要求２４ＨＰと同様である（上記を参照）。これはブロッキング要求であって、ＲＤＭＡ論理１０２が完了ハンドラ１６によるこの要求の遂行を待つことを意味する。この要求が出されるのは、ＲＤＭＡ読み出し要求を受信したことと、受信キューに空きスペースがなかったこととがその理由である。ＲＤＭＡプロトコルは、一時に（回線上で）保留可能なインバウンドＲＤＭＡ読み出し要求の数を制限している。この数は、読み出しキューの深さを規定する。完了合体リスト１８内の完了要求（例えば、受信ＴＣＰ  ＡＣＫ）の合体により、読み出しキューが完了ハンドラ１６によってまだクリーンアップされてない（すなわち、完了要求がまだ完了合体リスト１８にある）場合があり、その場合には、ＲＤＭＡ論理１０２は、まず読み出しキュー内である程度のスペースを解放する必要があり、その後にのみ、インバウンドＲＤＭＡ読み出し要求を処理する。
【００４２】
本明細書に記載されたシステム、機能、機構、方法、およびモジュールは、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせで実装できることは当然である。これらは、任意の種類のコンピュータシステムまたは本明細書に記載された方法を実行するために適応された他の装置によって実装されてもよい。ハードウェアおよびソフトウェアの典型的な組み合わせとしては、コンピュータプログラムを有する汎用コンピュータシステムであって、当該コンピュータプログラムは、ロードされ実行されると本明細書に記載された方法を実行するように当該コンピュータシステムを制御するものが挙げられよう。代わりに、本発明の機能的なタスクのうちの１つ以上を実行するための専用のハードウェアを含んでいる特定用途コンピュータを使用することもできよう。本発明は、コンピュータプログラム製品に組み込むこともできる。本コンピュータプログラム製品は、本明細書に記載の方法および機能の実装を可能にするすべての特徴を備え、コンピュータシステムにロードされると、これらの方法および機能を実行することができるものである。コンピュータプログラム、ソフトウェアプログラム、プログラム、プログラム製品、またはソフトウェアは、ここでは、情報処理能力を有するシステムに対して、直接、または、（ａ）他の言語、コード、もしくは表記への変換、および（ｂ）異なる物質形態での複製のいずれか一方または両方が行われた後に、特定の機能を実行させることが意図された命令の組の、任意の言語、コードまたは表記による任意の表現を意味する。
【００４３】
本発明を上記に概説した特定の実施形態と共に説明してきたが、数多くの代替物、修正、および変形物が当業者には明らかであろう。したがって、本発明の上述の実施形態は例示であって、限定的なものではない。請求項に規定されるような本発明の精神および範囲から逸脱することなく、様々な変更を行ってもよい。
【図面の簡単な説明】
【００４４】
【図１】本発明に係るＴＣＰ  ＡＣＫの完了処理のための完了合体システムのブロック図を示す。
【図２】本発明に係る完了合体リストの構成を示す。
【図３】本発明に係る完了コンテキストの完了合体リストへの追加を示す。
【図４】本発明に係るＴＣＰ  ＡＣＫおよびリモートデータメモリアクセス（ＲＤＭＡ）読み出し応答の完了処理のための完了合体システムのブロック図を示す。
【図５】ＲＤＭＡプロトコルの完了順序付け規則を示す。
【図６】ＲＤＭＡ読み出し動作を概略的に示す。
【図１】
2007518360.tif 000003
【図２】
2007518360.tif 000004
【図３】
2007518360.tif 000005
【図４】
2007518360.tif 000006
【図５】
2007518360.tif 000007
【図６】
2007518360.tif 000008
【国際調査報告】
2007518360.tif 000009