次の方法で共有

エンドポイントの検索

  • [アーティクル]

サーバー プログラムは、クライアント要求のエンドポイントをリッスンします。 エンドポイント文字列の構文は、使用するプロトコル シーケンスによって異なります。 たとえば、TCP/IP のエンドポイントはポート番号であり、名前付きパイプのエンドポイント構文は有効なパイプ名です。

エンドポイントには、既知と動的の 2 種類があります。 プログラムで使用するエンドポイントの種類を選択すると、分散アプリケーションとランタイム ライブラリのどちらでエンドポイントが指定されるかが決まります。

このセクションでは、エンドポイントについて説明し、その検索方法について説明します。 これは、次のトピックにまとめられています。

Note

静的エンドポイントと既知のエンドポイントという用語は同等であり、同じ意味で使用されます。

 

クライアント アプリケーションでエンドポイント マップを使用して、サーバー プログラムが現在実行されているかどうかを判断できます。 クライアントは 、RpcMgmtInqIfIds、 RpcMgmtEpEltInqBegin、 および RpcMgmtEpEltInqDone を呼び出して、サーバーがエンドポイント マップに必要な特定のインターフェイスを登録しているかどうかを確認できます。

既知のエンドポイントの使用

既知のエンドポイントは、サーバー プログラムが実行するたびに使用する事前に割り当てられたエンドポイントです。 サーバーは常にその特定のエンドポイントをリッスンするため、クライアントは常にそのエンドポイントへの接続を試みます。 既知のエンドポイントは、通常、トランスポート プロトコルを担当する機関によって割り当てられます。 サーバー ホスト コンピューターには使用可能なエンドポイントが限られているため、アプリケーション開発者は既知のエンドポイントを使用しないことを強くお勧めします。 動的エンドポイントのもう 1 つの利点は、システムの長期的な管理とメンテナンスを簡素化することです。

分散アプリケーションでは、既知のエンドポイントを文字列で指定し、その文字列をパラメーターとして関数 RpcServerUseProtseqEp に渡すことができます。 または、エンドポイント文字列を [ endpoint] インターフェイス属性の一部として IDL ファイル インターフェイス ヘッダーに表示することもできます。

次の 2 つの方法を使用して、既知のエンドポイントを実装できます。

  • 文字列バインディング内のすべての情報を指定する
  • ネーム サービス データベースに既知のエンドポイントを格納する

バインディングを確立するために必要なすべての情報を、開発時に分散アプリケーションに書き込むことができます。 クライアントは、既知のエンドポイントを文字列で直接指定し、 RpcStringBindingCompose を呼び出してすべてのバインディング情報を含む文字列を作成し、この文字列を 関数 RpcBindingFromStringBinding に指定してハンドルを取得できます。 クライアントとサーバーは、既知のエンドポイントを使用するようにハードコーディングすることも、エンドポイント情報がコマンド ライン、データ ファイル、構成ファイル、または IDL ファイルから取得されるように書き込むことができます。

クライアント アプリケーションは、既知のエンドポイント情報をネーム サービス データベースに照会することもできます。

動的エンドポイントの使用

通常、特定のサーバーと特定のプロトコル シーケンスのエンドポイントの数は制限されます。 たとえば、TCP/IP を使用して RPC ネットワーク通信が行われることを示す ncacn_ip_tcp プロトコル シーケンスを使用する場合、使用できるポートの数は限られています (ほとんどのシステムでは、1025 ~ 5000 の範囲のみが開かれています)。 RPC ランタイム ライブラリを使用すると、必要に応じてエンドポイントを動的に割り当てることができます。 使用可能なインターフェイス UUID の数は実質的に無制限であるため、インターフェイス UUID を使用して呼び出しを指示すると、拡張の余地が広がり、柔軟性が向上します。

既定では、RPC ランタイム ライブラリ関数は、ネーム サービス データベースに対してクエリを実行するときにエンドポイント情報を検索します。 エンドポイントが動的な場合、ネーム サービス データベースにはエンドポイント情報は含まれません。 ただし、クエリによってクライアント プログラムにサーバーの名前が与えられます。 その後、サーバーのエンドポイント マップを検索できます。

クライアントが動的エンドポイントを使用してリモート プロシージャ 呼び出しを行う必要がある場合は、部分的にバインドされたバインド ハンドルで呼び出しを行うことが推奨されます。 RPC ランタイムは、エンドポイントを透過的に解決します。 RPC 実行時に高度なキャッシュ メカニズムが可能であるため、このメソッドは RpcEpResolveBinding 関数を使用するよりも優れています。

エンドポイントの選択をより具体的に制御する必要がある場合、クライアントは、RpcMgmtEpEltInqBegin、RpcMgmtEpEltInqNext、RpcMgmtEpEltInqDone 関数を呼び出すことによって、エンドポイント マップを一度に 1 つずつ検索できます。

既知のエンドポイントをエンドポイント マップ データベースにエクスポートする

特に、分散システムが既知のエンドポイント モデルから動的エンドポイント モデルに移行している場合は、エンドポイントを見つけるための 2 つのアプローチを組み合わせることができます。 このような移行では、サーバーの中間バージョンでは既知のエンドポイントが使用されますが、既知のエンドポイントもエンドポイント マップ データベースに登録されます。 この方法では、既知のエンドポイントを使用するクライアントと、動的エンドポイントを使用するクライアントを接続できます。 すべてのサーバーがアップグレードされると、動的エンドポイントのみを使用する新しいクライアント バージョンをデプロイできます。 すべてのクライアントがアップグレードされると、最終的なサーバー バージョンは既知のエンドポイントの使用を停止し、動的エンドポイントの使用のみを開始できます。

この方法では、既知のエンドポイントで開始されているが、すべてのサーバーとクライアントの同時更新を必要とせずに動的エンドポイントに移行するアプリケーションの移行パスを使用できます。