OpenCyphal-Garage / libcyphal

Portable reference implementation of the Cyphal protocol stack in C++ for embedded systems and Linux.
http://opencyphal.org
MIT License
292 stars 502 forks source link

progress on Transport layer #330

Closed thirtytwobits closed 9 months ago

thirtytwobits commented 1 year ago

Bulk change over from previous design to pycyphal-like design. At this checkin we confirmed the network layer was functional on osx. There should be little difference, if any, for linux. The UDP transport layer is 90% complete with the read and write runFor methods being the last integration point needed for an end-to-end test.

This is mostly a design review and I'd encourage you to checkout the change locally and review that way instead of trying to cut through the noise of the diff (which is more deleted files than added).

The code is incomplete in the runFor methods of the input and output sessions since this is going to change a bit when we integrate with the changes to udpard.

Things to evaluate:

  1. Any missed opportunities to align with pycyphal
  2. any use of the default heap. The design should support a no-default-heap use of C++ and I believe I've used PMR everywhere that I used containers and other heapy things from stl.
  3. Suitability of the network layer to also implement CAN, serial, etc.
  4. Suitability of the transport layer to also implement CAN, serial, etc.
  5. Suitability of the network layer to get implemented directly on top of hardware (bare metal)
  6. Layering violations: the network layer should operate independent of any other libcyphal code and the transport layer should allow exchanging Cyphal messages without the automation and convenience of the presentation or application layers.
  7. Balance between type-safety and SLoC: I've biased towards writing more lines of code where it can guarantee more type safety. The biggest example is jenky::IPolymorphicType and sockets. The need to provide an explicit type system could be obviated by using opaque void*s, blind reinterpret_casts, and other C-like solutions that bypass the C++ type system. We should agree the proposed approach is the right one for libcyphal.
  8. Likely performance bottlenecks. I've tried to move more expensive operations to one-time initialization and de-initalization routines optimizing object states for higher performance in their runFor methods.
  9. Suitability to build the presentation and application layers on top of the transport layer.