JP4464969B2 - Ｒｄｍａ完了および再送信システムおよび方法 - Google Patents

Description

本発明は、一般的に、リモート・データ・メモリ・アクセス（ＲＤＭＡ）完了および再送信システムに関し、より特定的には、ＲｅｓｐｏｎｓｅＯｕｔチャンネルと、ＲｅｑｕｅｓｔＯｕｔチャンネルとの間の順序を維持するＲＤＭＡ完了および再送信の実施に関する。

ＲＤＭＡ（リモート・データ・メモリ・アクセス）は、あるコンピュータが情報を他のコンピュータのメモリ内に直接置くことができるようにするネットワーク・インターフェイス・カード（ＮＩＣ）機能である。本技術は、帯域幅および処理オーバヘッドに対する要求を最小限にすることによって、待ち時間を削減している。従来のハードウェアおよびソフトウェア・アーキテクチャは、サーバのＣＰＵおよびメモリに対して著しく負担を課している。なぜならば、カーネルとアプリケーションとの間でデータをコピーしなければならないからである。メモリ障害は、接続速度がサーバの処理能力およびメモリ帯域幅を上回るに従っていっそう深刻になる。

ＲＤＭＡは、この点の回避を、ハードウェアにおける確実なトランスポート・プロトコルをＲＮＩＣ（ＲＤＭＡネットワーク・インターフェイス・カード）上で実施し、かつ、カーネルバイパスを使用するコピーなしのネットワーキングをサポートすることによって行う。コピーなしのネットワーキングによって、ＲＮＩＣは、データをアプリケーションメモリへまたはそこから直接転送することができ、アプリケーション・メモリとカーネルとの間でデータをコピーすることが不要となる。

カーネルバイパスによって、アプリケーションは、カーネル呼び出しを実行しなくてもＲＮＩＣに対してコマンドを発行することができる。カーネルの介在をなんら必要とすることなく、ＲＤＭＡ要求は、ユーザ空間からローカルＲＮＩＣへ、およびネットワークを越えてリモートＲＮＩＣへ発行される。これにより、ネットワーク・トラフィックを取り扱っている間のカーネル空間とユーザ空間との間のコンテキスト切り換え数が削減される。

ＲＤＭＡ消費者（アプリケーション）は、通信にメッセージ意味論を使用する。データは、メッセージ内での送信用に書き込まれ、メッセージ内で受信され、完了はメッセージ単位で通知されることが期待されている。それに対して、ＴＣＰは、バイト・ストリーム重視のプロトコルであって、ＵＬＰデータのメッセージという範囲がありうることに気づいていない。したがって、メッセージからバイト・ストリームへの意味論の変換というタスクは、ＲＤＭＡおよびそこから肩代わりされた実施によって行われることになる。

ＲＤＭＡは、ＴＣＰの信頼性サービスを使用するメッセージ重視のＵＬＰである。ＲＤＭＡは、メッセージ重視のＵＬＰをバイト重視のＴＣＰ意味論へマッピングする際に別レベルの複雑性を加えることになる。ＲＤＭＡは、同一のＴＣＰ接続を使用して、２つの独立したソースによって書き込まれたメッセージを送信する。
・ＲｅｑｕｅｓｔＯｕｔ−ローカル消費者によって発せられたＲＤＭＡ要求
・ＲｅｓｐｏｎｓＯｕｔ−リモート消費者によって送られた受信ＲＤＭＡ読み出し要求の受信および処理の結果として、ＲＮＩＣによって発せられたＲＤＭＡ応答

ＲＮＩＣは、ＲｅｑｕｅｓｔＯｕｔメッセージおよびＲｅｓｐｏｎｓｅＯｕｔメッセージを同一のＴＣＰ接続を通じて送信する場合にインターリーブする。バイト・ストリームからメッセージ・ストリームへのマッピングに加えて、ＲＮＩＣは、完了処理および再送信処理中に、ＲｅｑｕｅｓｔＯｕｔおよびＲｅｓｐｏｎｓｅＯｕｔからのメッセージ間における「送信順序」を保存する必要がある。

異なるＲＤＭＡ要求（例えば、フェンス（Ｆｅｎｃｅ））および完了順序規則（例えば、ＲＮＩＣがＲＤＭＡ読み出し応答を受信すると、ＲＤＭＡ読み出し要求が完了する）は、ＲｅｑｕｅｓｔＯｕｔにおける送信または完了処理を中断させてもよい。しかしながら、この中断によって、ＲｅｓｐｏｎｓｅＯｕｔがＲＤＭＡ読み出し応答の送信および完了を行わなくなるわけではない。したがって、ＲＤＭＡ要求キューとＲＤＭＡ応答キューとの間の独立性を保存するためには、当該２つのキュー間の順番を効率的に保存する必要がある。

この問題を解決する取り組みの一つとしては、例えば、制御構造（記述子）を使用するか、またはデータの別個のコピーを保持するか、あるいはその両方によって、単一の要求／応答チャンネルを実施して構築することが挙げられよう。そのような取り組みには、いくつかの短所があり、以下のものが含まれる。
・追加のコピー動作が必要である。
・その様な取り組みを実施するには、より多くのＲＮＩＣリソースが必要となる（データ／制御はアダプタ・メモリにコピーされる）。
・柔軟性の欠如（アダプタ・メモリは、限られたリソースであり、有線上において未処理となりうるＲＤＭＡメッセージの数を制限する。）
・ＲＤＭＡ要求とＲＤＭＡ応答との間の完了順序付けを実施するのはいっそう困難である。

従って、上述の問題に対処するための解決策が必要である。

本発明は、追加のコピーまたは順序を維持するための制御構造を必要せずにＲＤＭＡストリームの完了および再送信のための効率的な解決策を提供することによって、上記の問題およびその他の問題に対処するものである。第１の局面において、本発明は、ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルを有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における完了要求を取り扱うための処理であって、チャンネル毎の記述子リストであって、その各々が、チャンネル内のメッセージ毎のメッセージ記述子を含む、記述子リストと、チャンネル交換がＲｅｑｕｅｓｔＯｕｔチャンネルとＲｅｓｐｏｎｓｅＯｕｔチャンネルとの間で生じる度に、メッセージ記述子内のメッセージ長フィールドをメッセージ内の最終バイトのシーケンス番号で更新するための更新機構と、完了コンテキスト内の値を検査して、次回完了メッセージのシーケンス番号と最終受け取りシーケンス番号とを比較して、メッセージを完了すべきかどうかを決定する肯定応答（Ａｃｋ）完了システムとを備える処理を提供するものである。

第２の局面において、本発明は、ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルを有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における完了処理を取り扱うための方法であって、各チャンネルにおける肯定応答完了を、次回完了メッセージのシーケンス番号が無効である場合には、完了処理の処理の過程が終了したると判断するステップと、次回完了メッセージのシーケンス番号が最終受け取りシーケンス番号よりも大きい場合には、完了処理の過程が終了したと判断するステップと、次回完了メッセージのシーケンス番号が最終受け取りシーケンス番号以下である場合には、チャンネル内のメッセージを完了させるステップとを伴って実行するステップを含む方法を提供するものである。

第３の局面において、本発明は、ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルを有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における再送信要求に対して再送信すべきセグメントの位置を特定するための方法であって、ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルの両方について候補メッセージを識別するステップと、２つの候補メッセージから、送信すべきセグメントを搬送するメッセージを選択するステップと、再送信すべきセグメントの開始を指すポインタ記述子の位置を決定するステップとを備える方法を提供するものである。

第４の局面において、本発明は、ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルを有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における送信要求を取り扱うためのシステムであって、チャンネル毎の記述子リストであって、その各々が、チャンネル内のメッセージ毎のメッセージ記述子を含む、記述子リストと、チャンネル交換がＲｅｑｕｅｓｔＯｕｔチャンネルとＲｅｓｐｏｎｓｅＯｕｔチャンネルとの間で生じる度に、メッセージ記述子内のメッセージ長フィールドをメッセージ内の最終バイトのシーケンス番号で更新するための更新機構とを備えるシステムを提供するものである。

本発明のこれらの特徴および他の特徴は、添付の図面と共に本発明の様々な局面についての以下の詳細な説明から、いっそう容易に理解されるだろう。

ＲＤＭＡ完了および再送信を実施するためのシステムおよび方法を以下に説明する。ＲＤＭＡプロトコル内では、「完了（ｃｏｍｐｌｅｔｉｏｎ）」は、特定のＲＤＭＡ動作が配置および配信を含むＲＤＭＡ動作について指定されたすべての機能を行ったことをＵＬＰ（上層プロトコル）へ通知する処理として規定される。各ＲＤＭＡ動作の完了の意味論は、固有に規定される。「再送信（ｒｅｔｒａｎｓｍｉｔ）」は、チャンネル上でデータを再送信する処理として規定される。

以下に説明するように、本発明は、二重チャンネルの実施（すなわち、１つはＲｅｓｐｏｎｓｅＯｕｔ用で、１つはＲｅｑｕｅｓｔＯｕｔ用）を利用する。そのような実施を達成するには、本発明は、完了または再送信動作が必要な場合にはいつでも、２つのチャンネル間の順序を保存するための手法を提供する。

この説明の目的のために、ＲＤＭＡプロコルと、そのＲＮＩＣ環境での実施とを読者が理解しているものとする。ＲＤＭＡプロトコルは、ウェブ上の＜ｗｗｗ．ｒｄｍａｃｏｎｓｏｒｔｉｕｍ．ｏｒｇ／ｈｏｍｅ＞にて入手可能である。

背景−ＲＤＭＡプロトコル順序規則
ＲＤＭＡプロトコルは、ＲｅｑｕｅｓｔＯｕｔチャンネルを介して送信されたメッセージについての完了順序規則を規定する。これらの規則の概要は以下の通りである。

すべてのＲＤＭＡ要求は、消費者によって書き込まれた順番で完了されなければならない。ＲＤＭＡ要求は、３種類の要求を有する。
（１）単一のＲＤＭＡメッセージ（例えば、送出（Ｓｅｎｄ）、書き込み（Ｗｒｉｔｅ））からなるＲＤＭＡ動作。これらの動作では、ローカルからリモート・ホストへデータを転送することになっており、リモートからローカル・ホストへ送られた単一のＲＤＭＡメッセージからなる。送出および書き込み動作は、これらのメッセージを備えるすべてのＴＣＰセグメントがＴＣＰ接続の他の終点へ確実に送信されるであろうことをＲＮＩＣが保証できる場合に、完了したものとみなされる。

（２）例えば読み出し（Ｒｅａｄ）などのいくつか（通常２つ）のＲＤＭＡメッセージからなるＲＤＭＡ動作。これらの動作では、リモート・メモリからデータを読み出すことになっている。そのような動作は、読み出し要求（Ｒｅａｄ Ｒｅｑｕｅｓｔ）および読み出し応答（Ｒｅａｄ Ｒｅｑｕｅｓｔ）という２つのＲＤＭＡメッセージからなる。読み出し要求は、要求発信者によってデータ・ソースへ送られるメッセージである。このメッセージは、リモート・メモリからデータを読み出すのに必要なすべての情報を搬送しており、応答メッセージを構築する。応答メッセージは、リモート・ホストによって生成される読み出し応答である。このメッセージは、要求者のメモリへ書き込まれるべきデータを搬送しており、また、データが書き込まれるべき位置の説明を含む。読み出し動作は、ＲＤＭＡ読み出し応答メッセージが読み出し開始者によって正常に受信された場合に完了したものとみなされる。ＲＤＭＡ読み出し応答は、別個のＲＤＭＡ動作ではない（すなわち、読み出し動作の一部である）ので、メッセージは、トランスポート層が正常に送信した場合に完了したものとみなされる。

（３）ローカルＲＤＭＡ動作（例えば、結合（Ｂｉｎｄ）、高速レジスタ（Ｆａｓｔ−Ｒｅｇｉｓｔｅｒ）など）。これらの動作の結果、いかなるデータ（例えば、ＴＣＰセグメント）も送信されるものではない。ローカルＲＤＭＡ動作は、その処理がＲＮＩＣによって終了した場合に完了したものとみなされる。

概要
図１を参照すると、ＲｅｓｐｏｎｓｅＯｕｔチャンネルとＲｅｑｕｅｓｔＯｕｔチャンネルとの間の順序を保存するための完了および再送信システム１０が示されている。完了アルゴリズム２４または再送信アルゴリズム２６のいずれかを使用して「完了のための要求」または「再送信のための要求」が発行される場合に、順序は維持される。処理を促進するために、システム１０は、
（１）ＲｅｑｕｅｓｔＯｕｔチャンネル１６およびＲｅｓｐｏｎｓｅＯｕｔチャンネル１８について別個の記述子リスト１２および１４を提供し、
（２）これらの記述子リストからの情報を使用して、送信、完了、および再送信動作を行う。

この取り組みにおいて、各ワーク・キュー・エントリ（ＷＱＥ）は２回処理され（例えば、読み出され）、１回目はＷＱＥの送信時、２回目はＷＱＥの完了時に行われる（なお、再送信動作は、再送信されたＷＱＥをさらに読み出す必要がある場合がある）。

ＲＮＩＣは、接続を維持する必要がある各ＲＤＭＡ接続について情報を保持する。この情報は、接続コンテキスト２２に保持され、本実施形態においては、接続コンテキスト・フィールドの組を使用して、完了アルゴリズム２４および再送信アルゴリズム２６の実施を促進する。一実施形態例において、コンテキスト・フィールドは、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＦｉｅｌｄＮａｍｅによって示される。本発明に関連するのは、以下のコンテキスト・フィールドである。

１．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＣｏｍｐｌｅｔｉｏｎＲｅｑｕｅｓｔ−取り扱う保留ＡｃｋまたはＲＤＭＡ読み出し完了要求をＲＮＩＣが有することを表すために使用されるビットである。
２．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔｓＮｕｍ−完了した読み出し要求の数を表すために使用される。
３．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳｎ−ｒｅｑｕｅｓｔ ｏｕｔチャンネルにおける最終完了済みメッセージのシーケンス番号（ＳＮ）を表すために使用される。
４．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮ−ｒｅｑｕｅｓｔ ｏｕｔチャンネルにおける次回完了メッセージのシーケンス番号（ＳＮ）を表すために使用される。
５．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮ−ｒｅｓｐｏｎｓｅ ｏｕｔチャンネルにおける最終完了済みメッセージのシーケンス番号（ＳＮ）を表すために使用される。
６．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮ−ｒｅｓｐｏｎｓｅ ｏｕｔチャンネルにおける次回完了メッセージのシーケンス番号（ＳＮ）を表すために使用される。
７．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮ−最終受信済みＡＣＫのシーケンス番号である。
８．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔ−このビットは、完了動作を実行中にＲＮＩＣがＲＤＭＡ読み出し要求で停止したため、受信論理によるＲＤＭＡ読み出し応答の受信および配信を待った上でこの読み出し要求を完了させ、任意の後続のＲＤＭＡ要求の完了に進まなくてはならないことを示している
９．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔｓＣｏｕｎｔ−送信済みで未完了のＲＤＭＡ読み出し要求の数を表すために使用される値である。
１０．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔＣｏｍｐｌｅｔｉｏｎ−ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔビットを使用する必要がある。
１１．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｏｓｔｅｄＭｓｇＣｏｕｎｔ−書き込み済みで未送信のメッセージの数を表す。
１２．Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｅｎｄｉｎｇＭｓｇＣｏｕｎｔ−接続毎に完了を待っている送信済みのメッセージの数を表す。

記述子リスト内のＲＤＭＡメッセージを表すために、いくつかの記述子の種類が使用される。そのうちの１つがメッセージ記述子であり、図２に示すようなものである。この記述子は、各ＲＤＭＡメッセージを開始させ、メッセージ記述と、メッセージを表すために使用される他の記述子についての情報とを搬送する。本発明に関連するのは、以下のフィールドである。
１．ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈは、メッセージ長またはシーケンス番号のいずれかを搬送するために使用される。
２．ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＳＮ／ＭｓｇＬｅｎｇｔｈＢｉｔは、ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈの内容を説明するために使用される。

完了アルゴリズム
本発明に係る完了アルゴリズム２４は、２つの完了トリガを有する。
（１）ＴＣＰ肯定応答（Ａｃｋ）の受信。これは、送信されたデータが接続の他の終点で正常に受信され、かつ、本Ａｃｋの範囲であるＲＤＭＡ動作（送出、書き込み）が完了することを示す。読み出し動作の一部としてのＲＤＭＡ読み出し応答メッセージは、このメッセージの範囲であるＡｃｋが受信されると完了する。
（２）ＲＤＭＡ読み出し応答の受信および配信。これは、対応するＲＤＭＡ読み出し要求（または保留読み出し動作）が完了することを示す。

保留完了要求の表示は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＣｏｍｐｌｅｔｉｏｎＲｅｑｕｅｓｔ（ＲＮＩＣが完了動作を行う必要なことを表す。これは、受信論理が新たなＴＣＰ Ａｃｋを受信したか、もしくはＲＤＭＡ読み出し応答を受信および配信したかのいずれかを実際には意味し、完了論理は、もしあればどの動作が完了したかを把握して、これらの動作の完了を消費者に報告しなければならない）と、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｅｕｓｔｓＮｕｍ（完了した読み出し要求の数を含む）とを含む接続コンテキスト２２内に保持される。このフィールドは、読み出し論理によって受信されかつ配信された、ＲＤＭＡ読み出し応答メッセージの数を保持する。これは、完了論理が、消費者によって書き込まれたこれらの数多くの保留ＲＤＭＡ読み出しメッセージを完了できることを事実上意味する。ＲＮＩＣの観点からは、完了論理は、これらの数多くのＲＤＭＡ読み出し要求を完了しており、当該完了を消費者に対して報告する必要がまだある。

これらの場合を取り扱うための全手法を図３に示す。はじめに、ステップＳ１において、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｔｓＮｕｍがチェックされる。値が非ゼロである場合（ステップＳ２）、これは、当該接続が保留読み出し要求完了を有することを意味する。この場合には、ＲＮＩＣは、後述の「読み出し要求完了」動作をまず行い、その後、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＣｏｍｐｌｅｔｉｏｎＲｅｑｕｅｓｔビットに関わらず、同じく後述の「Ａｃｋ完了」（ステップＳ３およびＳ４）を行う。Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔＮｕｍが０に等しく、かつ、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＣｏｍｐｌｅｔｉｏｎＲｅｑｕｅｓｔビットが設定されている場合には（ステップＳ５）、ＲＮＩＣは、同じく後述のＡｃｋ完了を行う（ステップＳ４）

Ａｃｋ完了
受信されたＴＣＰ Ａｃｋは、ＲｅｑｕｅｓｔＯｕｔチャンネル１６およびＲｅｓｐｏｎｓｅＯｕｔチャンネル１８に書き込まれたＲＤＭＡ要求を完了させる。完了処理の主な課題は、ＲｅｓｐｏｎｓｅＯｕｔチャンネルおよびＲｅｑｕｅｓｔＯｕｔチャンネルからのメッセージが送信された順番に従うということである。この順番を保存するためには、ＲＮＩＣは、更新機構２５を使用して、メッセージの最終バイトのシーケンス番号（ＳＮ）を搬送する選択されたメッセージのメッセージ記述子を更新する。この更新処理は、「書き戻し（ｗｒｉｔｅ−ｂａｃｋ）」とも称され、ＲＮＩＣがメッセージの最終セグメントを送信するときに行われる。ＲＮＩＣは、ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドを使用して、メッセージ長またはシーケンス番号のいずれかを搬送する。ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＳＮ／ＭｓｇＬｅｎｇｔｈＢｉｔは、ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈフィールドの内容を記述する。

ＲＮＩＣは、すべてのメッセージを更新するのではなく、チャンネル交換後、すなわち、チャンネル交換後に第１のメッセージが更新された後に使用されたもののみを更新する。ＲＤＭＡメッセージを送信する際に、ＲＮＩＣは、ＲｅｑｕｅｓｔＯｕｔメッセージおよびＲｅｓｐｏｎｓｅＯｕｔメッセージをインターリーブする。ＲＮＩＣは、ＲｅｓｐｏｎｓｅＯｕｔチャンネルとＲｅｑｕｅｓｔＯｕｔチャンネルとの間を仲裁して、これらのチャンネルのうちの１つを選択して、次のメッセージを送信する。送信済みメッセージの途中では、チャンネル交換は行われない。チャンネル間で交換が行われる場合に、更新機構２５は、チャンネル交換後のチャンネル内の次のメッセージのＳＮで、メッセージ記述子を更新する。交換後、メッセージ記述子は、新たなチャンネル内の第１のメッセージについてのみ更新され、関連ＳＮは、当該メッセージの最終送信済みバイトのＳＮへ更新される。図２に示すように、メッセージ長フィールド（メッセージ長またはシーケンス番号のいずれか）に保持された情報は、その後、完了および再送信処理中に使用される。

更新処理の一例を図４に示す。この例において、ＲＮＩＣは、チャンネルを４回交換する。ＲｅｑｕｅｓｔＯｕｔチャンネルにおけるメッセージ＃１で開始し、その後、ＲｅｓｐｏｎｓｅＯｕｔチャンネルに交換して（メッセージ＃２）、このメッセージを、このメッセージ＃２の最終バイトのＳＮで更新する。メッセージ＃３の後、ＲＮＩＣは、ＲｅｑｕｅｓｔＯｕｔチャンネルへの交換をメッセージ＃４のために行い、その更新を行う。メッセージ＃５の後、ＲＮＩＣは、ＲｅｓｐｏｎｓｅＯｕｔチャンネルへの交換をメッセージ＃６のために行い、その更新を行う。メッセージ＃７の後、ＲＮＩＣは、ＲｅｑｕｅｓｔＯｕｔチャンネルへの交換をメッセージ＃８のために行い、その更新を行う。

書き戻し動作は、両方のチャンネルを利用する接続についてのみ行われる。接続が１つのチャンネルしか使用しない場合には、書き戻し動作は行われない。

ＲＮＣは、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮ，Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮ，Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮ，およびＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮの各チャンネルについて、いくつかのシーケンス番号を接続コンテキスト２２に保持し、これらは、各チャンネルにおける最終完了済みおよび最初の未完了メッセージのシーケンス番号（ＳＮ）をそれぞれ搬送する。これらは、初期接続シーケンス番号を搬送するように初期化されて、完了動作中に更新される。

Ａｃｋ完了フロー
完了フローは、ＲｅｓｐｏｎｓｅＯｕｔチャンネルおよびＲｅｑｕｅｓｔＯｕｔチャンネルの両方について別個に、一連のステップを通じてＲＮＩＣルーピングによって実施される。この処理を以下に説明する。なお、最終受信済みＡＣＫのシーケンス番号は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓＡｃｋｅｄＳＮに示される。

ステップは、図５のフロー図を参照すると、以下のような概略となる。

ステップ１（Ｓ１０）：チャンネルがＲＤＭＡ読み出し要求の完了を待っている場合（すなわち、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔが設定されている場合）、ＲＮＩＣは、完了要求を無視する（Ｓ１１）。なお、この規則は、ＲｅｓｐｏｎｓｅＯｕｔチャンネルには妥当ではない。なぜならば、ＲｅｓｐｏｎｓｅＯｕｔチャンネルは、ＲＤＭＡ読み出し応答のみを搬送するからである。

ステップ２（Ｓ１２）：Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮが無効である場合には、このチャンネルについての完了要求の処理を完了する（Ｓ１３）。これは、これ以上メッセージか書き込まれていないか、次に書き込まれたメッセージが完全には送信されなかったことのいずれかを示す。

ステップ３（Ｓ１４）：Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮ＞Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮである場合には、受信された完了要求は、当該チャンネル内のいかなるメッセージをも完了させず、このチャンネルについての完了要求の処理を終了させる（Ｓ１３）。

ステップ４（Ｓ１５）：その他の場合には、完了要求は、当該チャンネル内の少なくとも１つのメッセージを完了させて、ＲＮＩＣは、接続コンテキストを以下のように更新する。
・Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮは、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮで更新され、
・Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮは、チャンネル内の次のメッセージの最終ＳＮで更新される。次のメッセージの最終ＳＮは、以下のやり方のうちの１つで取り出されることができる。
（１）本フィールドがシーケンス番号を搬送している旨をＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＳＮ／ＭｓｇＬｅｎｇｔｈＢｉｔが示している場合には、ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈ／ＳＮフィールドにおいて明示的に、
（２）ＭｅｓｓａｇｅＤｅｓｃｒｉｐｔｏｒ：：ＭｅｓｓａｇｅＬｅｎｇｔｈをアプリケーションペイロードの大きさとして使用して、プロトコル・ヘッダ、フッタ、および制御情報（ＤＤＰヘッダ、マーカ、パディング、ＣＲＣ）を付加して暗示的に、
（３）チャンネルが次の送信済みメッセージを有していない場合には、無効である。これは、メッセージが全く書き込まれていない場合、およびメッセージは書き込まれたが、完全には送信されていない場合が含まれる。

なお、完了したメッセージがＲＤＭＡ読み出し要求でない場合には、ＲＮＩＣは、ＲＤＭＡ動作の完了を行うが、その詳細は本発明には関連しない。

ＲＤＭＡ読み出し要求の場合には、ＲＮＩＣは、ＲＤＭＡ読み出し応答を待って、完了を行い、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔビットを設定する。
ステップ５：ステップ１へ戻る。

ＲＤＭＡ読み出し要求完了
ＲＮＩＣは、要求の範囲に含むＴＣＰ Ａｃｋを受信すると、書き込まれたＲＤＭＡ要求を完了させる。ＲＤＭＡ読み出し要求は、対応ＲＤＭＡ読み出し応答が受信される場合に完了される例外的な場合である。

ＲＤＭＡ順序規則は、送られた順番でＲＤＭＡ要求を完了することを要求する。これは、ＲＤＭ読み出し要求に続くＲＤＭＡ要求を完了する前に、ＲＮＩＣはＲＤＭＡ読み出し応答の受信するのを待つ必要があることを意味する。受信されたＲＤＭＡ読み出し応答の処理を図６におけるフロー・チャートに示し、以下のステップを含む。

ステップ１（Ｓ２０）：必要があれば、ＲＤＭＡ読み出し要求に先立つＲＤＭＡ要求の完了を行う。
これは非常に稀な場合であり、完了要求がＲＤＭＡ読み出し応答を受信するまでに処理されない場合に生じる。よって、ＲＮＩＣは、ＲＤＭＡ読み出し要求に先立つすべての要求をまず完了させる必要がある。この場合は、非ゼロＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔＣｏｕｎｔと、クリアＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔビットとによって示される。

ステップ２（Ｓ２１）：ＲＤＭＡ読み出し要求自体の完了を行う。
ＲＮＩＣは、ＲＤＭＡ読み出し動作の完了を行うが、その詳細は本願には関連しない。

ステップ３（Ｓ２２）：完了したＲＤＭＡ読み出し要求に続く任意のＲＤＭＡ要求の完了を実行する。

ステップ４（Ｓ２３）：ステップ２および３をＮ回繰り返す。ここで、Ｎは、
Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＣｏｍｐｌｅｔｅｄＲｅａｄＲｅｑｕｅｓｔｓＮｕｍ
によって規定された完了したＲＤＭＡ読み出し要求の数である。

これらの処理の一例は、図７にも示されている。

再送信要求フロー
再送信要求の処理は、以下の問題に対処することを含む。

問題１：ＲＮＩＣは、この接続についてのすべての保留完了要求を処理する必要がある。したがって、未処理の完了要求を接続が有する場合には、ＲＮＩＣは、この要求を処理することが要求される。再送信要求の処理は、当該接続についての完了処理が終了した後にのみ再開される。

問題２：再送信は、高速再送信機構によって、またはタイムアウトによって要求される。タイムアウトによる再送信には、送信されたが完了されていないすべてのＴＣＰセグメントの再送信が含まれる。高速再送信機構による再送信には、最初の未完了のＴＣＰセグメントのみの再送信が含まれる。ＲＮＩＣは、互いに異なる再送信要求の種類を使用する。再送信要求の処理は、要求の種類に依存しており、このことは後述する。

問題３：再送信処理の極めて重要な部分の１つは、ＲｅｑｕｅｓｔＯｕｔまたはＲｅｓｐｏｎｓｅＯｕｔ記述子リストにおける、再送信するセグメントの位置である。この処理は後述する。

再送信は、送信されたセグメントの範囲を保存するものでは必ずしもない。再送信を開始すべき位置は、ＬａｓｔＡｃｋｅｄＳＮによって示される。ソケットおよびｉＳＣＳＩは、送信済みのセグメント範囲の変更の影響を受けない。ｉＳＣＳＩは、ＴＣＰが見送信のデータについて再送信を実行する要求を送り出さないと推定する。これにより、ｉＳＣＳＩデータ処理論理は、再送信中に、すべての受信中間コマンド記述子が、送信中に計算された有効なｉＳＣＳＩ ＣＲＣを搬送すると推定することができる。

ＲＤＭＡは、ＤＤＰセグメントの境界線を保存し、よってＬａｓｔＡｃｋｅｄＳＮ以外の位置を再送信を開始してもよい。

再送信要求の種類
図８に示すように、ＴＣＰは、３種類の再送信要求を書き込む。
（１）高速再送信による再送信
（２）タイムアウトによる開始再送信
（３）進行タイムアウト再送信

すべての種類の再送信要求には、単一のＴＣＰセグメントの再送信が含まれる。ＲＮＩＣは、ＮｅｘｔＴｏＣｏｍｐｌｅｔｉｏｎ（次回完了）ポインタおよびＮｅｘｔＴｏＳｅｎｄ（次回送出）ポインタを使用して、各ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルについて、完了済みメッセージ、完了待ちメッセージ、および送信待ちメッセージの範囲を保持する。ＲＮＩＣは、また、書き込まれたが未送信のメッセージの数（Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｏｓｔｅｄＭｓｇＣｏｕｎｔ）と、完了待ちの送信済みメッセージの数（Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｅｎｄｉｎｇＭｓｇＣｏｕｎｔ）とを接続毎に保持する。なお、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｏｓｔｅｄＭｓｇＣｏｕｎｔおよびＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｅｎｄｉｎｇＭｓｇＣｏｕｎｔは共に、接続毎に保持され、ＲｅｓｐｏｎｓｅＯｕｔチャンネルおよびＲｅｑｕｅｓｔＯｕｔチャンネルの両方について使用される。高速再送信の場合には、ＲＮＩＣは、上述のポインタまたはカウンタのいずれをも更新せずに、最初の未完了セグメント（すなわち、ＮｅｘｔＴｏＣｏｍｐｌｅｔｅによって参照されたＴＣＰセグメント内部メッセージ）を単に再送信する。再送信を行うチャンネルは、以下のように選択される。

タイムアウトによる開始再送信の場合は、ＲＮＩＣは、チャンネルのうちの１つまたは両方のＮｅｘｔＴｏＳｅｎｄポインタを更新して、当該チャンネルの最初の未完了ＴＣＰセグメントをＮｅｘｔＴｏＣｏｍｐｌｅｔｅ（Ｎ２Ｃ）によって参照されたメッセージの内部で参照し、この位置から単一のＴＣＰセグメントを再送信する。Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｏｓｔｅｄＭｓｇＣｏｕｎｔおよびＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｅｎｄｉｎｇＭｓｇＣｏｕｎｔは、それぞれ更新される。ＮｅｘｔＴｏＳｅｎｄ（Ｎ２Ｓ）チャンネル・ポインタが進められて、当該チャンネル内の再送信（または送信）すべき次のセグメントを参照する。進行タイムアウト再送信の場合には、ＲＮＩＣは単一のＴＣＰセグメントを、ＮｅｘｔＴｏＳｅｎｄによって参照された位置から再送信し、ＮｅｘｔＴｏＳｅｎｄと、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＴｏｔａｌＰｅｎｄｉｎｇＭｓｇＣｏｕｎｔとをそれぞれ更新する。なお、ＴＣＰは、送信されていないＴＣＰデータの再送信を要求するものではない。

再送信すべきセグメントの位置特定
再送信すべきＴＣＰセグメントの位置特定は、送信されたメッセージを有するＲｅｑｕｅｓｔＯｕｔおよびＲｅｓｐｏｎｓｅＯｕｔという２つのチャンネルを有することによって、影響を受ける。再送信すべきセグメントの位置特定は、いくつかのステップからなり、その概要を以下に示す。

ステップ１：ＲｅｑｕｅｓｔＯｕｔチャンネルにおける最初の未完了メッセージを見つける。

このステップ後、各チャンネル（ＲｅｑｕｅｓｔＯｕｔおよびＲｅｓｐｏｎｓｅＯｕｔ）は、候補メッセージを有する。このステップは、チャンネルが保留ＲＤＭＡ読み出し要求（すなわち、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＰｅｎｄｉｎｇＲｅａｄＲｅｑｕｅｓｔビットセット）の完了を待つ場合にのみ関連があるので、ＲｅｑｕｅｓｔＯｕｔチャンネルについてのみ関連がある。

これには、「完了フロー」という表題の段落における計算オプションで説明する、上述のチャンネル・メッセージ処理の通常の完了ウォーク・スルーに非常に類似した処理が含まれる。この処理の目的は、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＬａｓｔＡｃｋｅｄＳＮを超える最終シーケンス番号を有するメッセージを見つけることである。このメッセージは、再送信するセグメントを搬送している場合がある。図９に示すように、これは、例Ａにおけるメッセージ＃５であり、例Ｂにおけるメッセージ＃８である。ウォーク・スルー処理には、メッセージの最終シーケンス番号の計算が含まれる。ＲｅｑｕｅｓｔＯｕｔ記述子についてのこのウォーク・スルーと、上述のようにＴＣＰ Ａｃｋの受信による通常の完了処理について説明したウォーク・スルーとの重要な違いに注意されたい。この違いとは、再送信によるウォーク・スルーにおいては、ＲＮＩＣはＲＤＭＡ順序規則を無視し、ＲＤＭＡ読み出し要求を（送出、またはＲＤＭＡ書き込みのような）単方向のＲＤＭＡ動作として扱う。これが行われるのは、ＴＣＰによって正常に送信されなかった最初のＲＤＭＡメッセージにたどり着くのが目的だからである。

ＲＤＭＡ読み出し応答の受信による完了の場合についての図９における上述の例において、通常の完了取り扱い処理は、両方の場合とも、ＲｅｑＯｕｔ：：ＮＣＳＮ＝１００，ＲｅｑＯＵｔ：：ＬＣＳＮ＝０，ＲｅｓｐＯｕｔ：：ＮＣＳＮ＝６００，ＲｅｓｐＯｕｔ：：ＬＣＳＮ＝３００で終了する（なお、ＲｅｓｐＯｕｔは、既に候補ＷＱＥを指し示している）。両方の場合のＲｅｑＯｕｔチャンネルにおいて、完了処理は、最初の保留ＲＤＭＡ読み出し要求（これらの例における最初のＷＱＥ＃）で停止することがある。２つの例の違いは、最後に受信したＡｃｋのＡｃｋＳＮが例Ａでは４５０であり、例Ｂでは５５０であろうということである。これが、再送信動作の初期条件である。再送信動作は、ＲｅｑＯｕｔチャンネルにおけるウォーク・スルーで開始する。例Ａにおいては、ＲＮＩＣは、ＷＱＥ＃１およびＷＱＥ＃４をウォーク・スルーして、ＷＱＥ＃５に到達し、これはＬａｓｔＡｃｋｅｄＳＮ（４５０）よりも大きなＳＮ（５００）で終了する。例Ｂにおいては、ウォーク・スルーはＷＱＥ＃８で終了する。その後、ＮＣＳＮおよびＬＣＳＮは、各例についてそれぞれ更新される。

なお、ウォーク・スルー処理は、保留ＲＤＭＡ読み出し要求を有するＲｅｑｕｅｓｔＯｕｔチャンネルに関連する。その他の場合には、読み出し要求がない場合、またはＲｅｓｐｏｎｓｅＯｕｔチャンネルの場合には、次回完了（Ｎ２Ｃ）は常にメッセージ候補を指し示す。なお、再送信要求の実行に先立って、保留完了動作がないことを単に確認するために、通常の完了が両方のチャンネルに対して行われなければならない。

ステップ２：２つの候補メッセージ（１つは各ＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルに属する）間で、再送信するセグメントを搬送するメッセージを選択する。

再送信するセグメントを保持するメッセージを選択するために、ＲＮＩＣは、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮをＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮと比較する。小さな値であるほど、再送信するセグメントを有するメッセージを保持するチャンネルに属している。

図９は、２つの例を示している。例Ａにおいて（ＲｅｑＯｕｔ：：ＮＣＳＮ＝５００，ＲｅｓｐＯｕｔ：：ＮＣＳＮ＝６００）、選択されたメッセージは、ＲｅｑｕｅｓｔＯｕｔチャンネル、すなわち、メッセージ＃５に属している。例Ｂにおいて（ＲｅｑＯｕｔ：：ＮＣＳＮ＝８００，ＲｅｓｐＯｕｔ：：ＮＣＳＮ＝６００）、選択されたメッセージは、ＲｅｓｐｏｎｓｅＯｕｔチャンネル、すなわち、メッセージ＃６に属している。

ステップ３：再送信を開始するメッセージに属するデータ・バッファを見つける。

メッセージ選択の後、このステップは、再送信すべきセグメントの開始を参照するポインタ記述子の位置を決定する。ポインタ記述子を見つけるためには、ＲＮＩＣは、メッセージの開始シーケンス番号を計算する必要がある。なお、メッセージの開始ＳＮを使用して、メッセージ内のバッファ・オフセットを見つける助けとすることができ、このオフセットを使用して、再送信をすべきバッファを見つけることができる。メッセージの最終シーケンスは既知であり、接続コンテキストに保持されている（Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮまたはＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＮｅｘｔＴｏＣｏｍｐｌｅｔｅＭｓｇＳＮ）。

メッセージの開始シーケンス番号を計算するためには、ＲＮＩＣは、Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮをＣｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮと比較する。大きな値であるほど、メッセージの開始シーケンス番号を示しており、より正確には、このメッセージの開始シーケンス番号は、ｍａｘ（Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｑＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮ，Ｃｏｎｔｅｘｔ［Ｃｈ＃］：：ＲｅｓｐＯｕｔＬａｓｔＣｏｍｐｌｅｔｅｄＭｓｇＳＮ）＋１に等しい。

図９に示すように、例Ａにおいては、開始シーケンス番号は４０１であり、例Ｂにおいては、開始シーケンス番号は５０１である。メッセージの開始シーケンス番号が見つかると、ＲＮＩＣは、ポインタ記述子をウォーク・スルーして、再送信すべきセグメントの開始を保持するポインタ記述子を探す。なお、一般的に、ＬａｓｔＡｃｋｅｄＳＮは、再送信すべきセグメントの開始を示す。

本明細書に記載されたシステム、機能、機構、方法、エンジン、およびモジュールは、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせにおいて実施できることは当然である。これらは、任意の種類のコンピュータ・システムおよび本明細書に記載された方法を実行するために適応された他の装置によって実施されてもよい。ハードウェアおよびソフトウェアの典型的な組み合わせとしては、コンピュータ・プログラムを有する汎用コンピュータ・システムであって、当該コンピュータ・プログラムは、ロードされ実行されると本明細書に記載された方法を実行するように当該コンピュータ・システムを制御するものが挙げられよう。代わりに、特定用途のコンピュータであって、本発明の機能的なタスクのうちの１つ以上を実行するための専用のハードウェアを含んでいるものを使用することもできよう。本発明は、コンピュータ・プログラム製品に埋め込まれることもでき、本コンピュータ・プログラム製品は、本明細書に記載の方法および機能の実施を可能にするすべての特徴を備え、コンピュータ・システムにロードされると、これらの方法および機能を実行することができるものである。コンピュータ・プログラム、ソフトウェア・プログラム、プログラム、プログラム製品、またはソフトウェアは、本件においては、任意の言語、コードまたは表記による、情報処理能力を有するシステムに対して、直接、もしくは、（ａ）他の言語、コード、または表記への変換、または（ｂ）異なる物質的な形式のいずれかあるいはその両方の後のいずれかにおいて、特定の機能を行わせることが意図された命令の組の任意の表現を意味する。

本発明の好ましい実施形態の上記説明を、例示および説明の目的で提示してきた。これらは、網羅的なものでも、また、開示された明確な形式に本発明を限定するものでもなく、当然ながら、数多くの修正および変形物が上記教示の観点から可能である。当業者にとって明白なそのような修正および変形物は、添付の請求項によって規定されるような本発明の範囲内に含まれるものである。

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

本発明に係る順序を維持するための完了および送信システムを示す。 本発明に係るメッセージ記述子を示す。 本発明に係る完了アルゴリズムのフロー・チャートを示す。 本発明に係るＲｅｑｕｅｓｔＯｕｔチャンネルおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルのシーケンス番号を更新する一例を示す。 Ａｃｋ完了動作を示すフロー・チャートを示す。 ＲＤＭＡ読み出し要求完了動作を示すフロー・チャートを示す。 本発明に係るＲｅｑｕｅｓｔＯｕｔおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルにおける完了順序を維持するための一対の例を示す。 本発明に係る３つの再送信の場合を示す。 本発明に係るＲｅｑｕｅｓｔＯｕｔおよびＲｅｓｐｏｎｓｅＯｕｔチャンネルにおける完了順序を維持するための一対の例を示す。

Claims (15)

1. ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）およびＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）を有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における完了処理を取り扱うためのシステムであって、
   チャンネル毎の記述子リスト（１２，１４）であって、その各々が、当該チャンネル内のメッセージ毎のメッセージ記述子を含む、各記述子リスト（１２，１４）と、
   チャンネル交換が前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）と前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）との間で生じる度に、前記メッセージ記述子内のメッセージ長フィールドを前記メッセージ内の最終バイトのシーケンス番号で更新するための更新機構（２５）と、
   完了コンテキスト（２２）内の値を検査して、次回完了メッセージのシーケンス番号と最終受け取りシーケンス番号とを比較して、前記メッセージを完了すべきかどうかを決定する肯定応答（Ａｃｋ）完了システムと、
   読み出し要求の完了を行う読み出し要求完了システムと
   を備える、システム。
2. 前記肯定応答完了システムは、各前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）および前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）に別個に提供される一連の反復論理ステップを含む、請求項１に記載のシステム。
3. 前記反復論理ステップは、
   前記次回完了メッセージの前記シーケンス番号が無効である場合には、前記完了処理の過程が終了したと判断するステップと、
   前記次回完了メッセージの前記シーケンス番号が前記最終受け取りシーケンス番号より大きい場合には、前記完了処理の過程が終了したと判断するステップと、
   前記次回完了メッセージの前記シーケンス番号が前記受け取りシーケンス番号以下である場合には、前記チャンネル内の前記メッセージを完了させるステップと
   を含む、請求項２に記載のシステム。
4. 前記反復論理ステップは、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）が読み出し要求の完了を待っている場合には、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）における前記完了処理を終了させる更なるステップを含む、請求項３に記載のシステム。
5. 前記チャンネル内の前記メッセージを完了させる前記ステップは、
   最終完了メッセージのシーケンス番号を前記次回完了メッセージの前記シーケンス番号で更新するステップと、
   前記次回完了メッセージの前記シーケンス番号を前記チャンネル内の次のメッセージの最終シーケンス番号で更新するステップと
   をさらに含む、請求項３に記載のシステム。
6. 前記チャンネル内の前記メッセージを完了させる前記ステップは、
   前記完了されたメッセージが読み出し要求メッセージでない場合には、動作の完了を行うステップと、
   前記メッセージが読み出し要求メッセージである場合には、完了を行う前に、読み出し応答の受信および配信を待ってから完了を行い、その後、完了コンテキスト内の保留読み出し要求ビットを設定するステップと
   をさらに含む、請求項５に記載のシステム。
7. 前記読み出し要求完了システムは、
   前記読み出し要求に先立つ任意の要求を完了させるステップと、
   前記読み出し要求を完了させるステップと、
   前記読み出し要求に続く任意の要求を完了させるステップと
   を含む第２の一連の論理ステップとを提供する、請求項２に記載のシステム。
8. 前記第２の組の論理ステップの最後の２つのステップは、Ｎ回繰り返され、ここで、Ｎは、完了された読み出し要求の数を表す完了コンテキストに記憶された値である、請求項７に記載のシステム。
9. 再送信すべきセグメントの位置特定のための第３の一連の論理ステップを含む再送信要求を取り扱うためのシステムをさらに備え、前記ステップは、
   保留完了がないことを保証するための完了動作を行うステップと、
   前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）および前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）の両方について、候補メッセージを識別するステップと、
   ２つの候補メッセージから、送信すべき前記セグメントを搬送するメッセージを選択するステップと、
   再送信すべき前記セグメントの開始を示すポインタ記述子の位置を決定するステップとを含む、請求項１に記載のシステム。
10. 前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）が保留読み出し要求の完了を待っている場合には、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）内の前記候補メッセージは、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）内の最初の未完了メッセージのいずれかを備え、
    前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）が保留読み出し要求の完了を待っていない場合には、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）内の前記候補メッセージは、次回完了（Ｎ２Ｃ）ポインタによって与えられ、
    前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）内の前記候補メッセージは、次回完了（Ｎ２Ｃ）ポインタによって与えられる、
    請求項９に記載のシステム。
11. 送信すべき前記セグメントを搬送する前記メッセージは、前記次回完了メッセージについての最下位のシーケンス番号を有するチャンネルにある候補メッセージである、請求項９に記載のシステム。
12. 再送信すべき前記セグメントの前記開始を示す前記ポインタ記述子の前記位置は、
    前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）内の最終完了メッセージのシーケンス番号と、
    前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）内の最終完了メッセージのシーケンス番号と
    のうちの最大値より１大きい、請求項９に記載のシステム。
13. ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）およびＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）を有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における完了処理を取り扱うための方法であって、各チャンネルにおける肯定応答完了を、
    次回完了メッセージのシーケンス番号が無効である場合には、前記完了処理の過程が終了したと判断するステップと、
    前記次回完了メッセージの前記シーケンス番号が最終受け取りシーケンス番号よりも大きい場合には、前記完了処理の前記処理を終了させると判断するステップと、
    前記次回完了メッセージの前記シーケンス番号が最終受け取りシーケンス番号以下である場合には、前記チャンネル内の前記メッセージを完了させるステップと、
    前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）が読み出し要求の完了を待っている場合に、前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）における前記完了処理を終了させるステップと
    を伴って実行するステップを含む、方法。
14. ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）およびＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）を有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における再送信要求に対して再送信すべきセグメントの位置を特定するための方法であって、
    完了動作を行うステップと、
    前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）および前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）の両方について候補メッセージを識別するステップと、
    前記２つの候補メッセージから、送信すべき前記セグメントを搬送するメッセージを選択するステップと、
    再送信すべき前記セグメントの開始を指すポインタ記述子の位置を決定するステップとを備える、方法。
15. ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）およびＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）を有するリモート・データ・メモリ・アクセス（ＲＤＭＡ）環境における送信要求を取り扱うためのシステムであって、
    チャンネル毎の記述子リスト（１２，１４）であって、その各々が、チャンネル内のメッセージ毎のメッセージ記述子を含む、記述子リスト（１２，１４）と、
    チャンネル交換が前記ＲｅｑｕｅｓｔＯｕｔチャンネル（１６）と前記ＲｅｓｐｏｎｓｅＯｕｔチャンネル（１８）との間で生じる度に、前記メッセージ記述子内のメッセージ長フィールドを前記メッセージ内の最終バイトのシーケンス番号で更新するための更新機構（２５）と
    を備える、システム。

Images