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-439) Issues from Boris Verkhovykh


     [ https://issues.oasis-open.org/browse/MQTT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-439:
--------------------------------

    Description: 
1.
1775   If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN
1776 flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the
1777 received PUBLISH packet [MQTT-3.3.1-12].
1778   If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN
1779 flag equal to the RETAIN flag in the received PUBLISH packet [MQTT-3.3.1-13].

And it appears that [MQTT-3.3.1-12] (RaP bit == 0) contradicts the last sentence from the following chapter:

2332 3.8.3.1 Subscription Options
...
2341 Bit 3 of the Subscription Options represents the Retain As Published option. If 1, Application Messages
2342 forwarded using this subscription keep the RETAIN flag they were published with. If 0, the RETAIN flag in
2343 the PUBLISH packet indicates whether it came from a retained source or is a new publication.

Or, is it different functionality for bridging? Then it should be articulated more the clearly.

2.
2332 3.8.3.1 Subscription Options
...
2337 Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages
2338 MUST NOT be forwarded to a connection with a ClientId equal to the ClientId of the publishing
2339 connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared [MQTT-3.8.3-4].

I guess, the word "Subscription" is missed at the end.

3.
Second, what is the rationale to prohibit the "No Local" option for Shared Subscriptions?
I would see a useful scenario: client asks to pass a message to one of its peers (if they exist), while accepting similar messages from others.
It may help building auto-configurable systems.

4.
Paragraph with [MQTT-3.1.4-1] says

1325   2. The Server MUST validate that the CONNECT packet conforms to section 3.1 and close the
1326   Network Connection if it does not conform [MQTT-3.1.4-1]. The Server MAY send a
1327   DISCONNECT with a Return Code of 128 or greater as described in section 4.13 before closing
1328   the Network Connection.

But, is it allowed to send DISCONNECT packet before accepting the connection?
I guess it should say "The Server MAY send a CONNACK..." packet as in the paragraph "3." later.
Actually paragraphs "2." and "3." should have similar wording to avoid confusion.

5
Paragraph with [MQTT-3.1.4-3] says

1337   1. If the ClientID represents a Client already connected to the Server, the Server sends a
1338   DISCONNECT packet to the existing Client with Return Code of 0x8E (Session taken over) as
1339   described in section 4.13 and MUST close the Network Connection of the existing Client [MQTT-
1340   3.1.4-3]. If the existing Client has a Will Message, that Will Message is published as described in
1341   section 3.1.2.5.

What is the purpose of sending Will Message in case of the session takeover? What is the expected scenario?
I would say a new connection with the existing ClientID is a very special case and should be treated accordingly!
First of all, such simple logic may allow a DoS attack (even if not intended), when multiple "identical" clients try to work with the same Server.
Second, if a Client developer has plans for the legitimate "session takeover" - switching from one client instance to another - it is better to allow some level of control over it.
For example, special CONNECT option, which tells the Server to deny "duplicate ClientID" connection or even instructs it to somehow query the existing client if it allows a take over.
I understand that it may be technically difficult to implement, so

switching from my phantasies back to Will Message.
My understanding of the Will Message is to indicate (to the interested parties) that a service from the specific Client is no longer available.
I think, that the Will Message MUST not be published in situations when the Client reconnects after detecting network errors, but the Server does not (yet) recognize the loss of connection. Even if it is a completely different new Client instance, the same ClientID, especially when the session is preserved, indicates that the service is still available.

  was:
1.
1775   If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN
1776 flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the
1777 received PUBLISH packet [MQTT-3.3.1-12].
1778   If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN
1779 flag equal to the RETAIN flag in the received PUBLISH packet [MQTT-3.3.1-13].

And it appears that [MQTT-3.3.1-12] (RaP bit == 0) contradicts the last sentence from the following chapter:

2332 3.8.3.1 Subscription Options
...
2341 Bit 3 of the Subscription Options represents the Retain As Published option. If 1, Application Messages
2342 forwarded using this subscription keep the RETAIN flag they were published with. If 0, the RETAIN flag in
2343 the PUBLISH packet indicates whether it came from a retained source or is a new publication.

Or, is it different functionality for bridging? Then it should be articulated more the clearly.

2.
2332 3.8.3.1 Subscription Options
...
2337 Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages
2338 MUST NOT be forwarded to a connection with a ClientId equal to the ClientId of the publishing
2339 connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared [MQTT-3.8.3-4].

I guess, the word "Subscription" is missed at the end.

3.
Second, what is the rationale to prohibit the "No Local" option for Shared Subscriptions?
I would see a useful scenario: client asks to pass a message to one of its peers (if they exist), while accepting similar messages from others.
It may help building auto-configurable systems.



       Proposal: 
1. Clarify the statement in 3.8.3.1
2. Add the word Subscription
3. This issue has been discussed by the TC and the resolution was to not allow noLocal and shared together.  We could add a non-normative comment concerning the reasons.
4. Change to CONNACK
5. This issue has been discussed by the TC and as a result we added the explicit text about what is done.  We could add a non-normative comment about why.

  was:
1. Clarify the statement in 3.8.3.1
2. Add the word Subscription
3. This issue has been discussed by the TC and the resolution was to not allow noLocal and shared together.  We could consider adding a non-normative comment concerning the reasons.


4. 
This is a bug and needs to be fixed

5.
There was a lot of discussion in the MQTT TC about will messages and ClientID stealing.  We also added the support for Will Delay to deal with some of this.  After much discussion the consensus is that the will message must be sent when a session ends or when the will delay interval has passed after the connection closes (whichever happens sooner) unless the connection is closed with a DISCONNECT of rc=0.  Thus if the new connection has CleanStart=0 and the exiting connection had a Will Delay > 0 then the will message is not sent, but in this case you really do get session takeover.  If the new connection has CleanStart=1 then the new connection causes the existing session to be ended, and a new session created with the same ClientID.  This is not session takeover but session replacement.

The understanding is that other than adding the Will Delay this function is unchanged from MQTT v3.1.1 but that we added explicit statements about how this works in an attempt to clarify exactly how it behaves.

I do not think there is much desire in the MQTT TC to reopen this issue, but I will raise this as an issue to the TC if you see it as very important.

> Issues from Boris Verkhovykh
> ----------------------------
>
>                 Key: MQTT-439
>                 URL: https://issues.oasis-open.org/browse/MQTT-439
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: edits
>    Affects Versions: 5, wd13
>            Reporter: Ken Borgendale
>            Assignee: Ken Borgendale
>            Priority: Minor
>
> 1.
> 1775   If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN
> 1776 flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the
> 1777 received PUBLISH packet [MQTT-3.3.1-12].
> 1778   If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN
> 1779 flag equal to the RETAIN flag in the received PUBLISH packet [MQTT-3.3.1-13].
> And it appears that [MQTT-3.3.1-12] (RaP bit == 0) contradicts the last sentence from the following chapter:
> 2332 3.8.3.1 Subscription Options
> ...
> 2341 Bit 3 of the Subscription Options represents the Retain As Published option. If 1, Application Messages
> 2342 forwarded using this subscription keep the RETAIN flag they were published with. If 0, the RETAIN flag in
> 2343 the PUBLISH packet indicates whether it came from a retained source or is a new publication.
> Or, is it different functionality for bridging? Then it should be articulated more the clearly.
> 2.
> 2332 3.8.3.1 Subscription Options
> ...
> 2337 Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages
> 2338 MUST NOT be forwarded to a connection with a ClientId equal to the ClientId of the publishing
> 2339 connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared [MQTT-3.8.3-4].
> I guess, the word "Subscription" is missed at the end.
> 3.
> Second, what is the rationale to prohibit the "No Local" option for Shared Subscriptions?
> I would see a useful scenario: client asks to pass a message to one of its peers (if they exist), while accepting similar messages from others.
> It may help building auto-configurable systems.
> 4.
> Paragraph with [MQTT-3.1.4-1] says
> 1325   2. The Server MUST validate that the CONNECT packet conforms to section 3.1 and close the
> 1326   Network Connection if it does not conform [MQTT-3.1.4-1]. The Server MAY send a
> 1327   DISCONNECT with a Return Code of 128 or greater as described in section 4.13 before closing
> 1328   the Network Connection.
> But, is it allowed to send DISCONNECT packet before accepting the connection?
> I guess it should say "The Server MAY send a CONNACK..." packet as in the paragraph "3." later.
> Actually paragraphs "2." and "3." should have similar wording to avoid confusion.
> 5
> Paragraph with [MQTT-3.1.4-3] says
> 1337   1. If the ClientID represents a Client already connected to the Server, the Server sends a
> 1338   DISCONNECT packet to the existing Client with Return Code of 0x8E (Session taken over) as
> 1339   described in section 4.13 and MUST close the Network Connection of the existing Client [MQTT-
> 1340   3.1.4-3]. If the existing Client has a Will Message, that Will Message is published as described in
> 1341   section 3.1.2.5.
> What is the purpose of sending Will Message in case of the session takeover? What is the expected scenario?
> I would say a new connection with the existing ClientID is a very special case and should be treated accordingly!
> First of all, such simple logic may allow a DoS attack (even if not intended), when multiple "identical" clients try to work with the same Server.
> Second, if a Client developer has plans for the legitimate "session takeover" - switching from one client instance to another - it is better to allow some level of control over it.
> For example, special CONNECT option, which tells the Server to deny "duplicate ClientID" connection or even instructs it to somehow query the existing client if it allows a take over.
> I understand that it may be technically difficult to implement, so
> switching from my phantasies back to Will Message.
> My understanding of the Will Message is to indicate (to the interested parties) that a service from the specific Client is no longer available.
> I think, that the Will Message MUST not be published in situations when the Client reconnects after detecting network errors, but the Server does not (yet) recognize the loss of connection. Even if it is a completely different new Client instance, the same ClientID, especially when the session is preserved, indicates that the service is still available.



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