Tiny suggestion, possibly without merit (no comments or email in the article):
Use ULEB64 encoding instead of RAW unsigned 64-bit fields for STRING lengths.
ULEB64 (https://en.wikipedia.org/wiki/LEB128) is a simple encoding where the 7th bit is used to show if there are more bytes following. So, lengths less than 128 can be encoded in one byte and so forth.
I doubt the protocol will routinely send lengths that are more than, say, four gigabytes. The longest ULEB64 number is eleven bytes, as far as I recall.
Other than that, I know nothing about the ancestors of the proposed protocol and thus cannot comment.
Use ULEB64 encoding instead of RAW unsigned 64-bit fields for STRING lengths.
ULEB64 (https://en.wikipedia.org/wiki/LEB128) is a simple encoding where the 7th bit is used to show if there are more bytes following. So, lengths less than 128 can be encoded in one byte and so forth.
I doubt the protocol will routinely send lengths that are more than, say, four gigabytes. The longest ULEB64 number is eleven bytes, as far as I recall.
Other than that, I know nothing about the ancestors of the proposed protocol and thus cannot comment.