Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-555

Clarification of broker behaviour when client REGISTERs a PREDEFINED topic

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Applied
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: MQTT-SN-1.2
    • Fix Version/s: None
    • Component/s: MQTT-SN
    • Proposal:
      Hide

      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 +.

      Show
      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 +.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              simon.johnson Simon Johnson [X] (Inactive)
              Reporter:
              simon.johnson Simon Johnson [X] (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: