Limiting queued message depth purely based on message count is hard to
control for memory constrained devices. The size of messages can vary
wildly, from a few bytes, to a few kilobytes. Support a new
max_queued_bytes option, and drop packets when the first limit is
reached. Option defaults to 0 (disabled) by default.
Support also a max_inflight_bytes variable, with similar behaviour.
Fixes (partof) https://github.com/eclipse/mosquitto/issues/100
This pulls up some helper routines for calculating whether to allow
inflight or queuing, resolving some inconsistences in connection
resumption.
Signed-off-by: Karl Palsson <karlp@etactica.com>
libmosquitto shouldn't cancel threads it didn't create. This change
allows us to keep track of whether threads were created by the library
or by external code.
Thanks to Josip Ćavar.
Bug: https://github.com/eclipse/mosquitto/issues/166
Split message queue in two queues: in-flight and queued to avoid the
need to iterate over all messages.
Signed-off-by: Pierre Fersing <pierre.fersing@bleemeo.com>
Fix the case where a message received just before the keepalive timer
expired would cause the client to miss the keepalive timer.
Thanks to Graham Benton.
This change in behaviour can be justified by considering when the
timeout may have occurred.
* If a connection is unreliable and has dropped, but without one end
noticing, the messages will be retried on reconnection. Sending
additional PUBLISH or PUBREL would not have changed anything.
* If a client is overloaded/unable to respond/has a slow connection then
sending additional PUBLISH or PUBREL would not help the client catch
up. Once the backlog has cleared the client will respond. If it is not
able to catch up, sending additional duplicates would not help either.
