[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-257) Flow Control
[ https://issues.oasis-open.org/browse/MQTT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63040#comment-63040 ]
Ed Briggs commented on MQTT-257:
--------------------------------
The following is an updated specification for flow control. It incorporates previous feedback on the handling of SUBSCRIBE, and DISCONNECT. There is an open question of how to handle the 'send publish before CONNACK' (aka immediate send) scenario.
Description
This mechanism allows clients and servers to limit the maximum number of
PUBLISH QoS > 0 messages that may arrive in rapid succession. Such bursts oftraffic may occur when a connection is re-established after messages have beenqueued, or in other circumstances. The mechanism is also useful if memory constrained clients need to limit the number of messages that can be sent to them in rapid succession because of limited buffer space.
The mechanism replaces a similar capability in some MQTT 3.1.1 implementations with a standard mechanism, and adds the ability for clients and servers to exchange information about each others capabilities during connection establishment.
During session establishment, clients and servers tell each other how many
messages they can accept by exchanging 'maximum receive credit' values in the CONNECT and CONNACK messages. Thereafter, these credit values are used to limit the number of unacknowledged QoS > 0 PUBLISH messages in each direction.
The credit value is not part of the session context, and applies only for the duration of the transport connection over which it was established. The maximum send credit value may be different in either direction.
No provision is made to control QoS 0 messages because QoS 0 has no
acknowledgment or other message with which to advance the credit value. If
necessary, QoS 0 traffic can be controlled using transport level flow control
(TCP).
Mechanism:
Each client and server shall provide the following values:
1. Local.RxMax - The maximum number of PUBLISH QoS > 0 messages this endpoint is willing to receive in a burst. This is an implementation defined constant or configurable value in the range of 1 to 65535.
2. Local.TxMax - The maximum number of QoS > 0 messages this endpoint is permitted to send on a transport connection in the absence acknowledgement(s). This value is usually supplied by the remote session partner during connection establishment but may be reduced by the local policy if necessary. It must be in the range of 1 to 65535.
Each client and server shall implement the following variable:
3. Local.TxCredit - The current send credit for the local sender. This value
is initialized during session establishment as described below in Credit
Advertisement. With the transmission of each PUBLISH QoS > 0, the sender must reduce this value by one. The credit must be increased by 1 by the reception of a PUBACK or PUBCOMP regardless of whether the PUBACK or PUBCOMP carry a success or failure code.
If the value of Local.TxCredit reaches zero, transmission of PUBLISH Qos > 0 must be suspended until an acknowledgement arrives and the Local.TxCredit becomes greater than zero.
Suspension of PUBLISH messages QoS > 0, must not interfere with or delay the reception or transmission of other command packets. In particular,
acknowledgments messages (PUBACK, PUBREC, PUBREL, PUBCOMP) must not be delayed or deadlock may ensue.
Credit Advertisements
During connection establishment, the client must send its Local.RxMax value to the server in the CONNECT.RxMax field. The server must set its Local.TxMax value to min(Connect.RxMax, 65535). The server may reduce this value if necessary, but it must be at least 1. The server must reply with a CONNACK in which the CONNACK.RxMax field is set to the servers Local.RxMax. The client sets its Local.TxMax value to min(CONNACK.RxMax, 65535). The client may reduce this value if necessary, but Local.TxMax value must be at least 1.
If the Server rejects the connection request by returning a non-zero status
code, the client must ignore the CONNACK.RxMax value).
If the CONNECT or CONNACK commands do not contain a RxMax field, or if the field is set to zero, the recipient must set its Local.TxMax to 65535.
Disconnect Handling and Ordering
It is the responsibility of an implementation to delay the transmission of a DISCONNECT message until all messages have been sent, including those delayed by flow control, to prevent message loss. However, if a client or server needs to send a DISCONNECT to signal an error condition, it may do so without waiting for all messages to be sent.
Open Question : Immediate Transmission
A client may transmit command packets (including PUBLISH QOS > 0) prior to the receipt of a CONNACK. If it does so, it will not know and may exceed the receivers' RxMax.
By all available accounts, the ability to send messages prior to reception of
the CONNACK was intended to provide a very simple client the ability to send a CONNECT and a PUBLISH (QoS 0) and a DISCONNECT without ever checking for an acknowledgement. However, the MQTT 3.1.1 specification does not place any restriction on how many messages can be sent.
The question of this should be handled is a topic for discussion by the TC.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]