Revisit behavior of UDP socket and its connection states

[mlegner]

Currently, we can call connect repeatedly on a socket even if it already has a remote_address set. Additionally, we allow calling send_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 repeatedly connect().

[jpcsmith]

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 refactor: allow setters to be used on shared socket #94)
• connect(..) sets a default destination which enables the use of send* variants.
• recv returns a packet without the source address or fails?
  • A general search seems to imply that recv should only be used with a connected socket, but recv does not forbid this and a quick test in python does not immediately fail when recv() is called on an unconnected UDP socket but fails for a TCP socket.

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.
  • Question: what behaviour do we want to observe if connect is called while a recv is in progress?

Both:

• recv with a zero length buffer returns immediately with a sizes of 0
• recv*_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. (Implement checks for path usage in UDP Socket #98)

Other features which warrant their own issues:

• MTU discovery (Perform MTU discovery on UDP sockets and respect path MTUs. #96)

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.

[mlegner]

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).

[jpcsmith]

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