-
This needed a separation: getting the current thread, and getting the thread of the client you're queueing a command for. This also resolves a circular reference between Client and ThreadData.
-
Instead of the thread data, which didn't make sense.
-
This required adding a global stats object. It also contains a bit of refactor to make a type out of the derived counters.
-
This makes much more sense than returning the amount of messages sent all the way up the call stack.
-
They don't need object state.
-
It tested the wrong thing. Tests still pass.
-
This fixes clients being disconnected after reducing the max value and reloading the settings.
-
The code allowed one to try to upgrade a read lock to a write lock, which would/could fail. In the existing code, the only attempted double lock was a write lock, so this change doesn't actually fix anything, but it's clearer, and we can make do with the lock that was removed. It just takes a bit more overhead on app start-up, to place a lock per message.
-
It was reversed...
-
Check events are placed in a sorted map based on the last activity and keep-alive interval of the client. This makes it more accurate and reduces system load because it saves unnecessary checking.
-
This fixes wrong ones on various distros.
-
This is required to be able to put them all in the repo with reprepro.
-
I don't understand it still works on Travis CI though.
-
There's no point in keeping a vector per nanosecond.
-
There's no point in keeping a vector of removals per nanosecond.
-
This is theoretical, because I never called addCallback() after having started the timer.
-
This is fast(er).
-
This is way faster.
-
This should fix corruption. There were inexplicable stalls of timed events, and the debugger showed the names were all corrupted. std::sort can do that sort of thing, apparently.
-
And fix off-by-one error.
-
This implements the first testing version of MQTT5 support.
-
It merely drops packets when they exceed it. The specs are unclear about whether you're supposed to delay transmission until the quota is non-negative again. I decided against it because of increased complexity, and because on a continously overloaded client, this makes no sense. Effectively, this formalizes the 'max qos pending' mechanism that was already in place. It also includes PUBACK/PUBREL/PUBCOMP error handling, because that needed to be done for proper quota control.
-
The only thing it did was false trip the fuzzer.