16

I am studying Distributed Systems and when it comes to the RPC part, I have heard about these two semantics (at-most-once and exactly-once). I understand that the at-most-once is used on databases for instances, when we don't want duplicate execution.

First question:

How is this achieved? How does the server know that it shouldnt execute the request again? It might be a duplicate but it might be a legitimate request as well.

The second question is:

What is the difference between the two semantics in the title? I can read :). I know that at-most-once might not be executed at all but, what does exactly-once do that guarantees the execution?

BrunoMCBraga
  • 652
  • 2
  • 7
  • 23

5 Answers5

16

Here is a pretty good explanation of the different types of messaging semantics for your second question:

At-most-once semantics: The easiest type of semantics to achieve, from an engineering complexity perspective, since it can be done in a fire-and-forget way. There's rarely any need for the components of the system to be stateful. While it's the easiest to achieve, at-most-once is also the least desirable type of messaging semantics. It provides no absolute message delivery guarantees since each message is delivered once (best case scenario) or not at all.

At-least-once semantics: This is an improvement on at-most-once semantics. There might be multiple attempts at delivering a message, so at least one attempt is successful. In other words, there's a chance messages may be duplicated, but they can't be lost. While not ideal as a system-wide characteristic, at-least-once semantics are good enough for use cases where duplication of data is of little concern or scenarios where deduplication is possible on the consumer side.

Exactly-once semantics: The ultimate message delivery guarantee and the optimal choice in terms of data integrity. As its name suggests, exactly-once semantics means that each message is delivered precisely once. The message can neither be lost nor delivered twice (or more times). Exactly-once is by far the most dependable message delivery guarantee. It’s also the hardest to achieve.

High-level overview of message delivery semantics

That's all part of this blog post about Exactly-once message processing (Disclosure: I work for Ably)

Hope this helps

Ramiro Nuñez Dosio
  • 169
  • 1
  • 5
4

In cases of at most once semantics, request is sent again in case of failure, but request is filtered on the server for duplicates.

In exactly once semantics, request is sent again, request is filtered for duplicate and there is a guarantee for the server to restart after failure and start processing requests from where it crashed.

But exactly once is not realizable because what happens when client sends request, and before it reaches the server, server crashes. There is no way of tracking the request.

http://de.wikipedia.org/wiki/Remote_Procedure_Call#Fehlersemantik

Diogo Cruz
  • 66
  • 12
Kahn
  • 755
  • 3
  • 11
  • 28
  • 6
    This is incorrect! At most once, means the client will NOT send a request again if it doesn't receive a response. In the at least once semantics, the client will send the request again, and the server will (or will not) do the deduplication, depending if the operation is idempotent or not – Michael P Jul 07 '19 at 17:51
1

To correct Hesper's answer-

Earlier, exactly once RPC was not realisable but a research paper in 2015 [1] proved that it is possible to do so. Basically RIFL paradigm guarantees safety of exactly one execution of an RPC that is executed is stored durably

[1]: Lee, Collin, et al. "Implementing linearizability at large scale and low latency." Proceedings of the 25th Symposium on Operating Systems Principles. ACM, 2015

zorro
  • 94
  • 2
  • 10
  • It "proves" it on very broad assumption that it's possible to atomically store a record in database AND reform a side effect, and no actual proof is provided. In reality (sending emails, issuing some HTTP POST requests etc.) it's indeed not possible, because if you first send an email, then crash just before you store "completion record", and the operation result is lost. – toriningen May 05 '20 at 18:31
0

Bump, I'm studying this too and found this, hope it helps (helped me),

At-least-once versus at-most-once?

let's take an example: acquiring a lock
if client and server stay up, client receives lock
if client fails, it may have the lock or not (server needs a plan!)
if server fails, client may have lock or not
at-least-once: client keeps trying
at-most-once: client will receive an exception
what does a client do in the case of an exception?
need to implement some application-specific protocol
ask server, do i have the lock?
server needs to have a plan for remembering state across reboots
e.g., store locks on disk.
at-least-once (if we never give up)
clients keep trying. server may run procedure several times
server must use application state to handle duplicates
if requests are not idempotent
but difficult to make all request idempotent
e.g., server good store on disk who has lock and req id
check table for each requst
even if server fails and reboots, we get correct semantics
What is right?
depends where RPC is used.
simple applications:
at-most-once is cool (more like procedure calls)
more sophisticated applications:
need an application-level plan in both cases
not clear at-once gives you a leg up
=> Handling machine failures makes RPC different than procedure calls

quoted from distributed systems and paradigms 2nd edition

Vitor Mota
  • 255
  • 2
  • 13
0

For the first question I believe that each request should have a unique id attached to it. Therefore even if the client sends two requests that have the exact same command the server is able to filter and distinguish via the unique id of the request.

For the second question I think this article helps define the semantics for an rpc call. http://www.cs.unc.edu/~dewan/242/f97/notes/ipc/node27.html

kevb
  • 1
  • 1