Closed mlegner closed 9 months ago
From the UDP man pages and those for connect, send, and recv we can identify the following behaviours of the socket in order to be consistent:
When not connected:
send*_to
variants can be immediately used to send packets to a destination.send*
variants return ENOTCONN (renamed in #94)connect(..)
sets a default destination which enables the use of send*
variants.recv
returns a packet without the source address ~or fails?~
When connected:
recv
can be used to receive packets without the source address.send*
variants can be used to send to the configured destination.send*_to
variants can be used on a connected socket to send to other destinations. (We currently return an error which should only be the case for connection-oriented sockets)connect
limits (all) datagrams returned on recv
and recv_from
to those from the configured peer.connect
can be called again to change the associated remote address or completely unset the association.
Both:
recv
with a zero length buffer returns immediately with a sizes of 0recv*_from
variants can be used to receive a packet along with it's address.send*_via
should only use the path if it matches the ISD ASN of the source and destination. (#98)Other features which warrant their own issues:
Additionally, there are some race conditions worth paying attention to when working with bind + connect in standard UDP sockets. We should look which apply here.
Thanks a lot for this detailed investigation, @jpcsmith!
Question: what behaviour do we want to observe if connect is called while a recv is in progress?
I guess there are two options: (1) Use the state from when recv
was called or (2) use the new state. I can see arguments for both options, but would opt for (1).
Regarding the race conditions, they are only applicable if we attempt to support "UDP accept" where we create new connected sockets for peers. This, however, would also require some kind of demultiplexing of incoming packets to the correct socket
Currently, we can call
connect
repeatedly on a socket even if it already has aremote_address
set. Additionally, we allow callingsend_to(destination)
, even if it is already in a "connected" state.We should decide if we want to change that behavior; e.g., return an
AlreadyConnectedError
when trying to repeatedlyconnect()
.