# Publish request and single frame message

**URL:** <https://forum.opencyphal.org/t/publish-request-and-single-frame-message/963>\
**Category:** Development & Maintenance\
**Created:** [October 18, 2020, 4:52pm UTC](https://forum.opencyphal.org/t/publish-request-and-single-frame-message/963 "2020-10-18T16:52:49Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [October 19, 2020, 10:26am UTC](https://forum.opencyphal.org/t/publish-request-and-single-frame-message/963/2 "2020-10-19T10:26:39Z")

</div>

Hi Marcel 🌞

> [@r00tc0d3](#):
>
> The way UAVCAN is using the CAN transport is surprisingly similar to what I specified until now.

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

> [@r00tc0d3](#):
>
> 1. Having always a byte of overhead in the CAN payload. In CAN world this is a lot! Having, apart from the already high overhead of a CAN message, 50% overhead on the data part when sending 1 byte is huge. Therefore I would propose having a multi/single message bit in the CAN ID.

Allow me to retort:

1. 50% is nothing! If the payload is zero, _the overhead is 100%_ 🙀 (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](https://forum.opencyphal.org/t/alternative-transport-protocols-in-uavcan/324). 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.

> [@r00tc0d3](#):
>
> 1. Another ‘missing’ feature is to have a publish request. One could use a service request for it but this creates overhead in my opinion.

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](https://uavcan.org/guide/). Here it is also explained why node-ID should not be relied on in high-level application interfaces.

> [@r00tc0d3](#):
>
> Are you willing to consider such changes?

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.

---

_[View the full topic](https://forum.opencyphal.org/t/publish-request-and-single-frame-message/963)._