CODEWITHSUNDEEP
embeddedmqttiotpaho
frogatto
frogatto

Reputation: 29287

What's the problem of always using QoS 0 in a MQTT session?

I've been developing an always-connected MQTT client on a strictly resource constraint embedded device using Paho C library. Here's my questions:

  1. Apart from the broker and client crashes, Are there any other reasons for a QoS 0 message to not arrive at the destination?

  2. In a subscription request, is it possible that broker does not accept the requested QoS?

  3. Under what circumstances could a QoS 1 message be received multiple times?

Upvotes: 2

Views: 1285

Answers (1)

hardillb
hardillb

Reputation: 59866

(1) A message delivered at QOS0 via TCP/IP is only guaranteed to have reached the remote machine's TCP stack not the actual application that is running (be that a MQTT client or MQTT broker).

Messages sent at higher QOS are acknowledged by the application not just the TCP/IP stack of the host machine so mean that you can be more certain it has actually been processed.

(2) Some brokers may only support QOS 0 or QOS 0/1 (e.g. AWS IoT) and as mentioned in the doc the SUBACK message includes the QOS level that was granted which may not match what was requested. So even if the subscribing client

(3) If the client crashes having processed the message but before sending the PUBACK then the broker can try and deliver the message again when the client reconnects.

Upvotes: 3

Related Questions