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-269) MQTT-SN Feature: Topic Registration


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

Ed Briggs commented on MQTT-269:
--------------------------------


Additional Notes Topic Registration Discussion

At the MQTT-TC F2F on 28 September 2016, the TC made the following comments and suggestions regarding topic registration

1. The term 'topic alias' should be replaced by something else, perhaps 'topic token' to avoid confusion. In the JIRA, topic alias is used to refer to a number which is used in place of the topic string when it is transmitted. Members of the TC expressed concern that the term alias might lead readers to believe a string could be used in place of the numeric token. 

2. The TC discussed how many topics needed to be cached at a maximum, and the related question of the impact of topic caching on memory constrained clients. The TC reached consensus that 65,535 topics would be  sufficient for clients, servers, and field gateway/concentrators.  To reduce the memory requirements, both clients and servers will have the ability to advertise the maximum number of cached topics they are willing to support, and the session partner is required to obey the restriction passed in the advertisement.

3. Raphael Cohn suggested that in some cases, it might be useful for a client to pre-register all the topics it needed to use in a single registration.  Since the Client likely knows all the topics it will use, such a registration might be easier than adding them 'on the fly'.

4. Andrew Stanford Clark suggested than the topic token zero be reserved as a sentinel for uninitialized values, and that the topic tokens be on based, so that if 65535 topics were used, they would be numbered [1..65535]. Use  of token 0 would be illegal.

5. Dr. Andrew Banks observed that the proposed scheme offered an opportunity for applications to improve their efficiency by taking steps to take advantage of topic caching.

6. After a long discussion concerning the handling of various errors, including those arising from invalid topic token encoding, zero length topics, cached topic handling if the Client sent PUBLISH message prior to receiving a CONNACK containing an advertisement for the maximum number of cached topics, etc.,  Ed Briggs proposed that the editors try to clarify the language of various terms in the WD such as 'protocol error', and see if there were common error handling behaviors for these sorts of errors in other JIRAs that might serve to make error handling more consistent.  Ed Briggs is to open a JIRA to track this.

7. An informal consensus was reached that that errors due to PUBLISHing before CONNACK should not result in a transport
closure in connection with this JIRA.  

8. The topic of whether topic caching takes effect on the receive side in the event of a NAK or protocol error is a topic for further study.  The desired behavior is to insure that the producer and consumer agree on the state of topic registrations even in the event of failures.

9. The TC thanked Peter Niblett for his comprehensive proposal, and expressed enthusiasm for the efficiency it will provide.







> MQTT-SN Feature: Topic Registration
> -----------------------------------
>
>                 Key: MQTT-269
>                 URL: https://issues.oasis-open.org/browse/MQTT-269
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 5
>            Reporter: Ian Craggs
>            Assignee: Peter Niblett
>
> MQTT-SN allows topic names to be registered with the server (and client) so that a topic id only has to be sent on subsequent packets.  This can reduce the data flowing on the wire and is consistent with the goals of MQTT.  It would however complicate the packet flows.



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