Allow "reversed" Topic Alias definition logic

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major
    • None
    • Affects Version/s: None
    • Component/s: MQTT-SN
    • None

      Miroslav's comment 3.4:

      (This is just a suggestion and I’m aware it would be a breaking change of the protocol.)
      In MQTT-SN, both a gateway and a client must keep the topic alias map.
      But the gateway is the “master” which assigns the alias numbers to topics. If the alias numbers were assigned by the client, the client could take advantage of knowledge about the structure of the topics which the gateway can’t have.
      Let’s consider e.g. a device that measures pressure on hundred different pipes and periodically sends measured values to sensor/SEN_ID/pressure/MEAS_ID topics. When the gateway assigns aliases numbers, the device must keep at least one hundred different aliases (100*2B) in memory. If the registration logic were reversed, the device could assign aliases algorithmically:
      sensor/SEN_ID/pressure/X → alias=X
      The memory footprint on the gateway would be the same, but the device could avoid using any memory for topic aliases in the best case (if it does not subscribe to any topic). We can assume the client is always more resource-constrained than the gateway.
      This approach where the source of the data is also the source of the alias mapping is used e.g. in the SparkPlug protocol.

            Assignee:
            Unassigned
            Reporter:
            ian.craggs
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: