-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extending flags #56
Comments
Use 0x80 bitmap flag to say, there is a another byte flag ? (like radiotap) or already change to use 2 or 4 bytes ? |
I agree with Alexis the obvious approach is to use 0x80 to indicate another byte of flags. If we think extended flags will be common, I think we should change to 2 bytes as a minimum, because variable length fields before the connection id are more annoying to process in some systems(ie: BPFs), particularly if the number of times one can add more flags is unbounded.(ie: IPv6 extension headers). I would lean towards suggesting that extended flags should come after the connection id. |
I think a 2-byte field will be annoying in the near to medium-term, where the second byte is unused. Having the second byte after connection ID (and version?) would be annoying in the more distant future when 8+ flags are routine. But in either case, this is a matter of taste and I see no showstoppers with having the extra flags come later. Especially since we might end up having lots of these flags. On the other hand, I can imagine future protocol tweakers "abusing" unlimited public flags to put whole bitfields in there. I'm not sure if this is a "problem" we need to solve or not. |
In any case it might be worthwhile to spell out what's acceptable in the bounds of a version. If a given version has 6 defined flags, can there be any number of public flag bytes? If so, do I simply ignore whatever's there? |
As discussed in Tokyo, @ekr to write up "special packets" proposal & then we'll revisit this |
#361 purports to address this; please re-open or file a new issue if that's incorrect. |
We need to define how the public flags might be extended, or if it could be. This has a pretty serious impact on #55.
The text was updated successfully, but these errors were encountered: