networking - 为什么恰好一次语义不可行？

Question

在 Erlang 寄希望于最好的 RPC 语义中，SUN RPC 至少一次和 Java RMI 最多一次但没有人有完全一次的语义。

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

例如，如果客户端不断重新发送一个唯一标记的请求，直到收到回复，并且服务器跟踪所有处理的请求以便不重复请求。那不正是一次吗？

Answer 1

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

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

奇怪的是，这个（有超时）专利：http ://www.freepatentsonline.com/7162512.html 。除了我上面所说的，它不能保证完全一次。

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

但是在所有情况下都说“恰好一次”并不是真的可行

（网络错误也有类似的场景，而不是服务器崩溃）

Answer 2

像 IBM 的WebSphere MQ这样的高端消息传递总线确实声称提供一次交付。事实上，这是默认行为（截至我上次使用 WMQ 时...）。他们通过预写日志和各种锁定技术来实现这一点。

当然，我不怀疑埋在他们的法律文件中的某个地方，“恰好一次”实际上被定义为“消息可能会或可能不会被传递，一次，不止一次。或很多。或少于零。” 为了掩盖他们的背部，但它在绝大多数情况下确实有效，包括踢掉电源线，将斧头带到网络基础设施等。

Answer 3

我认为答案是你需要无限的时间来获得这些语义，因为客户端必须等待来自服务器的明确结果，而这可能永远不会到来。这个要求在真实网络上是不切实际的。

如果客户端放弃尝试（或者如果服务器在完成事务之前或在发出信号完成之前长时间停机，这取决于它执行这些操作的顺序），那么客户端可能无法知道请求是否被接收和处理。在实践中，例如，RPC 系统可能希望遵守默认的 TCP 超时，因此不希望必须等待服务器确定的成功或失败。

不过这是一个猜测：我从未设计过 RPC 协议。