Publish message flows

[Nicolas Jouanin]

Hi,

This mails deals with QOS1 and QOS2 message delivery retry.
Paragraph 4.4 describes message delivery retry on reconnect, but I wonder how clients and broker are expected to deal with message delivery retry when running. I mean for example, let’s say a broker is getting saturated and can’t immediately reply PUBREC to a client PUBLISH. Should the client wait indefinitely or should it consider redelivery after a certain timeout ?

Another question that comes to my mind and may be related, is how current implementations (like mosquito) handle features like ACL? What kind of message is returned to the client if a published is denied ? I don’t see any way to handle this with the current protocol, there may be an issue if there’s no reply to a denied PUBLISH. Client may understand it as a delivery timeout ?

Thanks for your replies.

Nico.

[Roger Light]

Hi Nico,

With regards to redelivery whilst connected, I've been taken to the
opinion that it may be counter productive. If the broker is struggling
to keep up then sending more messages isn't going to help. If you've
not received a reply because the connection has dropped somewhere and
you've not noticed it yet, then you will resend on reconnect.

ACL - I would complete the message flow if a message is denied,
otherwise the client may keep retrying as you suggest. Hopefully there
will be a way to indicate a negative publish result in the future.

Cheers,

Roger

> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google Groups "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.

[Nicolas Jouanin]

Hi, Roger thanks for your reply.

I see that mosquito has a retry_interval parameter which, according to the documentation, allows publish retry when no response is received after a certain time interval. Is it used for redelivery while connected ?

Concerning ACL, I guess there’s a pitfall here, has client can consider a message has been delivered while the broker may discarded it. An option could be to change PUBACK and PUBREC messages and something like a flag so the receiver can inform the send that the message is accepted or discarded. This may be disputed in a new message thread.