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

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

MQTT WD04 is missing several vital elements concerning flow control

1. The following text, which describes the operation flow control must be added.


Operation of Flow Control

If a client or server wishes to limit the maximum number of QoS 1 or QoS2 PUBLISH packets it can receive without sending an explicit acknowledgement to fewer than 65535, it can advertise the value (called Receive Maximum) by sending the desired Receive Maximum value in the CONNECT or CONNACK message as described in sections 3.2.1.13 and 3.2.2.1 respectively.

Non Normative Comment

This flow control mechanism can be useful for embedded clients with limited memory, or for servers which need to limit the flood of messages which can arrive following a prolonged disconnection. 

END Non Normative Comment

The Receive Maximum value applies only for the lifetime of the transport connection over which it was sent. The value is not part of the session state.

The Receive Maximum establishes a quota which is used to limit the number of PUBLISH commands which can be sent without receiving an PUBACK (for QoS 1) or PUBCOMP (for QoS 2). The PUBACK and PUBCOMP replenish the quota in the manner described below.

When a client or server receives a Receive Maximum value, it sets its send quota to that value.  It may use a smaller value, but the value chosen must always be in range of [1...Receive Maximum].  If the Receive Maximum value is missing from the CONNECT or CONNACK the maximum value of 65535 is used.  It is an protocol error to send a Receive Maximum value of zero.

Each time the client or server sends a PUBLISH command at QoS > 0, it decrements the quota. If the quota becomes zero, the client or server can not send any more PUBLISH commands at QoS > 0. It MAY continue to send PUBLISH commands at QoS 0, or MAY choose to suspend these as well. The client and server MUST continue to process and respond to all other command packets even if the quota is zero.

Each time a PUBACK or PUBCOMP are received, the quota is incremented by 1. The increment is applied regardless of whether the PUBACK or PUBCOMP carried an error code.

The quota must not be allowed to grow larger than the original quota or Receive Maximum. In the event of QoS 2 retransmission, it is possible for a PUBREL to be sent, causing a duplicate PUBCOMP to be received. If applying the quota update would cause the quota to exceed the original value, it is not applied. In this way, the maximum level is 'clamped'.

The quota and Receive Maximum value are not preserved across transport connections, and are re-initialized with each new transport connection as described above.

 


> 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
>            Assignee: Andrew Banks
>             Fix For: 5
>
>
> 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)