Reputation: 2313
I am currently using the PAHO MQTT C++ library (but should apply to other flavors of the MQTT library as well, especially C) to implement an MQTT client asynchronously. From time to time, the MQTT server does not respond with a SUBACK, after a SUBSCRIBE is sent even though later PUBLISH/PUBACK pairs are successful.
I am currently not interested why the SUBACK is missing (I expect that can just happen that a single packet is lost...), but what should I expect from the MQTT client library in this case?
My initial expectation was that after some timeout, a failure handler is called, but I am not sure if there is even such a timeout or if it is expected behavior that if I do not check actively (e.g. by using wait_for) it is just pending in the queue forever?
Upvotes: 0
Views: 1904
Reputation: 438
According to MQTT specification version 3.1.1, when the Server receives a SUBSCRIBE Packet from a Client the Server MUST respond with a SUBACK Packet. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718067
But the specification doesn't describe what should a client do when there is no SUBACK. So it is definitely up to you. (or your customer) Your application specification should say what a client does in this case, which is not against the MQTT specification.
In my opinion, it is better not to go the further step of sending PUBLISH. It would be a kind of a fail-safety.
Upvotes: 1
Reputation: 394
The specification (3.1.1) is not very clear about this situation. In my opinion it is flawed.
The broker must respond a SUBSCRIBE with a SUBACK. It is however allowed to send PUBLISH packets before it sends the SUBACK.
There is no real QoS for subscribe/unsubscribe messages. Furthermore, the SUBACK packets are not part of the session data. So it is entirely up to the broker's implementation to do retries or not.
Upvotes: 1