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=77323#comment-77323 ] 

Ian Craggs commented on MQTT-543:

'Normal ids' are those assigned by registration, either by the client or the server - that's correct isn't it?

Long topic names for QoS -1 can be implemented by using the spare topicIdType 0b11, and then the topicId field in the publish packet is used to indicate the topic name length which is included in the payload along with the message data.ÂÂ I don't think this has any effect on the use of normal ids.Â

QoS -1 publishes would allow short topic names, predefined topic ids, or long topic names (not normal ids).

So, everything would remain as before, but with the addition of the use of the topicidTYpe 0b11 for long topic names without registration. This had been requested and sometime implemented for QoS -1. But if we allow it for QoS -1, why not allow it for all QoSs? This would allow maximum flexibility.


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