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

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

In the face-to-face MQTT-TC meetings in Redmond, an informal consensus was reached that flow control for QoS 0 would not be provided by this mechanism.  In addition, as a consequence subsequent discussions with Ian Craggs and Ken Borgendale, I am revising the flow control scheme to restrict not just QoS 1 and QoS 2 PUBLISH messages, but also SUBSCRIBE and UNSUBSCRIBE messages to avoid re-ordering PUBLISHES and SUBSCRIBES. This re-ordering might create difficulties in request/reply interactions which assume a subscription needs to be in place before PUBLISHING a message which might generate a reply.  Ian Craggs points out that this is not strictly necessary because applications can wait for the SUBACK or UNSUBACK before issuing PUBLISHES that may require an answer topic to be in place.

I am currently studying whether DISCONNECTS should be subject to flow control  to prevent a DISCONNECT message from overtaking PUBLISH and SUBSCRIBE messages delayed by flow control. We will need to determine whether proposed changes in session control (Simplified Session Control) require special treatment of the DISCONNECT message (which is part of the session control mechanism) regarding flow control.

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