This comes in the form of:
* Per listener maximum_qos option, which can be in the range 0-2.
* Changes to mosquitto_publish*() to return MOSQ_ERR_QOS_NOT_SUPPORTED
if attempting to publish with a higher QoS than supported.
* Bridges will downgrade messages to match the maximum QoS.
More tests on the broker side (specifically bridges) are required. This
needs bridge support for MQTT 5 first.
Relate to issues #327 and #63.
mosq->sock may be closed before FD_SET(mosq->sock, &writefds) and
FD_ISSET(mosq->sock, &writefds) but after judgement in line 947
if(mosq->sock != INVALID_SOCKET). FD_SET(-1, ...) and FD_ISSET(-1, ...)
would certainly crash.
Signed-off-by: Zard1096 <mr.zardqi@gmail.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
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.
If the socket pair is still opened on reconnect, close it before
creating it again (just like the state variables). Otherwise, these
sockets are leaked on multiple mosquitto_connect() calls.
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
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.
Roger A. Light
Pierre Fersing
Zard1096
Teun Lassche
Simon Wunderlich
Anmol Sarma