[OASIS Issue Tracker] (MQTT-257) Flow Control

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63072#comment-63072 ] 

Ken Borgendale commented on MQTT-257:
-------------------------------------

1. So for any message where we have not received a PUBACK or PUBREC the publisher would re-publish the message and this republish would be subject to normal flow control.  For a message for which the publisher has received a PUBREC but not a PUBCOMP, it sends the PUBREL without any flow control limit, but would decrement Local.TxCredit, possibly making it negative.

2. I still think the issue at DISCONNECT is that at the protocol level we have no idea what has caused the client or server to initiate a DISCONNECT, and we therefore cannot say what it should wait for before sending the DISCONNECT.  The MQTT spec should not be involved with defining how the client or server decides such things, and it is not something we should give any advice about.  If the API is "quiesce and then disconnect" then presumably the action would be to wait for outstanding ACKs and then send the disconnect.  If the APIs is "disconnect immediately", then it would most likely disconnect without waiting.  If the API is "quiesce with a 1 second timeout and then disconnect", I presume the client or server would do that.  It would also be perfectly reasonable for the publisher to treat messages in the queue to be send differently from messages which have been sent and no ACK received in the case of DISCONNECT.

> Flow Control
> ------------
>
>                 Key: MQTT-257
>                 URL: https://issues.oasis-open.org/browse/MQTT-257
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: futures
>    Affects Versions: 5
>            Reporter: Peter Niblett
>
> Developers sometimes ask if there's a way to slow down an MQTT message sender to stop it sending PUBLISH packets faster than the receiver (be it a server or client) is able to process them.
> The receiver can apply back pressure at the TCP/IP level (if it's a TCP/IP transport) or - for QOS 1 and QOS2 - it can delay sending acks so that eventually the sender's inflight message window will fill up, but these mechanisms are a bit crude, and the receiver has no in-band way of letting the sender know what rate is acceptable to it. 
> We need to decide whether this is a problem that affects a significant number of existing or envisaged real-life applications (as opposed to performance and stress tests)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)