I was considering the application to handle the actual sockets and the library would only handle the cyphal frame as well as some translation functions between cyphal concepts and UDP/IP concepts (ip address, ports, etc.)
The user of the library would use something like socket(2) - Linux manual page (Berkley Sockets I think?) setup as a UDP socket and then bind based on the SessionSpecifier. The user would need to create a SessionSpecifier based on the socket struct received during a recvfrom call.
With regards to the API, what is the function of udpardServe and UdpardIface? Would this be passing the file_descriptor of the socket to the library to handle sending and receiving?
On a side note:
Would we anticipate that the frame layout for TSN, TCP, etc. would be the same as UDP? Where Cyphal/ETH has the format:
typedef struct
{
uint8_t version;
uint8_t priority;
uint16_t _reserved_a;
uint32_t frame_index_eot;
uint64_t transfer_id;
uint64_t _reserved_b;
} EthardFrameHeader;
typedef struct
{
size_t payload_size;
EthardFrameHeader cyphal_header;
const void* payload;
} EthardFrame;
If that is or could be the case, then we could have libethard be an underlying library that queues and reassembles EthardFrames and libupdard, libtcpard, and libtsnard would handle their own UDP Header, TSN Header, etc. while packing the EthardFrame as their payload?