Remaining Length encoding

[John Wilson]

Hi!

I'm very new to MQTT and I'm sorry if this has been asked before. I'm trying to make a very lightweight broker to run on something like an ESP8226.

It seems that the same number can be encoded in the remaining length field in several different ways:

For example I think zero can be encoded as 0X00 or 0X80 0X00 or 0X80 0X80 0X00 or 0X80 0X80 0X80 0X00

However where the packet definitions define the value of remaining length (e.e. PUBACK) they are defined using the one byte encoding.

The packet definitions are normative so my implementation rejects any encoding but the shortest possible one.

Is this right? Will I break any clients by doing this?

Thanks

      John Wilson

[Nicholas O'Leary]

It must be the shortest possible encoding. The fact that using 0x80 allows you to pad the remaining length is an artefact of the non-normative example pseudo-code that doesn't police this. This was recently spotted and an issue raised to ensure it gets clarifies in the next version.

The normative text in section 2.2.3 indicates how many bytes should be used to encode different ranges of length values:

Digits	From	To
1	0 (0x00)	127 (0x7F)
2	128 (0x80, 0x01)	16 383 (0xFF, 0x7F)
3	16 384 (0x80, 0x80, 0x01)	2 097 151 (0xFF, 0xFF, 0x7F)
4	2 097 152 (0x80, 0x80, 0x80, 0x01)	268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718023

That table shows it is not valid to use more than one digit to encode values in the range 0-127.

Nick

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[John Wilson]

On 31 May 2016 at 19:52, Nicholas O'Leary <nick.oleary@gmail.com> wrote:

It must be the shortest possible encoding. The fact that using 0x80 allows you to pad the remaining length is an artefact of the non-normative example pseudo-code that doesn't police this. This was recently spotted and an issue raised to ensure it gets clarifies in the next version.

The normative text in section 2.2.3 indicates how many bytes should be used to encode different ranges of length values:

Digits	From	To
1	0 (0x00)	127 (0x7F)
2	128 (0x80, 0x01)	16 383 (0xFF, 0x7F)
3	16 384 (0x80, 0x80, 0x01)	2 097 151 (0xFF, 0xFF, 0x7F)
4	2 097 152 (0x80, 0x80, 0x80, 0x01)	268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718023

That table shows it is not valid to use more than one digit to encode values in the range 0-127.

Thank you, Nick.

Making the next issue clarify this would be helpful to us dullards :)

   John