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

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

1. I presume that we will send the credit as an Int2, and thus you can only send 0-65535.  If we treat 0 (or not specified) as equal to 65535 that gives us no invalid values.

2. There are several statements about client must send and server must send.  We also talk about default values.  I assume these are Indentifier/Value pairs and do not need to be specified.  

3. The statement about the default says the receiver will set its TxMax to 65535.  In fact it is allowed to set it to any value less than or equal to the 65535.

4. Disconnect handling:  The sender of QoS>0 messages is required to persist those messages and send them at some point.  It is not required to do so before closing the current connection.  We do not know what causes the sender to initiate a disconnect, and therefore cannot tell whether the correct action is to delay the disconnect until all messages have been send and ACKs received, to disconnect immediately, or anything in between.

5. Immediate transmission: The assumption of any client which proceeds without waiting for a CONNACK is that it knows what the server's response will be.  If such a client is wrong then presumably the subsequent packets it sends might fail.  This is true for this value as for other things such as authentication.

6. It is unclear how flow control interacts with the unified packet ID JIRA (mqtt-287).  Does the credit only apply to PUBLISH, or does it apply to other packets using packet identifiers as well?

7. I believe the imperative should be:  The sender SHOULD NOT have more publishes outstanding that the receiver requested and that the receiver MAY disconnect the sender if it exceeds this value.

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