RPC 拡張開発ガイド

Sun RPC ライブラリの拡張

Sun RPC ライブラリの以前のバージョンでは、ほとんどのリクエストは 2 方向性メッセージングにより送られていました。2 方向性メッセージングでは、クライアントスレッドは処理を進める前にサーバーからの応答を得るまで待つ必要があります。クライアントスレッドが一定の時間内にサーバーからの応答を受け取らなかった場合、タイムアウトになります。このクライアントスレッドは、1 番目のリクエストが実行されるかタイムアウトになるまで、2 番目のリクエストを送ることができません。このメッセージングのメソッドを図 1–1 に図示します。

図 1–1 2 方向性メッセージング

Graphic


注 –

Sun RPC ライブラリの以前のバージョンには、バッチングと呼ばれるもう 1 つのメッセージング方法があります。この方法では、グループ中のリクエストが同時に処理可能の間、クライアントのリクエストはキューに保持されます。これは 1 方向性メッセージングの形態です。詳細は、『ONC+ 開発ガイド』の「RPC プログラマインタフェース」を参照してください。


Sun RPC ライブラリの新しい機能は、ライブラリのパフォーマンスを次のように拡張します。

  1. 1 方向性メッセージング - クライアントがサーバーにリクエストを送信する際、クライアントはサーバーからの応答を待つことなく、トランスポート層がその リクエストを受け入れる場合は処理を進めることができます。2 方向性メッセージングではなく 1 方向性メッセージングでメッセージを送信すると、処理時間を得ることができます。図 1–2 に、1 方向性メッセージングのメソッドを図示します。

    図 1–2 1 方向性メッセージング

    Graphic

  2. 非-ブロッキング入出力 - クライアントとトランスポート層との間に追加バッファーが 1 つあります。図 1–3 は、入出力モードで非-ブロッキングを選択し、トランスポート層のキューが満杯であるケースを示しています。この状況では、リクエストはトランスポート層のキューに入ることができず、バッファー内に置かれます。クライアントは、そのリクエストがバッファーに受け入れられた場合は、トランスポート層がそのリクエストを受け入れるのを待つことなく処理を続けることができます。非-ブロッキング入出力を使用することにより、2 方向性メッセージングや 1 方向性メッセージングに較べてより多くの処理時間を得ることができます。クライアントは、処理の継続をブロックされることなくリクエストを続けて送信することができます 。

    図 1–3 非-ブロッキングメッセージング

    Graphic

  3. クライアント接続クロージャーコールバック - 接続型トランスポートにおいて、クライアントとの接続が切断されたことをサーバーが検知し、トランスポートエラーから回復するための必要なアクションを行うことができます。トランスポートエラーは、リクエ ストがサーバーに着信した時、またはサーバーがリクエストを待機していて接続が切断された時に起こります。

  4. ユーザーファイル記述子コールバック - RPC サーバーが、RPC リクエスト同様非-RPC リクエストも受け入れることができるようにします。Sun RPC ライブラリの以前のバージョンでは、ユーザーが独自のサーバーループを記述するか、ソケット API にコンタクトをとる別個のスレッドを使用する場合にのみ、RPC コールおよび非-RPC ファイル記述子の両方をサーバーに受け入れさせることが可能でした。

    ユーザーファイル記述子コールバックでは、RPC サーバーは、クライアントリクエストを svc_run() を使用して実行ループを介して処理します。詳細は、svc_run(3NSL) のマニュアルページを参照してください。サーバーはサーバー接続の開始時に実行ループに入り、その接続の終了時に実行ループを終了します。RPC コールを行うが、ユーザーファイル記述子コールバックが無い場合は、非-RPC リクエストの受け入れはブロックされます。