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

Ken Borgendale commented on MQTT-257:
-------------------------------------

My preference for a QoS=0 flow control is to have SUSPEND and RESUME control packets.  However, we need to understand that some of our clients (and indeed some servers) are pretty stupid and might not have any way of suspending publish.  So the meaning of them would be:

SUSPEND:  Refrain from sending any more QoS=0 messages as doing so could cause them to be discarded.  
RESUME: Resume sending QoS=0 messages.  

Any number of SUSPENDs can be sent and a single RESUME will terminate this mode.  A RESUME while already in RESUME mode has no meaning.

A client which is unable to refrain from publish can ignore the suspend.  This could be simple clients which just periodically send messages, or clients which publish at QoS=0 and do not even look at the receive side of the connection.  For clients or servers who do honor it, it might just mean that the message is thrown away before the publish rather than after being received.

If we want to deal with latency issues then we can put a count on RESUME (you can send N QoS=0 messages).  This gives finer grain control over QoS=0 flow but opens up more error conditions.  I think we should go simple and not do this.

While I would like to have a server initiated PING as an aliveness check,  I do not think we should overload PING and PINGRESP.  I am also in favor of keeping the definition of topics (even $ topics) as out of scope.  As we are currently using 28 of the 256 encodings of the command/flags byte, I think we can find room for two more control packets.

As the mechanisms for QoS=0 flow control, and those for QoS>0 flow control seem to be radically different, we might want to split them up into two JIRAs.  I seems reasonable that we would deal with one but not the other of these.


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