-
Was caught by refactor testNotMessingUpQosLevels away from QMQTT, which didn't trip on this bug.
-
The extraneous creation would happen when multiple subscribes at different QoS levels happen.
-
Also add a test to test all scenarios. This also fixes session clean_start, which was never done since the MQTT5 refactor to clean_start (vs clean session).
-
It timed out sometimes. When it works, it doesn't even take longer, because it's just the timeout.
-
It was caught by an assert. In release mode, this simply meant subscribing to 0 still gave you QoS messages.
-
This was old debug code. The effect is that QoS now doesn't do unnecessary queueing.
-
Fixes assertion error in debug only.
-
It was flakey. I also ported it to the new test client.
-
They now contain sender info of publishes.
-
This requires storing the clientid and username in the Publish object.
-
Only split when they're needed, instead of pre-determining whether I'll need the subtopics. This makes the coming refactor of authentication easier. Also treated user properties with the same brush a bit. Downside: it now always assigns user properties to newly constructed publish objects, even if they are not needed (because the generated packet may only be needed for writing to the client's output buffer). But determining the flow of when and when not they'll be needed is impossible with the coming authentication refactor.
-
It's probably not good for anything.
-
The order packets would (mostly) arrive, is 'retained publish', then 'sub ack'. This is now fixed. This also stablizes test_retained_changed(). The test was also refactored to use the new test client.
-
This prevents confusion when another instance of FlashMQ is running. This is not the final way. For instance, when SSL connections will also be tested, this won't work anymore.
-
A recent refactor caused this fuzz mode to crash because the thread data wasn't set.
-
There was a null dereference on a call of member function Client::sendOrQueueWill(). Null clients shouldn exist in the list and this was the only place it could have come from. But, I never got proof.
-
No issues were reported, but I noticed the theoretical issue.
-
When SSL wants the app to retry, it stands to reason that the local write buffer needs to be grown (read: reallocated) to hold the application bytes. At that point, the buffer is no longer where it was originally. This fixes segfaults.
-
I've see various variations, like mqtt and mqttv31. The 3.1.1 specs are clear what it should be, but the 3.1 specs aren't. So, allowing anything with mqtt in it.
-
Now that parsing and handling of packets is separated, we can use the main code to parse packets in the new FlashMQTestClient. This allows great flexibility in inspecting the server response in a flexible manner. We now also have the ability to make tests for MQTT5 features.
-
Will be used for the test client I have in mind.