エンドポイントの指定

エンドポイントは、リモート プロシージャ コール用のサーバー プロセスのネットワーク固有のアドレスです。 エンドポイントの実際の名前は、使用されるプロトコル シーケンスによって異なります。 たとえば、TCP、UDP、HTTP ではポートが使用されます。 名前付きパイプでは、名前付きパイプ名が使用されます。 クライアント/サーバー アプリケーションでは、既知のエンドポイントまたは動的エンドポイントを使用できます。 このセクションでは、サーバー プログラムが既知のエンドポイントと動的エンドポイントを指定するために使用する手法について説明します。 この情報については、次のトピックで説明します。

既知のエンドポイントの指定

サーバーが既知のエンドポイントを使用する場合、ネーム サービス データベース エントリの一部としてエンドポイント データを含めることができます。 その場合、クライアントのバインド ハンドルには、クライアントがサーバー エントリからバインド ハンドルをインポートするときに、既知のエンドポイントを含む完全なサーバー アドレスが含まれます。

サーバー プログラムは、プロトコル シーケンスを指定するのと同時に、既知のエンドポイントを指定することもできます。 RpcServerUseProtseqEp または RpcServerUseProtseqEpEx 関数を呼び出します。 2 つの違いは、後者の関数には、サーバーが動的ポート割り当てを制御するために使用できる追加のパラメーターがあるということです。

サーバー プログラムがこのようにエンドポイント情報を指定する場合は、 RpcEpRegister 関数も呼び出してエンドポイント マップにエンドポイントを登録する必要があります。 エンドポイントは常に同じですが、クライアントはエンドポイント マップを使用してサーバーを検索できます。

プロトコル シーケンスと同様に、アプリケーションは IDL ファイルにエンドポイント情報を指定できます。 その場合は、 RpcServerUseAllProtseqsIf 関数または RpcServerUseAllProtseqsIfEx 関数を呼び出して、プロトコル シーケンスとエンドポイントの両方を同時に登録 する 必要があります。 この場合、クライアントは IDL ファイルのインターフェイス仕様を通じてエンドポイント情報にアクセスできます。 そのため、 RpcEpRegister 関数を呼び出す必要はありません。

動的エンドポイントの指定

動的エンドポイントは、サーバーが実行を開始するときにサーバー ホスト コンピューターによって割り当てられるエンドポイントです。 ほとんどのサーバー アプリケーションでは、動的エンドポイントを使用して、サーバー ホスト コンピューター システムで使用できるポートの数が限られている他のプログラムとの競合を回避します。 ただし、名前付きパイプまたは ncalrpc プロトコル シーケンスを使用するプログラムには、非常に大きなエンドポイントネームスペースがあります。 動的エンドポイントのメリットは、他のトランスポートを使用するプログラムよりも少なくなります。

サーバー プログラムは、エンドポイント マップ データベースに動的エンドポイントを登録します。 サーバーで使用可能なエンドポイントを使用する場合は、 RpcServerUseAllProtSeqsRpcServerUseAllProtseqsExRpcServerUseProtseqまたは RpcServerUseProtseqEx を呼び出します。 これにより、RPC ランタイム ライブラリが、動的エンドポイントですべてまたは 1 つの有効なプロトコル シーケンスを使用するように設定されます。 その後、サーバーは RpcServerInqBindings を 呼び出して、有効なバインド ハンドルのセットを取得する必要があります。 サーバーは、バインド ハンドル (バインド ベクター) のセットを関数 RpcEpRegister に渡して、エンドポイント マップに適切なすべてのエンドポイントを登録します。 サーバーが RpcEpRegister に対して行う呼び出しごとに、バインド ベクターで使用されるメモリを解放するために 、RpcBindingVectorFree への対応する呼び出しが必要です。

サーバー プログラムでは、 RpcEpRegister ではなく RpcEpRegisterNoReplace 関数を使用できること に注意してください。 サーバー プログラムの複数のコピーをサーバー ホスト システムで実行する必要がある場合、通常、プログラムは RpcEpRegisterNoReplace を使用します。

RpcEpRegister 関数と RpcEpRegisterNoReplace 関数の両方で、サーバーのインターフェイスとバインド ハンドルがエンドポイント マッパー データベースに追加されます。 クライアントが部分的にバインドされたハンドルを使用してリモート プロシージャ 呼び出しを行うと、クライアントのランタイム ライブラリは、サーバー コンピューターのエンドポイント マッパーに、互換性のあるサーバー インスタンスのエンドポイントを要求します。 クライアント ライブラリは、インターフェイス UUID、プロトコル シーケンス、および存在する場合は、クライアント バインド ハンドル内のオブジェクト UUID を提供します。 エンドポイント マッパーは、クライアントの情報と一致するデータベース エントリを検索します。 クライアント/サーバー インターフェイス UUID、インターフェイス メジャー バージョン、プロトコル シーケンスはすべて完全に一致する必要があります。 さらに、サーバーのインターフェイスのマイナー バージョンは、クライアントのマイナー バージョン以上である必要があります。

すべてのテストが成功した場合、エンドポイント マッパーは有効なエンドポイントを返し、クライアント ランタイム ライブラリはバインド ハンドル内のエンドポイントを更新します。

サーバー プロセスの実行が停止すると、動的エンドポイントはエンドポイント マッパー データベースから自動的に消去されます。 サーバー プログラムが RpcEpUnregister 関数を使用して終了する前にエンドポイント マッパー データベースからエンドポイントを削除するか、エンドポイントの削除を自動クリーンアップで管理できます。