Ian Craggs
Ian Craggs
Yep, that's what it does, or is supposed to do. Except if you connect cleansession=false, then the onFailure callback isn't called until destroy() because you might reconnect and complete the...
It still seems odd to me for an asynchronous API, but I'm glad it was useful!
If you have connected cleansession=false, then a disconnect is merely an interruption in the TCP connection. There is no way of telling that you want to reconnect now, or later...
@fpagliughi we might need a close function here (or a similar name) to allow the client object to be cleaned up including callbacks for any outstanding messages before the destroy...
Yes, destroy does that if the session hasn't been closed before. If you connected with cleansession=true, then all the close session processing will be done on disconnect. But you can't...
MQTTClient_destroy() cleans up all the resources associated with a client object. It should only be called when the client is completely and properly disconnected so that those resources are not...
There's no test, so I'd like to know out of interest, did you try out this change and have it working?
Ok, I was just wondering how I could test it, so that a test could be added to the automated suite. Is there some particular Mosquitto configuration for instance? The...
I put a change in the develop branch which will affect/fix this.
I didn't put a struct version number in MQTTAsync_successData, which could be an issue for backward compatibility at the binary level. I did in the MQTT 5.0 version as that...