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

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

Having a pause/resume or any flow control is pointless if the message rate of published messages stays above the rate that the client for long periods of time, but is highly useful to deal with spikes.  A good example is when a durable subscriber connects and gets a large number of messages.  The server may be willing to send them all at once, but the client might get them too fast.

The in-flight window can be used for QoS>0 messages to implement a sort of flow control, but there is no way within the protocol to set it.  Thus we are left with what is probably course grain admin setting.  For QoS=0 the only flow control is to stop receiving from the TCP connection.  Of course this stops not only messages but also ACKs.

I would prefer a method of sending a request (in either direction) to slow down sending messages.  It would be good if the other end receiving this request honors it, but it should not be required to do so as there might be some reason it cannot.

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