Yeah, I don't want to suffer the excess overhead of QoS==2, so I use QoS==1... the continuous retransmission thing I had heard that MQTT does... The thing is, for the protocol to work, it has to leave some time for the acks to happen at all, so it cannot be too frequent. This guy did the homework:
It shows retransmissions happening 9 seconds, 7 seconds, then 20 seconds later...
In the best case, there is no queueing on the client, and processing on the far end fits in such an interval, so it doesn't make any difference.
IF the library is as dumb as described, where it start resending rapidly and unconditionally, then
If you have large queueing on the client... like 5 minutes... well it also doesn't matter whether you are acknowledging in the library or not... so... it is going to behave very badly no matter what level the ack is done at.
It is only in the middle case, where you have either: a little queueing, large propagation delay, or a potentially large processing time, where it will cause extra message sends by the broker.
Does anyone know of a reference that describes how brokers are supposed to decide when to resend with QoS==1 ? I looked through the OASIS standard, and did not see anything,
Ideally, the broker would take hints from the rate at which acknowledgements from the consumer arrives, and only resend when it has good reason to believe they are "late".
In such as case, the broker will see the receiver acknowledging messages gradually later and later, and it should accumulate, say a mean time to acknowledgement receipt, and only resend after... oh... twice that time has gone by...
That would be robust... anybody know if any brokers actually do this sort of thing?
I'll take a look at mosquitto source... but someone who knows might be easier.