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-543) Allow long topic names for publish of all QoS

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

Simon Johnson commented on MQTT-543:

A couple of points that spring to mind;

# Allowing the client to specify the topicId as part of a PUBLISH operation does change the rules of assignment of normalIds. I believe presently only the broker is responsible for being able to create and assign normalIds by way of a REGISTER -> REGACK. i.e. the client issues a REGISTER with the topic, the broker responds with the topicId (normal) OR the BROKER sends a REGISTER with both the topicName and the (normal) topicId. In both cases, this is the broker maintaining the handing out of normalIds. FWIW, the broker being the single control assignment seems to make sense to me, given its easier to synchronise the handing out of Ids centrally.
# This issue is also predicated on the fact that normalIds are allowed to be used outside the context of a CONNECTED session. Are we saying this is allowed? It makes sense to me that PREDEFINED topicIds are allowed OUTSIDE of a CONNECT, but normalIds are maintained in the CONNECTed session. Perhaps this is a broader discussion.

> Allow long topic names for publish of all QoS
> ---------------------------------------------
>                 Key: MQTT-543
>                 URL: https://issues.oasis-open.org/browse/MQTT-543
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>    Affects Versions: MQTT-SN-1.2
>            Reporter: Ian Craggs
>            Priority: Major
> In both MQTT 5.0 and MQTT-SN topic ids can be used instead of a full topic string. However, in MQTT-SN this is almost compulsory, because the PUBLISH packetâs one variable length field is the payload. The topic data is limited to a two byte field to hold a topic id (2 byte integer) or a short topic string (2 bytes). In MQTT 5.0 the topic id is registered by including it in the publish packet along with the long topic string. In MQTT-SN this registration is delegated to a separate packet, REGISTER, which must be sent before sending a PUBLISH packet. This applies to both clients and servers.
> This does lead to a problem when using the PUBLISH packet in a QoS -1 mode, which is exclusive to MQTT-SN. QoS -1 in MQTT-SN means that a client can send a message to a server outside of the familiar CONNECT/DISCONNECT session start and end range. Typically this could be used in a multi-cast environment where the client is not sure of the location of the server. There are a number of proposals to allow a variable length topic name to be included in a PUBLISH packet. At least one has already been implemented, which is to use the spare topic id type indicator to specify that the topic name is variable length field, and the topic id integer holds the length. This would mean the PUBLISH packet is the only one with two variable length fields (topic name and payload). I would advocate allowing this format for all PUBLISH QoS.

This message was sent by Atlassian Jira

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