[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-301) Metadata: CONNACK Retained messages supported
[ https://issues.oasis-open.org/browse/MQTT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63537#comment-63537 ]
Ed Briggs commented on MQTT-301:
--------------------------------
This note describes the mechanism used by a Server to notify a Client it does not support RETAIN messages, and related actions to be taken by the Client and Server. It works by the server 'advertising' that it does not support RETAIN by including a tag in the CONNACK. To reduce message overhead for the common case, the tag is only present if RETAIN is *not* supported.
The idea is simple, but the implementation is somewhat complicated by:
a) WD04 Section 3.2.2.3 "Connect Return Codes" BREAKS this feature with the following non-normative text
"The Server may choose to close the network connection without sending a CONNACK to enhance security
in the case where an error is found in the CONNECT..." . This requires discussion/clarification of the WD text.
b) the CONNECT message can carry a RETAIN flag (for the Will message) making an advertisement in a CONNACK 'to late' to be useful.
c) A Client may send PUBLISH commands with RETAIN=1 prior to receiving a CONNACK containing notification that RETAIN is not supported. Again, the advertisement arrives too late.
d) Using transport disconnection or DISCONNECT commands in response to violation of the RETAIN advertisement on QoS > 0 may result in infinite re-connect/retry cycles.
e) QoS 0 has no ACK/NAK so DISCONNECT must be used to respond to violation of the RETAIN-NOT-SUPPORTED advertisement by QoS 0 PUBLISH commands.Introduction
NOTE 1 - This JIRA is a work item taken from the original 'METADATA' JIRA These items have been broken into separate JIRAs to divide and (hopefully) conquer them.
NOTE 2 - This proposes new behavior not yet reviewed by the TC. Please review and comment.
NOTE 3 - This proposes two new Error Codes to be added
a) DISCONNECT reason RETAIN-NOT-SUPPORTED
b) PUBACK RETAIN-NOT-SUPPORTED
NOTE 4 - The encoding of the RETAIN-NOT-SUPPORTED advertisement follows WD04 Section 2.3.3 "Identifier/Value Pairs" which specifies a single byte identifier followed by a length field.
{This section to be added in the CONNACK payload description}
Retain Unavailable Advertisement
--------------------------------
Identifier value 34 (0x22) followed by a zero length payload signifies that a Server will reject messages in which the RETAIN flag is set to 1.
A Server which does not implement the RETAIN message capability MUST send a CONNACK containing a RETAIN UNAVAILABLE Advertisement in response to a CONNECT message. It is an error to include the RETAIN UNAVAILABLE message more than once. If the Server rejects the CONNECT for any other reason, it MUST NOT send a RETAIN UNAVAILABLE advertisement.
A Server providing RETAIN message capabilities MUST NOT send the RETAIN UNAVAILABLE Advertisement.
{This text to be added to the section on RETAIN}
If a server does not support RETAIN, and it receives a CONNECT message with a WILL RETAIN flag set in the Connect Flags Field, it MUST reject the CONNECT command and send a CONNACK with a return code of RETAIN NOT SUPPORTED and then close the transport connection.
A Client which has received CONNACK with a RETAIN UNAVAILABLE Advertisement MUST NOT send PUBLISH commands with RETAIN=1 in the fixed header.
If a Server does not support RETAIN, and it receives QoS 0 PUBLISH commands marked with a RETAIN = 1 in the PUBLISH Fixed Header, it MUST transmit a DISCONNECT message with a return code RETAIN-NOT-SUPPORTED and then disconnect the transport connection. This behavior is also used if a Client sends QoS 0 PUBLISH commands before a CONNACK.
If a Server does not support RETAIN, and it receives a QoS 1 or QoS 2 PUBLISH command, it MUST respond with PUBACK or PUBREC with a return code of RETAIN-NOT-SUPPORTED. It MUST NOT close the session or transport connection because doing so could result in cyclical retries. This behavior is also used if a Client sends QoS > 0 PUBLISH commands before a CONNACK.
> Metadata: CONNACK Retained messages supported
> ---------------------------------------------
>
> Key: MQTT-301
> URL: https://issues.oasis-open.org/browse/MQTT-301
> 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]