Why is exactly once semantics infeasible?
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?
Answer
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)