一度だけのセマンティクスが実行不可能なのはなぜですか？

Question

Erlangが最高の希望を持っているRPCセマンティクスでは、少なくとも1回のセマンティクスを持つSUN RPCと最大1回のセマンティクスを持つJava RMI。

セマンティクスを1回だけ持つのはなぜ不可能なのですか？

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

Answer 1

リクエストを実行してからリクエストを実行したことを記録するまでにサーバーがクラッシュした場合、どうなるかを考えてください

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

奇妙なことに、これは（タイムアウト付きで）特許を取得しています： http://www.freepatentsonline.com/7162512 .html 。上記で議論した場合を除き、1回限りを保証するものではありません。

実行してから記録することにより、少なくとも1回取得します。 2つの間にクラッシュが発生した場合、リクエストが繰り返されると再度実行されます。

しかし、「一度だけ」と言うことは実際には実行できません。すべての状況で

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

Answer 2

IBMの WebSphere MQ は、1回だけの配信を提供することを目的としています。実際、これはデフォルトの動作です（前回WMQを使用したとき...）。これは、先行書き込みログとさまざまなロック技術で実現しています。

もちろん、法的文書のどこかに埋もれていることは疑いようがありません。は、「メッセージが1回、複数回配信される場合とされない場合がある」という意味で定義されています。またはたくさん。またはゼロ未満です。＆quot;背中を覆うためですが、電源ケーブルを蹴ったり、軸をネットワークインフラストラクチャに接続するなど、ほとんどの場合に機能します。

Answer 3

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

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

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