为什么恰好一次语义不可行? [英] Why is exactly once semantics infeasible?

问题描述

在 Erlang 寄予厚望的 RPC 语义中，SUN RPC 至少一次，Java RMI 最多一次，但没有人拥有完全一次语义.

In RPC semantics where Erlang has hope for the best, SUN RPC with at-least once and Java RMI with at-most-once but no one has exactly once semantics.

为什么只拥有一次语义似乎不可行?

Why does it seem infeasible to have exactly once semantics?

例如，如果客户端不断重新发送唯一标记的请求，直到收到回复，并且服务器会跟踪所有已处理的请求，以免重复请求.不会正好是一次吗?

For example if the client keeps resending a uniquely tagged request until a reply is received and a server keeps track of all handled requests in order not to duplicate a request. Would that not be exactly once?

推荐答案

考虑如果服务器在执行请求和记录它已执行请求之间崩溃会发生什么?

Consider what happens if the server crashes between carrying out the request and recording that it has carried out the request?

通过记录请求，然后执行它，您最多可以获得一次.如果您在两者之间发生崩溃，那么您(错误地)将其记录为已执行，因此您不会再这样做了.因此最多一次

You can get at-most-once by recording the request, then carrying it out. if you get a crash between the two, then you've (erroneously) recorded it as carried out, so you won't do it again. Hence at-most-once

奇怪的是，这个(带超时)已获得专利:http://www.freepatentsonline.com/7162512.html.除了我上面所说的，它并不能保证恰好一次.

Bizarrely, this one (with timeouts) is patented: http://www.freepatentsonline.com/7162512.html. Except as I argue above, it doesn't guarantee exactly-once.

通过执行它，然后记录它，您至少可以获得一次.如果两者之间发生崩溃，如果请求重复，您将再次执行.

You get at-least-once by carrying it out, then recording it. If you get a crash between the two, you'll carry it out again if the request is repeated.

但是在所有情况下都说恰好一次"并不真正可行

But it's not really feasible to say "exactly once" in all circumstances

(网络错误而不是服务器崩溃也有类似的情况)

(There are similar scenarios for network errors rather than server crashes)

这篇关于为什么恰好一次语义不可行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！