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-280) MQTT 3.1.1 Session Take Over and Will Message Delivery


    [ https://issues.oasis-open.org/browse/MQTT-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62093#comment-62093 ] 

Ken Borgendale commented on MQTT-280:
-------------------------------------

The normative text about will messages is at line 474:
If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8]. 

The text starting at line 478 should be considered as non-normative as it does not include a mandate and specifically says "included, but are not limited to".  The normative text makes clear that the will message is attached to the connection, and MUST be sent when the connection closes except when a DISCONNECT has been received.  A second connection with the same ClientID, whether or not it takes over the session is still a separate connection.  When the original connection is closed, a WILL message must be sent unless a DISCONNECT has been received on it.  We could clarify that this list is non-normative by labeling it, but is does not contain a mandate, contains words to show it is not normative, and it does not contradict the normative language.

The table of mandatory normative statements (appendix B) is itself not normative, but is a collection of the mandatory normative statements from earlier in the document.

One thing we did try to clarify elsewhere is that the server (or for that matter the client) is free to close the connection at any time, and indeed for any reason.

> MQTT 3.1.1 Session Take Over and Will Message Delivery
> ------------------------------------------------------
>
>                 Key: MQTT-280
>                 URL: https://issues.oasis-open.org/browse/MQTT-280
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: edits
>    Affects Versions: 3.1.1
>         Environment: MQTT 3.1.1
>            Reporter: Rahul Gupta
>            Priority: Minor
>             Fix For: 3.1.1
>
>
> Ed Briggs Reported -
> The specification does not seem to  specify if the will message should be delivered as a consequence of session take-over. (i.e. due to a second connection with the same client id)
> From the specification: "Section 3.1.2.5
> 478  Situations in which the Will Message is published include, but are not limited to:
> 479  - An I/O error or network failure detected by the Server.
> 480  - The Client fails to communicate within the Keep Alive time.
> 481  - The Client closes the Network Connection without first sending a DISCONNECT Packet.
> 482  - The Server closes the Network Connection because of a protocol error."
> Later, in the table of Mandatory Normative Statements, it states the requirements a bit differently:
> [MQTT-3.1.2-8] Mandatory Normative Statements (Page 71, no line numbers)
>  " ...  The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet."
>  
> It isn’t clear what the correct behavior should be when session take-over occurs. There are several other confusing aspects to interpreting the normative text:
> - the term 'protocol error' appears only on line 482 (above) and is not defined.
> - the term 'protocol violation' is defined, but session eviction is not defined as a protocol violation.
> I spotted this while investigating the session behavior in connection with proposed  'server initiated disconnect messages'.I wonder if this might need to be clarified in the MQTT 3.1.1 specification, even in the form of non-normative text.



--
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]