Extend API of UnconnectedUdpSocket

[maikerlab]

To improve compatibility of RIOT Sockets with more libraries and applications, I want to propose implementing the following functions for riot_wrappers::socket_embedded_nal_async_udp::UnconnectedUdpSocket, similar to the API of async-io

• pub async fn send_to(&mut self, data: &[u8], addr: SocketAddr) -> Result<(), Error> (like this one)
• pub async fn recv_from(&mut self, buffer: &mut [u8]) -> Result<(usize, SocketAddr), Error> (like this one from async-io)
• something like pub async fn peek_from(&self, buf: &mut [u8]) -> Result<(usize, SocketAddr)> (like this one to receive a packet without removing it from the queue

Background: While integrating the (experimental) Rust Matter Library into RIOT OS (see PR) I had to deal with incompatibilities between the Traits NetworkSend and NetworkReceive and the provided functions by UnconnectedUdpSocket. As a workaround I developed a "Wrapper" where I just called the corresponding functions send/receive_into and did some coordination between them. After my implementation, there were some changes in rs-matter, where the traits got renamed and additionally required the wait_available function to enable sharing one buffer between two UDP sockets.

I don't know if there are any other popular libraries in "Rust Embedded" where the same problem arises, but for using the rs-matter Library in RIOT OS it is required. I think it would also be a great benefit in general, if an async_io socket could easily be swapped out by a RIOT Socket.

[chrysn]

How are those different from the ones available through embedded-nal?

As far as I understand the Rust Matter implementation's issue, the trouble they have (and while I haven't seen any other UDP user run into this, that doesn't tell much) is that they want to have the &mut self of send_to and the &mut self of recv_from to be distinct, so that they could be used independently in different tasks. Is that what you are suggesting? (I don't see it in your description, and don't see how the linked "this one"s provide that either).

As for peeking, I don't think that this functionality is available in RIOT sockets; that'd need to be added (or emulated, but at that point it may be better to emulate it in the Matter receiver and buffer there, rather than making the RIOT wrapper do more-than-wrapping work).

[maikerlab]

Yes, "use send/recv independently in different tasks" is a better description of the issue I want to address. :) This was the main reason I had to develop this wrapper, which was a workaround for my specific usecase with rs-matter, so I wanted to ask if it would make sense to implement such functionality for the UDP Sockets in this library. But I guess first this should be implemented in embedded-nal (if accepted), before implementing the "split socket functionality" in riot-wrappers.

For peeking I didn't find out if this is available in RIOT Sockets. Are you aware of other usecases where this is needed by riot-wrappers?