@brunowonka I don't really have time to review this at the moment, but if you open a draft pr I can start reviewing the code once I have some time. In general I think that if the API surface isn't too big socket2 should be able to support this.

Thanks @Thomasdezeeuw, opened #316 to get the conversation started

I don't have an opinion on the code per-say, but I did want to link some other resources I stumbled across that may be helpful:

• quinn udp used in rust QUIC impl, has a cmsg type that may be informative
• nix sendmsg

As an argument for supporting sendmsg/recvmsg, if you want to modify the interface or ip used when sending or receiving a message while bound to ipaddr_any, for instance, those methods are necessary. dnsmasq does this in its DHCP impl. If socket2 is meant to support "advanced configuration options" it seems like something it should be able to do.

edit: it looks like quinn uses sendmmsg/recvmmsg on linux but falls back to just send_to/recv_from on windows? see here

There also is some incomplete work in the standard library

• Tracking Issue for feature(unix_socket_ancillary_data) rust#76915
• https://doc.rust-lang.org/std/os/unix/net/struct.UnixStream.html#method.recv_vectored_with_ancillary

If this is useful for anyone, I extracted some of the code from quinn into a library that has sendmsg/recvmsg for tokio & std https://github.com/leshow/unix-udp-sock

Reading and writing PKTINFO would also be of great help for std_embedded_nal, as having the local address is mandatory for that interface, to allow QUIC and CoAP implementations. (Right now, that crate goes through nix, but this crate could offer it in a sufficiently abstract way that even Windows can be supported).