[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=63110#comment-63110 ] 

Andrew Banks commented on MQTT-257:
-----------------------------------

Ed, thanks. I was primarily addressing the PubRel case that you mention.

Firstly, if at reconnect there are some unacknowledged PubRels which will be re transmitted, then these need to cause Local.TxCredit to be decremented as they are re transmitted. Or some equivalent implementation. Hopefully this is obvious, it just needs to be made clear, that's all.

Secondly, if at reconnect there are say 10  unacknowledged PubRels which will be re transmitted, but LocalTxCredit is negotiated to be say 9. Then the sender cannot immediately resend all of the PubRels as it might do under the current specification. Instead it would have to wait until at least one of the PubRels is acknowledged with a PubComp before it can re transmit the 10th PubRel. 

> 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)