Publish request and single frame message

Hi Marcel :sun_with_face:

All happy CAN protocols are alike. I think this is to be expected considering that the solution space is small.

Allow me to retort:

  1. 50% is nothing! If the payload is zero, the overhead is 100% :scream_cat: (relative overhead is quite a useless metric unless you are comparing different technologies)

  2. Classic CAN is going away, especially in the fields that are not as encumbered by legacy as automotive or industrial fieldbuses. Many of the new UAVCAN/CAN applications will be leveraging CAN FD from day one, so that should be the primary optimization target. This is not to say that the Classic CAN is irrelevant, but it is to say that its performance is not the most critical factor to consider.

  3. The CAN ID should be a function of the Session Specifier to ensure its consistent and simple behavior at runtime. More on this either in the Specification or in Alternative transport protocols in UAVCAN. Using it to communicate auxiliary states of the transport layer means that the CAN ID will be changing depending on some highly volatile trifling details of the current configuration, which is undesirable.

  4. The extra byte is needed regardless of the above to support deduplication (which happens in CAN due to the ACK loss edge case briefly mentioned in the Spec), redundant transports, transfer loss monitoring, and some fringe features described in the Spec at length. You can remove it but it will be costly to the protocol.

The publish request does not fit into the data model that the protocol is based upon. We value statelessness and service-orientation, pub-sub is the main mode of interaction; you will find a detailed discussion in The UAVCAN Guide. Here it is also explained why node-ID should not be relied on in high-level application interfaces.

No. UAVCAN/CAN is stable and it is not going to be changing for a long time unless the change is wire-compatible with existing deployments out there and is strongly motivated.