[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [paho-dev] When to send publish acknowledgements
|
OK. Got it. Thanks, everyone.
Frank
On 7/28/21 7:41 AM, Andy Stanford-Clark
wrote:
in the olden
days,
we used to assume the publisher would retry the messages on a
timer if
it hadn't received the appropriate ack.
It took a
while
before we realised that TCP/IP actually does assured delivery,
so as long
as the connection is still intact, the original message WILL get
there,
and sending it again (particularly for large messages over slow
links)
just adds to the congestion.
Hence we gave
the advice to only republish on a reconnect, but the "and other
times
if you want to" is a vestige of our earlier (lack of)
)understanding.
Andy
Andy Stanford-Clark
IBM Corporate Strategy - SPEED leader for EMEA
Distinguished Engineer, Master Inventor, IBM Quantum Ambassador,
Member IBM Academy of Technology, Fellow BCS
Visiting Professor at Newcastle, Southampton and UEA.
Tel: +44 (0)7801 787096 [internal: 37 277624] twitter: @andysc
From:
"Roger
Light" <roger@xxxxxxxxxx>
To:
"General
development discussions for paho project"
<paho-dev@xxxxxxxxxxx>
Date:
28/07/2021
00:27
Subject:
[EXTERNAL]
Re: [paho-dev] When to send publish acknowledgements
Sent
by: "paho-dev"
<paho-dev-bounces@xxxxxxxxxxx>
Hi Ian,
I think you're mistaken - in v5.0 the broker/client must only
retry
messages when it reconnects. In v3.1.1 it is required to retry
messages on reconnect, but it is not forbidden to retry
messages in
other circumstances (I would argue that it is a bad idea to
retry in
other circumstances though).
Regards,
Roger
On Tue, 27 Jul 2021 at 20:08, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales
with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6
3AU
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
