-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
publish / subscribe / unsubscribe methods return a notice future that waits publish (QoS0), PubAck (QoS1) and PubRec (QoS2) #851
base: acked
Are you sure you want to change the base?
Conversation
* fix: v5 doesn't write outgoing packets onto network bytebeamio#825 (comment) * same for pingreq
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question
rumqttc/src/state.rs
Outdated
// Notify user about the publish, pubrel and pubcomp will be handled in background | ||
if let Some(tx) = tx { | ||
tx.success(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is "handled in the background" supposed to mean in this context.
From what I understand, this makes the NoticeFuture
complete on PubRec
instead of PubComp
for ExactlyOnce
QoS, which is the wrong behavior from what I understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the notice is to confirm that the message actually received by broker.
So in QoS0 it's noticed on message sent (since there is no ACK), in QoS1 it's noticed on ACK reception, in QoS2 it's noticed on REC which indicates broker accept the message. The PubRel and PubComp do not affect the broker reception of message, but some way to let broker release QoS2 message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
QoS2 it's noticed on REC which indicates broker accept the message. The PubRel and PubComp do not affect the broker reception of message, but some way to let broker release QoS2 message.
The original code by @de-sh notifies on PubComp
not on PubRec
for QoS2 which I believe to be the correct behavior. Because when using this feature, I want to be notified once I'm certain the message will fulfil it's QoS. For QoS2, the message is only sent after sending PubRel
to the broker, which the broker then acknowledges by responding with PubComp
. If the client dies after receiving PubRec
but before the broker received PubRel
, the message might get lost and the NoticeFuture
shouldn't resolve for a message that might not fulfil it's QoS, which for 1 and 2 means it not getting lost.
At least that's my take based on my understanding of how MQTT QoS works and my take on the NoticeFuture
feature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is we can get notice on message ownership transfer, which is mentioned in the section 4.4, "When its original sender receives the PUBREC packet, ownership of the Application Message is transferred to the receiver". But I am totally fine to be noticed by PUBCOMP, where message ownership definitely transferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW I see your works on migrating this ack wait feature to main in #883, hoping the PR and discuss here can help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is we can get notice on message ownership transfer, which is mentioned in the section 4.4
Yeah, but that is transferring it to the broker, right? My understanding was what is described in Method A
in this non-normative example in the spec: https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Figure_4.3_%E2%80%93 In that case the message is only delivered onwards after the receiver has received PUBREL
. (although for Method B
it sends it with the PUBLISH
already, so I'm kind of confused)
BTW I see your works on migrating this ack wait feature to main in #883, hoping the PR and discuss here can help.
Yeah, I was looking at this PR for reference, but basically wanted to preserve the original commits for easier rebasing/updating with main and making it easier to diff to main. Also there were a few more commits in the acked
branch since you made this PR, those are also included there.
commit 518773d Author: CQ Xiao <[email protected]> Date: Tue May 21 14:47:32 2024 +0800 rumqttc: resume session only if CONNACK with session present 1 (bytebeamio#864) * Check if session present to restore pending publishes. * Modify changelog. * remove changes that don't seem to be related * refactor: improve readability * feat: apply changes to v4 * Remove session_expiry_interval related code. * test: set clean session * test: broker saved session * test: fix resume reconnect --------- Co-authored-by: Devdutt Shenoi <[email protected]> Co-authored-by: Devdutt Shenoi <[email protected]> commit 67d9ca7 Author: CQ Xiao <[email protected]> Date: Thu May 16 23:05:10 2024 +0800 feat(rumqttc): set `session_expiry_interval` in v5 (bytebeamio#854) Co-authored-by: Devdutt Shenoi <[email protected]> commit 98997d1 Author: CQ Xiao <[email protected]> Date: Wed Jul 3 18:13:54 2024 +0800 HashMap -> VecDeque, cleanup
Some updates for reference:
|
Hi @xiaocq2001 , thanks for your work, this feature is exactly what I need for my current project. I can't wait for the upstream, and your PR seems quite promising, so how mature is your PR? If I can spend some effort to do the tests, can I use your PR right now? |
Feel free to test and use that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please provide your suggestions against #916
@@ -12,6 +12,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
* `size()` method on `Packet` calculates size once serialized. | |||
* `read()` and `write()` methods on `Packet`. | |||
* `ConnectionAborted` variant on `StateError` type to denote abrupt end to a connection | |||
* `set_session_expiry_interval` and `session_expiry_interval` methods on `MqttOptions`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the extremely late response, if you are still interested in contributing this change, please do open a separate PR. Currently this PR will be hard to accept given it has deviated from the issue focus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For session expiry interval support, it's already done in #854.
I'v done integrating with your |
Thanks @KillingJacky! |
Type of change
Added reason code for PubAck/Rec/Comp.
Fix notification flow for NoticeFuture and Eventloop.
See discuss #805
Checklist:
cargo fmt
CHANGELOG.md
if it's relevant to the users of the library. If it's not relevant mention why.