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-555) Clarification of broker behaviour when client REGISTERs a PREDEFINED topic


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

Simon Johnson updated MQTT-555:
-------------------------------
    Proposal: 
Two Sections to update;

*5.4.11 REGACK*

||Length||MsgType||Flags||TopicId||MsgId||ReturnCode||
|(octet 0)|(1)|(2)|(3-4)|(5-6)|(7)

Table 15: REGACK Message
The REGACK message is sent by a client or by a GW as an acknowledgment to the receipt and processing of a REGISTER message. Its format is illustrated in Table 15:
* Length and MsgType: see Section 5.2.
* Flags:
â DUP: not used.
â QoS: not used.
â Retain: not used.
â CleanSession: not used.
â TopicIdType: indicates the type of information included at the end of the message, namely â0b00â
topic name, â0b01â pre-defined topic id, â0b10â short topic name, and â0b11â reserved.
* TopicId: the value that shall be used as topic id in the PUBLISH messages;
* MsgId: same value as the one contained in the corresponding REGISTER message. 
* ReturnCode: âacceptedâ, or rejection reason. See section 5.3.10.

AND

*6.5 Topic Name Registration Procedure*
Because of the limited bandwidth and the small message payload in wireless sensor networks, data is not published together with its topic name as in MQTT. A registration procedure is introduced which allows both a client and a GW to inform its peer about the short topic id and its corresponding topic name before it can start sending PUBLISH messages using a topicId.
To register a topic name a client sends a REGISTER message to the GW. If the registration could be accepted, the gateway assigns a topicId to the received topic name and returns it with a REGACK message to the client. If the client initiates a REGISTER against a topic which is known by the gateway to have a predefined topicId associated with it, the gateway will specify its topicIdType to be predefined and set the topicId value to match this in the REGACK. The client can then choose to update its registry of predefined topicIds if it so wishes. If there are no predefined topicIds, the gateway will pass back a NORMAL alias topicIdType.
If the registration could not be accepted, a REGACK is also returned to the client with the failure reason encoded in the ReturnCode field.
After having received the REGACK message with ReturnCode=âacceptedâ, the client shall use the assigned topicId to publish data of the corresponding topic name. If however the REGACK contains a rejection code, the client may try to register later again. If the return code was ârejected: congestionâ, the client should wait for a timeTWAIT beforerestartingtheregistrationprocedure.
At any point in time a client may have only one REGISTER message outstanding, i.e. it has to wait for a REGACK message before it can register another topic name.
A GW sends a REGISTER message to a client if it wants to inform that client about the topic name and the assigned topic id that it will use later on when sending PUBLISH messages of the corresponding topic name. This happens for example when the client re-connects without having set the âCleanSessionâ flag or the client has subscribed to topic names that contain wildcard characters such as # or +.

  was:
Section should read;

*5.4.11 REGACK*

||Length||MsgType||Flags||TopicId||MsgId||ReturnCode||
|(octet 0)|(1)|(2)|(3-4)|(5-6)|(7)

Table 15: REGACK Message
The REGACK message is sent by a client or by a GW as an acknowledgment to the receipt and processing of a REGISTER message. Its format is illustrated in Table 15:
* Length and MsgType: see Section 5.2.
* Flags:
â DUP: not used.
â QoS: not used.
â Retain: not used.
â CleanSession: not used.
â TopicIdType: indicates the type of information included at the end of the message, namely â0b00â
topic name, â0b01â pre-defined topic id, â0b10â short topic name, and â0b11â reserved.
* TopicId: the value that shall be used as topic id in the PUBLISH messages;
* MsgId: same value as the one contained in the corresponding REGISTER message. 
* ReturnCode: âacceptedâ, or rejection reason. See section 5.3.10.

AND

6.5 Topic Name Registration Procedure
Because of the limited bandwidth and the small message payload in wireless sensor networks, data is not published together with its topic name as in MQTT. A registration procedure is introduced which allows both a client and a GW to inform its peer about the short topic id and its corresponding topic name before it can start sending PUBLISH messages using a topicId.
To register a topic name a client sends a REGISTER message to the GW. If the registration could be accepted, the gateway assigns a topicId to the received topic name and returns it with a REGACK message to the client. If the client initiates a REGISTER against a topic which is known by the gateway to have a predefined topicId associated with it, the gateway will specify its topicIdType to be predefined and set the topicId value to match this in the REGACK. The client can then choose to update its registry of predefined topicIds if it so wishes. If there are no predefined topicIds, the gateway will pass back a NORMAL alias topicIdType.
If the registration could not be accepted, a REGACK is also returned to the client with the failure reason encoded in the ReturnCode field.
After having received the REGACK message with ReturnCode=âacceptedâ, the client shall use the assigned topicId to publish data of the corresponding topic name. If however the REGACK contains a rejection code, the client may try to register later again. If the return code was ârejected: congestionâ, the client should wait for a timeTWAIT beforerestartingtheregistrationprocedure.
At any point in time a client may have only one REGISTER message outstanding, i.e. it has to wait for a REGACK message before it can register another topic name.
A GW sends a REGISTER message to a client if it wants to inform that client about the topic name and the assigned topic id that it will use later on when sending PUBLISH messages of the corresponding topic name. This happens for example when the client re-connects without having set the âCleanSessionâ flag or the client has subscribed to topic names that contain wildcard characters such as # or +.


> Clarification of broker behaviour when client REGISTERs a PREDEFINED topic
> --------------------------------------------------------------------------
>
>                 Key: MQTT-555
>                 URL: https://issues.oasis-open.org/browse/MQTT-555
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>    Affects Versions: MQTT-SN-1.2
>            Reporter: Simon Johnson
>            Assignee: Simon Johnson
>            Priority: Minor
>              Labels: Implementation-notes
>
> If a client issues a âREGISTER âagainst the topic that happens to also be predefined, should  this be allowed? If so, does this yield a normalId in the REGACK, in which case the broker must use an order of precedence when selecting the topic id scheme to use in deliveries to this client.



--
This message was sent by Atlassian Jira
(v8.3.3#803004)


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