UDP: Local address should be regularly available

[chrysn]

Many UDP based protocols (eg. CoAP and QUIC) require the application to have control over the local address -- running a server at :: (or 0.0.0.0) means that a datagram comes in, and the server needs to take extra steps to reply with the same address (otherwise it violates the protocol, and the peer won't process the response).

While this is supported in POSIX sockets, it means that rather than doing the simple thing, implementers need to set the IPV6_RECVPKTINFO option, do recvmsg instead of recvfrom and pick the address out of there (which only in IPv6 is well specified).

WASI has the opportunity to make this straightforward, please use it. An example API that provides both addresses is the Rust embedded-nal abstraction for UDP (and the PR introducing it contains ample references and discussion on why this is necessary and good, which I'm happy to reiterate here in case this request is contentious).

[badeend]

My current line of thinking is to extend the datagram record with the additional fields. See:
badeend@185aee9#diff-dd6be4acde08e40226bc7d44060c0e1cae9acf6a3bd6036afbd26915706007d5

This also includes some extra fields unrelated to this specific IP_PKTINFO issue.

What do you think?

---

Also: since you already have implementation experience, do you by any chance know which error codes are returned by the various platforms when an invalid local address is provided when sending? (The question marks (???) in the diff linked above)

[chrysn]

Having all these unconditional sounds like a good choice for WASI to me. It's not that much data (traffic class and hop limit together as options are still at most one machine word), and having-it-and-not-using-it is likely cheaper than going through conditionals (was it requested?) on modern PCs.

On the errors when the local address can't be used any more: Frankly, I don't know – I've always treated them like other network errors, because either the application doesn't care (then it doesn't set it), or it does care. Then it doesn't really matter whether we changed our address or the destination became unroutable, the packet is just not sendable. It's not like there was ever a fallback situation like "try these source addresses in order". Experimentally it's EINVAL (-22) for bogus addresses and ENODEV (-19) for bogus interface identifiers, which is distinct from the ENETUNREACH (-101) sending to an unroutable address gives.