[OASIS Issue Tracker] (MQTT-587) PingReq maxMessages to be updated to support a low default value

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=82034#comment-82034 ] 

Simon Johnson commented on MQTT-587:
------------------------------------

I updated the proposal, to remove the overhead of the maxMessages from the DISCONNECT (and its presence forcing the use of 0 for clients who don't know what they want (which could yield too many gateway controlled messages). Add the awakeMessagesValue 4 bits to the CONNECT message, allowing the client to select 0 for gateway controlled or 1-15 for Max receive before PINGRESP.

> PingReq maxMessages to be updated to support a low default value
> ----------------------------------------------------------------
>
>                 Key: MQTT-587
>                 URL: https://issues.oasis-open.org/browse/MQTT-587
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>            Reporter: Simon Johnson
>            Assignee: Simon Johnson
>            Priority: Major
>
> 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.
> Â
> Â



--
This message was sent by Atlassian Jira
(v8.3.3#803004)