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

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

Your suggestion is interesting.  In the currently proposed scheme, the flow of QoS 0 is not affected by QoS > 0 flow control, so the sender can keep sending QoS 0 PUBLISH messages even if QoS > 0 is suspended.. This may be possible to justify (rationalize?) because QoS 0 messages are not queued to topics on 'persistent sessions' (CleanSession=0) nor are they retransmitted following re-establishment of a transport session, so they won't create a flood of messages that might occur with QoS > 0 messages in those two cases.  Ultimately, TCP flow control can be invoked for QoS 0.

We do, however, need to keep sending PUBACK, PUBREC, PUBREL, PUBCOMP or deadlock will ensue. We also need to keep sending PUBREQ/PUBRESP, and do not delay any of the SUBSCRIBE/UNSUBSCRIBE/SUBACK/UNSUBACK or DISCONNECT. So there will always
be *some* traffic.  

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