How does tokio UdpSocket recover from errors?

I'm working with the tokio UDP library and have encountered this question. How does a UdpSocket recover from an error?

Consider recv_dgram. It takes the owned UdpSocket as input, and returns a RecvDgram future, which provides the UdpSocket back as part of the item type. But the error type in this case is only an error and the UdpSocket is inaccessible.

If my UdpSocket call fails, is my socket just gone and I need to reopen a new one if I want? Is UDP so sturdy that it just never fails and I don't have to worry about it? I'm working on how to pass the socket's ownership around right now and this case seemed confusing.

Any guidance is appreciated, thanks!

1 Like

In terms of recvfrom on Unix systems, about the only other error that should be handled would be EINTR - your read was interrupted from a signal (see other errors here).

If RecvDgram errors, the UdpSocket is dropped, which, through mio -> rust stdlib -> sys -> std::fd, drops the file descriptor and closes the socket.

This is one of my pet peeves about Result - often times, having the original item back in the case of error is extremely useful.

1 Like

The RecvDgram function is a small future - it is be possible to write your own future that wraps UdpSocket's recv_from directly similar to how RecvDgram operates, but to return the UdpSocket in the case of error.