次の方法で共有

接続の損失に対処する

  • [アーティクル]

RPC 呼び出しが完了すると、接続は閉じられません。これは無料としてマークされています。 そのため、サーバーがダウンしたり、呼び出し中や呼び出しの間にネットワーク接続が失われたり、接続がプールに配置されている間に失われる可能性があります。 ポリシーの問題として、RPC ランタイムは、次の 2 つの条件が満たされた場合にのみ、これらの呼び出しを再試行します。

  • サーバーが呼び出しを実行できないか、呼び出しがべき等です。
  • クライアントは、パフォーマンス効率の高い方法で再試行を実装できます。

次の段落では、2 つの条件を展開して明確にします。

べき等呼び出しは、望ましくない副作用なしにサーバー上で複数回実行できる呼び出しです。 たとえば、特定の口座に対して銀行の残高を照会する RPC 呼び出しはべき等です。 接続が失われたためにこの呼び出しが 2 回実行された場合、害は発生しません。 べき等呼び出しのもう 1 つの例は、データベース内の顧客のアドレスを変更することです。 2 回目の実行では既に現在のアドレスが同じアドレスに置き換えられるので、2 回実行しても問題ありません。 "口座 xyz から 50 ドルを減算する" などの操作はべき等ではありません。 ネットワーク接続が失われると、このような呼び出しが複数回実行されるわけではありません。

安全を確保するために、RPC ランタイムは、すべての呼び出しをべき等でないものとして扱います。 [べき等] 属性は 、ncacn_ip_tcpではサポートされておらず、無視されます。 そのため、上記の一覧の最初の条件は、 呼び出しを実行できない可能性があるサーバーに減少します。

多くの場合、RPC ランタイムは、呼び出しがまだサーバーで実行されていないことを確定できません。 このような場合、クライアントは呼び出しの実行を再試行しません。

次の例は、RPC ランタイムが呼び出しを再試行する場合、または再試行しない場合を示しています。

  • サーバーが再起動されます。

    再起動後に以前の呼び出しが行われなかったインターフェイスでは、セキュリティのない単純な RPC 呼び出しが行われます。 このインターフェイスで呼び出しが行われなかったため、RPC ランタイムは最初にインターフェイスの使用をネゴシエートしようとします。 プール内の接続を使用してパケットを送信します。 サーバーが再起動され、接続が無効になったため、エラーが返されます。 クライアント側の RPC ランタイムは、実際の呼び出しのデータの送信をまだ開始していないため、クライアントは、サーバーがそれらのデータに対して実行できなかった可能性があると判断します。 そのため、接続が閉じられ、プール内の別の接続が検索されます。 接続が見つからない場合は、新しい接続が開き、インターフェイスの使用のネゴシエートが再試行されます。 これが成功すると、呼び出しが行われます (つまり、呼び出しが開始される前にエラーが検出されたため、再試行が行われます)。

  • プライバシー レベルのセキュリティ (暗号化) を使用した RPC 呼び出しは、既にネゴシエートされたセキュリティ コンテキストとの接続で行われます。

    効率的なパフォーマンスを確保するために、RPC ランタイムは(クリア テキスト データを介して) マーシャリングされたパケットをインラインで暗号化します。 データの送信試行が失敗した場合、クリア テキスト データは暗号化されたデータで上書きされ、新しいセキュリティ コンテキストでデータを再暗号化できないため、RPC ランタイムは呼び出しを再試行できません。 そのため、再試行は行われません。

  • 最初以外のフラグメントの送信が失敗します。

    再試行は行われません。RPC ランタイムでは、最初のフラグメントの内容が完了した後に破棄する場合があり、最初のフラグメントの送信を再試行する方法がないためです。

  • RPC 要求が送信されます。

    サーバーは接続を中止します。 RPC は、サーバーが呼び出しを受信して実行を開始したかどうかを識別できないため、再試行は試行されません。

サーバーが動的エンドポイントを使用している場合、RPC は再試行中にエンドポイントを再解決しません。 つまり、サーバーが停止して復帰した場合、サーバーは別のエンドポイントに存在する可能性があり、RPC は呼び出しが再試行されたときにエンドポイントを透過的に再解決しません。 エンドポイントの再解決を強制するには、RPC クライアントが呼び出しを再試行する前に RpcBindingReset を呼び出す必要があります。

これらの多くの場合、RPC クライアントが呼び出しがべき等であるかどうかを判断できる場合、または RPC が破棄するデータを保持する場合は、RPC の上に再試行メカニズムを構築することを選択できます。

Note

サーバーがクラスターであり、クラスターの異なるノードが異なるバージョンのサーバー ソフトウェアを実行している場合、RPC 再試行により、フェールオーバーの場合はクラスターの別のノードに呼び出しが送信され、サーバーの異なるバージョンに到達する可能性があります。 このような展開シナリオでは、クライアントが特定のバージョンのサーバー ソフトウェアに依存して特定の呼び出しを実行しないようにします。 その場合、クライアントは RPC の上に、そのような条件を検出して処理するメカニズムを構築する必要があります。