Comment by Thorrez
2 years ago
>Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?
Maybe it was a deprecated part of the protocol, and setting it would cause an error or do nothing.
Or it could be a placeholder for future expansion and while it would do nothing now, in the future it might break things if you've ignored the documentation.
If you design a protocol without at least one field reserved for future expansion you are a bad engineer. Generally I would call this the protocol version number field, but there are other options. The important thing is there is some field that currently has a defined range, but can get an a larger range in the future and you check that field and abort if it is out of range.
I also recommend a second field called protocol ID which is set to a known random value (your wife's birthday) so that if someone gets an unknown message if they see that value they can guess what the protocol is.
Maybe it's there to prevent desyncing errors that occur for long strings of zeroes. Information theory isn't the only possible consideration.