repeated SUBACKs on same topic send new topic ids #5
Comments
gazally
added a commit
to gazally/rsmb
that referenced
this issue
Jul 13, 2016
If a MQTTS client missed a SUBACK and consequently resent the SUBSCRIBE, rsmb would send the next SUBACK with a different topic id. But later PUBLISHes on that topic would use the first topic id which was unknown to the client. Fix is to use the same check for a previously registered topic in MQTTSProtocol_handleSubscribes that MQTTSProtocol_handleRegisters uses.
jlam732
pushed a commit
to bluerover/rsmb
that referenced
this issue
Oct 27, 2016
If a MQTTS client missed a SUBACK and consequently resent the SUBSCRIBE, rsmb would send the next SUBACK with a different topic id. But later PUBLISHes on that topic would use the first topic id which was unknown to the client. Fix is to use the same check for a previously registered topic in MQTTSProtocol_handleSubscribes that MQTTSProtocol_handleRegisters uses.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
If a client on a noisy network misses a SUBACK packet, it will resend the SUBSCRIBE. Since
MQTTSProtocol_handleSubscribesdoesn't check if a topic is already registered before registering it, it will send the next SUBACK with a new topic id. But later PUBLISHes on that topic will use the first topic id, which the client doesn't know.The fix is to use the same check in
MQTTProtocol_handleSubscribesthatMQTTProtocol_handleRegistersuses to see if a topic is already registered.The text was updated successfully, but these errors were encountered: