(57)【要約】  ＲＤＭＡ（リモートダイレクトメモリアクセス）対応ネットワーク相互接続を使用して、Ｉ／Ｏ処理を第１のコンピュータから第２のコンピュータにオフロードするための方法およびシステムを提供する。この方法およびシステムは、第１のコンピュータ上のクライアントがＲＤＭＡ接続を介してライトウエイト入力／出力（ＬＷＩＯ）プロトコルを介して第２のコンピュータ上のサーバと通信するステップを含む。このプロトコルは一般に、ネットワーク発見段階、続いてＩ／Ｏ処理段階を含む。この発見段階中、クライアントおよびサーバは、共有のＲＤＭＡ対応プロバイダの最小リストを割出しする。Ｉ／Ｏ処理段階中、クライアントは、互いに認証されたＲＤＭＡチャネルを介してオフロードを求めるＩ／Ｏ要求を第２のマシンに送る。Ｉ／Ｏモデルは非対称であり、読み取り操作はＲＤＭＡを使用して実施され、書き込み操作は通常の送信を使用して実施される。読み取り要求および書き込み要求は、ポーリングモードおよび割り込みモードで完了することができる。バッファは、クレジット機構を介して管理される。
2007527057.tif 000002
【特許請求の範囲】
【請求項１】
入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードするシステムであって、
前記第１のコンピュータ上で稼働するクライアントと、
前記第２のコンピュータ上で稼働するサーバと、
前記第１のコンピュータと前記第２のコンピュータとをリンクする少なくとも１つのＲＤＭＡチャネルとを含み、前記第１のコンピュータおよび前記２のコンピュータは、ネットワーク発見段階およびＩ／Ｏ処理段階を含むプロトコルに従って通信する
ことを特徴とするシステム。
【請求項２】
前記Ｉ／Ｏ処理段階において、読み取り操作はＲＤＭＡ（リモートダイレクトメモリアクセス）を使用して実施され、書き込み操作は送信操作を使用して実施されることを特徴とする請求項１に記載のシステム。
【請求項３】
前記プロトコルは第２のネットワークプロトコルとともに使用されることを特徴とする請求項１に記載のシステム。
【請求項４】
前記第２のプロトコルはＳＭＢ（Server Message Block）であることを特徴とする請求項３に記載のシステム。
【請求項５】
前記第２のプロトコルはＣＩＦＳ(Common Internet File System)であることを特徴とする請求項３に記載のシステム。
【請求項６】
入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードするシステムで使用するためのコンピュータプログラムを含むコンピュータ実行可能命令およびコンピュータ可読データを格納するコンピュータ可読媒体であって、前記システムは
前記第１のコンピュータと前記第２のコンピュータとをリンクする少なくとも１つのＲＤＭＡチャネルを含み、前記第１のコンピュータおよび前記２のコンピュータは、ネットワーク発見段階およびＩ／Ｏ処理段階を含むプロトコルに従って通信する
ことを特徴とするコンピュータ可読媒体。
【請求項７】
入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードする方法であって、
前記第１のコンピュータ上のクライアントおよび前記第２のコンピュータ上のサーバによって１つまたは複数の共有のＲＤＭＡ対応プロバイダを発見するステップと、
前記クライアントによって前記第２のコンピュータ上の前記サーバによる完了を求めるＩ／Ｏ処理要求を送るステップと
を含むことを特徴とする方法。
【請求項８】
１つまたは複数の共有のＲＤＭＡ対応プロバイダを発見する前記ステップは、
前記クライアントによって前記サーバからサーバ要求レジュームキーを取得するステップと、
前記クライアントによって前記サーバへのパイプを開くステップと、
前記クライアントによって前記パイプを介して交渉要求を送信するステップと、
前記サーバによって前記パイプを介して共通プロバイダの最小リストを含む交渉応答を送信するステップと
をさらに含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記クライアントによって共有のＲＤＭＡ対応プロバイダを介した前記サーバへのＲＤＭＡ接続を設けるステップと、
前記クライアントおよび前記サーバによって前記ＲＤＭＡ接続を認証するステップと
をさらに含むことを特徴とする請求項７に記載の方法。
【請求項１０】
前記クライアントによって、前記ＲＤＭＡを介して、使用する１つまたは複数のファイルを前記サーバに登録するステップ
をさらに含むことを特徴とする請求項９に記載の方法。
【請求項１１】
１つまたは複数のファイルを登録する前記ステップは、
前記クライアントによって前記サーバにファイル登録メッセージを送信するステップと、
前記サーバによって前記クライアントにファイル登録完了メッセージを送信するステップと
を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ＲＤＭＡ接続を認証する前記ステップは、
前記クライアントによって前記サーバにキーを含む認証要求メッセージを送信するステップと、
前記キーが前記サーバから前記クライアントに送信された以前のキーと一致する場合、前記サーバによって前記クライアントに認証応答メッセージを送信するステップと
をさらに含むことを特徴とする請求項９に記載の方法。
【請求項１３】
前記以前のキーは前記サーバから前記クライアントに送信された交渉応答メッセージ内に含まれるキーであることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記サーバによって前記クライアントに、前記認証ステップを完了するために状況応答メッセージを送信するステップ
をさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記Ｉ／Ｏ処理要求を送る前記ステップは、前記クライアントによって（ａ）終了要求、（ｂ）キャンセル要求、（ｃ）読み取り要求、（ｄ）書き込み要求、（ｅ）ベクトル化読み取り要求、および（ｆ）ベクトル化書き込み要求のうちの１つを送信するステップを含むことを特徴とする請求項７に記載の方法。
【請求項１６】
前記サーバによって、ＲＤＭＡ書き込み操作を使用してデータを送信することによって前記読み取り要求および前記ベクトル化読み取り要求を完了するステップと、
前記サーバによって、通常の送信操作を使用してデータを送信することによって前記書き込み要求および前記ベクトル化書き込み要求を完了するステップと
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ベクトル化書き込み要求は前記要求のヘッダ内に折りたたみフラグを含むことを特徴とする請求項１５に記載の方法。
【請求項１８】
前記Ｉ／Ｏ処理要求を送る前記ステップは、前記サーバによる前記完了がポーリングモードであるかどうかを示すステップをさらに含むことを特徴とする請求項７に記載の方法。
【請求項１９】
前記完了がポーリングモードであるかどうかを示す前記ステップは、前記Ｉ／Ｏ処理要求のヘッダ内に割り込みフラグを設定することによって前記完了がポーリングモードではないことを示すステップを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記クライアントが非ポーリングモードでの前記完了を指示した場合、前記サーバによって、ＲＤＭＡ転送を介して状況ブロックを前記第１のコンピュータに送信することによって前記Ｉ／Ｏ処理要求を完了するステップ
をさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２１】
前記クライアントがポーリングモードでの前記完了を指示し、前記クライアントが割り込み要求メッセージを前記サーバに送信した場合、前記サーバによって前記クライアントに通常の送信を介して割り込み応答メッセージを送信するステップ
をさらに含むことを特徴とする請求項１８に記載の方法。
【請求項２２】
前記Ｉ／Ｏ処理要求を送るステップは、前記要求のヘッダ内にいくつかのクレジットを指定するステップをさらに含むことを特徴とする請求項７に記載の方法。
【請求項２３】
入力／出力（Ｉ／Ｏ）タスクを第１のコンピュータから第２のコンピュータにオフロードする方法を実施するコンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記方法は
前記第１のコンピュータ上のクライアントおよび前記第２のコンピュータ上のサーバによって、１つまたは複数の共有のＲＤＭＡ対応プロバイダを発見するステップと、
前記クライアントによって前記第２のコンピュータ上の前記サーバによる完了を求めるＩ／Ｏ処理要求を送るステップと
を含むことを特徴とするコンピュータ可読媒体。
【請求項２４】
入力／出力オフロードプロトコルにおいてバッファを管理する方法であって、
サーバによってクライアントにクレジットの数に設定された情報フィールドを含むデルタクレジットメッセージを送信するステップであって、前記数が負の数−Ｎである場合、前記サーバは前記クライアントにＮ個のクレジットを廃棄するよう要求するステップと、
前記クレジットの数が負の数−Ｎである場合、前記クライアントによって前記サーバにＮ個のクレジットメッセージを送信し、そうでない場合、前記クライアントによって前記サーバに１つのクレジットメッセージを送信するステップと、
前記クライアントによって送信されたクレジットメッセージごとに、前記サーバによって前記クライアントに状況応答メッセージを送信するステップと
を含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、リモートファイルアクセスのシステムおよび方法に関し、より詳細には、リモートダイレクトメモリアクセス（遠隔直接記憶呼出し：ＲＤＭＡ）を使用して入力／出力処理をオフロードする技術に関する。
【背景技術】
【０００２】
コンピューティング環境では、一般に乏しいＣＰＵリソース（資源）を節約することが望ましい。アプリケーションサーバノードのネットワークなど、こうした一部の環境では、こうした節約は特に重要である。ネットワークが速くなるにつれて、パケットを処理し、Ｉ／Ｏ（入力／出力）操作を実行させるためのＣＰＵに対する需要がより多くなり、その結果、アプリケーションパフォーマンス（実行）が遅くなる。このことは、データベースのように本質的にＩ／Ｏを集中的に行うアプリケーションには特に不利である。
【０００３】
この問題を改善する１つの手法は、ＣＰＵから過度のＩ／Ｏおよびネットワーク処理をオフロードする（取り外す）ことである。ネットワーク環境では、ＮＦＳやＳＭＢ／ＣＩＦＳなど、分散されたファイルシステムおよび転送プロトコルを使用することによって、Ｉ／Ｏ要求をローカルマシンからリモートマシン（遠隔地の装置）に送信することができる。しかし、こうした手法を使用することによって、ローカルマシンの処理の大幅な節約を達成できるとは限らない。
【０００４】
単一のマシンの操作状況（context）では、Ｉ／Ｏタスクを直接メモリアクセス（ＤＭＡ）コントローラへオフロードすることによって、Ｉ／Ｏ処理の負荷を軽減することができる。リモートダイレクトメモリアクセス（ＲＤＭＡ）技術とは、ネットワーク接続された複数のコンピュータ用にごく最近開発されたＤＭＡの拡張機能である。ＲＤＭＡは、ソースまたは宛先のマシンのＣＰＵおよびオペレーティングシステムの関与を必要とせずに、ＲＤＭＡ対応ネットワークインターフェイスカード（ＮＩＣ）を備えていて、通信している２つのマシンのメモリバッファ間でのデータの移動を許容する。ＲＤＭＡを使用してＩ／Ｏ処理をリモートマシンへオフロードし、それによってローカルマシンは、ＣＰＵサイクルをアプリケーションのために再利用することができるようになる。ＲＤＭＡは、仮想インターフェイスアーキテクチャ（ＶＩＡ）、ＩｎｆｉｎｉＢａｎｄ(インフィニバンド)、ｉＷａｒｐ（アイワープ）などの、高速、高帯域の相互接続技術で活用されてきている。これらの相互接続は、特に、データセンタ、または他のローカルのファイル共有環境内のサーバノードのクラスタ間の高信頼性ネットワーク接続用に設計されている。
【０００５】
ローカルのオフロード側ノードとリモートマシンとの間の通信を定義するプロトコルは、ＲＤＭＡ技術に関連付けられている機能が十分に使用され、それらの利点が有効に得られるように設計されなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、本発明によるライトウエイト（ライトウエイト）入力／出力（ＬＷＩＯ）プロトコルが必要とされている。
【課題を解決するための手段】
【０００７】
本発明の一態様によれば、Ｉ／Ｏタスクを第１のコンピュータから第２のコンピュータにオフロードするシステムが提供される。このシステムは、第１のコンピュータ上で稼働するクライアント、および第２のコンピュータ上で稼働するサーバを含む。システムは、第１のコンピュータと第２のコンピュータとをリンクする１つまたは複数のＲＤＭＡチャネルをさらに含む。クライアントおよびサーバは、ネットワーク発見段階およびＩ／Ｏ処理段階を含むＬＷＩＯプロトコルに従って通信する。ＬＷＩＯプロトコルは、ＳＭＢ／ＣＩＦＳなど別のネットワークプロトコルとともに使用され、第２のプロトコルのセキュリティおよび認証インフラストラクチャを活用することができる。よりよいセキュリティモデルを提供するために、このプロトコルでのＩ／Ｏモデルは非対称であり、読み取りはＲＤＭＡを使用して実施され、書き込みは送信操作を使用して実施される。
【０００８】
本発明の別の態様によれば、Ｉ／Ｏタスクを第１のコンピュータから第２のコンピュータにオフロードする方法が提供される。この方法は、２つのコンピュータ上の共通のＲＤＭＡ対応通信装置を使用し、ライトウエイト入力／出力（ＬＷＩＯ）クライアント−サーバプロトコルに関連付けられる。プロトコルは一般に、発見段階、続いてＩ／Ｏ処理段階を含む。この発見段階中、クライアントおよびサーバは、共有のＲＤＭＡ対応プロバイダの最小リストを割出しする。Ｉ／Ｏ処理段階中、クライアントは、オフロードを求めるＩ／Ｏ要求を第２のマシンに送る。
【０００９】
発見段階中、クライアントは、最初にサーバからサーバ要求レジュームキー（ｓｅｒｖｅｒ  ｒｅｑｕｅｓｔ  ｒｅｓｕｍｅ  ｋｅｙ）を取得する。次いでクライアントは、サーバへのパイプを開き、それを介して第１のマシン上のＲＤＭＡ対応プロバイダのリストを含む交渉要求を送信する。サーバは、第１のマシン上のプロバイダと一致する第２のマシン上の使用可能なプロバイダのリストを含む交渉応答を、そのパイプを介して送信する。次いでクライアントは、共有のプロバイダを介したサーバへのＲＤＭＡ接続を設ける。クライアントおよびサーバは、新しい接続を互いに認証する。次いでクライアントは、使用する１つまたは複数のファイルをサーバに登録する。
【００１０】
Ｉ／Ｏ処理要求メッセージは、終了メッセージ、キャンセルメッセージ、読み取りメッセージ、書き込みメッセージ、ベクトル化読み取りメッセージ（ｖｅｃｔｏｒｅｄ  ｒｅａｄ  ｍｅｓｓａｇｅ）、ベクトル化書き込みメッセージ（ｖｅｃｔｏｒｅｄ  ｗｒｉｔｅ  ｍｅｓｓａｇｅ）を含む。プロトコルは、安全上の理由から、非対称のＩ／Ｏモデルを特徴とする。読み取りデータは、ＲＤＭＡ書き込み操作を使用してクライアントに送信され、書き込みは、通常の送信を使用して完了される。読み取り要求および書き込み要求は、サーバによってポーリングモードまたは割り込みモードで完了されるようにクライアントによって指定することができる。クライアントが非ポーリングモードでの完了を指示した場合、サーバは、ＲＤＭＡ転送を介して状況ブロックを第１のコンピュータに送信することによってＩ／Ｏ処理要求を完了する。クライアントがポーリングモードでの完了を指示した場合、クライアントは、割り込み要求メッセージを介してＩ／Ｏの完了後にサーバによって起動されることを要求することができる。
【００１１】
本発明の別の態様によれば、Ｉ／Ｏオフロードプロトコルでバッファを管理する方法が提供される。この方法は、バッファクレジット機構（ｂｕｆｆｅｒ  ｃｒｅｄｉｔ  ｍｅｃｈａｎｉｓｍ）の使用を伴う。サーバ−クライアントクレジットトランザクションは、サーバによって開始され、完了される３方向ハンドシェイクを含む。サーバは、いくつかのクレジットに設定された情報フィールドを含めて、デルタクレジット（ｄｅｌｔａ  ｃｒｅｄｉｔ）メッセージをクライアントに送信する。その数が負の数−Ｎである場合、クライアントはＮ個のクレジットを捨てる必要がある。
【００１２】
本発明の他の態様は、コンピュータプログラムおよびデータ構造としてコンピュータ可読媒体に組み込まれた上記の特徴を含む。
【００１３】
特許請求の範囲には本発明の特徴を詳しく記載しているが、本発明、並びにその目的および効果は、以下の詳細な説明を添付の図面と併せ読むことによって最もよく理解することができる。
【発明を実施するための最良の形態】
【００１４】
本発明のいくつかの実施形態を、図１〜図１７Ｅを参照して以下で説明する。しかし、これらの図に関して本明細書に示した詳細な説明は例示のためのものであり、本発明はこれらの実施形態を超えて広がることを当業者は容易に理解されよう。
【００１５】
図１は、本発明の態様を組み込むことができる代表的なネットワーク式クライアント／サーバ環境のいくつかの特徴をおおまかに示す概略図である。図１には、ホストＡ１０１およびホストＢ１２１とラベル付けされた２つのコンピュータマシンを示している。本発明は異なる多くのタイプおよび使用のコンピュータを含む環境で実施することができるが、１つの代表的なシナリオでは、ホストＡ１０１は、データベースサーバなど、Ｉ／Ｏを集中的に行う作業が課せられるアプリケーションサーバマシンとして働く。
【００１６】
ホストＡ１０１およびホストＢ１２１のそれぞれは、一方のマシンから他方のマシンへのネットワーク式データ通信を許可するいくつかのネットワークインターフェイスカード（ＮＩＣ）１０９、１１１、１１３、１３３、１３５、１３７を含む。これらのＮＩＣのうち、ＲＤＭＡデータ転送を可能にするのはＮＩＣ１０９、１１１、１３５、１３７である。示したように、非ＲＤＭＡネットワークリンク１１９およびＲＤＭＡチャネル１１７が２つのホスト１０１と１２１との間に存在している。
【００１７】
ホストＡ１０１では、カーネルモードＩ／Ｏ読み取り／書き込みサービス１０５と対話する、Ｉ／Ｏタスクの処理の責任を負うアプリケーションに関連付けられているＬＷＩＯクライアントアプリケーション１０３が実行されている。ＬＷＩＯクライアント１０３は、Ｉ／Ｏ処理をホストＡ１０１からホストＢ１２１にオフロードするために使用される。ホストＢ１２１では、ＬＷＩＯサーバ１２３が実行されている。本明細書に記載したＬＷＩＯプロトコルによれば、ＬＷＩＯクライアント１０３は、ＬＷＩＯサーバ１２３と通信する。ＬＷＩＯクライアント１０３およびＬＷＩＯサーバ１２３は、送られたバッファ１０７、１２７を使用して、ファイル関連のデータを、ＲＤＭＡチャネル接続１１７を介して直接転送することができる。読み取りタスクおよび書き込みタスクは、ＬＷＩＯプロトコルメッセージを介して、ホストＢ１２１にオフロードされる。サーバ１２３は、ハードディスク１３１へのインターフェイスとして働くファイルシステム１２９にＩ／Ｏ要求を伝える。
【００１８】
一般に、ＲＤＭＡ接続１１７には２種類のメッセージが関連付けられている。第１のタイプは、宛先マシンで割り込みを生成する通常のネットワーク送信／受信である。第２のタイプはＲＤＭＡ読み取り／書き込みであり、リモートＣＰＵの援助無しに、従って割り込みを生成する必要なく、リモートマシン上のメモリ空間へのアクセスが行われる。リモートＣＰＵは、ＲＤＭＡのために公開されたメモリ領域を割出しするが、一般にはＲＤＭＡ操作がいつ実行されるかを知らない。
【００１９】
本明細書に記載した本発明の一実施形態では、ＬＷＩＯプロトコルは、別のプロトコルの既存のセキュリティおよび認証のインフラストラクチャを利用できるように、ＳＭＢやＣＩＦＳなど別のネットワークプロトコルとともに使用される。これは、ＬＷＩＯプロトコルのオーバーヘッドを最低限に抑えるのを助ける。図１に示すように、ホストＢ１２１上のＬＷＩＯサーバ１２３は、ＳＭＢサーバ１２５の上で動作する。同様にＳＭＢクライアント（図示せず）もホストＡ１０１上で稼働し、ＬＷＩＯクライアントアプリケーション１０３と対話する。
【００２０】
ＬＷＩＯプロトコルは、発見段階（discovery phase）、次いでＩ／Ｏ段階(I/O phase)の２段階を含む。本明細書に記載した実施形態に関連付けられているデータ構造では、データサイズは次の通りである。
【００２１】
【表１】
2007527057.tif 000003
【００２２】
図２は、本発明の一実施形態におけるＬＷＩＯプロトコルの発見段階で行われるステップを示している。ＬＷＩＯサーバが実行されているホストに関して、ステップ２０１で、ＬＷＩＯサーバをそのホストマシン上で稼働しているＳＭＢ／ＣＩＦＳサーバに登録する。この登録に従って、ステップ２０３で、ＳＭＢ／ＣＩＦＳサーバは、リモートホスト上で稼働しているＳＢＭ／ＣＩＦＳクライアントに、ＬＷＩＯサーバが使用可能であることを通知する。ステップ２０５で、ＬＷＩＯクライアントは、サーバ要求レジュームキーを要求する。再開キーとは認証機構であり、これについては、本出願と同じ譲受人を有する別の出願、すなわち、参照により本明細書に組み込まれている「Method and System for Accessing a File (Resume Key)」という名称の２００３年１０月２４日に出願した米国特許出願第 号の明細書に開示されている。
【００２３】
ステップ２０７で、ＬＷＩＯサーバは、サーバ要求レジュームキーをクライアントに返す。本発明の一実施形態では、サーバ要求レジュームキーは、次の構造を有する。
【００２４】
【表２】
2007527057.tif 000004
【００２５】
図３は、サーバ要求レジュームキー２１９の表現例を提示する。ＲｅｓｕｍｅＫｅｙ（レジュームキー）２２１、Ｔｉｍｅｓｔａｍｐ（タイムスタンプ）２２３、およびＰｉｄ（ピッド）２２５は、サーバ上で生成され、クライアントからは見えない。Ｃｏｎｔｅｘｔ(コンテキスト)２２９は、サーバに連絡するためにＬＷＩＯクライアントによって使用されるＵＮＣ名を含むアレイである。ＣｏｎｔｅｘｔＬｅｎｇｔｈ（コンテキストレングス）２２７は、Ｃｏｎｔｅｘｔ２２９におけるバイト数である。
【００２６】
ネットワークの発見
クライアントアプリケーションは、サーバ要求レジュームキー２１９を受信すると、コンテキストフィールド２２９からサーバＵＮＣ名を取り出す。図２に戻って、ステップ２０９で、クライアントはＬＷＩＯサーバへのパイプを開く。パイプは、以下でさらに詳しく説明するように、ネットワークで使用可能なＲＤＭＡ対応装置を自動的に発見するために使用される。これは本発明の重要かつ有用な特徴であり、一般にＶＩＡネットワークおよび同様のネットワークには、ＡＲＰのようなアドレス解決機構がない。
【００２７】
次にクライアントは、サーバに対して、ＬＷＩＯプロトコルとともに使用可能なそのＲＤＭＡ対応装置（「プロバイダ」）のリストについての照会を行う。照会は、クライアントが構築し、ステップ２１１で新しく開かれたパイプを介してサーバに送信する交渉（ネゴシエーション）要求を介して達成される。本発明の一実施形態では、交渉要求は、次の構造を有する。
【００２８】
【表３】
2007527057.tif 000005
【００２９】
図４Ａは、本発明の一実施形態による交渉要求パケット２３１の表現例を示す。交渉要求は、制御ヘッダ２３３、固定長Ｕｎｉｃｏｄｅ（ユニコード）クライアント名フィールド２３５、キーとして使用されるクライアントＵＵＩＤ２３７、応答を受信するローカルバッファサイズ２３９、およびプロバイダのリスト２４１を含む。制御ヘッダ２３３には、Ｐｒｏｔｏｃｏｌ(プロトコル)Ｉｄ「ＬＷＩＯ」２４３がヘッダの最初の４バイトとして格納されている。
【００３０】
ＲｅｖＩｄ２４５は、現在定義されている値０ｘ１００１、ＬＷＩＯ＿ＲＥＶ＿ＩＤを保持する。Ｏｐｃｏｄｅ２４７は、現在定義されている値０ｘｆｅ、ＬＷＩＯ＿ＣＯＮＴＲＯＬ＿ＯＰＣＯＤＥ＿ＮＥＧＯＴＩＡＴＥを保持する。Ｌｅｎｇｔｈ（レングス）２４９は、すべての演算コード固有のデータを含めて、サーバに送信される完全なパケットのバイト単位のサイズである。
【００３１】
ＣｌｉｅｎｔＮａｍｅ（クライアントネーム）２３５は、サーバがクライアントを識別するために使用する。Ｋｅｙ（キー）２３７は、後述するように、その後のネットワーク固有の認証手順で使用される。ＲｅｓｐｏｎｓｅＬｅｎｇｔｈ（レスポンスレングス）２３９は、後述するように、サーバからの交渉応答を受信するバッファのサイズである。ＰｒｏｖｉｄｅｒＣｏｕｎｔ（プロバイダカウント）２５１は、クライアントマシンに関連付けられているプロバイダの数であり、クライアントはそれについてサーバに知らせている。プロバイダリスト２４１は、ＰｒｏｖｉｄｅｒＣｏｕｎｔプロバイダのリストを含む。
【００３２】
プロバイダリスト２４１の要素の中のＮａｍｅ（ネーム）２５３はプロバイダの名前である。互換性のあるネットワークを検出するために、クライアントおよびサーバは、同じ名前を同じプロバイダに使用することが好ましい。ＩｎｓｔａｎｃｅＣｏｕｎｔ（インスタンスカウント）２５５は、特定のプロバイダタイプの装置数である。インスタンステーブル２５７は、ネットワーク／識別子の対のテーブルであり、１対は、装置固有の方法で、リモート接続をどのように形成するかを説明するよう働く。ＨｏｓｔＡｄｄｒｅｓｓＬｅｎ（ホストアドレスレン）２５９は、ネットワーク固有のホストアドレス２６３の長さである。ＤｉｓｃｒｉｍｉｎａｔｏｒＬｅｎ（ディスクリミネータレン）２６１は、ネットワーク固有の識別子２６５の長さである。これらの長さフィールドに続いて、ＨｏｓｔＡｄｄｒｅｓｓＬｅｎバイトのホストアドレス２６３、およびＤｉｓｃｒｉｍｉｎａｔｏｒＬｅｎバイトの識別子２６５がある。
【００３３】
図２に戻ると、クライアントのプロバイダのリストを含む交渉要求を受信すると、ステップ２１３で、サーバは、クライアントと共通するＲＤＭＡ対応通信装置を割出しする。ステップ２１５で、サーバは、共有プロバイダのリストを含めて、交渉応答をパイプを介してクライアントに送信する。本発明の一実施形態では、交渉応答は、次の構造を有する。
【００３４】
【表４】
2007527057.tif 000006
【００３５】
図４Ｂは、本発明の一実施形態による交渉応答２６７の表現例を示す。制御ヘッダ２６９は、ここではＬｅｎｇｔｈ（レングス）２７１が応答メッセージ２６７のサイズを反映することを除いて、交渉要求のものと同様である。ＳｒｖＮａｍｅ（サーバネーム）２７３は、サーバ名を保持する。Ｋｅｙ（キー）２７５は、クライアントによって使用するためのサーバ生成ＧＵＩＤである。以下でさらに説明するように、クライアントは、このＫｅｙを、共通の通信装置のうちの１つを使用する新しい接続を介して認証要求でサーバに返送する。ＰｒｏｖｉｄｅｒＣｏｕｎｔ（プロバイダカウント）２７７は、プロバイダリスト２７９内のプロバイダ数である。プロバイダリスト２７９は、サーバおよびクライアントに共通のプロバイダのリストを含む。クライアントが実際にこれらのプロバイダに接続することができるという保証はない。
【００３６】
図２に戻ると、この時点で、サーバおよびクライアントは通信装置情報を共有しており、共通プロバイダの最小リストが割出しされている。ステップ２１７で、クライアントは、共有の装置のうちの１つまたは複数を介したＬＷＩＯサーバへの１つまたは複数のＲＤＭＡ接続を設ける。本発明の一実施形態では、本明細書に記載するように、クライアントからサーバへの通信には次の演算コードが定義される。
【００３７】
【表５】
2007527057.tif 000007
【００３８】
クライアントからサーバへの通信では、次の定義されたフラグが変更子（modifier）として使用される。
【００３９】
【表６】
2007527057.tif 000008
【００４０】
ＬＷＩＯプロトコルでの対応するクライアントからサーバへのメッセージは、共通のヘッダ構造を特徴とする。本発明の一実施形態では、共通ヘッダは以下のフォーマットを有する。
【００４１】
【表７】
2007527057.tif 000009
【００４２】
接続の認証
図５は、ＬＷＩＯプロトコルの最初の段階の残りの間に本発明の一実施形態においてクライアントおよびサーバによって行われるステップを示している。ステップ６０１で、クライアントは、上述したように、共有の通信装置を介してサーバへの接続を確立する。ここでクライアントおよびサーバは、新しい接続を互いに認証する。ステップ６０３で、クライアントは、認証要求メッセージ（ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＡＵＴＨ）をサーバに送信する。サーバ側およびクライアント側のスプーフィングを防ぐために認証が行われる。認証がタイムリーに完了しない場合、接続が中断される。
【００４３】
図６Ａは、本発明の一実施形態によるクライアント認証要求メッセージの表現例を示す。認証メッセージ６１７は、共通ヘッダ６１９、次いでＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造６２１を含む。ヘッダ６１９の中のＬｅｎｇｔｈ（レングス）６２３は、サーバに送信されるバイト数（共通ヘッダ６１９のサイズプラスＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１のサイズ）に設定される。Ｏｐｃｏｄｅ（オプコード）６２５はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＡＵＴＨ（０ｘ６）に設定される。Ｆｌａｇｓ(フラッグス)６２７はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴに設定される。Ｃｏｏｋｉｅ（クッキー）６２９は、これおよび他のクライアントプロトコルメッセージでは、クライアントによって選択された値に送信され、サーバの応答で返送される。Ｃｏｏｋｉｅ値は一般に、要求をサーバの応答に一致させるために使用される。ＤａｔａＶａ（データＶａ）６３１は、サーバがサーバ認証パラメータにＲＤＭＡすべきアドレスに設定される。ＤａｔａＭｈ（データＭｈ）６３３は、ＤａｔａＶａ６３１に関連付けられているＲＤＭＡメモリハンドルを保持する。
【００４４】
本発明の一実施形態では、ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造は、次のフォーマットを有する。
【００４５】
【表８】
2007527057.tif 000010
【００４６】
認証メッセージ６１７の中のＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１は、パケットの第２の部分を形成する。Ｍａｇｉｃ(マジック)６３５は「ＬＷＩＯ」に設定される。ＲｅｖＩｄ６３７はＬＷＩＯ＿ＲＥＶ＿ＩＤに設定される。Ｅｎｄｉａｎ（エンディアン）６３９はｓｉｚｅｏｆ（ＵＬＯＮＧ＿ＰＴＲ）に設定される。ＰａｇｅＳｉｚｅ（ページサイズ）６４１は、ＣＰＵページサイズ（３２ビットマシンでは４ｋ、６４ビットマシンでは８ｋ）に設定される。ＢａｓｅＳｅｑｕｅｎｃｅ（ベースシーケンス）６４３は０に設定される。ＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅ（マックスＲＤＭＡウインドウサイズ）６４５は、クライアントがＲＤＭＡ転送で受け入れることができる最大バイト数に設定されるものとし、図に描いた実施形態では、６４ｋに設定される。ＭａｘＳｅｎｄＢｕｆｆｅｒＳｉｚｅ(マックスセンドバッファサイズ)６４７は、単一の要求でクライアントがサーバに送信することができるバイト数に設定されるものとし、図に描いた実施形態では、１ｋに設定される。ＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅ(マックスレシーブバッファサイズ)６４９は、サーバからデータを受信するためにクライアントが送ったバイト数に設定されるものとし、図に描いた実施形態では、１６バイトに設定される。ＨｅａｄｅｒＳｉｚｅ（ヘッダサイズ）６５１は、ＬＷＩＯ制御ヘッダ６１９でのバイト数に設定される。Ｃｒｅｄｉｔｓ（クレジット）６５２は、クライアントが有したい最初のバッファクレジット数に設定される。クレジットの使用については、以下でさらに説明する。サーバは、クライアントの要求を満たしても満たさなくてもよい。ＲｄｍａＲｅａｄＳｕｐｐｏｒｔｅｄ（ＲＭＡＤＡリードサポーテッド）６５３は、クライアントがＲＤＭＡ読み取り操作をサポートしていない場合は０に設定され、クライアントがＲＤＭＡ読み取り操作をサポートしている場合は１に設定される。
【００４７】
ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造の一部は、１つまたは複数の選択肢の組である。選択肢は、認証をより柔軟にするために使用される。各選択肢は、選択肢のリストを終了させるヌルの選択肢として働く、選択肢コードのみを有するリスト内の最後の選択肢ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＥＮＤ以外は、選択肢コード、長さ、およびデータを有する。認証メッセージでは、クライアントはサーバに、Ｋｅｙ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＫＥＹ）およびＳｉｇｎａｔｕｒｅ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＩＧＮＡＴＵＲＥ）の選択肢を送信する。Ｋｅｙ（キー）６５５は、交渉応答でサーバによって以前返されたＫｅｙに設定される。Ｓｉｇｎａｔｕｒｅ（シグネチャ）６５７は、署名なしのＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ６２１のＭＤ５署名である。
【００４８】
図５に戻って、ステップ６０５で、認証メッセージで送信されたＫｅｙがパイプを介して交渉応答で返されたキーに一致する場合、サーバは、クライアントによって認証メッセージで提供されたＤａｔａＶａアドレス、および関連のＤａｔａＭｈメモリハンドル宛てに、認証応答として、８バイトのＳｅｓｓｉｏｎＩｄ（セッションＩｄ）を含むＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造をクライアントにＲＤＭＡ（リモートダイレクトメモリアクセス）する。ステップ６０７で、サーバは認証を完了するためにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥを送信する。
【００４９】
図６Ｂは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造６５９の表現例を示している。Ｍａｇｉｃ（マジック）６６１は「ＬＷＩＯ」に設定される。ＲｅｖＩｄ６６３はＬＷＩＯ＿ＲＥＶ＿ＩＤに設定される。Ｅｎｄｉａｎ（エンディアン）６６５はｓｉｚｅｏｆ（ＵＬＯＮＧ＿ＰＴＲ）に設定される。ＰａｇｅＳｉｚｅ（ページサイズ）６６７はＣＰＵページサイズに設定される。ＢａｓｅＳｅｑｕｅｎｃｅ（ベースシーケンス）６６９は、（クライアントＢａｓｅＳｅｑｕｅｎｃｅ＋１）に設定されるものとする。ＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅ（マックスＲＤＭＡウインドウサイズ）６７１は、クライアントがＲＤＭＡ転送で受け入れることができる最大バイト数に設定されるものとし、図に描いた実施形態では、５１２ｋに設定される。ＭａｘＳｅｎｄＢｕｆｆｅｒＳｉｚｅ（マックスセンドバッファサイズ）６７３は、単一の応答でサーバがクライアントに送信するバイト数に設定されるものとし、図に描いた実施形態では、１６バイトに設定される。ＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅ（マックスＲＥＣＶバッファサイズ）６７５は、クライアントからデータを受信するためにサーバが事前に送ったバイト数に設定されるものとし、図に描いた実施形態では、８ｋに設定される。ＨｅａｄｅｒＳｉｚｅ（ヘッダサイズ）６７７は、共通のヘッダにおけるバイト数に設定される。Ｃｒｅｄｉｔｓ（クレジット）６７９は、サーバがクライアントに使用可能な最初のクレジット数に設定される。ＲｄｍａＲｅａｄＳｕｐｐｏｒｔｅｄ（ＲＤＭＡリードサポーテッド）６８１は、サーバがＲＤＭＡ読み取りをサポートしていない場合は０に設定され、サーバがＲＤＭＡ読み取りをサポートしている場合は１に設定される。サーバは、Ｋｅｙ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＫＥＹ）６８３、ＳｅｓｓｉｏｎＩｄ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＥＳＳＩＯＮ＿ＩＤ）６８５、およびＳｉｇｎａｔｕｒｅ（ＬＷＩＯ＿ＡＵＴＨ＿ＯＰＴＩＯＮ＿ＳＩＧＮＡＴＵＲＥ）６８７の選択肢を送信する。Ｋｅｙ（キー）６８３は、交渉要求でクライアントが前もって送信したＫｅｙに設定される。ＳｅｓｓｉｏｎＩｄ（セッションＩＤ）６８５値は、後述するように、クライアントファイルをサーバに登録する際にクライアントによって使用される。Ｓｉｇｎａｔｕｒｅ（シグネチャ）６８７は、署名なしのＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳのＭＤ５署名である。
【００５０】
本発明の一実施形態では、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ構造は、次のフォーマットを有する。
【００５１】
【表９】
2007527057.tif 000011
【００５２】
図６Ｃは、本発明の一実施形態において認証を完了させるためにサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ６８９の表現例を示している。Ｃｏｏｋｉｅ６９１は、認証メッセージのヘッダ内のクライアントによって設定されたクッキー値に設定される。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）６９３は、ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳプラス８バイトのバイト数に設定される。Ｓｔａｔｕｓ（ステータス）６９５は、０ｘ０（成功を示す）または０ｘＣ０００００２２（「アクセス拒否」を示す）に設定される。
【００５３】
ファイル登録
図５に戻って、ステップ６０９で、新しい接続がクライアントおよびサーバによって互いに認証されると、クライアントは、使用するファイルのサーバへの登録を開始する。ファイルのファイル操作は、クライアントが使用するファイルをサーバに登録するまで、リンクを介して処理されない。
【００５４】
図７Ａは、本発明の一実施形態によるクライアントからサーバに送信されるファイル登録メッセージの表現例を示している。登録メッセージ７０１は、共通ヘッダ７０３、次いでＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造７０５を含む。Ｌｅｎｇｔｈ（レングス）７０７は、サーバに送信されるバイト数（ヘッダ７０３のサイズプラスＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ７０５のサイズ）に設定される。Ｏｐｃｏｄｅ（オプコード）７０９はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＧＩＳＴＥＲ（０×７）に設定される。Ｆｌａｇｓ(フラッグス)７１１はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴに設定される。このクライアントメッセージおよびその後のクライアントメッセージでは、Ｃｒｅｄｉｔｓ（クレジット
）７１３は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｒｅｄｉｔｓフィールドは、より多くのクレジットを接続に割り振ることについてのサーバへのヒントとしての役割を果たし、従って以下でさらに説明するように、追加の未解決のＩ／Ｏ要求を許可する。１回の未解決のクライアント要求の数が「Ｃｒｅｄｉｔｓ」値を超えることはできない。上述したように、Ｃｏｏｋｉｅ（クッキー）７１５は、クライアント指定の値に設定される。
【００５５】
本発明の一実施形態では、ＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造は、次のフォーマットを有する。
【００５６】
【表１０】
2007527057.tif 000012
【００５７】
ファイル登録メッセージ７０１のＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ７０５では、ＲｅｓｕｍｅＫｅｙ(レジュームキー)７１７は、最初のファイルアクセスチャネルを介して返されたサーバ要求レジュームキーに設定される。ＳｅｓｓｉｏｎＩｄ（セッションＩｄ）７１９は、接続認証段階中、サーバによって返されたＳｅｓｓｉｏｎＩｄに設定される。ＦｌａｇｓＡｎｄＡｔｔｒｉｂｕｔｅｓ（フラッグスアンドアンドリブーツ）７２１は、最初にファイルを開くために使用されるＷｉｎ３２  Ｃｒｅａｔｅ  Ｆｌａｇｓに設定される。
【００５８】
図５に戻って、ステップ６１１で、サーバはファイル登録を完了するためにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答する。図７Ｂは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ７２３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）７２７は、Ｉ／Ｏ要求を送信するときに使用されるＦｉｄ（ＦｉｌｅＩＤ）に設定される。Ｓｔａｔｕｓ（ステータス）７２９は、０×０（成功）、または失敗時は別のＮＴＳＴＡＴＵＳコードに設定される。Ｃｏｏｋｉｅ（クッキー）７２５は、ファイル登録メッセージのヘッダ内にクライアントが設定したクッキー値に設定される。
【００５９】
Ｉ／Ｏ処理
この時点で、クライアント接続が確立され、ファイルが登録されており、ＬＷＩＯプロトコルのＩ／Ｏ処理段階が開始する。ＬＷＩＯプロトコルの実施形態の１つの重要な特徴は、読み取りおよび書き込みについての非対称のＩ／Ｏモデルである。読み取り操作はＲＤＭＡを使用して実施され、書き込みは送信操作を使用して実施される。より良いセキュリティモデルを提供するように、書き込みの実施にはＲＤＭＡは使用されない。サーバがＲＤＭＡのためにＮＩＣ（ネットワークインターフェイスカード）を介してそのアドレス空間を公開すると、悪意のあるクライアントによって悪用されるおそれのあるデータ破損の脆弱性がもたらされる。このシナリオでは、悪意のあるクライアントは、ループ内で所与のサーバ仮想アドレスに対するＲＤＭＡ書き込み操作を発行する。サーバアドレス空間は有限であり、ある時点でサーバ仮想アドレスを再利用しなければならないため、悪意のあるクライアントは、最終的に、異なる接続に同じ仮想アドレスを使用するサーバをつかまえ、異なるクライアントに関連付けられている可能性のあるサーババッファにデータが書き込まれてしまう。ＬＷＩＯプロトコルでの非対称のＩ／Ｏモデルは、この可能性を防ぐ。この特徴は、ＬＷＩＯプロトコルと、ＤＡＦＳ（Direct Access File System）などの他のＲＤＭＡベースのファイル転送プロトコルとの間の主な違いである。
【００６０】
図５に戻って、ステップ６１３で、クライアントはＩ／Ｏ処理要求を送り始める。サーバからクライアントへのＩ／Ｏ要求の完了は、非ポーリングモードまたはポーリングモードのいずれかで行われる。非ポーリングモードでは、Ｉ／Ｏの完了は、通常の送信／受信メッセージを使用した割り込みベースである。ポーリングモードでは、Ｉ／Ｏの完了は、ＲＤＭＡを使用し、割り込みベースではない。
【００６１】
図８の流れ図は、ＬＷＩＯサーバからの一般的な観点から、ポーリングモードまたは非ポーリングモードでのＩ／Ｏ要求の完了に関して本発明の一実施形態で行われるステップをおおまかに示している。クライアントＩ／Ｏ要求は、サーバが送信後（ｐｏｓｔ−ｓｅｎｄ）メッセージ（ＣＰＵの割り込み）またはＲＤＭＡメッセージを返送するべきかどうかを指定する。ステップ８０１で、サーバは、ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴフラグがクライアントＩ／Ｏ要求メッセージの共通ヘッダに設定されているかどうかを割出しする。このフラグが設定されている場合、ステップ８０３で、サーバは、通常の送信を使用してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥを介してクライアント要求を完了する。ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴフラグが設定されていない場合（ポーリングモード）、ステップ８０５で示すように、サーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをクライアントにＲＤＭＡすることによってクライアント要求を完了する。
【００６２】
ポーリングモードでのクライアントの起動
ポーリングモードでは、クライアントは、サーバからのＩ／Ｏの完了を待つ間スリープしたい場合がある。この場合の完了はＲＤＭＡを介してクライアントに送信されるため、クライアントを起動させて、完了が行われたことをクライアントに通知する機構が必要となる。クライアントは、起動したい場合、図８のステップ８０７でサーバによって受信された割り込み要求（ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＩＮＴＥＲＲＵＰＴ）メッセージをサーバに送信する。割り込み要求を受信するサーバは、サーバにおいてＩ／Ｏ要求が完了する（ステップ８０９）まで応答を送信しない。完了は、ステップ８１１で、通常の送信を介してクライアントに送信され、クライアントに割り込みがかかる。所与のクライアント接続について、未解決とすることができる割り込みメッセージは１つのみである。
【００６３】
図９Ａは、本発明の一実施形態においてクライアントからサーバに送信される割り込み要求メッセージの表現例を示している。メッセージは、共通ヘッダ８１５を含んでいる。Ｏｐｃｏｄｅ(オプコード)８１７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＧＩＳＴＥＲ（０×９）に設定される。Ｆｌａｇｓ（フラッグス）８１９は（ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ｜ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＮＴＲＯＬ）（０×Ｃ０）に設定される。Ｃｒｅｄｉｔｓ(クレジット)８２１は、クライアント上の保留中のＩ／Ｏ要求の数に設定され、Ｃｏｏｋｉｅ(クッキー)８２３は、クライアント指定の値に設定される。
【００６４】
サーバは、別のＩ／Ｏ要求が処理された後、割り込み要求メッセージに応答する。図９Ｂは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージ８２５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）８２７は０に設定される。Ｓｔａｔｕｓ（ステータス）８２９は、０×０（成功）、または失敗時は別のＮＴＳＴＡＴＵＳコードに設定される。Ｃｏｏｋｉｅ８３１は、クライアントによって送信された割り込み要求のヘッダ内のＣｏｏｋｉｅ値に設定される。
【００６５】
クレジット
上述したように、すべてのクライアントからサーバへのＩ／Ｏ要求は、ヘッダ内にクレジットフィールドを含んでいる。クレジットフィールドは、クライアントがサーバに送信したい未解決のＩ／Ｏ要求の数に関するサーバへのヒントである。クレジットを管理するのはサーバの責任である。クレジットは、バッファのフラッシュの問題に新しい解決策を提供する。クライアントが現在Ｎ個のクレジットを有している場合、サーバがクライアントにクレジットメッセージを送信するには、Ｎ＋１個の受信バッファを送る必要がある。サーバは、クライアント接続に沿って未解決のクレジット要求を常に１つだけ有する。クレジットメッセージは常に、割り込みモードで送信される。
【００６６】
クレジットトランザクションは、クライアントとサーバとの間のサーバが開始する３方向のハンドシェイクを含む。図１０は、本発明の一実施形態におけるクレジットトランザクションを含むステップをおおまかに示している。ステップ１００１で、サーバは、デルタクレジット要求メッセージを、クライアント接続に沿って送信する。
【００６７】
図１１Ａは、本発明の一実施形態によるサーバデルタクレジットメッセージの表現例を示す。このメッセージは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０１１の形をとる。クレジットはバッファに対応する。Ｉｎｆｏｒｍａｔｉｏｎ（インフォメーション）１０１３は、クライアントが捨てるべき（負の数）クレジットの数、またはクライアントの使用のためにサーバが新しく割り振った（正の数）クレジットの数（余分なバッファ）に設定される。Ｓｔａｔｕｓ（ステータス）１０１５は、ＬＷＩＯ＿ＮＯＴＩＦＹ＿ＣＲＥＤＩＴ（０×１）に設定される。Ｃｏｏｋｉｅ（クッキー）１０１７は０に設定される。
【００６８】
図１０に戻って、クライアントは、サーバからクレジットメッセージを受信する。クライアントは、同じ接続で、サーバに対してＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴで応答する必要がある。このメッセージは、単一のクレジットの解放、またはクライアントが使用した新しく割り振られたクレジットの数のサーバへの通知のいずれかを指定する。サーバクレジットメッセージ内のＩｎｆｏｒｍａｔｉｏｎフィールドが負の数−Ｎを含んでいる場合（ステップ１００３）、ステップ１００５で示すように、クライアントは、Ｎ個のＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージ（捨てる必要があるのはクレジットごとに１つ）を送信する。情報フィールドが正である場合、ステップ１００７で示すように、クライアントは、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージを１つだけ送信する。
【００６９】
図１１Ｂは、本発明の一実施形態においてクライアントによって送信されるＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージの表現例を示している。ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージ１０１９は、共通ヘッダ１０２１を含む。Ｏｐｃｏｄｅ１０２３は、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴ（０×８）に設定される。Ｆｌａｇｓ１０２５はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０２７は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０３１はクライアント指定の値に設定される。クライアントが正のデルタクレジットメッセージを受信した場合、Ｏｆｆｓｅｔ（オフセット）１０２９の上位３２ビットは、クレジットが使用しなかった、サーバによって割り振られたクレジットの数に設定される。クライアントがこのフィールド内にゼロより大きい値を返すと、サーバは通常、少なくとも１つの負の更新が送信されるまで、別の正の更新メッセージを送信しない。一般に、クライアントはゼロを返す。
【００７０】
上述したように、クライアントは、負（−Ｎ）のデルタクレジットメッセージを受信した場合、捨てるクレジットごとに１つのＮ個のクレジットメッセージをサーバに送信することが必要である。この場合のＯｆｆｓｅｔ１０２９の上位３２ビットは、従って−Ｎ、−（Ｎ−１）、・・・−１に設定される。サーバは、Ｏｆｆｓｅｔ１０２９の上位３２ビットが−１に設定された状態でクライアントクレジットメッセージを受信した場合、クライアントがサーバクレジットメッセージの処理を終了し、新しいクレジットメッセージを受信する資格があると判断する。
【００７１】
図１０に戻って、ステップ１００９に示すように、サーバは、クライアントにＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージを送信することによって３方向ハンドシェイクを完了する。図１１Ｃは、本発明の一実施形態においてサーバによって送信されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０３３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０３７は０に設定される。クライアントによって送信されたＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージのヘッダ内のＯｆｆｓｅｔの上位３２ビットが０以上であった場合、Ｓｔａｔｕｓ（ステータス）１０３９は、成功を示す０×０に設定される。Ｏｆｆｓｅｔの上位３２ビットが負の数に設定されている場合、サーバは、クライアントがクレジットを廃棄するのを許可するように、Ｓｔａｔｕｓ１０３９をＬＷＩＯ＿ＣＲＥＤＩＴ＿ＮＯＴＩＦＹに設定する。Ｃｏｏｋｉｅ１０３５は、ＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＲＥＤＩＴメッセージの共通ヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。
【００７２】
終了
終了メッセージは、登録段階中に交換された特定のＦｉｄのＩ／Ｏ処理を停止するために使用される。サーバが応答すると、Ｆｉｄが再利用されるまで、新しい要求は失敗する。図１２Ａは、本発明の一実施形態においてクライアントによって送信される終了メッセージの表現例を示している。終了メッセージ１０４１は、共通ヘッダ１０４３を含む。Ｏｐｃｏｄｅ１０４５はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＬＯＳＥ（０×４）に設定される。Ｆｌａｇｓ１０４７はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０４９は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０５３はクライアント指定の値に設定される。Ｆｉｄ１０５１は、終了すべきファイルのＦｉｌｅ  Ｉｄに設定される。
【００７３】
サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答する。図１２Ｂは、本発明の一実施形態においてサーバによって返される終了完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０５５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０５９は０に設定される。Ｓｔａｔｕｓ１０６１は、成功を示す０に設定される。Ｃｏｏｋｉｅ１０５７は、クライアント終了要求で設定されたＣｏｏｋｉｅ値に設定される。
【００７４】
キャンセル
キャンセルメッセージは、登録段階中に交換された特定のＦｉｄのＩ／Ｏ処理を停止するために使用される。キャンセルが発行されると、サーバは要求を終える。しかし、キャンセルできないＩ／Ｏ要求は、サーバ上で依然として続行している場合がある。図１３Ａは、本発明の一実施形態においてクライアントによって送信されるキャンセルメッセージの表現例を示している。キャンセルメッセージ１０６３は、共通ヘッダ１０６５を含む。Ｏｐｃｏｄｅ１０６７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＣＡＮＣＥＬ（０×５）に設定される。Ｆｌａｇｓ１０６９はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１０７１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｃｏｏｋｉｅ１０７５はクライアント指定の値に設定される。Ｆｉｄ１０７３は、キャンセルが発行されているＦｉｌｅ  Ｉｄに設定される。
【００７５】
サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥメッセージでキャンセルを完了する。図１３Ｂは、本発明の一実施形態においてサーバによって返されるキャンセル完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１０７７の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１０８１は０に設定される。Ｓｔａｔｕｓ１０８３は、成功を示す０に設定される。Ｃｏｏｋｉｅ１０７９は、クライアントキャンセル要求で設定されたＣｏｏｋｉｅ値に設定される。
【００７６】
読み取りメッセージは、登録段階中に交換された特定のＦｉｄからデータを取得するために使用される。１キロバイトより小さい読み取り要求については、ユーザバッファがＮＩＣに登録されていない場合、データは、予め登録されていた内部バッファ内に受信され、データがサーバから受信されると、ユーザバッファ内にコピーが行われる。これが行われるのは、小さいユーザバッファを登録するより、少量のデータをコピーすることがより効率的であるからである。大量の読み取りでは、ユーザバッファが登録され、データは、ＲＤＭＡ書き込みを介して直接受信される。単一の読み取り要求に従って読み取られたデータの量は、サーバのＭａｘＲｄｍａＷｉｎｄｏｗＳｉｚｅによって限定される。
【００７７】
図１４Ａおよび図１４Ｃは、本発明の一実施形態においてクライアントによって送信される読み取りメッセージの表現例を示しており、図１４Ａは非ポーリングの場合、図１４Ｃはポーリングの場合を示している。読み取りメッセージ１４０１は、共通ヘッダ１４０３を含む。Ｌｅｎｇｔｈ１４０５は、関連のファイルから読み取られるバイト数に設定される。Ｏｐｃｏｄｅ１４０７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＲＥＡＤ（０×０）に設定される。Ｏｆｆｓｅｔ１４１７は、ファイルの読み取りを開始するバイト位置に設定される。Ｍａｒｋｅｒ１４１３は０×ＦＦに設定される。Ｆｌａｇ１４０９、１４２７は、ポーリングの場合１４２７では０×０に設定され、非ポーリングの場合１４０９ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｃｒｅｄｉｔｓ１４１１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１４１５は、Ｉ／Ｏを発行するＦｉｌｅ  Ｉｄに設定される。ＤａｔａＶａ１４１９は、読み取りデータがＲＤＭＡされるアドレスに設定され、ＤａｔａＭｈ１４２１は、関連のメモリハンドルに設定される。
【００７８】
非ポーリングの場合、ＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１４２３およびＣｏｏｋｉｅ１４２５は、クライアント指定の値に設定される。サーバは、この場合、通常の送信を介してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで、または読み取りが成功した場合、即値データによりＲＤＭＡで読み取り要求を完了することができる。ＲＤＭＡ書き込みの即値データは、それに応じて読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に設定される。ポーリングの場合、ＩｏｓＶａ１４３１は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１４２９は、関連のメモリハンドルに設定される。
【００７９】
非ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答することができ、またはサーバは、即値データをＲＤＭＡ読み取りデータとともに送信することができる。この場合即値データは、読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に送信される。図１４Ｂは、本発明の一実施形態において、非ポーリングの場合にサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１４３３の表現例を示している。
【００８０】
Ｉｎｆｏｒｍａｔｉｏｎ１４３７は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１４３９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１４３５は、読み取りメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。
【００８１】
ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをクライアントにＲＤＭＡする。図１４Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１４４１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１４４３は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１４４５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。
【００８２】
書き込み
書き込みメッセージは、ファイル登録中に交換された特定のＦｉｄにデータを入れるために使用される。すべての書き込みデータは、通常の送信操作を使用して送信される。書き込まれるデータ量は、サーバのＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅによって限定される。クライアントがこれより多くのデータを送信すると、接続が中断される。
【００８３】
図１５Ａおよび図１５Ｃは、本発明の一実施形態においてクライアントによって送信される書き込みメッセージの表現例を示しており、図１５Ａは非ポーリングの場合、図１５Ｃはポーリングの場合を示している。書き込みメッセージ１５０１は、共通ヘッダ１５０３を含む。Ｌｅｎｇｔｈ１５０５は、書き込まれるデータのバッファ数に設定される。０Ｏｐｃｏｄｅ１５０７はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＷＲＩＴＥ（０×１）に設定される。Ｏｆｆｓｅｔ１５１７は、ファイルデータの書き込みを開始するバイト位置に設定される。Ｆｌａｇ１５０９、１５２９は、ポーリングの場合１５２９では０×０に設定され、非ポーリングの場合１５０９ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｍａｒｋｅｒ１５１３は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１５１１は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１５１５は、Ｉ／Ｏを発行するＦｉｌｅ  Ｉｄに設定される。書き込まれるデータ１５２７は、書き込みメッセージの共通ヘッダ１５０３のすぐ次に来る。
【００８４】
非ポーリングの場合、Ｃｏｏｋｉｅ１５２５は、クライアント指定の値に設定される。ポーリングの場合、ＩｏｓＶａ１５３３は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１５３１は、関連のメモリハンドルに設定される。
【００８５】
非ポーリングの場合、サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで書き込みメッセージに応答する。図１５Ｂは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１５３５の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１５３９は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１５４１は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１５３７は、書き込みメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。ポーリングの場合、サーバは、ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１５Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１５４３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１５４５は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１５４７は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。
【００８６】
ベクトル化読み取り
ベクトル化読み取りは、登録段階中に交換された特定のＦｉｄからデータを取得し、データをページごとに要求側の複数のセグメントに分散するために使用される。読み取られたすべてのデータは、読み取りセグメントごとにサーバから１つのＲＤＭＡ書き込みを介して要求側に送信される。ディスクから読み取られたデータは連続している。読み取られたデータ量は、単一の要求で記載することができる最大数の宛先ページによって限定される。この限定は、ｓｉｚｅｏｆ（ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮ）によって分割されるサーバＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅである。ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮの構造を以下に示す。
【００８７】
図１６Ａおよび図１６Ｃは、本発明の一実施形態においてクライアントによって送信されるベクトル化読み取りメッセージの表現例を示しており、図１６Ａは非ポーリングの場合、図１６Ｃはポーリングの場合を示している。読み取りメッセージ１４０１は、共通ヘッダ１６０３、次いで１つまたは複数のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント１６０５、１６０７を含む。ヘッダ１６０３の中のＬｅｎｇｔｈ１６０９は、ファイルから読み取られるデータのバイト数に設定される。Ｏｐｃｏｄｅ１６１１はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＶＥＣ＿ＲＥＡＤ（０×２）に設定される。Ｏｆｆｓｅｔ１６２１は、ファイルデータの読み取りを開始するバイト位置に設定される。Ｆｌａｇ１６１３、１６３１は、ポーリングの場合１６３１では０×０に設定され、非ポーリングの場合１６１３ではＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）に設定される。Ｍａｒｋｅｒ１６１７は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１６１５は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１６１９は、Ｉ／Ｏを発行するＦｉｌｅ  Ｉｄに設定される。Ｎｕｍｐａｇｅｓ１６２３は、共通ヘッダ１６０３に続くＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮの数に設定される。ＰａｇｅＳｉｚｅ１６２５はローカルページサイズにバイト単位で設定される。
【００８８】
非ポーリングの場合、ＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１６２７およびＣｏｏｋｉｅ１６２９は、クライアント指定の値に設定される。サーバは、この場合、通常の送信を介してＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで、または読み取りが成功した場合は即値データによりＲＤＭＡでベクトル化読み取り要求を完了することができる。ＲＤＭＡ書き込みの即値データは、それに応じて読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ１６２７値に設定される。ポーリングの場合、ＩｏｓＶａ１６３５は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定され、ＩｏｓＭｈ１６３３は、関連のメモリハンドルに設定される。
【００８９】
共通ヘッダ１６０３のすぐ次に十分な数のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント１６０５、１６０７が続き、要求の長さをカバーする。中間セグメントのサイズは、すべて１ページとすべきである。最後のセグメントは１つのページより小さくてもよいが、バックエンドディスクセクタサイズ（ｂａｃｋｅｎｄ  ｄｉｓｋ  ｓｅｃｔｏｒ  ｓｉｚｅ）の倍数とする必要がある。本発明の一実施形態では、ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮ構造は、次のフォーマットを有する。
【００９０】
【表１１】
2007527057.tif 000013
【００９１】
第１のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮは、読み取られる第１のＰａｇｅＳｉｚｅバイトに対応し、第２のＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮは、読み取られる第２のＰａｇｅＳｉｚｅバイトに対応し、以下同様である。ＤａｔａＶａ１６３７は、読み取りデータが入れられるページの先頭を示す位置に設定される。ＤａｔａＭｈ１６３９は、ＤａｔａＶａ１６３７のメモリハンドルに設定される。Ｌｅｎｇｔｈ１６４１は、最後の領域を除くすべての領域についてＰａｇｅＳｉｚｅ１６２５に設定される。最後の領域は、Ｌｅｎｇｔｈは小さくてもよいが、バックエンドディスクセクタサイズの倍数とする必要がある。
【００９２】
非ポーリングの場合、サーバは、まず、読み取りデータをＲＤＭＡする。次いでサーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで応答することができ、またはサーバは、即値データをＲＤＭＡ読み取りデータとともに送信することができる。この場合即値データは、読み取り要求のＩｍｍｅｄｉａｔｅＣｏｏｋｉｅ値に送信される。図１６Ｂは、本発明の一実施形態において、非ポーリングの場合にサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１６４３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１６４７は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１６４９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１６４５は、ベクトル化読み取りメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。
【００９３】
ポーリングの場合、サーバはまず、読み取りデータをＲＤＭＡし、次いでＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１６Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１６５１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１６５３は、読み取られるバイト数に設定される。Ｓｔａｔｕｓ１６５５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。
【００９４】
ベクトル化書き込み
ベクトル化書き込みメッセージは、ファイル登録中に交換された特定のＦｉｄへの収集的な書き込み（ｇａｔｈｅｒ  ｗｒｉｔｅ）を行うために使用される。すべての書き込みデータは、通常の送信操作を使用して送信される。書き込まれるデータ量は、サーバのＭａｘＲｅｃｖＢｕｆｆｅｒＳｉｚｅによって限定される。クライアントがこれより多くのデータを送信すると、接続が中断される。
【００９５】
図１７Ａ、図１７Ｂ、図１７Ｃは、本発明の一実施形態におけるクライアントによって送信されるベクトル化書き込みメッセージの表現例を示しており、図１７Ａは、非ポーリング、非折りたたみの場合、図１７Ｂは、非ポーリング、折りたたみの場合、および図１７Ｃはポーリング、折りたたみの場合を示している。
【００９６】
書き込みメッセージ１７０１は、共通ヘッダ１７０３、次いで書き込まれるデータ１７０５を含む。共通ヘッダ１７０３の中のＬｅｎｇｔｈ１７０７は、書き込まれるデータのバイト数に設定される。Ｏｐｃｏｄｅ１７０９はＬＷＩＯ＿ＯＰＣＯＤＥ＿ＷＲＩＴＥ（０×３）に設定される。Ｏｆｆｓｅｔ１７１９は、ファイルデータの書き込みを開始するバイト位置に設定される。Ｍａｒｋｅｒ１７１５は０×ＦＦに設定される。Ｃｒｅｄｉｔｓ１７１３は、クライアント上の保留中のＩ／Ｏ要求の数に設定される。Ｆｉｄ１７１７は、Ｉ／Ｏを発行するＦｉｌｅ  Ｉｄに設定される。
【００９７】
Ｆｌａｇ１７１１、１７２１、１７２７は、ポーリング１７２７を示す０×０に設定され、そうでない場合はＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＩＮＴＥＲＲＵＰＴ（０×８０）１７１１に設定される。後者の場合、フラグは、書き込み内のすべてのページが同じデータを含み、従ってデータの単一ページのみが送信されたことを示すためにＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＬＬＡＰＳＥ１７２１を含むことができる。これは、冗長データの転送を最低限に抑えるための最適化である。ＬＷＩＯ＿ＨＤＲ＿ＦＬＡＧ＿ＣＯＬＬＡＰＳＥは、登録されたファイルフラグがＦＩＬＥ＿ＮＯ＿ＩＮＴＥＲＭＥＤＩＡＴＥ＿ＢＵＦＦＥＲＩＮＧ（０×８）を含み、認証段階中に交換されたＰａｇｅＳｉｚｅが偶数による互いの倍数である場合にのみ使用することができる。折りたたみされたＩ／Ｏの場合、ＮｕｍＰａｇｅｓ１７２３は、Ｉ／Ｏがまたがるデータのページ数に設定される。最後のページは、Ｌｅｎｇｔｈパラメータのために部分的である場合がある。ＰａｇｅＳｉｚｅ１７２５はローカルページサイズにバイト単位で設定される。ポーリングの場合、ＩｏｓＶａ１７３１は、サーバ応答状況（ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ）がＲＤＭＡされる位置に設定される。ＩｏｓＭｈ１７２９は、関連のメモリハンドルである。
【００９８】
非ポーリングの場合、非折りたたみおよび折りたたみのＩ／Ｏの両方で、サーバは、ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥで書き込みメッセージに応答する。
【００９９】
図１７Ｄは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ１７３３の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１７３７は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１７３９は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。Ｃｏｏｋｉｅ１７３５は、書き込みメッセージのヘッダ内のクライアントによって設定されたＣｏｏｋｉｅ値に設定される。
【０１００】
ポーリングの場合、非折りたたみおよび折りたたみのＩ／Ｏの両方で、サーバはＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫをＲＤＭＡする。図１７Ｅは、本発明の一実施形態においてサーバによって返されるＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ１７４１の表現例を示している。Ｉｎｆｏｒｍａｔｉｏｎ１７４３は、書き込まれるバイト数に設定される。Ｓｔａｔｕｓ１７４５は、成功を示す０、または失敗を示す別のＮＴＳＴＡＴＵＳに設定される。
【０１０１】
結論
本発明の実施形態の例を示し、説明してきたが、本発明から逸脱することなく様々な変更を加えることができることを理解されたい。同様に、本明細書に記載した任意のプロセスステップを他のステップと交換して同じ結果を達成することができる。さらに、上述した例は、網羅的なものではなく、開示された正確なフォーマットに本発明を限定するためのものでもない。むしろ、本発明は、本発明が意図する特許請求の範囲内に含まれるすべての変更、変形、構成、および均等物をカバーするものとする。
【図面の簡単な説明】
【０１０２】
【図１】本発明の態様を組み込むことができる、ＲＤＭＡ転送を介して通信することができる２つのコンピュータを含む典型的なクライアント−サーバコンピューティング環境を示す概略図である。
【図２】本発明の一実施形態によるＬＷＩＯプロトコルの発見段階において行われる最初のステップを示す概略流れ図である。
【図３】本発明の一実施形態による典型的なサーバ要求レジュームキーの表現を示す概略図である。
【図４Ａ】本発明の一実施形態による典型的なクライアント交渉要求メッセージの表現を示す概略図である。
【図４Ｂ】本発明の一実施形態による典型的なサーバ交渉応答の表現を示す概略図である。
【図５】本発明の一実施形態によるＬＷＩＯプロトコルの発見段階において行われる追加のステップを示す概略流れ図である。
【図６Ａ】本発明の一実施形態による典型的なクライアント認証要求メッセージの表現を示す概略図である。
【図６Ｂ】本発明の一実施形態による典型的なサーバ認証応答の表現を示す概略図である。
【図６Ｃ】本発明の一実施形態による認証を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図７Ａ】本発明の一実施形態による典型的なクライアントファイル登録メッセージの表現を示す概略図である。
【図７Ｂ】本発明の一実施形態によるファイル登録を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図８】本発明の一実施形態によるポーリングモードおよび非ポーリングモードにおいてＩ／Ｏ要求の完了に関して行われるステップを示す概略流れ図である。
【図９Ａ】本発明の一実施形態による典型的なクライアント割り込み要求メッセージの表現を示す概略図である。
【図９Ｂ】本発明の一実施形態による割り込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１０】本発明の一態様によるサーバ−クライアントクレジットトランザクションに関して行われるステップを示す概略流れ図である。
【図１１Ａ】本発明の一実施形態による典型的なサーバデルタクレジットメッセージの表現を示す概略図である。
【図１１Ｂ】本発明の一実施形態による典型的なクライアントからサーバへのクレジットメッセージの表現を示す概略図である。
【図１１Ｃ】本発明の一実施形態によるクレジット−サーバクレジットトランザクションを完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１２Ａ】本発明の一実施形態による典型的なクライアント終了要求メッセージの表現を示す概略図である。
【図１２Ｂ】本発明の一実施形態による終了要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１３Ａ】本発明の一実施形態による典型的なクライアントキャンセル要求メッセージの表現を示す概略図である。
【図１３Ｂ】本発明の一実施形態によるキャンセル要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１４Ａ】本発明の一実施形態による非ポーリングモードの場合の典型的なクライアント読み取り要求メッセージの表現を示す概略図である。
【図１４Ｂ】本発明の一実施形態による非ポーリングモードの場合の読み取り要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１４Ｃ】本発明の一実施形態によるポーリングモードの場合の典型的なクライアント読み取り要求メッセージの表現を示す概略図である。
【図１４Ｄ】本発明の一実施形態によるポーリングモードの場合の読み取り要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。
【図１５Ａ】本発明の一実施形態による非ポーリングモードの場合の典型的なクライアント書き込み要求メッセージの表現を示す概略図である。
【図１５Ｂ】本発明の一実施形態による非ポーリングモードの場合の書き込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１５Ｃ】本発明の一実施形態によるポーリングモードの場合の典型的なクライアント書き込み要求メッセージの表現を示す概略図である。
【図１５Ｄ】本発明の一実施形態によるポーリングモードの場合の書き込み要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。
【図１６Ａ】本発明の一実施形態による非ポーリングモードの場合の典型的なクライアントベクトル化読み取り要求メッセージの表現を示す概略図である。
【図１６Ｂ】本発明の一実施形態による非ポーリングモードの場合のベクトル化読み取り要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１６Ｃ】本発明の一実施形態によるポーリングモードの場合の典型的なクライアントベクトル化読み取り要求メッセージの表現を示す概略図である。
【図１６Ｄ】本発明の一実施形態によるポーリングモードの場合のベクトル化読み取り要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。
【図１７Ａ】本発明の一実施形態による、非ポーリングモードで折りたたみされていない場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。
【図１７Ｂ】本発明の一実施形態による、非ポーリングモードで折りたたみされた場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。
【図１７Ｃ】本発明の一実施形態による、ポーリングモードで折りたたみされた場合の典型的なクライアントベクトル化書き込み要求メッセージの表現を示す概略図である。
【図１７Ｄ】本発明の一実施形態による非ポーリングモードの場合のベクトル化書き込み要求を完了する典型的なサーバ状況応答の表現を示す概略図である。
【図１７Ｅ】本発明の一実施形態によるポーリングモードの場合のベクトル化書き込み要求を完了する典型的なサーバＩ／Ｏ状況ブロックの表現を示す概略図である。
【符号の説明】
【０１０３】
１０１  ホストＡ
１０３  ＬＷＩＯクライアント
１０５  カーネルモード読み取り／書き込み
１０７  バッファ
１０９  ＲＤＭＡ対応ＮＩＣ
１１１  ＲＤＭＡ対応ＮＩＣ
１１３  ＮＩＣ
１１７  ＲＤＭＡチャネル
１１９  非ＲＤＭＡネットワークリンク
１２１  ホストＢ
１２３  ＬＷＩＯサーバ
１２５  ＳＭＢサーバ
１２７  バッファ
１２９  ＮＴＦＳ
１３１  リードディスク
１３３  ＮＩＣ
１３５  ＲＤＭＡ対応ＮＩＣ
１３７  ＲＤＭＡ対応ＮＩＣ
２１９  サーバ要求レジュームキー
２３１  交渉要求パケット
２３３  制御ヘッダ
２４１  プロバイダのリスト
２５７  インスタンステーブル
２６７  交渉応答
２６９  制御ヘッダ
２７９  プロバイダリスト
６１７  認証メッセージ
６１９  共通ヘッダ
６２１  ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造
６５９  ＬＷＩＯ＿ＡＵＴＨ＿ＰＡＲＡＭＳ構造
６８９  サーバ認証完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
７０１  登録メッセージ
７０３  共通ヘッダ
７０５  ＬＷＩＯ＿ＦＩＤ＿ＰＡＲＡＭＳ構造
７２３  サーバ登録完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
８１５  共通ヘッダ
８２５  サーバ割り込み完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０１１  ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０１９  ＣＲＥＤＩＴメッセージ
１０２１  共通ヘッダ
１０３３  サーバクレジット完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０４１  終了メッセージ
１０４３  共通ヘッダ
１０５５  サーバ終了完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１０６３  キャンセルメッセージ
１０６５  共通ヘッダ
１０７７  サーバキャンセル完了ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１４０１  読み取りメッセージ
１４０３  共通ヘッダ
１４３３  読み取り完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１４４１  読み取り完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１５０１  書き込みメッセージ
１５０３  共通ヘッダ
１５３５  書き込み完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１５４３  書き込み完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１６０３  共通ヘッダ
１６０５  ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント
１６０７  ＬＷＩＯ＿ＲＤＭＡ＿ＲＥＧＩＯＮセグメント
１６４３  ベクトル化完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１６５１  ベクトル化完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
１７０１  書き込みメッセージ
１７０３  共通ヘッダ
１７０５  書き込まれるデータ
１７３３  クライアントＶＥＣ書き込み完了（非ポーリング）
ＬＷＩＯ＿ＭＳＧ＿ＳＴＡＴＵＳ＿ＲＥＳＰＯＮＳＥ
１７４１  クライアントＶＥＣ書き込み完了（ポーリング）
ＬＷＩＯ＿ＩＯ＿ＳＴＡＴＵＳ＿ＢＬＯＣＫ
【図１】
2007527057.tif 000014
【図２】
2007527057.tif 000015
【図３】
2007527057.tif 000016
【図４Ａ】
2007527057.tif 000017
【図４Ｂ】
2007527057.tif 000018
【図５】
2007527057.tif 000019
【図６Ａ】
2007527057.tif 000020
【図６Ｂ】
2007527057.tif 000021
【図６Ｃ】
2007527057.tif 000022
【図７Ａ】
2007527057.tif 000023
【図７Ｂ】
2007527057.tif 000024
【図８】
2007527057.tif 000025
【図９Ａ】
2007527057.tif 000026
【図９Ｂ】
2007527057.tif 000027
【図１０】
2007527057.tif 000028
【図１１Ａ】
2007527057.tif 000029
【図１１Ｂ】
2007527057.tif 000030
【図１１Ｃ】
2007527057.tif 000031
【図１２Ａ】
2007527057.tif 000032
【図１２Ｂ】
2007527057.tif 000033
【図１３Ａ】
2007527057.tif 000034
【図１３Ｂ】
2007527057.tif 000035
【図１４Ａ】
2007527057.tif 000036
【図１４Ｂ】
2007527057.tif 000037
【図１４Ｃ】
2007527057.tif 000038
【図１４Ｄ】
2007527057.tif 000039
【図１５Ａ】
2007527057.tif 000040
【図１５Ｂ】
2007527057.tif 000041
【図１５Ｃ】
2007527057.tif 000042
【図１５Ｄ】
2007527057.tif 000043
【図１６Ａ】
2007527057.tif 000044
【図１６Ｂ】
2007527057.tif 000045
【図１６Ｃ】
2007527057.tif 000046
【図１６Ｄ】
2007527057.tif 000047
【図１７Ａ】
2007527057.tif 000048
【図１７Ｂ】
2007527057.tif 000049
【図１７Ｃ】
2007527057.tif 000050
【図１７Ｄ】
2007527057.tif 000051
【図１７Ｅ】
2007527057.tif 000052