Menu
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?
292
For the at-most-once delivery semantic, a message is delivered either one time only or not at all. Failure to deliver a message is typically due to a communication error or other disruption that causes consumers to not be able to handle an event.
If the server crashes before the message is sent from the client, the message will be lost and the client will be blocked in the receive block. The solution is to monitor the server process using Process.
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
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)
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
