@kjetilkjeka is proposing to change the CAN ID format of anonymous transfers by adding a new flag located at bit 23, called invert, that would convey whether the ID should be inverted. For example:
- Sub-subject ID = 5, invert = 0, resulting subject ID = 5.
- Sub-subject ID = 5, invert = 1, resulting subject ID = ~5 = 65530.
I think the idea is solid but the bit 23 is clearly a suboptimal choice since it happens to be located in the middle of a reserved field:
I suggest we move the flag to the bit 25, keeping the rest unchanged/reserved.
I do not have very strong feeling towards which bit is used, and is basically on board with any bit as long as we get an inverted field instead of inversion as a default. But lets discuss it a little to bring the different arguments to the surface.
We obviously don’t want it to far to the right as we might want to extend on which ports can be used anonymously.
The problem off moving it to bit-25 is that an anonymous transfer will sometimes have higher priority than services and sometimes lower (depending on the ID), this seems like an unnecessary breach of determinism. And since we have a lot of bits to take from this should not be deemed necessary.
We could fix bit 25 once and for all as a “redundant” service not message bit (in addition to NodeID being 0) to make priority deterministic and put it in bit 24? I think we have enough “spare bits” that we can afford to use one to make the protocol more deterministic.
Bit 24 it is then. All hail determinism.
1 Like
