# On CAN adapters and stateless interfaces **URL:** \ **Category:** Development & Maintenance\ **Created:** [September 7, 2019, 3:47pm UTC](https://forum.opencyphal.org/t/on-can-adapters-and-stateless-interfaces/613 "2019-09-07T15:47:39Z")\ **Posts on this page:** 2\ **Page:** 1
**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:** [September 7, 2019, 3:47pm UTC](https://forum.opencyphal.org/t/on-can-adapters-and-stateless-interfaces/613/1 "2019-09-07T15:47:39Z")
As a practical experiment on the applicability of DSDL, I have designed a namespace defining the interface to an abstract UAVCAN-interfaced CAN adapter. It is not supposed to be included in the standard namespace since it’s too application-specific; rather, suppose that these definitions are contained in a vendor-specific namespace. The exact use I have in mind for these definitions is irrelevant as of now so I am not going to discuss that; think that the business requirements are to make a generic bridge. The interface is designed to be fully stateless (one side does not make assumptions about the state of the other side) and is based on the continuous exchange of two messages between the “master” node (the user of the interface bridge) and the “bridge”/“adapter” node itself: - Idempotent command message type `Configuration`, published periodically by the “master”. - Informative status message type `Status`, published periodically by the bridge. Such message-based idempotent interface is desirable because it is self-recovering against loss of state on the bridges (e.g., due to power cycling) and scales automatically to any number of bridges working in lockstep (modular redundancy). The proposed types define the management interface only. The application data is transferred via separate topics of type [`uavcan.metatransport.can.Frame.1.0`](https://github.com/UAVCAN/public_regulated_data_types/blob/metatransport/uavcan/metatransport/can/Frame.0.1.uavcan), which is a very new experimental message type that I’m planning to merge into the standard namespace soon as a part of the ongoing work on the [logging feature](https://github.com/UAVCAN/pyuavcan/issues/74) (the link points to PyUAVCAN but the feature is obviously supposed to be implementation-agnostic). One thing I noticed is that having complex data type definitions with a deep level of nesting in one namespace directory gets messy fast. When you’re looking at the directory, the structure looks flat and it’s hard to grasp the purpose of the namespace at a glance: ![image](https://forum.opencyphal.org/uploads/default/original/1X/62a99609cf77e2995f453ff6e830008aaa966754.png) Perhaps in the future, we should look at having some means of defining simple (anonymous?) types in-place or expressing the structure at the directory level. Find the definitions at: [https://github.com/Zubax/zubax\_dsdl/tree/master/zubax/bridge/can](https://github.com/Zubax/zubax_dsdl/tree/master/zubax/bridge/can) ---
**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:** [September 10, 2019, 9:15am UTC](https://forum.opencyphal.org/t/on-can-adapters-and-stateless-interfaces/613/2 "2019-09-10T09:15:30Z")
> [@pavel.kirienko](#): > > The application data is transferred via separate topics of type [`uavcan.metatransport.can.Frame.1.0`](https://github.com/UAVCAN/public_regulated_data_types/blob/metatransport/uavcan/metatransport/can/Frame.0.1.uavcan), which is a very new experimental message type that I’m planning to merge into the standard namespace soon as a part of the ongoing work on the logging feature. The pull request is up: > > > This pull request adds the experimental namespace \`uavcan.metatransport\` with da…ta types designed for transferring transport frames over UAVCAN (hence the name). This is necessary for logging and tunneling: > > \- https://github.com/UAVCAN/pyuavcan/issues/74 > \- https://forum.uavcan.org/t/on-can-adapters-and-stateless-interfaces/613 > > Seeing as the logging and tunneling are largely application- and implementation-agnostic, these data types should be included in the standard set. > > The three top-level data types are: > > \- \`uavcan.metatransport.can.Frame\` (generic CAN and CAN FD frames) > \- \`uavcan.metatransport.udp.Frame\` (generic UDP/IPv6 jumbo frames) > \- \`uavcan.metatransport.serial.Fragment\` (not "frame" because the serial transport is stream-oriented and does not support framing natively)