networking - なぜ正確に一度のセマンティクスが実行不可能なのですか?

Question

Erlang が最善を期待している RPC セマンティクスでは、少なくとも 1 回の SUN RPC と最大 1 回の Java RMI がありますが、正確に 1 回のセマンティクスを持つ人はいません。

厳密に 1 回のセマンティクスを持つことが実行不可能に思えるのはなぜですか?

たとえば、クライアントが応答を受信するまで一意にタグ付けされたリクエストを再送信し続け、サーバーがリクエストを複製しないように処理されたすべてのリクエストを追跡する場合。それはちょうど一度ではないでしょうか？

Answer 1

リクエストを実行してからリクエストを実行したことを記録するまでの間にサーバーがクラッシュした場合はどうなるでしょうか?

リクエストを記録してから実行することで、最大 1 回取得できます。2 つの間でクラッシュが発生した場合は、(誤って) 実行済みとして記録したことになるため、再度実行することはありません。したがって、多くても 1 回

奇妙なことに、これ (タイムアウト付き) は特許を取得しています: http://www.freepatentsonline.com/7162512.html。私が上で議論したことを除いて、それは正確に1回を保証するものではありません.

それを実行してから記録することで、少なくとも1回は取得できます。2 つの間でクラッシュが発生した場合、要求が繰り返されると再度実行されます。

しかし、すべての状況で「ちょうど 1 回」と言うのは現実的ではありません。

(サーバーのクラッシュではなく、ネットワーク エラーにも同様のシナリオがあります)

Answer 2

IBM のWebSphere MQのようなハイエンドのメッセージング バスは、正確に 1 回の配信を提供すると主張しています。実際、これはデフォルトの動作です (最後に WMQ を使用したとき...)。これは、先行書き込みログとさまざまなロック手法によって実現されます。

もちろん、彼らの法律文書のどこかに埋もれている「正確に 1 回」が、実際には「メッセージが 1 回、複数回、または何度も、または 0 回未満で配信されるか、配信されないか」を意味するように定義されていることに疑いの余地はありません。しかし、電源ケーブルを蹴ったり、斧をネットワーク インフラストラクチャに持って行ったりするなど、ほとんどの場合に機能します。

Answer 3

答えは、クライアントがサーバーからの決定的な結果を待たなければならないため、これらのセマンティクスを取得するのに無期限の時間が必要になるということだと思います。この要件は、実際のネットワークでは実用的ではありません。

クライアントが試行をあきらめた場合 (または、トランザクションを完了する前、またはトランザクションが完了したことを通知する前にサーバーが長時間ダウンした場合、それらのことを行う順序に応じて)、クライアントが次のことを行う方法がない可能性があります。リクエストが受信され、処理されたかどうかがわかります。実際には、RPC システムは、たとえばデフォルトの TCP タイムアウトを尊重したい場合があるため、サーバーからの決定的な成功または失敗を待つ必要はありません。

これは推測ですが、私は RPC プロトコルを設計したことがありません。