为什么一旦语义不可行?

时间:2009-01-06 13:43:17

标签: networking rpc semantics

在RPC语义中,Erlang有最好的希望,SUN RPC至少有一次,Java RMI最多只有一次,但没有人只有一次语义。

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

例如,如果客户端继续重新发送唯一标记的请求,直到收到回复并且服务器跟踪所有处理的请求以便不复制请求。这不是一次吗?

3 个答案:

答案 0 :(得分:23)

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

您可以通过录制请求然后执行请求来获取最多一次。如果你在两者之间发生了崩溃,那么你(错误地)将其记录为执行,所以你不会再这样做了。因此,至多一次

奇怪的是,这个(有超时)获得专利:http://www.freepatentsonline.com/7162512.html。除非我在上面论证,否则它不能完全保证一次。

通过执行它,然后记录它,你至少得到一次。如果您在两者之间发生崩溃,如果重复请求,您将再次执行此操作。

但在所有情况下说“完全一次”并不可行

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

答案 1 :(得分:3)

像IBM的WebSphere MQ这样的高端消息传递总线声称只提供一次交付。实际上,这是默认行为(截至上次使用WMQ时...)。他们通过Write-ahead logs和各种锁定技术实现了这一目标。

当然,我不怀疑在他们的法律文件中埋藏的地方,“恰好一次”实际上被定义为“消息可能会或可能不会被传递,一次,不止一次。或者很多。或者少于零“。为了掩盖他们的背部,但它确实适用于绝大多数情况,包括踢出电源线,将轴线连接到网络基础设施等。

答案 2 :(得分:1)

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

如果客户端放弃尝试(或者如果服务器在完成交易之前或者在发出信号完成之前已经停止了很长时间,取决于它执行这些操作的顺序)那么可能没有办法客户端知道是否收到并处理了请求。实际上,RPC系统可能希望尊重默认的TCP超时,因此不希望必须等待服务器的确定成功或失败。

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