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

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

I still suggest that flow control be only for PUBLISH.  Any client using request/response should wait for the SUBACK for the reply-to topic before publishing a request with that as the reply-to topic.  There is no requirement for PUBLISH and SUBSCRIBE to be processed by the server in any order relative to each other, regardless of the order in which they are sent by the client.  Even for PUBLISH the requirement for ordered processing is restricted to same connection, same topic, and same QoS.

I also do not see the point of constraining DISCONNECT by flow control.  In any case where the publisher has not received an ACK before a disconnect, it is required to re-publish the message on reconnect. That is true regardless of what triggers the disconnect. Thus it is reasonable for a client application to not disconnect until it has received the ACK for all publishes (at least in the non-error case). It does not help at all for the client library to delay sending the DISCONNECT until after it has sent any PUBLISH packets.

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