Good catch—let me clarify what QoS 2 in BinaryRPC really does.
It follows the MQTT-style 2-step handshake:
1. Sender → `PUBLISH(id, data)`
2. Receiver → `PUBREC(id)` // stored as “seen but not completed”
3. Sender → `PUBREL(id)`
4. Receiver → `PUBCOMP(id)` // marks id as done, then passes data to the app layer
While an id is in “seen” state the receiver drops duplicates, so the message is
delivered to user code exactly once per session even if the socket retries.
If the client reconnects with the same session-key, the server reloads the
in-flight id table, so duplicates are still filtered.
If the session is lost (no session-key) we fall back to at-least-once because
there is no common store.
So: “exactly once within a persisted session; effectively once” as long as the
application is idempotent. I’ll update the docs to state this more precisely.
Thanks for pointing it out!
It follows the MQTT-style 2-step handshake:
1. Sender → `PUBLISH(id, data)` 2. Receiver → `PUBREC(id)` // stored as “seen but not completed” 3. Sender → `PUBREL(id)` 4. Receiver → `PUBCOMP(id)` // marks id as done, then passes data to the app layer
While an id is in “seen” state the receiver drops duplicates, so the message is delivered to user code exactly once per session even if the socket retries.
If the client reconnects with the same session-key, the server reloads the in-flight id table, so duplicates are still filtered. If the session is lost (no session-key) we fall back to at-least-once because there is no common store.
So: “exactly once within a persisted session; effectively once” as long as the application is idempotent. I’ll update the docs to state this more precisely. Thanks for pointing it out!