Re: Proposal to replace ACK block count with ACK length

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Missed that mail.

My concern was mostly that you when several people raises concerns about a
protocol design principle being changed, you need to argue why such a
change is viable rather than just - need to check EOB anyway.

You code goes some way to address that. I didn’t go through it in detail
(I’m beyond my code line limit for today) but there could can be problems
such as:

ACK frame with length prefix says it does not exceed end of buffer. Parser
reads all data and confirms this fact, so frame is accepted. What it might
miss is that the length points after the end of the parse block leaving
undetermined data hanging. Not saying this actually happens, but that is a
concern.

Personally, I actually like a length prefix, and generally don’t see a
problem with it. But I’d prefer if it was a global principle then rather
than mixing those concepts. When this is done in a generic fashion, and end
pointer can be passed everywhere, and as soon as something does fit
cleanly, abort the connection.

The MQTT packet framing uses a length prefix uniformly:

http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/

Mikkel


On 19 June 2018 at 21.12.13, Eric Rescorla ([e-mail]) wrote:


Not Manasi, but I don't understand (e).

Here's the relevant section of the Minq decoder.