Some time ago when we were discussing subjects and services @kjetilkjeka pointed out that the idea of special values like invalid identifiers is problematic because it undermines type safety. Similar issues can be found elsewhere as NullPointerException or the NULL pointer from C. I am wondering if we’re not making a mistake by allowing the special node ID of zero in UAVCAN v1.0?
A possible CAN ID format for anonymous messages if we were to unreserve the node ID of zero. The two other formats remain unchanged, a “reserved” field in message frames renamed into “anonymous message” field with the same value.
Generally I like this proposal. But, wow; this makes things really consistent! How worried are we about reducing the discriminator to 7 bits?
I really like the though of getting rid of the node id = 0 special case. I suspect having it as a bit simplify both library implementation and use. And I love the alternative layout you’re presenting.
I suspect it will be enough with 7 bit discriminators. As long as ordinary messages have deterministically higher priority than anonymous messages they will only collide with each other and not degrade performance for nodes that has been assigned an ID.
I think we need to look at it a bit more formal though and sort out what kind of performance we can expect from anonymous ID transmissions with a concrete back off strategy.
I have implemented these changes in my transport branch in the spec repo; we will get to the details and wording once the branch is PR-worthy.
7-bit discriminators are, indeed, quite narrow; with 128 possible values, collisions would be likely to occur when there is a lot of anonymous traffic on the bus. One of the worst case scenarios is when a network that relies solely on plug-and-play nodes is powered on so that all nodes begin initialization synchronously (e.g., when a vehicle is powered on); suppose there is one central controller and 127 other nodes requesting a plug-and-play node ID. If they were to emit their requests simultaneously, there would be 127 contesting requests with 128 possible discriminator values; the probability of a collision would be negligibly close to 1. With a 10-bit discriminator we used to have, there would be the same 127 nodes with 1024 possible discriminator values, resulting in the collision probability of only just 0.9996 (yay). For reference, a 16-bit discriminator yields 0.115.
Disregarding the impractical option of using a huge 16-bit discriminator, one would see that as far as the worst case is concerned, 7-bit vs 10-bit does not make a lot of practical difference, hence it makes sense to sacrifice the three bits for the sake of more consistent ID layout.
Regarding the back-off strategy – a very practical approach that is currently employed by the existing plug-and-play protocol is a variant of CSMA/CD. You can see the explanation here, it will not be affected by the reduction of the discriminator bit width: https://github.com/UAVCAN/dsdl/blob/uavcan-v1.0/uavcan/pnp/65534.NodeIDAllocationData.0.1.uavcan