search

pascaldekloe / mqtt

Message Queuing Telemetry Transport Client 🤖
Other
41 stars 4 forks source link

Clarification on AWS IoT unacked QoS 1 publish requests #6

Closed lbjarre closed 3 months ago

lbjarre commented 3 months ago

Hello,

I have a question regarding the wiki entry for using this client with AWS IoT. The entry notes that AWS deviates from the standard on several points and recommends users to configure the client behavior around QoS1/2 publish packets.

Regarding QoS 2 I understand the recommendation. As noted AWS deviates here by not implementing exactly once delivery at all. Clients should configure their client accordingly by disabling publishing via QoS 2, which as far as I can tell means setting ExactlyOnceMax option to 0. The wiki entry is a bit vague here however, I can see how one could interpret it to mean that 1 is also a valid value which I believe should not work at all.

With QoS 1 there is not the same deviation from the MQTT standard as AWS implements this. There is however a quota related to how many unacknowledged QoS 1 publish requests are allowed for a single client, which is 100. If I understand this correctly the client should be able to handle being configured with AtLeastOnceMax set to 100. This again seems contradictory to the wiki entry.

Do you remember what the recommendation in the wiki entry was based on? Does my reading of the quotas seem reasonable, and if so should we update the wiki entry?

BR, Lukas

pascaldekloe commented 3 months ago

Good catch Lucas. ExactlyOnceMax must be 0 for AWS indeed.

AWS breaks QoS 1 with: “The message broker doesn't guarantee the order in which messages and ACK are received.” This client will break the connection on any ACK that is out of order (and automatically reconnect). Set AtLeastOnceMax to 1 instead of 100 as a workaround.

I'll update the wiki.

lbjarre commented 3 months ago

Thanks for the quick reply!

Reg. out of order delivery: I'm not familiar enough with the standard here but I assume that a well behaved client should expect acks in order. It does feel like a less important feature however, i.e. certain clients might not care about the order. Would you be open to consider making it opt-out for the client, or would that break compliance with the specification?

pascaldekloe commented 3 months ago

Mandatory statement MQTT-4.6.0-2 from the 3.1.1 specification leaves no room for interpretation. “Client MUST send PUBACK packets in the order in which the corresponding PUBLISH packets were received (QoS 1 messages).”

Send my greetings to Frank.