次の方法で共有

コンテキスト ハンドル

  • [アーティクル]

分散アプリケーションでは、クライアント呼び出し間で状態情報を維持するためにサーバー プログラムが必要な場合があります。 一度に複数のクライアントにサービスを提供するサーバー プログラムは、各クライアントの状態情報を保持する必要があります。 クライアントとサーバーは異なるコンピューター上で異なるアドレス空間を使用し、必ずしも相互に信頼していないので、データ共有に対する一般的なアプローチは機能しないことが多いです。 たとえば、クライアントとサーバーは、同じグローバル アドレス空間を共有していないため、リモート セッションの状態情報をグローバル変数に保持できません。 情報は異なるコンピューターで実行されるため、共有ファイルに保持することは困難です。 単純なアプローチでは、すべての状態をクライアントに出荷し、次の呼び出しでクライアントに返してもらう場合がありますが、このアプローチには欠陥があります。サーバーはクライアントが正しい状態を返すとは限りません。また、状態がサーバー上の他の状態 (ファイル ハンドルや開かれたソケットなど) に暗黙的に関連付けられている可能性があります。

Microsoft RPC は、サーバー上の特定のクライアントに関連付けられた状態を維持するためのコンテキスト ハンドルと呼ばれる強力で安全なメカニズムを提供します。 状態情報は、サーバーのコンテキストと呼ばれます。 クライアントは、個々の RPC セッションのサーバーのコンテキストを識別するコンテキスト ハンドルを取得できます。

たとえば、分散アプリケーション内の各クライアントは、サーバー プログラムで RPC セッションのデータ ファイルを作成および更新できます。 サーバーは、各クライアントのデータ ファイルのファイル ハンドルをコンテキスト ハンドルとして使用できます。 クライアントは、サーバーが作成するデータ ファイルに対する操作を要求するたびに、コンテキスト ハンドルをサーバーに渡します。 クライアントは実際にはファイル ハンドル自体を取得しません。サーバー RPC ランタイムがファイル ハンドルに一意に関連付けることができる不透明なトークンを取得します。 コンテキスト ハンドルは実際にはファイル ハンドルであるため、コンテキスト ハンドルはサーバーのアドレス空間でのみ意味があります。 ただし、クライアント プログラムはコンテキスト ハンドルを使用して、更新を実行するファイルをサーバーに通知できます。

その他のデータは、コンテキスト ハンドルにすることもできます。 たとえば、クライアントとサーバーは、データベース レコードのレコード番号をファイル ハンドルとして使用できます。 クライアントが特定のレコードに対して多数の更新を実行する必要がある場合は、コンテキスト ハンドルとしてレコード番号を取得できます。 データベース レコードを更新するリモート プロシージャを呼び出すたびに、レコード番号がサーバーに渡されます。

ほとんどの場合、コンテキスト ハンドルは、サーバーがさまざまな管理情報を保持するサーバー上のメモリ ブロックを指します。

このセクションでは、コンテキスト ハンドルの定義と使用について説明します。 ここでは、次のトピックについて説明します。