[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-300) Metadata: CONNACK Maximum QoS
[ https://issues.oasis-open.org/browse/MQTT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63548#comment-63548 ]
Ed Briggs commented on MQTT-300:
--------------------------------
NOTE 1 - This JIRA is a work item taken from the original 'METADATA' JIRA
NOTE 2 - This proposes new behavior not yet reviewed by the TC.
NOTE 3 - This JIRA proposes a new CONNACK return code WILL-QOS-NOT-SUPPORTED
Introduction (non-normative)
-------------------------------------
If a Server does not support all QoS levels, it can notify a Client of this restriction during connection establishment by sending a Maximum QoS advertisement in CONNACK metadata. Thereafter the Client will not send PUBLISH commands at QoS levels the Server does not support.
A Client does not issue Maximum QoS advertisements because it can specify the maximum QoS level it will accept in the SUBSCRIBE command. If the Client subscribes to a topic at a QoS level greater than the Server supports, the
Server simply returns the Maximum QoS level it supports in the corresponding SUBACK and thereafter uses that QoS level when sending PUBLISH commands to the Client.
This mechanism only applies to PUBLISH commands and does not affect the transmission or processing of SUBSCRIBE, UNSUBSCRIBE, and PUBREL all of which have the low-order QoS bit set in the fixed header, suggesting they are QoS 1 although they are not otherwise processed by QoS 1 rules.
The Maximum QoS Advertisement tag is only sent if the server does not support all three QoS levels. No advertisement is sent in the common case that all QoS levels are supported.
In the event that a Client violates the Maximum QoS level the Server supports by sending a PUBLISH command with an unsupported QoS Level, the approach used here is to send an PUBACK or PUBREC with an error code
QoS-Not-Supported.
This implicitly acknowledges the offending PUBLISH so that:
a) The offending PUBLISH will not be retransmitted (which would occur if we disconnected transport or send a DISCONNECT) averting a potential endless reconnect/retry cycle.
b) Other messages can continue to flow so that progress can be made.
c) Flow Control will continue to work.
The exception to this rule occurs if a CONNECT containing a Will QoS exceeding the Servers QoS level is received. In this case a CONNACK with an error code Will-QoS-Not-Supported is returned and the transport connection closed.
This means that the Client APPLICATION is responsible for adjusting the PUBLISH command QoS downward, and there is no automatic down-leveling of PUBLISH commands by the Client MQTT implementation.
Although the idea is straight forward, the following cases need to be handled:
a) the CONNECT message can carry a QoS level (the Will QoS) making an advertisement in a CONNACK 'too late'.
b) A Client may send PUBLISH commands with any QoS level prior to receiving a CONNACK containing notification that the QoS level is not supported, again too late.
c) Using transport disconnection or DISCONNECT commands in response to violation of the MAX-QOS advertisement on QoS > 0 may result in infinite re-connect/retry cycles.
Proposed Normative Text (draft)
------------------------------
{This text is to be added in the CONNACK payload description}
Maximum QoS Advertisement Format and Values
-------------------------
Identifier value 35 (0x23) followed by a one byte integer containing highest QoS level that a server will accept. Permissible values are 0 or 1. A Server MUST NOT send any other value, and it is an error to send the Maximum QoS
advertisement more than once in a CONNACK.
{This text is to be added in a new section of the specification}
Maximum QoS Advertisement Processing
------------------------------------
If a Server supports all QoS Levels, it MUST NOT send a Maximum QoS Advertisement. This signifies it supports all three QoS levels.
At a minimum, a Server MUST support the reception and transmission of QoS 0 PUBLISH commands, AND MUST accept and process SUBSCRIBE, UNSUBSCRIBE and PUBREL messages which are encoded with as if they were QoS 1 messages. In addition, the server MUST accept SUBSCRIBE commands containing QoS 0, 1, or 2, and it MUST return the Maximum QoS level it supports in the SUBACK.
If a Server does not support QoS 1 or QoS 2 PUBLISH commands, it MUST send a Maximum QoS Advertisement and MUST support all lower QoS Levels in addition to the value contained in the advertisement. If the Server does not send a Maximum QoS Advertisement, it MUST support QoS 0, 1, and 2.
If a Client receives a Maximum QoS Advertisement from a Server, it MUST NOT send PUBLISH commands at a QoS level exceeding the Maximum QoS level specified. This restriction does not apply to SUBSCRIBE, UNSUBSCRIBE and PUBREL command packets.
If a Server receives a CONNECT message containing a Will QoS that exceeds its capabilities, it MUST reject the connection by returning a CONNACK with the error code WILL-QoS-NOT-SUPPORTED and then terminate the transport connection.
If a Server receives a QoS > 0 PUBLISH message at and that QoS level exceeds its capabilities it MUST reply with a PUBACK or PUBREC with the error status QoS-NOT-SUPPORTED. In the case of QoS 2 messages, the server MUST also process the subsequent PUBREL event though it is encoded as a QoS 1 message and issue a PUBCOMP to complete the packet processing.
{End Normative Text}
> Metadata: CONNACK Maximum QoS
> ------------------------------
>
> Key: MQTT-300
> URL: https://issues.oasis-open.org/browse/MQTT-300
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: New Feature
> Components: core
> Affects Versions: 5
> Reporter: Brian Raymor
> Assignee: Ed Briggs
>
> This was discussed in MQTT-276 with notes from the F2F meetings and has been tracked in MQTT-256.
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192:
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values."
--
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]