[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-276) MQTT enhancements for large scale distributed systems
[ https://issues.oasis-open.org/browse/MQTT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60857#comment-60857 ]
Ed Briggs edited comment on MQTT-276 at 9/29/15 6:39 PM:
---------------------------------------------------------
I am confused by the response that a server is already allowed to not support a given QoS, in any situation, for this client, for this user, for this topic, or any combination of the above".
It's certainly true that a server can return a granted QoS level lower than the QoS level specified in the SUBSCRIBE(topic), but this only governs maximum QoS Level of PUBLISH(topic) from the Server to the Client. [MQTT -3.8.4-6]
I find no mechanism by which a server can restrict the QoS levels used by the client when it sends PUBLISH messages. In fact the following mandatory normative statements (Appendix B) [MQTT-4.3.3-1 & governing the obligation of the receiver in QOS 2 doesn't seem to offer any alternative. Similar requirements for QoS 1 appear in [MQTT-4.3.2-1 & 2].
In the presence of durable sessions, (CleanSession = 0) an (infinite) re-connect / re-transmit cycle would arise if either end of the link disconnected the session upon the reception of a command with an unsupported QoS level. Silently discarding the message and acknowledging the message violates the QoS > 0 delivery guarantees, and would complicate diagnosis of message loss in the field.
I support the idea of a protocol 'negative ack' or 'error message' to handle unsupported QoS levels, but this must (IMO) be used in conjunction with a prior advertisement of a maximum QoS 'setting' at session establishment. If a sender subsequently violated the maximum QoS setting, the receiver would respond with a specific nak.
In summary, if my understanding is correct, the combination of a setting conveyed in an advertisement during session establishment and the provision of NAK or REJECT capability to handle subsequent violation of the "setting" conveyed in the advertisement is preferable to the nak solution alone. The 'immediate send mode' presents difficulties for advertisements of settings, but this can be overcome, and it might be useful to explore how that would be done since there are a number of other capabilities that require a simple means of providing setting advertisements.
was (Author: edbriggs):
I am confused by the response that a server is already allowed to not support a given QoS, in any situation, for this client, for this user, for this topic, or any combination of the above".
It's certainly true that a server can return a granted QoS level lower than the QoS level specified in the SUBSCRIBE(topic), but this only governs maximum QoS Level of PUBLISH(topic) from the Server to the Client. [MQTT -3.8.4-6]
I find no mechanism by which a server can restrict the QoS levels used by the client when it sends PUBLISH messages. In fact the following mandatory normative statements (Appendix B) [MQTT-4.3.3-1 & governing the obligation of the receiver in QOS 2 doesn't seem to offer any alternative. Similar requirements for QoS 1 appear in [MQTT-4.3.2-1 & 2].
In the presence of durable sessions, (CleanSession = 0) an (infinite) re-connect / re-transmit cycle would arise if either end of the link disconnected the session upon the reception of a command with an unsupported QoS level. Silently discarding the message and acknowledging the message violates the QoS > 0 delivery guarantees, and would complicate diagnosis of message loss in the field.
I support the idea of a protocol 'negative ack' or 'error message' to handle unsupported QoS levels, but this must (IMO) be used in conjunction with a prior negotiation or advertisement at session establishment. If a sender violates the negotiated maximum QoS, the receiver would respond with a specific nak.
In summary, if my understanding is correct, the combination of a negotiation during session establishment and the provision of NAK or REJECT capability to handle subsequent violation of the negotiation is preferable to the nak solution alone. The 'immediate send mode' presents difficulties for negotiations of this type, but this can be overcome, and it might be useful to explore how that would be done since there are a number of other capabilities that require a simple negotiation mechanism.
> MQTT enhancements for large scale distributed systems
> -----------------------------------------------------
>
> Key: MQTT-276
> URL: https://issues.oasis-open.org/browse/MQTT-276
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: New Feature
> Components: futures
> Affects Versions: 3.1.1
> Reporter: Konstantin Dotchkoff
> Assignee: Konstantin Dotchkoff
> Fix For: 3.1.1
>
>
> As presented during the TC call on 8/6/2015, there are challenges in implementing MQTT in large scale distributed systems with the specific case being QoS 2:
> https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/56237/MQTT%20QoS2%20Considerations.pptx
> Retained messages were also noted during the call.
--
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]