OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[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 commented on MQTT-276:

I am confused by the response that    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].

I 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 be 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.  This would signify a protocol violation, and since it is not recoverable by retransmission, 

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]