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

PingReq maxMessages to be updated to support a low default value

    XMLWordPrintable

    Details

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

      I propose (in order to keep complexity to a minimum);

      1. We remove the maxMessages on PINGREQ and instead revert to a CONNECT flags value "defaultAwakeMaxMessagesValue"
      2. "defaultAwakeMaxMessagesValue" is added as normative to a value of 0 (unlimited or gateway bounded)
      3. "defaultAwakeMaxMessagesValue" is added to the new "sessionFlags" field in the CONNACK packet (utilising 4 bits of the reserved sessionFlags field - meaning values in the range of 1-15 can be specified as default or 0 which means gateway controlled) to indicate what the gateway as this set as - this leaves 1 bits reserved for other use
      Show
      I propose (in order to keep complexity to a minimum); We remove the maxMessages on PINGREQ and instead revert to a CONNECT flags value "defaultAwakeMaxMessagesValue" "defaultAwakeMaxMessagesValue" is added as normative to a value of 0 (unlimited or gateway bounded) "defaultAwakeMaxMessagesValue" is added to the new "sessionFlags" field in the CONNACK packet (utilising 4 bits of the reserved sessionFlags field - meaning values in the range of 1-15 can be specified as default or 0 which means gateway controlled ) to indicate what the gateway as this set as - this leaves 1 bits reserved for other use

      Description

      The proposal is that a default maxMessages during AWAKE cycle should be catered for on the gateway so that in instances where a device chooses not to restrict the number of messages (omits or sends 0 in PINGREQ maxMessages field) in a PING awake cycle - the gateway will respond with only a low (configurable) limit default 1.

      The idea is to stop devices who have not utilised the max messages restriction properly from being overwhelmed.

       

      In this scenario, it may also be valid for the gateway to advertise its "defaultAwakeMaxMessage" size as part of the CONNECT interaction.

       

      Presently - the specification outlines that maxMessages 0 on a PINGREQ packet indicates to the gateway that the client wishes all messages to be sent back to the client as part of the AWAKE cycle.

       

      The maxMessages field is OPTIONAL at the moment, but given its position preceding the clientId (also optional); as it currently stands the OMISSION of the field cannot be used to derive function, as to supply a clientId, a 0 value must be supplied. This ~could be alleviated by switching the order of the clientId and maxMessages field (since the clientId is a UTF field - which means it can supply a 0 length field using 2 bytes of length data) allowing a maxMessages field to be omitted in isolation, however this ADDs 2 bytes of data per interaction for clients who wish to specify a length value of 0 or more - something I would not advocate.

       

       

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: