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

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

Hi Jonathan

There were several approaches we I've been pondering, and would be interested in your thoughts.

1. Sending a credit size of 0 in the CONNECT/CONNACK is an error. We could either send an error message and disconnect, or ignore it.  OR
2. A credit of 0 means the flow control mechanism is disabled. That is, the sender does not use flow control at all.  This might be useful if we found
    that in some (currently unforseen) situation, the use of flow control is problematic (e.g. a broken implementation). 

Another interesting question,  is the presence of the flow control advertisement mandatory in the CONNECT and CONNACK?  If not, should the receiver use
65535 if there is no advertisement ?

I think the simplest approach is to require the fields to be present, and to use zero to disable flow control. There might be a subtle difference between
disabling flow control and using a value of 65535 and maybe its worth while to have the option to disable it.

Thoughts?


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