[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] When to send publish acknowledgements
|
No. In MQTT 3.1.1 the broker only resends publishes (or pubrels)
on the restart of a connection. It would be up to the client
library to keep the message queued up and retry until the
application accepted the message.
It could be a bit different in MQTT 5.0. There is the
opportunity for the client library to send a negative ack back to
the broker - I don't know of any implementation that does that
though. In that case, I think the broker wouldn't (mustn't?) send
a duplicate, but it could possibly take some other course of
action.
Ian
On 27/07/2021 17:37, Frank Pagliughi
wrote:
Hello Ian and all,
This issue just popped up again for the C++ library. I had not
passed on the ability for the C++ apps to return a not-good value
back to the library, and I would like to fix that now.
But it does beg the question, as Greg had asked... If the app
doesn't return an "OK" value, what happens next? Will the broker
keep sending DUP messages until ACK'ed?
Frank
On 3/30/21 2:51 PM, Greg Troxel
wrote:
Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> writes:
if I understand you correctly, this is what I do in the C client. I
send the PUBACK or PUBCOMP (old style QoS 2) after the message handler
callback has been invoked, and has returned a good result.
What happens if the handler runs for a very long time (in a thread?)?
What happens if it returns some kind of not good result?
Isn't the MQTT implementation still required to ack the message, even if
the client that wants it is misbehaving? Or is there some support in
the specification that the acks are supposed to be from the program that
is using MQTT?
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev