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

Clarify whether clients should maintain normal topicIds during sleep state

    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

      Section 6.14 Support of Sleeping Clients

      Add this paragraph, which closely follows MQTT 5.0.

       

      Topic Alias mappings exist only while a client is active and last for the entire duration of the active state.  A receiver MUST NOT carry forward any Topic Alias mappings from one active state to another.

      Show
      Section 6.14 Support of Sleeping Clients Add this paragraph, which closely follows MQTT 5.0.   Topic Alias mappings exist only while a client is  active and last for the entire duration of the active state.  A receiver MUST NOT carry forward any Topic Alias mappings from one  active  state to another.

      Description

      Whether or not a client maintains its normal topicId registry whilst in a sleeping state is a fundamental implementation decision, and one that effects the entire client lifecycle and broker interactions upon waking. I do not believe this to be a trivial implementation detail or broker "feature".

      Should, for example, the broker have to re-issue REGISTER messages for every unconfirmed topic during a wake up phase, only for them to be cleared again upon receipt of the PINGRESP.

      Mandating clients maintain the registry across sleeps, means low powered devices can not truly power down where they have only volatile space to write their registry's. Flushing the registry means more message interaction upon wake.

      Neither are small overheads. Perhaps there is scope for different sleep states?

        Attachments

          Activity

            People

            • Assignee:
              ian.craggs Ian Craggs
              Reporter:
              simon.johnson Simon Johnson [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: