JP4564970B2 - ライトウエイト入力／出力プロトコル - Google Patents

Description

本発明は一般に、リモートファイルアクセスのシステムおよび方法に関し、より詳細には、リモートダイレクトメモリアクセス（遠隔直接記憶呼出し：ＲＤＭＡ）を使用して入力／出力処理をオフロードする技術に関する。

コンピューティング環境では、一般に乏しいＣＰＵリソース（資源）を節約することが望ましい。アプリケーションサーバノードのネットワークなど、こうした一部の環境では、こうした節約は特に重要である。ネットワークが速くなるにつれて、パケットを処理し、Ｉ／Ｏ（入力／出力）操作を実行させるためのＣＰＵに対する需要がより多くなり、その結果、アプリケーションパフォーマンス（実行）が遅くなる。このことは、データベースのように本質的にＩ／Ｏを集中的に行うアプリケーションには特に不利である。

この問題を改善する１つの手法は、ＣＰＵから過度のＩ／Ｏおよびネットワーク処理をオフロードする（取り外す）ことである。ネットワーク環境では、ＮＦＳやＳＭＢ／ＣＩＦＳなど、分散されたファイルシステムおよび転送プロトコルを使用することによって、Ｉ／Ｏ要求をローカルマシンからリモートマシン（遠隔地の装置）に送信することができる。しかし、こうした手法を使用することによって、ローカルマシンの処理の大幅な節約を達成できるとは限らない。

単一のマシンの操作状況（context）では、Ｉ／Ｏタスクを直接メモリアクセス（ＤＭＡ）コントローラへオフロードすることによって、Ｉ／Ｏ処理の負荷を軽減することができる。リモートダイレクトメモリアクセス（ＲＤＭＡ）技術とは、ネットワーク接続された複数のコンピュータ用にごく最近開発されたＤＭＡの拡張機能である。ＲＤＭＡは、ソースまたは宛先のマシンのＣＰＵおよびオペレーティングシステムの関与を必要とせずに、ＲＤＭＡ対応ネットワークインターフェイスカード（ＮＩＣ）を備えていて、通信している２つのマシンのメモリバッファ間でのデータの移動を許容する。ＲＤＭＡを使用してＩ／Ｏ処理をリモートマシンへオフロードし、それによってローカルマシンは、ＣＰＵサイクルをアプリケーションのために再利用することができるようになる。ＲＤＭＡは、仮想インターフェイスアーキテクチャ（ＶＩＡ）、ＩｎｆｉｎｉＢａｎｄ(インフィニバンド)、ｉＷａｒｐ（アイワープ）などの、高速、高帯域の相互接続技術で活用されてきている。これらの相互接続は、特に、データセンタ、または他のローカルのファイル共有環境内のサーバノードのクラスタ間の高信頼性ネットワーク接続用に設計されている。

ローカルのオフロード側ノードとリモートマシンとの間の通信を定義するプロトコルは、ＲＤＭＡ技術に関連付けられている機能が十分に使用され、それらの利点が有効に得られるように設計されなければならない。

従って、本発明によるライトウエイト（ライトウエイト）入力／出力（ＬＷＩＯ）プロトコルが必要とされている。

本発明の一態様によれば、Ｉ／Ｏタスクを第１のコンピュータから第２のコンピュータにオフロードするシステムが提供される。このシステムは、第１のコンピュータ上で稼働するクライアント、および第２のコンピュータ上で稼働するサーバを含む。システムは、第１のコンピュータと第２のコンピュータとをリンクする１つまたは複数のＲＤＭＡチャネルをさらに含む。クライアントおよびサーバは、ネットワーク発見段階およびＩ／Ｏ処理段階を含むＬＷＩＯプロトコルに従って通信する。ＬＷＩＯプロトコルは、ＳＭＢ／ＣＩＦＳなど別のネットワークプロトコルとともに使用され、第２のプロトコルのセキュリティおよび認証インフラストラクチャを活用することができる。よりよいセキュリティモデルを提供するために、このプロトコルでのＩ／Ｏモデルは非対称であり、読み取りはＲＤＭＡを使用して実施され、書き込みは送信操作を使用して実施される。

本発明の別の態様によれば、Ｉ／Ｏタスクを第１のコンピュータから第２のコンピュータにオフロードする方法が提供される。この方法は、２つのコンピュータ上の共通のＲＤＭＡ対応通信装置を使用し、ライトウエイト入力／出力（ＬＷＩＯ）クライアント−サーバプロトコルに関連付けられる。プロトコルは一般に、発見段階、続いてＩ／Ｏ処理段階を含む。この発見段階中、クライアントおよびサーバは、共有のＲＤＭＡ対応プロバイダの最小リストを割出しする。Ｉ／Ｏ処理段階中、クライアントは、オフロードを求めるＩ／Ｏ要求を第２のマシンに送る。

発見段階中、クライアントは、最初にサーバからサーバ要求レジュームキー（ｓｅｒｖｅｒ ｒｅｑｕｅｓｔ ｒｅｓｕｍｅ ｋｅｙ）を取得する。次いでクライアントは、サーバへのパイプを開き、それを介して第１のマシン上のＲＤＭＡ対応プロバイダのリストを含む交渉要求を送信する。サーバは、第１のマシン上のプロバイダと一致する第２のマシン上の使用可能なプロバイダのリストを含む交渉応答を、そのパイプを介して送信する。次いでクライアントは、共有のプロバイダを介したサーバへのＲＤＭＡ接続を設ける。クライアントおよびサーバは、新しい接続を互いに認証する。次いでクライアントは、使用する１つまたは複数のファイルをサーバに登録する。

Ｉ／Ｏ処理要求メッセージは、終了メッセージ、キャンセルメッセージ、読み取りメッセージ、書き込みメッセージ、ベクトル化読み取りメッセージ（ｖｅｃｔｏｒｅｄ ｒｅａｄ ｍｅｓｓａｇｅ）、ベクトル化書き込みメッセージ（ｖｅｃｔｏｒｅｄ ｗｒｉｔｅ ｍｅｓｓａｇｅ）を含む。プロトコルは、安全上の理由から、非対称のＩ／Ｏモデルを特徴とする。読み取りデータは、ＲＤＭＡ書き込み操作を使用してクライアントに送信され、書き込みは、通常の送信を使用して完了される。読み取り要求および書き込み要求は、サーバによってポーリングモードまたは割り込みモードで完了されるようにクライアントによって指定することができる。クライアントが非ポーリングモードでの完了を指示した場合、サーバは、ＲＤＭＡ転送を介して状況ブロックを第１のコンピュータに送信することによってＩ／Ｏ処理要求を完了する。クライアントがポーリングモードでの完了を指示した場合、クライアントは、割り込み要求メッセージを介してＩ／Ｏの完了後にサーバによって起動されることを要求することができる。

本発明の別の態様によれば、Ｉ／Ｏオフロードプロトコルでバッファを管理する方法が提供される。この方法は、バッファクレジット機構（ｂｕｆｆｅｒ ｃｒｅｄｉｔ ｍｅｃｈａｎｉｓｍ）の使用を伴う。サーバ−クライアントクレジットトランザクションは、サーバによって開始され、完了される３方向ハンドシェイクを含む。サーバは、いくつかのクレジットに設定された情報フィールドを含めて、デルタクレジット（ｄｅｌｔａ ｃｒｅｄｉｔ）メッセージをクライアントに送信する。その数が負の数−Ｎである場合、クライアントはＮ個のクレジットを捨てる必要がある。

本発明の他の態様は、コンピュータプログラムおよびデータ構造としてコンピュータ可読媒体に組み込まれた上記の特徴を含む。

特許請求の範囲には本発明の特徴を詳しく記載しているが、本発明、並びにその目的および効果は、以下の詳細な説明を添付の図面と併せ読むことによって最もよく理解することができる。

本発明のいくつかの実施形態を、図１〜図１７Ｅを参照して以下で説明する。しかし、これらの図に関して本明細書に示した詳細な説明は例示のためのものであり、本発明はこれらの実施形態を超えて広がることを当業者は容易に理解されよう。

図１は、本発明の態様を組み込むことができる代表的なネットワーク式クライアント／サーバ環境のいくつかの特徴をおおまかに示す概略図である。図１には、ホストＡ１０１およびホストＢ１２１とラベル付けされた２つのコンピュータマシンを示している。本発明は異なる多くのタイプおよび使用のコンピュータを含む環境で実施することができるが、１つの代表的なシナリオでは、ホストＡ１０１は、データベースサーバなど、Ｉ／Ｏを集中的に行う作業が課せられるアプリケーションサーバマシンとして働く。

ホストＡ１０１およびホストＢ１２１のそれぞれは、一方のマシンから他方のマシンへのネットワーク式データ通信を許可するいくつかのネットワークインターフェイスカード（ＮＩＣ）１０９、１１１、１１３、１３３、１３５、１３７を含む。これらのＮＩＣのうち、ＲＤＭＡデータ転送を可能にするのはＮＩＣ１０９、１１１、１３５、１３７である。示したように、非ＲＤＭＡネットワークリンク１１９およびＲＤＭＡチャネル１１７が２つのホスト１０１と１２１との間に存在している。

ホストＡ１０１では、カーネルモードＩ／Ｏ読み取り／書き込みサービス１０５と対話する、Ｉ／Ｏタスクの処理の責任を負うアプリケーションに関連付けられているＬＷＩＯクライアントアプリケーション１０３が実行されている。ＬＷＩＯクライアント１０３は、Ｉ／Ｏ処理をホストＡ１０１からホストＢ１２１にオフロードするために使用される。ホストＢ１２１では、ＬＷＩＯサーバ１２３が実行されている。本明細書に記載したＬＷＩＯプロトコルによれば、ＬＷＩＯクライアント１０３は、ＬＷＩＯサーバ１２３と通信する。ＬＷＩＯクライアント１０３およびＬＷＩＯサーバ１２３は、送られたバッファ１０７、１２７を使用して、ファイル関連のデータを、ＲＤＭＡチャネル接続１１７を介して直接転送することができる。読み取りタスクおよび書き込みタスクは、ＬＷＩＯプロトコルメッセージを介して、ホストＢ１２１にオフロードされる。サーバ１２３は、ハードディスク１３１へのインターフェイスとして働くファイルシステム１２９にＩ／Ｏ要求を伝える。

一般に、ＲＤＭＡ接続１１７には２種類のメッセージが関連付けられている。第１のタイプは、宛先マシンで割り込みを生成する通常のネットワーク送信／受信である。第２のタイプはＲＤＭＡ読み取り／書き込みであり、リモートＣＰＵの援助無しに、従って割り込みを生成する必要なく、リモートマシン上のメモリ空間へのアクセスが行われる。リモートＣＰＵは、ＲＤＭＡのために公開されたメモリ領域を割出しするが、一般にはＲＤＭＡ操作がいつ実行されるかを知らない。

本明細書に記載した本発明の一実施形態では、ＬＷＩＯプロトコルは、別のプロトコルの既存のセキュリティおよび認証のインフラストラクチャを利用できるように、ＳＭＢやＣＩＦＳなど別のネットワークプロトコルとともに使用される。これは、ＬＷＩＯプロトコルのオーバーヘッドを最低限に抑えるのを助ける。図１に示すように、ホストＢ１２１上のＬＷＩＯサーバ１２３は、ＳＭＢサーバ１２５の上で動作する。同様にＳＭＢクライアント（図示せず）もホストＡ１０１上で稼働し、ＬＷＩＯクライアントアプリケーション１０３と対話する。

ＬＷＩＯプロトコルは、発見段階（discovery phase）、次いでＩ／Ｏ段階(I/O phase)の２段階を含む。本明細書に記載した実施形態に関連付けられているデータ構造では、データサイズは次の通りである。

図２は、本発明の一実施形態におけるＬＷＩＯプロトコルの発見段階で行われるステップを示している。ＬＷＩＯサーバが実行されているホストに関して、ステップ２０１で、ＬＷＩＯサーバをそのホストマシン上で稼働しているＳＭＢ／ＣＩＦＳサーバに登録する。この登録に従って、ステップ２０３で、ＳＭＢ／ＣＩＦＳサーバは、リモートホスト上で稼働しているＳＢＭ／ＣＩＦＳクライアントに、ＬＷＩＯサーバが使用可能であることを通知する。ステップ２０５で、ＬＷＩＯクライアントは、サーバ要求レジュームキーを要求する。再開キーとは認証機構であり、これについては、本出願と同じ譲受人を有する別の出願、すなわち、参照により本明細書に組み込まれている「Method and System for Accessing a File (Resume Key)」という名称の２００３年１０月２４日に出願した米国特許出願第 号の明細書に開示されている。

ステップ２０７で、ＬＷＩＯサーバは、サーバ要求レジュームキーをクライアントに返す。本発明の一実施形態では、サーバ要求レジュームキーは、次の構造を有する。

図３は、サーバ要求レジュームキー２１９の表現例を提示する。ＲｅｓｕｍｅＫｅｙ（レジュームキー）２２１、Ｔｉｍｅｓｔａｍｐ（タイムスタンプ）２２３、およびＰｉｄ（ピッド）２２５は、サーバ上で生成され、クライアントからは見えない。Ｃｏｎｔｅｘｔ(コンテキスト)２２９は、サーバに連絡するためにＬＷＩＯクライアントによって使用されるＵＮＣ名を含むアレイである。ＣｏｎｔｅｘｔＬｅｎｇｔｈ（コンテキストレングス）２２７は、Ｃｏｎｔｅｘｔ２２９におけるバイト数である。

ネットワークの発見
クライアントアプリケーションは、サーバ要求レジュームキー２１９を受信すると、コンテキストフィールド２２９からサーバＵＮＣ名を取り出す。図２に戻って、ステップ２０９で、クライアントはＬＷＩＯサーバへのパイプを開く。パイプは、以下でさらに詳しく説明するように、ネットワークで使用可能なＲＤＭＡ対応装置を自動的に発見するために使用される。これは本発明の重要かつ有用な特徴であり、一般にＶＩＡネットワークおよび同様のネットワークには、ＡＲＰのようなアドレス解決機構がない。

次にクライアントは、サーバに対して、ＬＷＩＯプロトコルとともに使用可能なそのＲＤＭＡ対応装置（「プロバイダ」）のリストについての照会を行う。照会は、クライアントが構築し、ステップ２１１で新しく開かれたパイプを介してサーバに送信する交渉（ネゴシエーション）要求を介して達成される。本発明の一実施形態では、交渉要求は、次の構造を有する。

図４Ａは、本発明の一実施形態による交渉要求パケット２３１の表現例を示す。交渉要求は、制御ヘッダ２３３、固定長Ｕｎｉｃｏｄｅ（ユニコード）クライアント名フィールド２３５、キーとして使用されるクライアントＵＵＩＤ２３７、応答を受信するローカルバッファサイズ２３９、およびプロバイダのリスト２４１を含む。制御ヘッダ２３３には、Ｐｒｏｔｏｃｏｌ(プロトコル)Ｉｄ「ＬＷＩＯ」２４３がヘッダの最初の４バイトとして格納されている。

ＲｅｖＩｄ２４５は、現在定義されている値０ｘ１００１、ＬＷＩＯ＿ＲＥＶ＿ＩＤを保持する。Ｏｐｃｏｄｅ２４７は、現在定義されている値０ｘｆｅ、ＬＷＩＯ＿ＣＯＮＴＲＯＬ＿ＯＰＣＯＤＥ＿ＮＥＧＯＴＩＡＴＥを保持する。Ｌｅｎｇｔｈ（レングス）２４９は、すべての演算コード固有のデータを含めて、サーバに送信される完全なパケットのバイト単位のサイズである。

ＣｌｉｅｎｔＮａｍｅ（クライアントネーム）２３５は、サーバがクライアントを識別するために使用する。Ｋｅｙ（キー）２３７は、後述するように、その後のネットワーク固有の認証手順で使用される。ＲｅｓｐｏｎｓｅＬｅｎｇｔｈ（レスポンスレングス）２３９は、後述するように、サーバからの交渉応答を受信するバッファのサイズである。ＰｒｏｖｉｄｅｒＣｏｕｎｔ（プロバイダカウント）２５１は、クライアントマシンに関連付けられているプロバイダの数であり、クライアントはそれについてサーバに知らせている。プロバイダリスト２４１は、ＰｒｏｖｉｄｅｒＣｏｕｎｔプロバイダのリストを含む。

プロバイダリスト２４１の要素の中のＮａｍｅ（ネーム）２５３はプロバイダの名前である。互換性のあるネットワークを検出するために、クライアントおよびサーバは、同じ名前を同じプロバイダに使用することが好ましい。ＩｎｓｔａｎｃｅＣｏｕｎｔ（インスタンスカウント）２５５は、特定のプロバイダタイプの装置数である。インスタンステーブル２５７は、ネットワーク／識別子の対のテーブルであり、１対は、装置固有の方法で、リモート接続をどのように形成するかを説明するよう働く。ＨｏｓｔＡｄｄｒｅｓｓＬｅｎ（ホストアドレスレン）２５９は、ネットワーク固有のホストアドレス２６３の長さである。ＤｉｓｃｒｉｍｉｎａｔｏｒＬｅｎ（ディスクリミネータレン）２６１は、ネットワーク固有の識別子２６５の長さである。これらの長さフィールドに続いて、ＨｏｓｔＡｄｄｒｅｓｓＬｅｎバイトのホストアドレス２６３、およびＤｉｓｃｒｉｍｉｎａｔｏｒＬｅｎバイトの識別子２６５がある。

図２に戻ると、クライアントのプロバイダのリストを含む交渉要求を受信すると、ステップ２１３で、サーバは、クライアントと共通するＲＤＭＡ対応通信装置を割出しする。ステップ２１５で、サーバは、共有プロバイダのリストを含めて、交渉応答をパイプを介してクライアントに送信する。本発明の一実施形態では、交渉応答は、次の構造を有する。

図４Ｂは、本発明の一実施形態による交渉応答２６７の表現例を示す。制御ヘッダ２６９は、ここではＬｅｎｇｔｈ（レングス）２７１が応答メッセージ２６７のサイズを反映することを除いて、交渉要求のものと同様である。ＳｒｖＮａｍｅ（サーバネーム）２７３は、サーバ名を保持する。Ｋｅｙ（キー）２７５は、クライアントによって使用するためのサーバ生成ＧＵＩＤである。以下でさらに説明するように、クライアントは、このＫｅｙを、共通の通信装置のうちの１つを使用する新しい接続を介して認証要求でサーバに返送する。ＰｒｏｖｉｄｅｒＣｏｕｎｔ（プロバイダカウント）２７７は、プロバイダリスト２７９内のプロバイダ数である。プロバイダリスト２７９は、サーバおよびクライアントに共通のプロバイダのリストを含む。クライアントが実際にこれらのプロバイダに接続することができるという保証はない。

図２に戻ると、この時点で、サーバおよびクライアントは通信装置情報を共有しており、共通プロバイダの最小リストが割出しされている。ステップ２１７で、クライアントは、共有の装置のうちの１つまたは複数を介したＬＷＩＯサーバへの１つまたは複数のＲＤＭＡ接続を設ける。本発明の一実施形態では、本明細書に記載するように、クライアントからサーバへの通信には次の演算コードが定義される。

クライアントからサーバへの通信では、次の定義されたフラグが変更子（modifier）として使用される。

ＬＷＩＯプロトコルでの対応するクライアントからサーバへのメッセージは、共通のヘッダ構造を特徴とする。本発明の一実施形態では、共通ヘッダは以下のフォーマットを有する。

接続の認証
図５は、ＬＷＩＯプロトコルの最初の段階の残りの間に本発明の一実施形態においてクライアントおよびサーバによって行われるステップを示している。ステップ６０１で、クライアントは、上述したように、共有の通信装置を介してサーバへの接続を確立する。ここでクライアントおよびサーバは、新しい接続を互いに認証する。ステップ６０３で、クライアントは、認証要求メッセージ（ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＡＵＴＨ）をサーバに送信する。サーバ側およびクライアント側のスプーフィングを防ぐために認証が行われる。認証がタイムリーに完了しない場合、接続が中断される。

図６Ａは、本発明の一実施形態によるクライアント認証要求メッセージの表現例を示す。認証メッセージ６１７は、共通ヘッダ６１９、次いでＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造６２１を含む。ヘッダ６１９の中のＬｅｎｇｔｈ（レングス）６２３は、サーバに送信されるバイト数（共通ヘッダ６１９のサイズプラスＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１のサイズ）に設定される。Ｏｐｃｏｄｅ（オプコード）６２５はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＡＵＴＨ（０ｘ６）に設定される。Ｆｌａｇｓ(フラッグス)６２７はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴに設定される。Ｃｏｏｋｉｅ（クッキー）６２９は、これおよび他のクライアントプロトコルメッセージでは、クライアントによって選択された値に送信され、サーバの応答で返送される。Ｃｏｏｋｉｅ値は一般に、要求をサーバの応答に一致させるために使用される。ＤａｔａＶａ（データＶａ）６３１は、サーバがサーバ認証パラメータにＲＤＭＡすべきアドレスに設定される。ＤａｔａＭｈ（データＭｈ）６３３は、ＤａｔａＶａ６３１に関連付けられているＲＤＭＡメモリハンドルを保持する。

本発明の一実施形態では、ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造は、次のフォーマットを有する。

認証メッセージ６１７の中のＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１は、パケットの第２の部分を形成する。Ｍａｇｉｃ(マジック)６３５は「ＬＷＩＯ」に設定される。ＲｅｖＩｄ６３７はＬＷＩＯ＿ＲＥＶ＿ＩＤに設定される。Ｅｎｄｉａｎ（エンディアン）６３９はｓｉｚｅｏｆ（ＵＬＯＮＧ＿ＰＴＲ）に設定される。ＰａｇｅＳｉｚｅ（ページサイズ）６４１は、ＣＰＵページサイズ（３２ビットマシンでは４ｋ、６４ビットマシンでは８ｋ）に設定される。ＢａｓｅＳｅｑｕｅｎｃｅ（ベースシーケンス）６４３は０に設定される。ＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅ（マックスＲＤＭＡウインドウサイズ）６４５は、クライアントがＲＤＭＡ転送で受け入れることができる最大バイト数に設定されるものとし、図に描いた実施形態では、６４ｋに設定される。ＭａｘＳｅｎｄＢｕｆｆｅｒＳｉｚｅ(マックスセンドバッファサイズ)６４７は、単一の要求でクライアントがサーバに送信することができるバイト数に設定されるものとし、図に描いた実施形態では、１ｋに設定される。ＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅ(マックスレシーブバッファサイズ)６４９は、サーバからデータを受信するためにクライアントが送ったバイト数に設定されるものとし、図に描いた実施形態では、１６バイトに設定される。ＨｅａｄｅｒＳｉｚｅ（ヘッダサイズ）６５１は、ＬＷＩＯ制御ヘッダ６１９でのバイト数に設定される。Ｃｒｅｄｉｔｓ（クレジット）６５２は、クライアントが有したい最初のバッファクレジット数に設定される。クレジットの使用については、以下でさらに説明する。サーバは、クライアントの要求を満たしても満たさなくてもよい。ＲｄｍａＲｅａｄＳｕｐｐｏｒｔｅｄ（ＲＭＡＤＡリードサポーテッド）６５３は、クライアントがＲＤＭＡ読み取り操作をサポートしていない場合は０に設定され、クライアントがＲＤＭＡ読み取り操作をサポートしている場合は１に設定される。

ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造の一部は、１つまたは複数の選択肢の組である。選択肢は、認証をより柔軟にするために使用される。各選択肢は、選択肢のリストを終了させるヌルの選択肢として働く、選択肢コードのみを有するリスト内の最後の選択肢ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＥＮＤ以外は、選択肢コード、長さ、およびデータを有する。認証メッセージでは、クライアントはサーバに、Ｋｅｙ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＫＥＹ）およびＳｉｇｎａｔｕｒｅ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＩＧＮＡＴＵＲＥ）の選択肢を送信する。Ｋｅｙ（キー）６５５は、交渉応答でサーバによって以前返されたＫｅｙに設定される。Ｓｉｇｎａｔｕｒｅ（シグネチャ）６５７は、署名なしのＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１のＭＤ５署名である。

図５に戻って、ステップ６０５で、認証メッセージで送信されたＫｅｙがパイプを介して交渉応答で返されたキーに一致する場合、サーバは、クライアントによって認証メッセージで提供されたＤａｔａＶａアドレス、および関連のＤａｔａＭｈメモリハンドル宛てに、認証応答として、８バイトのＳｅｓｓｉｏｎＩｄ（セッションＩｄ）を含むＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造をクライアントにＲＤＭＡ（リモートダイレクトメモリアクセス）する。ステップ６０７で、サーバは認証を完了するためにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥを送信する。

図６Ｂは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造６５９の表現例を示している。Ｍａｇｉｃ（マジック）６６１は「ＬＷＩＯ」に設定される。ＲｅｖＩｄ６６３はＬＷＩＯ＿ＲＥＶ＿ＩＤに設定される。Ｅｎｄｉａｎ（エンディアン）６６５はｓｉｚｅｏｆ（ＵＬＯＮＧ＿ＰＴＲ）に設定される。ＰａｇｅＳｉｚｅ（ページサイズ）６６７はＣＰＵページサイズに設定される。ＢａｓｅＳｅｑｕｅｎｃｅ（ベースシーケンス）６６９は、（クライアントＢａｓｅＳｅｑｕｅｎｃｅ＋１）に設定されるものとする。ＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅ（マックスＲＤＭＡウインドウサイズ）６７１は、クライアントがＲＤＭＡ転送で受け入れることができる最大バイト数に設定されるものとし、図に描いた実施形態では、５１２ｋに設定される。ＭａｘＳｅｎｄＢｕｆｆｅｒＳｉｚｅ（マックスセンドバッファサイズ）６７３は、単一の応答でサーバがクライアントに送信するバイト数に設定されるものとし、図に描いた実施形態では、１６バイトに設定される。ＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅ（マックスＲＥＣＶバッファサイズ）６７５は、クライアントからデータを受信するためにサーバが事前に送ったバイト数に設定されるものとし、図に描いた実施形態では、８ｋに設定される。ＨｅａｄｅｒＳｉｚｅ（ヘッダサイズ）６７７は、共通のヘッダにおけるバイト数に設定される。Ｃｒｅｄｉｔｓ（クレジット）６７９は、サーバがクライアントに使用可能な最初のクレジット数に設定される。ＲｄｍａＲｅａｄＳｕｐｐｏｒｔｅｄ（ＲＤＭＡリードサポーテッド）６８１は、サーバがＲＤＭＡ読み取りをサポートしていない場合は０に設定され、サーバがＲＤＭＡ読み取りをサポートしている場合は１に設定される。サーバは、Ｋｅｙ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＫＥＹ）６８３、ＳｅｓｓｉｏｎＩｄ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＥＳＳＩＯＮ＿ＩＤ）６８５、およびＳｉｇｎａｔｕｒｅ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＩＧＮＡＴＵＲＥ）６８７の選択肢を送信する。Ｋｅｙ（キー）６８３は、交渉要求でクライアントが前もって送信したＫｅｙに設定される。ＳｅｓｓｉｏｎＩｄ（セッションＩＤ）６８５値は、後述するように、クライアントファイルをサーバに登録する際にクライアントによって使用される。Ｓｉｇｎａｔｕｒｅ（シグネチャ）６８７は、署名なしのＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳのＭＤ５署名である。

本発明の一実施形態では、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ構造は、次のフォーマットを有する。

図６Ｃは、本発明の一実施形態において認証を完了させるためにサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ６８９の表現例を示している。Ｃｏｏｋｉｅ６９１は、認証メッセージのヘッダ内のクライアントによって設定されたクッキー値に設定される。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）６９３は、ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳプラス８バイトのバイト数に設定される。Ｓｔａｔｕｓ（ステータス）６９５は、０ｘ０（成功を示す）または０ｘＣ０００００２２（「アクセス拒否」を示す）に設定される。

ファイル登録
図５に戻って、ステップ６０９で、新しい接続がクライアントおよびサーバによって互いに認証されると、クライアントは、使用するファイルのサーバへの登録を開始する。ファイルのファイル操作は、クライアントが使用するファイルをサーバに登録するまで、リンクを介して処理されない。

図７Ａは、本発明の一実施形態によるクライアントからサーバに送信されるファイル登録メッセージの表現例を示している。登録メッセージ７０１は、共通ヘッダ７０３、次いでＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造７０５を含む。Ｌｅｎｇｔｈ（レングス）７０７は、サーバに送信されるバイト数（ヘッダ７０３のサイズプラスＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ７０５のサイズ）に設定される。Ｏｐｃｏｄｅ（オプコード）７０９はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＧＩＳＴＥＲ（０×７）に設定される。Ｆｌａｇｓ(フラッグス)７１１はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴに設定される。このクライアントメッセージおよびその後のクライアントメッセージでは、Ｃｒｅｄｉｔｓ（クレジット
）７１３は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｒｅｄｉｔｓフィールドは、より多くのクレジットを接続に割り振ることについてのサーバへのヒントとしての役割を果たし、従って以下でさらに説明するように、追加の未解決のＩ／Ｏ要求を許可する。１回の未解決のクライアント要求の数が「Ｃｒｅｄｉｔｓ」値を超えることはできない。上述したように、Ｃｏｏｋｉｅ（クッキー）７１５は、クライアント指定の値に設定される。

本発明の一実施形態では、ＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造は、次のフォーマットを有する。

ファイル登録メッセージ７０１のＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ７０５では、ＲｅｓｕｍｅＫｅｙ(レジュームキー)７１７は、最初のファイルアクセスチャネルを介して返されたサーバ要求レジュームキーに設定される。ＳｅｓｓｉｏｎＩｄ（セッションＩｄ）７１９は、接続認証段階中、サーバによって返されたＳｅｓｓｉｏｎＩｄに設定される。ＦｌａｇｓＡｎｄＡｔｔｒｉｂｕｔｅｓ（フラッグスアンドアンドリブーツ）７２１は、最初にファイルを開くために使用されるＷｉｎ３２ Ｃｒｅａｔｅ Ｆｌａｇｓに設定される。

図５に戻って、ステップ６１１で、サーバはファイル登録を完了するためにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答する。図７Ｂは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ７２３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）７２７は、Ｉ／Ｏ要求を送信するときに使用されるＦｉｄ（ＦｉｌｅＩＤ）に設定される。Ｓｔａｔｕｓ（ステータス）７２９は、０×０（成功）、または失敗時は別のＮＴＳＴＡＴＵＳコードに設定される。Ｃｏｏｋｉｅ（クッキー）７２５は、ファイル登録メッセージのヘッダ内にクライアントが設定したクッキー値に設定される。

Ｉ／Ｏ処理
この時点で、クライアント接続が確立され、ファイルが登録されており、ＬＷＩＯプロトコルのＩ／Ｏ処理段階が開始する。ＬＷＩＯプロトコルの実施形態の１つの重要な特徴は、読み取りおよび書き込みについての非対称のＩ／Ｏモデルである。読み取り操作はＲＤＭＡを使用して実施され、書き込みは送信操作を使用して実施される。より良いセキュリティモデルを提供するように、書き込みの実施にはＲＤＭＡは使用されない。サーバがＲＤＭＡのためにＮＩＣ（ネットワークインターフェイスカード）を介してそのアドレス空間を公開すると、悪意のあるクライアントによって悪用されるおそれのあるデータ破損の脆弱性がもたらされる。このシナリオでは、悪意のあるクライアントは、ループ内で所与のサーバ仮想アドレスに対するＲＤＭＡ書き込み操作を発行する。サーバアドレス空間は有限であり、ある時点でサーバ仮想アドレスを再利用しなければならないため、悪意のあるクライアントは、最終的に、異なる接続に同じ仮想アドレスを使用するサーバをつかまえ、異なるクライアントに関連付けられている可能性のあるサーババッファにデータが書き込まれてしまう。ＬＷＩＯプロトコルでの非対称のＩ／Ｏモデルは、この可能性を防ぐ。この特徴は、ＬＷＩＯプロトコルと、ＤＡＦＳ（Direct Access File System）などの他のＲＤＭＡベースのファイル転送プロトコルとの間の主な違いである。

図５に戻って、ステップ６１３で、クライアントはＩ／Ｏ処理要求を送り始める。サーバからクライアントへのＩ／Ｏ要求の完了は、非ポーリングモードまたはポーリングモードのいずれかで行われる。非ポーリングモードでは、Ｉ／Ｏの完了は、通常の送信／受信メッセージを使用した割り込みベースである。ポーリングモードでは、Ｉ／Ｏの完了は、ＲＤＭＡを使用し、割り込みベースではない。

図８の流れ図は、ＬＷＩＯサーバからの一般的な観点から、ポーリングモードまたは非ポーリングモードでのＩ／Ｏ要求の完了に関して本発明の一実施形態で行われるステップをおおまかに示している。クライアントＩ／Ｏ要求は、サーバが送信後（ｐｏｓｔ−ｓｅｎｄ）メッセージ（ＣＰＵの割り込み）またはＲＤＭＡメッセージを返送するべきかどうかを指定する。ステップ８０１で、サーバは、ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴフラグがクライアントＩ／Ｏ要求メッセージの共通ヘッダに設定されているかどうかを割出しする。このフラグが設定されている場合、ステップ８０３で、サーバは、通常の送信を使用してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥを介してクライアント要求を完了する。ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴフラグが設定されていない場合（ポーリングモード）、ステップ８０５で示すように、サーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをクライアントにＲＤＭＡすることによってクライアント要求を完了する。

ポーリングモードでのクライアントの起動
ポーリングモードでは、クライアントは、サーバからのＩ／Ｏの完了を待つ間スリープしたい場合がある。この場合の完了はＲＤＭＡを介してクライアントに送信されるため、クライアントを起動させて、完了が行われたことをクライアントに通知する機構が必要となる。クライアントは、起動したい場合、図８のステップ８０７でサーバによって受信された割り込み要求（ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＩＮＴＥＲＲＵＰＴ）メッセージをサーバに送信する。割り込み要求を受信するサーバは、サーバにおいてＩ／Ｏ要求が完了する（ステップ８０９）まで応答を送信しない。完了は、ステップ８１１で、通常の送信を介してクライアントに送信され、クライアントに割り込みがかかる。所与のクライアント接続について、未解決とすることができる割り込みメッセージは１つのみである。

図９Ａは、本発明の一実施形態においてクライアントからサーバに送信される割り込み要求メッセージの表現例を示している。メッセージは、共通ヘッダ８１５を含んでいる。Ｏｐｃｏｄｅ(オプコード)８１７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＧＩＳＴＥＲ（０×９）に設定される。Ｆｌａｇｓ（フラッグス）８１９は（ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ｜ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＮＴＲＯＬ）（０×Ｃ０）に設定される。Ｃｒｅｄｉｔｓ(クレジット)８２１は、クライアント上の保留中のＩ／Ｏ要求の数に設定され、Ｃｏｏｋｉｅ(クッキー)８２３は、クライアント指定の値に設定される。

サーバは、別のＩ／Ｏ要求が処理された後、割り込み要求メッセージに応答する。図９Ｂは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージ８２５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）８２７は０に設定される。Ｓｔａｔｕｓ（ステータス）８２９は、０×０（成功）、または失敗時は別のＮＴＳＴＡＴＵＳコードに設定される。Ｃｏｏｋｉｅ８３１は、クライアントによって送信された割り込み要求のヘッダ内のＣｏｏｋｉｅ値に設定される。

クレジット
上述したように、すべてのクライアントからサーバへのＩ／Ｏ要求は、ヘッダ内にクレジットフィールドを含んでいる。クレジットフィールドは、クライアントがサーバに送信したい未解決のＩ／Ｏ要求の数に関するサーバへのヒントである。クレジットを管理するのはサーバの責任である。クレジットは、バッファのフラッシュの問題に新しい解決策を提供する。クライアントが現在Ｎ個のクレジットを有している場合、サーバがクライアントにクレジットメッセージを送信するには、Ｎ＋１個の受信バッファを送る必要がある。サーバは、クライアント接続に沿って未解決のクレジット要求を常に１つだけ有する。クレジットメッセージは常に、割り込みモードで送信される。

クレジットトランザクションは、クライアントとサーバとの間のサーバが開始する３方向のハンドシェイクを含む。図１０は、本発明の一実施形態におけるクレジットトランザクションを含むステップをおおまかに示している。ステップ１００１で、サーバは、デルタクレジット要求メッセージを、クライアント接続に沿って送信する。

図１１Ａは、本発明の一実施形態によるサーバデルタクレジットメッセージの表現例を示す。このメッセージは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０１１の形をとる。クレジットはバッファに対応する。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）１０１３は、クライアントが捨てるべき（負の数）クレジットの数、またはクライアントの使用のためにサーバが新しく割り振った（正の数）クレジットの数（余分なバッファ）に設定される。Ｓｔａｔｕｓ（ステータス）１０１５は、ＬＷＩＯ＿ＮＯＴＩＦＹ＿ＣＲＥＤＩＴ（０×１）に設定される。Ｃｏｏｋｉｅ（クッキー）１０１７は０に設定される。

図１０に戻って、クライアントは、サーバからクレジットメッセージを受信する。クライアントは、同じ接続で、サーバに対してＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴで応答する必要がある。このメッセージは、単一のクレジットの解放、またはクライアントが使用した新しく割り振られたクレジットの数のサーバへの通知のいずれかを指定する。サーバクレジットメッセージ内のＩｎｆｏｒｍａｔｉｏｎフィールドが負の数−Ｎを含んでいる場合（ステップ１００３）、ステップ１００５で示すように、クライアントは、Ｎ個のＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージ（捨てる必要があるのはクレジットごとに１つ）を送信する。情報フィールドが正である場合、ステップ１００７で示すように、クライアントは、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージを１つだけ送信する。

図１１Ｂは、本発明の一実施形態においてクライアントによって送信されるＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージの表現例を示している。ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージ１０１９は、共通ヘッダ１０２１を含む。Ｏｐｃｏｄｅ１０２３は、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴ（０×８）に設定される。Ｆｌａｇｓ１０２５はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０２７は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０３１はクライアント指定の値に設定される。クライアントが正のデルタクレジットメッセージを受信した場合、Ｏｆｆｓｅｔ（オフセット）１０２９の上位３２ビットは、クレジットが使用しなかった、サーバによって割り振られたクレジットの数に設定される。クライアントがこのフィールド内にゼロより大きい値を返すと、サーバは通常、少なくとも１つの負の更新が送信されるまで、別の正の更新メッセージを送信しない。一般に、クライアントはゼロを返す。

上述したように、クライアントは、負（−Ｎ）のデルタクレジットメッセージを受信した場合、捨てるクレジットごとに１つのＮ個のクレジットメッセージをサーバに送信することが必要である。この場合のＯｆｆｓｅｔ１０２９の上位３２ビットは、従って−Ｎ、−（Ｎ−１）、・・・−１に設定される。サーバは、Ｏｆｆｓｅｔ１０２９の上位３２ビットが−１に設定された状態でクライアントクレジットメッセージを受信した場合、クライアントがサーバクレジットメッセージの処理を終了し、新しいクレジットメッセージを受信する資格があると判断する。

図１０に戻って、ステップ１００９に示すように、サーバは、クライアントにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージを送信することによって３方向ハンドシェイクを完了する。図１１Ｃは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０３３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０３７は０に設定される。クライアントによって送信されたＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージのヘッダ内のＯｆｆｓｅｔの上位３２ビットが０以上であった場合、Ｓｔａｔｕｓ（ステータス）１０３９は、成功を示す０×０に設定される。Ｏｆｆｓｅｔの上位３２ビットが負の数に設定されている場合、サーバは、クライアントがクレジットを廃棄するのを許可するように、Ｓｔａｔｕｓ１０３９をＬＷＩＯ＿ＣＲＥＤＩＴ＿ＮＯＴＩＦＹに設定する。Ｃｏｏｋｉｅ１０３５は、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージの共通ヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。

終了
終了メッセージは、登録段階中に交換された特定のＦｉｄのＩ／Ｏ処理を停止するために使用される。サーバが応答すると、Ｆｉｄが再利用されるまで、新しい要求は失敗する。図１２Ａは、本発明の一実施形態においてクライアントによって送信される終了メッセージの表現例を示している。終了メッセージ１０４１は、共通ヘッダ１０４３を含む。Ｏｐｃｏｄｅ１０４５はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＬＯＳＥ（０×４）に設定される。Ｆｌａｇｓ１０４７はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０４９は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０５３はクライアント指定の値に設定される。Ｆｉｄ１０５１は、終了すべきファイルのＦｉｌｅ Ｉｄに設定される。

サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答する。図１２Ｂは、本発明の一実施形態においてサーバによって返される終了完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０５５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０５９は０に設定される。Ｓｔａｔｕｓ１０６１は、成功を示す０に設定される。Ｃｏｏｋｉｅ１０５７は、クライアント終了要求で設定されたＣｏｏｋｉｅ値に設定される。

キャンセル
キャンセルメッセージは、登録段階中に交換された特定のＦｉｄのＩ／Ｏ処理を停止するために使用される。キャンセルが発行されると、サーバは要求を終える。しかし、キャンセルできないＩ／Ｏ要求は、サーバ上で依然として続行している場合がある。図１３Ａは、本発明の一実施形態においてクライアントによって送信されるキャンセルメッセージの表現例を示している。キャンセルメッセージ１０６３は、共通ヘッダ１０６５を含む。Ｏｐｃｏｄｅ１０６７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＡＮＣＥＬ（０×５）に設定される。Ｆｌａｇｓ１０６９はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０７１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０７５はクライアント指定の値に設定される。Ｆｉｄ１０７３は、キャンセルが発行されているＦｉｌｅ Ｉｄに設定される。

サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージでキャンセルを完了する。図１３Ｂは、本発明の一実施形態においてサーバによって返されるキャンセル完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０７７の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０８１は０に設定される。Ｓｔａｔｕｓ１０８３は、成功を示す０に設定される。Ｃｏｏｋｉｅ１０７９は、クライアントキャンセル要求で設定されたＣｏｏｋｉｅ値に設定される。

読み取りメッセージは、登録段階中に交換された特定のＦｉｄからデータを取得するために使用される。１キロバイトより小さい読み取り要求については、ユーザバッファがＮＩＣに登録されていない場合、データは、予め登録されていた内部バッファ内に受信され、データがサーバから受信されると、ユーザバッファ内にコピーが行われる。これが行われるのは、小さいユーザバッファを登録するより、少量のデータをコピーすることがより効率的であるからである。大量の読み取りでは、ユーザバッファが登録され、データは、ＲＤＭＡ書き込みを介して直接受信される。単一の読み取り要求に従って読み取られたデータの量は、サーバのＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅによって限定される。

図１４Ａおよび図１４Ｃは、本発明の一実施形態においてクライアントによって送信される読み取りメッセージの表現例を示しており、図１４Ａは非ポーリングの場合、図１４Ｃはポーリングの場合を示している。読み取りメッセージ１４０１は、共通ヘッダ１４０３を含む。Ｌｅｎｇｔｈ１４０５は、関連のファイルから読み取られるバイト数に設定される。Ｏｐｃｏｄｅ１４０７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＡＤ（０×０）に設定される。Ｏｆｆｓｅｔ１４１７は、ファイルの読み取りを開始するバイト位置に設定される。Ｍａｒｋｅｒ１４１３は０×ＦＦに設定される。Ｆｌａｇ１４０９、１４２７は、ポーリングの場合１４２７では０×０に設定され、非ポーリングの場合１４０９ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１４１１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１４１５は、Ｉ／Ｏを発行するＦｉｌｅ Ｉｄに設定される。ＤａｔａＶａ１４１９は、読み取りデータがＲＤＭＡされるアドレスに設定され、ＤａｔａＭｈ１４２１は、関連のメモリハンドルに設定される。

非ポーリングの場合、ＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１４２３およびＣｏｏｋｉｅ１４２５は、クライアント指定の値に設定される。サーバは、この場合、通常の送信を介してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで、または読み取りが成功した場合、即値データによりＲＤＭＡで読み取り要求を完了することができる。ＲＤＭＡ書き込みの即値データは、それに応じて読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に設定される。ポーリングの場合、ＩｏｓＶａ１４３１は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１４２９は、関連のメモリハンドルに設定される。

非ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答することができ、またはサーバは、即値データをＲＤＭＡ読み取りデータとともに送信することができる。この場合即値データは、読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に送信される。図１４Ｂは、本発明の一実施形態において、非ポーリングの場合にサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１４３３の表現例を示している。

Ｉｎｆｏｒｍａｔｉｏｎ１４３７は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１４３９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１４３５は、読み取りメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。

ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをクライアントにＲＤＭＡする。図１４Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１４４１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１４４３は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１４４５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。

書き込み
書き込みメッセージは、ファイル登録中に交換された特定のＦｉｄにデータを入れるために使用される。すべての書き込みデータは、通常の送信操作を使用して送信される。書き込まれるデータ量は、サーバのＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅによって限定される。クライアントがこれより多くのデータを送信すると、接続が中断される。

図１５Ａおよび図１５Ｃは、本発明の一実施形態においてクライアントによって送信される書き込みメッセージの表現例を示しており、図１５Ａは非ポーリングの場合、図１５Ｃはポーリングの場合を示している。書き込みメッセージ１５０１は、共通ヘッダ１５０３を含む。Ｌｅｎｇｔｈ１５０５は、書き込まれるデータのバッファ数に設定される。０Ｏｐｃｏｄｅ１５０７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＷＲＩＴＥ（０×１）に設定される。Ｏｆｆｓｅｔ１５１７は、ファイルデータの書き込みを開始するバイト位置に設定される。Ｆｌａｇ１５０９、１５２９は、ポーリングの場合１５２９では０×０に設定され、非ポーリングの場合１５０９ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｍａｒｋｅｒ１５１３は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１５１１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１５１５は、Ｉ／Ｏを発行するＦｉｌｅ Ｉｄに設定される。書き込まれるデータ１５２７は、書き込みメッセージの共通ヘッダ１５０３のすぐ次に来る。

非ポーリングの場合、Ｃｏｏｋｉｅ１５２５は、クライアント指定の値に設定される。ポーリングの場合、ＩｏｓＶａ１５３３は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１５３１は、関連のメモリハンドルに設定される。

非ポーリングの場合、サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで書き込みメッセージに応答する。図１５Ｂは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１５３５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１５３９は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１５４１は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１５３７は、書き込みメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。ポーリングの場合、サーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１５Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１５４３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１５４５は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１５４７は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。

ベクトル化読み取り
ベクトル化読み取りは、登録段階中に交換された特定のＦｉｄからデータを取得し、データをページごとに要求側の複数のセグメントに分散するために使用される。読み取られたすべてのデータは、読み取りセグメントごとにサーバから１つのＲＤＭＡ書き込みを介して要求側に送信される。ディスクから読み取られたデータは連続している。読み取られたデータ量は、単一の要求で記載することができる最大数の宛先ページによって限定される。この限定は、ｓｉｚｅｏｆ（ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮ）によって分割されるサーバＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅである。ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮの構造を以下に示す。

図１６Ａおよび図１６Ｃは、本発明の一実施形態においてクライアントによって送信されるベクトル化読み取りメッセージの表現例を示しており、図１６Ａは非ポーリングの場合、図１６Ｃはポーリングの場合を示している。読み取りメッセージ１４０１は、共通ヘッダ１６０３、次いで１つまたは複数のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント１６０５、１６０７を含む。ヘッダ１６０３の中のＬｅｎｇｔｈ１６０９は、ファイルから読み取られるデータのバイト数に設定される。Ｏｐｃｏｄｅ１６１１はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＶＥＣ＿ＲＥＡＤ（０×２）に設定される。Ｏｆｆｓｅｔ１６２１は、ファイルデータの読み取りを開始するバイト位置に設定される。Ｆｌａｇ１６１３、１６３１は、ポーリングの場合１６３１では０×０に設定され、非ポーリングの場合１６１３ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｍａｒｋｅｒ１６１７は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１６１５は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１６１９は、Ｉ／Ｏを発行するＦｉｌｅ Ｉｄに設定される。Ｎｕｍｐａｇｅｓ１６２３は、共通ヘッダ１６０３に続くＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮの数に設定される。ＰａｇｅＳｉｚｅ１６２５はローカルページサイズにバイト単位で設定される。

非ポーリングの場合、ＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１６２７およびＣｏｏｋｉｅ１６２９は、クライアント指定の値に設定される。サーバは、この場合、通常の送信を介してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで、または読み取りが成功した場合は即値データによりＲＤＭＡでベクトル化読み取り要求を完了することができる。ＲＤＭＡ書き込みの即値データは、それに応じて読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１６２７値に設定される。ポーリングの場合、ＩｏｓＶａ１６３５は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１６３３は、関連のメモリハンドルに設定される。

共通ヘッダ１６０３のすぐ次に十分な数のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント１６０５、１６０７が続き、要求の長さをカバーする。中間セグメントのサイズは、すべて１ページとすべきである。最後のセグメントは１つのページより小さくてもよいが、バックエンドディスクセクタサイズ（ｂａｃｋｅｎｄ ｄｉｓｋ ｓｅｃｔｏｒ ｓｉｚｅ）の倍数とする必要がある。本発明の一実施形態では、ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮ構造は、次のフォーマットを有する。

第１のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮは、読み取られる第１のＰａｇｅＳｉｚｅバイトに対応し、第２のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮは、読み取られる第２のＰａｇｅＳｉｚｅバイトに対応し、以下同様である。ＤａｔａＶａ１６３７は、読み取りデータが入れられるページの先頭を示す位置に設定される。ＤａｔａＭｈ１６３９は、ＤａｔａＶａ１６３７のメモリハンドルに設定される。Ｌｅｎｇｔｈ１６４１は、最後の領域を除くすべての領域についてＰａｇｅＳｉｚｅ１６２５に設定される。最後の領域は、Ｌｅｎｇｔｈは小さくてもよいが、バックエンドディスクセクタサイズの倍数とする必要がある。

非ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答することができ、またはサーバは、即値データをＲＤＭＡ読み取りデータとともに送信することができる。この場合即値データは、読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に送信される。図１６Ｂは、本発明の一実施形態において、非ポーリングの場合にサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１６４３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１６４７は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１６４９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１６４５は、ベクトル化読み取りメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。

ポーリングの場合、サーバはまず、読み取りデータをＲＤＭＡし、次いでＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１６Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１６５１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１６５３は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１６５５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。

ベクトル化書き込み
ベクトル化書き込みメッセージは、ファイル登録中に交換された特定のＦｉｄへの収集的な書き込み（ｇａｔｈｅｒ ｗｒｉｔｅ）を行うために使用される。すべての書き込みデータは、通常の送信操作を使用して送信される。書き込まれるデータ量は、サーバのＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅによって限定される。クライアントがこれより多くのデータを送信すると、接続が中断される。

図１７Ａ、図１７Ｂ、図１７Ｃは、本発明の一実施形態におけるクライアントによって送信されるベクトル化書き込みメッセージの表現例を示しており、図１７Ａは、非ポーリング、非折りたたみの場合、図１７Ｂは、非ポーリング、折りたたみの場合、および図１７Ｃはポーリング、折りたたみの場合を示している。

書き込みメッセージ１７０１は、共通ヘッダ１７０３、次いで書き込まれるデータ１７０５を含む。共通ヘッダ１７０３の中のＬｅｎｇｔｈ１７０７は、書き込まれるデータのバイト数に設定される。Ｏｐｃｏｄｅ１７０９はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＷＲＩＴＥ（０×３）に設定される。Ｏｆｆｓｅｔ１７１９は、ファイルデータの書き込みを開始するバイト位置に設定される。Ｍａｒｋｅｒ１７１５は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１７１３は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１７１７は、Ｉ／Ｏを発行するＦｉｌｅ Ｉｄに設定される。

Ｆｌａｇ１７１１、１７２１、１７２７は、ポーリング１７２７を示す０×０に設定され、そうでない場合はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）１７１１に設定される。後者の場合、フラグは、書き込み内のすべてのページが同じデータを含み、従ってデータの単一ページのみが送信されたことを示すためにＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＬＬＡＰＳＥ１７２１を含むことができる。これは、冗長データの転送を最低限に抑えるための最適化である。ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＬＬＡＰＳＥは、登録されたファイルフラグがＦＩＬＥ＿ＮＯ＿ＩＮＴＥＲＭＥＤＩＡＴＥ＿ＢＵＦＦＥＲＩＮＧ（０×８）を含み、認証段階中に交換されたＰａｇｅＳｉｚｅが偶数による互いの倍数である場合にのみ使用することができる。折りたたみされたＩ／Ｏの場合、ＮｕｍＰａｇｅｓ１７２３は、Ｉ／Ｏがまたがるデータのページ数に設定される。最後のページは、Ｌｅｎｇｔｈパラメータのために部分的である場合がある。ＰａｇｅＳｉｚｅ１７２５はローカルページサイズにバイト単位で設定される。ポーリングの場合、ＩｏｓＶａ１７３１は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定される。ＩｏｓＭｈ１７２９は、関連のメモリハンドルである。

非ポーリングの場合、非折りたたみおよび折りたたみのＩ／Ｏの両方で、サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで書き込みメッセージに応答する。

図１７Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１７３３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１７３７は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１７３９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１７３５は、書き込みメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。

ポーリングの場合、非折りたたみおよび折りたたみのＩ／Ｏの両方で、サーバはＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１７Ｅは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１７４１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１７４３は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１７４５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。

結論
本発明の実施形態の例を示し、説明してきたが、本発明から逸脱することなく様々な変更を加えることができることを理解されたい。同様に、本明細書に記載した任意のプロセスステップを他のステップと交換して同じ結果を達成することができる。さらに、上述した例は、網羅的なものではなく、開示された正確なフォーマットに本発明を限定するためのものでもない。むしろ、本発明は、本発明が意図する特許請求の範囲内に含まれるすべての変更、変形、構成、および均等物をカバーするものとする。

本発明の態様を組み込むことができる、ＲＤＭＡ転送を介して通信することができる２つのコンピュータを含む典型的なクライアント−サーバコンピューティング環境を示す概略図である。 本発明の一実施形態によるＬＷＩＯプロトコルの発見段階において行われる最初のステップを示す概略流れ図である。 本発明の一実施形態による典型的なサーバ要求レジュームキーの表現を示す概略図である。 本発明の一実施形態による典型的なクライアント交渉要求メッセージの表現を示す概略図である。 本発明の一実施形態による典型的なサーバ交渉応答の表現を示す概略図である。 本発明の一実施形態によるＬＷＩＯプロトコルの発見段階において行われる追加のステップを示す概略流れ図である。 本発明の一実施形態による典型的なクライアント認証要求メッセージの表現を示す概略図である。 本発明の一実施形態による典型的なサーバ認証応答の表現を示す概略図である。 本発明の一実施形態による認証を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態による典型的なクライアントファイル登録メッセージの表現を示す概略図である。 本発明の一実施形態によるファイル登録を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態によるポーリングモードおよび非ポーリングモードにおいてＩ／Ｏ要求の完了に関して行われるステップを示す概略流れ図である。 本発明の一実施形態による典型的なクライアント割り込み要求メッセージの表現を示す概略図である。 本発明の一実施形態による割り込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一態様によるサーバ−クライアントクレジットトランザクションに関して行われるステップを示す概略流れ図である。 本発明の一実施形態による典型的なサーバデルタクレジットメッセージの表現を示す概略図である。 本発明の一実施形態による典型的なクライアントからサーバへのクレジットメッセージの表現を示す概略図である。 本発明の一実施形態によるクレジット−サーバクレジットトランザクションを完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態による典型的なクライアント終了要求メッセージの表現を示す概略図である。 本発明の一実施形態による終了要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態による典型的なクライアントキャンセル要求メッセージの表現を示す概略図である。 本発明の一実施形態によるキャンセル要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合の典型的なクライアント読み取り要求メッセージの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合の読み取り要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合の典型的なクライアント読み取り要求メッセージの表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合の読み取り要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合の典型的なクライアント書き込み要求メッセージの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合の書き込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合の典型的なクライアント書き込み要求メッセージの表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合の書き込み要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合の典型的なクライアントベクトル化読み取り要求メッセージの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合のベクトル化読み取り要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合の典型的なクライアントベクトル化読み取り要求メッセージの表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合のベクトル化読み取り要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。 本発明の一実施形態による、非ポーリングモードで折りたたみされていない場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。 本発明の一実施形態による、非ポーリングモードで折りたたみされた場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。 本発明の一実施形態による、ポーリングモードで折りたたみされた場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。 本発明の一実施形態による非ポーリングモードの場合のベクトル化書き込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。 本発明の一実施形態によるポーリングモードの場合のベクトル化書き込み要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。

符号の説明

１０１ ホストＡ
１０３ ＬＷＩＯクライアント
１０５ カーネルモード読み取り／書き込み
１０７ バッファ
１０９ ＲＤＭＡ対応ＮＩＣ
１１１ ＲＤＭＡ対応ＮＩＣ
１１３ ＮＩＣ
１１７ ＲＤＭＡチャネル
１１９ 非ＲＤＭＡネットワークリンク
１２１ ホストＢ
１２３ ＬＷＩＯサーバ
１２５ ＳＭＢサーバ
１２７ バッファ
１２９ ＮＴＦＳ
１３１ リードディスク
１３３ ＮＩＣ
１３５ ＲＤＭＡ対応ＮＩＣ
１３７ ＲＤＭＡ対応ＮＩＣ
２１９ サーバ要求レジュームキー
２３１ 交渉要求パケット
２３３ 制御ヘッダ
２４１ プロバイダのリスト
２５７ インスタンステーブル
２６７ 交渉応答
２６９ 制御ヘッダ
２７９ プロバイダリスト
６１７ 認証メッセージ
６１９ 共通ヘッダ
６２１ ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造
６５９ ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造
６８９ サーバ認証完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
７０１ 登録メッセージ
７０３ 共通ヘッダ
７０５ ＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造
７２３ サーバ登録完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
８１５ 共通ヘッダ
８２５ サーバ割り込み完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０１１ ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０１９ ＣＲＥＤＩＴメッセージ
１０２１ 共通ヘッダ
１０３３ サーバクレジット完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０４１ 終了メッセージ
１０４３ 共通ヘッダ
１０５５ サーバ終了完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０６３ キャンセルメッセージ
１０６５ 共通ヘッダ
１０７７ サーバキャンセル完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１４０１ 読み取りメッセージ
１４０３ 共通ヘッダ
１４３３ 読み取り完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１４４１ 読み取り完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１５０１ 書き込みメッセージ
１５０３ 共通ヘッダ
１５３５ 書き込み完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１５４３ 書き込み完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１６０３ 共通ヘッダ
１６０５ ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント
１６０７ ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント
１６４３ ベクトル化完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１６５１ ベクトル化完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１７０１ 書き込みメッセージ
１７０３ 共通ヘッダ
１７０５ 書き込まれるデータ
１７３３ クライアントＶＥＣ書き込み完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１７４１ クライアントＶＥＣ書き込み完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ

Claims (20)

1. 入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードするシステムであって、前記システムは、
   前記第１のコンピュータ上で稼働するクライアントと、
   前記第２のコンピュータ上で稼働するサーバと、
   前記第１のコンピュータと前記第２のコンピュータとをリンクする少なくとも１つのＲＤＭＡチャネルと
   を備え、
   前記第１のコンピュータおよび前記２のコンピュータは、
   ネットワーク発見段階であって、
   前記クライアントが、共有のＲＤＭＡ対応プロバイダを介した前記サーバへのＲＤＭＡ接続を生成すること、
   前記クライアントおよび前記サーバが、前記ＲＤＭＡ接続を相互に認証すること、
   前記サーバが、前記サーバのバッファの状況を表すクレジット要求メッセージを送信することであって、前記バッファの状況は、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求を処理する前記サーバの可用性に対応し、前記クレジット要求メッセージは、複数のフィールドから成る第１のフィールドを含み、前記第１のフィールドは、前記サーバが前記サーバの可用性に基づきこれ以上Ｉ／Ｏ要求を処理できない場合は前記クライアントが捨てるべきクレジットの数を表す負の値を、前記サーバが前記サーバの可用性に基づき前記クライアントからのさらなるＩ／Ｏ要求を受け入れることができる場合は前記サーバが前記クライアントによる使用のために新たに割り振ったクレジットの数を表す正の値を含み、前記クレジットは、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求の数に対応すること、
   前記クライアントが、前記クレジット要求メッセージを受信すること、および
   前記クライアントが前記クレジット要求メッセージを受信することに応答して、前記クライアントから前記サーバに、前記クレジット要求メッセージ中の前記第１のフィールドが前記正の値を含む場合は第１の指標を、前記クレジット要求メッセージ中の前記第１のフィールドが前記負の値を含む場合は少なくとも１つの第２の指標を送信することであって、前記第１の指標は、前記クライアントが使用した新たに割り振られたクレジットのうちの少なくとも１つを前記サーバに通知し、各第２の指標は、前記クライアントが解放した各クレジットに対応し、各第２の指標は、各第２の指標内の複数のフィールドから成る第２のフィールドのオフセット内にクレジットの解放値を含み、前記クレジットの解放値は、各第２の指標により前記負の値の大きさを減少させることで、解放できるクレジットの残りの量と関連付けられており、前記第２のフィールドのオフセットは、前記クレジットの解放値を３２ビット表現で伝達することができること
   を行うように構成されるネットワーク発見段階ならびに
   前記サーバにオフロードされる前記Ｉ／Ｏ要求を処理するよう構成されるＩ／Ｏ処理段階であって、前記Ｉ／Ｏ処理段階の読み取り操作は、ＲＤＭＡ操作を使用して実施され、前記Ｉ／Ｏ処理段階の書き込み操作は、送信操作を使用して実施され、前記書き込み操作は、前記ＲＤＭＡ操作を使用して実施されないＩ／Ｏ処理段階
   を含むプロトコルに従って通信することを特徴とするシステム。
2. 前記プロトコルは、ＳＭＢ（Server Message Block）と共に使用されることを特徴とする請求項１に記載のシステム。
3. 前記プロトコルは、ＣＩＦＳ(Common Internet File System)と共に使用されることを特徴とする請求項１に記載のシステム。
4. 入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードするシステムで使用するためのコンピュータプログラムを含むコンピュータ実行可能命令およびコンピュータ可読データを格納するコンピュータ可読媒体であって、前記システムは
   前記第１のコンピュータと前記第２のコンピュータとをリンクする少なくとも１つのＲＤＭＡチャネルを含み、
   前記第１のコンピュータおよび前記２のコンピュータは、
   ネットワーク発見段階であって、
   前記クライアントが、共有のＲＤＭＡ対応プロバイダを介した前記サーバへのＲＤＭＡ接続を生成すること、
   前記クライアントおよび前記サーバが、前記ＲＤＭＡ接続を相互に認証すること、
   前記サーバが、前記サーバのバッファの状況を表すクレジット要求メッセージを送信することであって、前記バッファの状況は、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求を処理する前記サーバの可用性に対応し、前記クレジット要求メッセージは、複数のフィールドから成る第１のフィールドを含み、前記第１のフィールドは、前記サーバが前記サーバの可用性に基づきこれ以上Ｉ／Ｏ要求を処理できない場合は前記クライアントが捨てるべきクレジットの数を表す負の値を、前記サーバが前記サーバの可用性に基づき前記クライアントからのさらなるＩ／Ｏ要求を受け入れることができる場合は前記サーバが前記クライアントによる使用のために新たに割り振ったクレジットの数を表す正の値を含み、前記クレジットは、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求の数に対応すること、
   前記クライアントが、前記クレジット要求メッセージを受信すること、および
   前記クライアントが前記クレジット要求メッセージを受信することに応答して、前記クライアントから前記サーバに、前記クレジット要求メッセージ中の前記第１のフィールドが前記正の値を含む場合は第１の指標を、前記クレジット要求メッセージ中の前記第１のフィールドが前記負の値を含む場合は少なくとも１つの第２の指標を送信することであって、前記第１の指標は、前記クライアントが使用した新たに割り振られたクレジットのうちの少なくとも１つを前記サーバに通知し、各第２の指標は、前記クライアントが解放した各クレジットに対応し、各第２の指標は、各第２の指標内の複数のフィールドから成る第２のフィールドのオフセット内にクレジットの解放値を含み、前記クレジットの解放値は、各第２の指標により前記負の値の大きさを減少させることで、解放できるクレジットの残りの量と関連付けられており、前記第２のフィールドのオフセットは、前記クレジットの解放値を３２ビット表現で伝達することができること
   を行うように構成されるネットワーク発見段階ならびに
   前記サーバにオフロードされる前記Ｉ／Ｏ要求を処理するよう構成されるＩ／Ｏ処理段階であって、前記Ｉ／Ｏ処理段階の読み取り操作は、ＲＤＭＡ操作を使用して実施され、前記Ｉ／Ｏ処理段階の書き込み操作は、送信操作を使用して実施され、前記書き込み操作は、前記ＲＤＭＡ操作を使用して実施されないＩ／Ｏ処理段階
   を含むプロトコルに従って通信することを特徴とするコンピュータ可読媒体。
5. 入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードする方法であって、前記方法は、
   前記第１のコンピュータ上のクライアントおよび前記第２のコンピュータ上のサーバによって少なくとも１つの共有のＲＤＭＡ対応プロバイダを発見するステップであって、
   前記クライアントが、前記少なくとも１つの共有のＲＤＭＡ対応プロバイダを介した前記サーバへのＲＤＭＡ接続を生成するステップ、
   前記クライアントおよび前記サーバが、前記ＲＤＭＡ接続を相互に認証するステップ、
   前記サーバが、前記サーバのバッファの状況を表すクレジット要求メッセージを送信するステップであって、前記バッファの状況は、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求を処理する前記サーバの可用性に対応し、前記クレジット要求メッセージは、複数のフィールドから成る第１のフィールドを含み、前記第１のフィールドは、前記サーバが前記サーバの可用性に基づきこれ以上Ｉ／Ｏ要求を処理できない場合は前記クライアントが捨てるべきクレジットの数を表す負の値を、前記サーバが前記サーバの可用性に基づき前記クライアントからのさらなるＩ／Ｏ要求を受け入れることができる場合は前記サーバが前記クライアントによる使用のために新たに割り振ったクレジットの数を表す正の値を含み、前記クレジットは、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求の数に対応するステップ、
   前記クライアントが、前記クレジット要求メッセージを受信するステップ、および
   前記クライアントが前記クレジット要求メッセージを受信するステップに応じて、前記クライアントから前記サーバに、前記クレジット要求メッセージ中の前記第１のフィールドが前記正の値を含む場合は第１の指標を、前記クレジット要求メッセージ中の前記第１のフィールドが前記負の値を含む場合は少なくとも１つの第２の指標を送信するステップであって、前記第１の指標は、前記クライアントが使用した新たに割り振られたクレジットのうちの少なくとも１つを前記サーバに通知し、各第２の指標は、前記クライアントが解放した各クレジットに対応し、各第２の指標は、各第２の指標内の複数のフィールドから成る第２のフィールドのオフセット内にクレジットの解放値を含み、前記クレジットの解放値は、各第２の指標により前記負の値の大きさを減少させることで、解放できるクレジットの残りの量と関連付けられており、前記第２のフィールドのオフセットは、前記クレジットの解放値を３２ビット表現で伝達することができるステップ
   を含む前記発見するステップならびに
   前記クライアントによって前記第２のコンピュータ上の前記サーバによる完了を求める前記クライアントからオフロードされる前記Ｉ／Ｏ処理要求を送るステップであって、読み取り操作は、ＲＤＭＡ操作を使用して実施され、書き込み操作は、送信操作を使用して実施され、前記書き込み操作は、前記ＲＤＭＡ操作を使用して実施されないステップ
   を含むことを特徴とする方法。
6. 少なくとも１つの共有のＲＤＭＡ対応プロバイダを発見する前記ステップは、
   前記クライアントによって前記サーバからサーバ要求レジュームキーを取得するステップと、
   前記クライアントによって前記サーバへのパイプを開くステップと、
   前記クライアントによって前記パイプを介して交渉要求を送信するステップと、
   前記サーバによって前記パイプを介して共通プロバイダの最小リストを含む交渉応答を送信するステップと
   をさらに含むことを特徴とする請求項５に記載の方法。
7. 前記クライアントによって、前記ＲＤＭＡ接続を介して、使用する１つまたは複数のファイルを前記サーバに登録するステップ
   をさらに含むことを特徴とする請求項５に記載の方法。
8. 少なくとも１つのファイルを登録する前記ステップは、
   前記クライアントによって前記サーバにファイル登録メッセージを送信するステップと、
   前記サーバによって前記クライアントにファイル登録完了メッセージを送信するステップと
   を含むことを特徴とする請求項７に記載の方法。
9. 前記ＲＤＭＡ接続を認証する前記ステップは、
   前記クライアントによって前記サーバにキーを含む認証要求メッセージを送信するステップと、
   前記キーが前記サーバから前記クライアントに送信された以前のキーと一致する場合、前記サーバによって前記クライアントに認証応答メッセージを送信するステップと
   をさらに含むことを特徴とする請求項５に記載の方法。
10. 前記以前のキーは前記サーバから前記クライアントに送信された交渉応答メッセージ内に含まれるキーであることを特徴とする請求項９に記載の方法。
11. 前記サーバによって前記クライアントに、前記認証ステップを完了するために状況応答メッセージを送信するステップ
    をさらに含むことを特徴とする請求項９に記載の方法。
12. 前記Ｉ／Ｏ処理要求を送る前記ステップは、前記クライアントによって（ａ）終了要求、（ｂ）キャンセル要求、（ｃ）読み取り要求、（ｄ）書き込み要求、（ｅ）ベクトル化読み取り要求、および（ｆ）ベクトル化書き込み要求のうちの１つを送信するステップを含むことを特徴とする請求項５に記載の方法。
13. 前記サーバによって、ＲＤＭＡ書き込み操作を使用してデータを送信することによって前記読み取り要求および前記ベクトル化読み取り要求を完了するステップと、
    前記サーバによって、通常の送信操作を使用してデータを送信することによって前記書き込み要求および前記ベクトル化書き込み要求を完了するステップと
    をさらに含むことを特徴とする請求項１２に記載の方法。
14. 前記ベクトル化書き込み要求は、前記要求のヘッダ内に折りたたみフラグを含むことを特徴とする請求項１２に記載の方法。
15. 前記Ｉ／Ｏ処理要求を送る前記ステップは、前記サーバによる前記完了がポーリングモードであるかどうかを示すステップをさらに含むことを特徴とする請求項５に記載の方法。
16. 前記完了がポーリングモードであるかどうかを示す前記ステップは、前記Ｉ／Ｏ処理要求のヘッダ内に割り込みフラグを設定することによって前記完了がポーリングモードではないことを示すステップを含むことを特徴とする請求項１５に記載の方法。
17. 前記クライアントが非ポーリングモードでの前記完了を指示した場合、前記サーバによって、ＲＤＭＡ転送を介して状況ブロックを前記第１のコンピュータに送信することによって前記Ｉ／Ｏ処理要求を完了するステップ
    をさらに含むことを特徴とする請求項１５に記載の方法。
18. 前記クライアントがポーリングモードでの前記完了を指示し、前記クライアントが割り込み要求メッセージを前記サーバに送信した場合、前記サーバによって前記クライアントに通常の送信を介して割り込み応答メッセージを送信するステップ
    をさらに含むことを特徴とする請求項１５に記載の方法。
19. 前記Ｉ／Ｏ処理要求を送るステップは、前記要求のヘッダ内にいくつかのクレジットを指定するステップをさらに含むことを特徴とする請求項５に記載の方法。
20. 入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードする方法を実施するコンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記コンピュータ実行可能命令により実行される前記方法は、
    前記第１のコンピュータ上のクライアントおよび前記第２のコンピュータ上のサーバによって、少なくとも１つの共有のＲＤＭＡ対応プロバイダを発見するステップと、
    前記第１のコンピュータが、サーバ要求レジュームキーを要求するステップと、
    前記第２のコンピュータが、前記サーバ要求レジュームキーを認証機構として渡すステップであって、前記サーバ要求レジュームキーを要求するステップと前記サーバ要求レジュームキーを渡すステップとは、
    前記クライアントが、前記少なくとも１つの共有のＲＤＭＡ対応プロバイダを介した前記サーバへのＲＤＭＡ接続を生成するステップ、
    前記クライアントおよび前記サーバが、前記ＲＤＭＡ接続を相互に認証するステップ、
    前記サーバが、前記サーバのバッファの状況を表すクレジット要求メッセージを送信するステップであって、前記バッファの状況は、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求を処理する前記サーバの可用性に対応し、前記クレジット要求メッセージは、複数のフィールドから成る第１のフィールドを含み、前記第１のフィールドは、前記サーバが前記サーバの可用性に基づきこれ以上Ｉ／Ｏ要求を処理できない場合は前記クライアントが捨てるべきクレジットの数を表す負の値を、前記サーバが前記サーバの可用性に基づき前記クライアントからのさらなるＩ／Ｏ要求を受け入れることができる場合は前記サーバが前記クライアントによる使用のために新たに割り振ったクレジットの数を表す正の値を含み、前記クレジットは、前記クライアントが前記サーバへオフロードしようとするＩ／Ｏ要求の数に対応するステップ、
    前記クライアントが、前記クレジット要求メッセージを受信するステップ、
    前記クライアントが前記クレジット要求メッセージを受信するステップに応じて、前記クライアントから前記サーバに、前記クレジット要求メッセージ中の前記第１のフィールドが前記正の値を含む場合は第１の指標を、前記クレジット要求メッセージ中の前記第１のフィールドが前記負の値を含む場合は少なくとも１つの第２の指標を送信するステップであって、前記第１の指標は、前記クライアントが使用した新たに割り振られたクレジットのうちの少なくとも１つを前記サーバに通知し、各第２の指標は、前記クライアントが解放した各クレジットに対応し、各第２の指標は、各第２の指標内の複数のフィールドから成る第２のフィールドのオフセット内にクレジットの解放値を含み、前記クレジットの解放値は、各第２の指標により前記負の値の大きさを減少させることで、解放できるクレジットの残りの量と関連付けられており、前記第２のフィールドのオフセットは、前記クレジットの解放値を３２ビット表現で伝達することができるステップ
    を含むステップと、
    前記クライアントによって前記第２のコンピュータ上の前記サーバによる完了を求める前記クライアントからオフロードされる前記Ｉ／Ｏ処理要求を送るステップであって、読み取り操作は、ＲＤＭＡ操作を使用して実施され、書き込み操作は、送信操作を使用して実施され、前記書き込み操作は、前記ＲＤＭＡ操作を使用して実施されないステップと
    を含むことを特徴とするコンピュータ可読媒体。

Images