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

Ed Briggs commented on MQTT-257:
--------------------------------

Andrew,
You commented that 'on re connect the number of unacknowledged messages from a previous connection needs to count toward the running total in Local.TxCredit'.   Could you elaborate on what you want to accomplish with this, please?

Suppose we have a persistent session with maximum send window of 10.   It sends 10 PUBLISH qos=2, and all are lost, and the Local.TxCredit = 0.   Following re-connection,  if we did not restore Local.TxCredit to something greater than 0, retransmission would be blocked by flow control.  So adjusting the Local.TxCredit to account for unacknowledged messages on a previous connection, could be a problem.  

Now, a different situation occurs if PUBRELs are pending retransmission.  If Local.TxCredit was set to 10 on re-connect, the retransmission of PUBRELs and consequent PUBCOMPs would cause LocalTxCredit to exceed Local.TxMax.  This could be largely remedied (I think) by clamping Local.TxCredit so that increments and decrements could not create values outside range [0, Local.TxMax].

We *could* do some fancier book-keeping, but I worry about what happens when a client re-connects to a persistent session and receives SessionPresent=0, signifying session context lost.   In this case, I believe the behavior of the client is implementation dependent, and in particular, whether the client MQTT engine should re-transmit unacknowledged messages is unspecified, and hence, any assumptions about flow control based on unacknowledged messages might be invalid.

In any case, I'd be grateful for any further thoughts you might have.


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