LengthPrefixedProtocol: Handle non protocol-compliant messages

[TiWi79]

I have been using "LengthPrefixedProtocol" in "MyCustomProtocol".

This works "well" (well meaning according to what I would expect) as long as

1.) the incoming message from the client is length-prefixed
2.) the message's length is precisely as long as the prefix indicates

As soon as the reader receives a single message, which does not comply with both conditions, it won't be able to recognize length-prefixed messages after that, even if ithe incoming message does comply with both conditions again.
You would have to do a disconnect/connect, in order to "reset" that.

While this may be intended behaviour(?), I found it confusing.
In my opinion, the reader should be able to recognize protocol-compliant messages, even after it receives by one or more non-compliant messages.

Adding
consumed = input.End;

in the if-statement of "TryParseMessage" has worked for me so far to work around this issue:

if (!reader.TryReadBigEndian(out int length) || reader.Remaining < length)
{
message = default;
consumed = input.End;
return false
}

While adding this line of code has worked so far for me, I cannot guarantee that doing so might not go along with implications not yet recognized or that it might be against the author's original intention.

I would appreciate feedback on this.

And thank you for Bedrock anyway. This framework is really valuable.

[adamradocz]

I created that protocol, and recovery wasn't implemented; I simply disconnected the connection if something wasn't going as intended. To be honest, I don't know how does your solution work because if the message length is not right, you simply don't know when the current message ends and the next message starts. It would require some identification to determine the next metadata or the end of the message. But in that case, you don't need length metadata at all, because you can parse by checking the ID code.

Yes, the framework is awesome indeed; it should have deserved more attention.

[TiWi79]

Hi Adam.
Thank you for your answer (and your contribution to the framework as well). That's both very helpful for me to get a better understanding.

I get the point you make. I understand that recovery is not part of the protocol as of now and that this would require a well-designed solution, if really required.
Yes, you are right; my single-line workaround cannot be considered a solution (I am glad I didn't call it a solution a any point). I was rather playing around with the framework and trying to get a feeling for what's happening.

So anyway, thank you again!

[adamradocz]

Sorry, I just realised you're talking about the standard length prefix protocol. I wrote the Variable Size Length Fielded Protocol. But the concept is the same.