mqtt-sn — archive

Re: Packet Type Field Change

From: Andy Stanford-Clark
To: [email protected]
Date: Mon, 09 Jan 2023 09:26:00 -0000

Well spotted, Si ð Isn't this just kicking the can down the road, Davide? Perhaps we should bite the bullet now and take the extra byte for the protocol version? Our future selves will one day thank us ð I really like the "drive-by publish" of QoS -1, but given that it is completely "self contained" it should not surprise us that it's a bit bigger than a normal "in session" publish. I admit to being torn on this one, as "spare bits" always make me unhappy! Andy Andy Stanford-Clark Innovation Leader - IBM SPEED team Distinguished Engineer, Master Inventor, IBM Quantum Ambassador, Member IBM Academy of Technology, Fellow BCS Visiting Professor at Newcastle, Southampton and UEA. Tel: +44 (0)7801 787096 twitter: @andysc From: [email protected] <[email protected]> on behalf of Davide Lenzarini <[email protected]> Sent: 09 January 2023 08:52 To: Simon Johnson <[email protected]> Cc: Ian Craggs <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [EXTERNAL] [mqtt-sn] RE: Packet Type Field Change Great catch Simon! I agree with your approach as consistent with MQTT5. I am anyway scared about the fact that the Protocol Version in CONNECT is represented over 1 byte and in PUBLISH-1 is represented over 2 bits. I propose the following ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Great catch Simon! I agree with your approach as consistent with MQTT5. I am anyway scared about the fact that the Protocol Version in CONNECT is represented over 1 byte and in PUBLISH-1 is represented over 2 bits. I propose the following 2 options to have a future-proof solution: Option 1 (Packet type 2 bits flag extension): 00 means MQTT-SN v1.2 01 means MQTT-SN v2 10 is reserved 11 means there is a following dedicated byte providing the Protocol Version Option 2 (Packet type refactoring) PUBLISH 0x0C (MQTT-SN v2) PUBLISHv1_2 0x1E (MQTT-SN v1.2) Bye Davide From: Simon Johnson <[email protected]> Sent: Sunday, January 8, 2023 11:31 AM To: [email protected] Cc: Ian Craggs <[email protected]>; [email protected]; Davide Lenzarini <[email protected]> Subject: Re: Packet Type Field Change **** This is an EXTERNAL email. It was sent from outside of u-blox. **** ERRATUM: That should be bits 7 & 6 for the flags and 5 - 0 for packet type On Sun, 8 Jan 2023 at 10:13, Simon Johnson < [email protected] > wrote: Good morning folks, I have been working with PUBLISH -1 in v2. I have found a flaw with the new packet type layouts. Presently you can PUBLISH -1 without a session, and it is the SESSION that determines the protocol version you have decided to use. Without a session, the GATEWAY has no mechanism to determine the version of the PUBLISH packet to use to decode it. So to maintain the ability for a GW to support both protocol versions, we must have a mechanism in the PUBLISH packet to note protocol version WITHOUT adding any further bytes. I was looking, the packet type field seems to be a great chance to squeeze some more space out of - in a similar fashion to tt5, so we coolocate a generic flags field in bits 1 & 0, using 6 bits of space (7-2) for packet type (64 available types - we currently use ~30) so plenty of growing room - then the 2 new flags can be used for flags on the message without needing a new flags field. In the case of PUBLISH this can be protocol version, but also it could be used for a few other types specifying and using only 1 or 2 flags saving space elsewhere. I feel this is a fundamental enough issue to warrant this change - and give us further flexibility for saving space elsewhere. I still havn't gained access to the ticketing system, but will press OASIS next week and raise a ticket when I can. I'm happy to create a WD version (25) with just this change applied to all the message types this week for review. Further, Davide, I have made the changes to the doc RE: network connection and will submit WD 24 this coming week. Best, Si Unless otherwise stated above: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU