On Wed May 10 16:11:02 2023 +0000, Zebediah Figura wrote:
We'd also need to limit it to connected UDP then which both adds
complications, if not an extra server call. But I hope we might rely on the sockets not giving ECONNREFUSED for send() in any other cases, error codes are documented and breaking those in Unix kernel will probably break a lot of things anyway. I've never managed to find more than vague documentation for any error handling when it comes to sockets; do you have a better source? I'll admit "breaking those will probably break a lot of things" is not a particularly comforting thought. At this point I'm pretty well convinced that nobody really knows how to handle network error conditions, and that's why network software is universally so bad... I'm not too scared to sign off on this patch, but it's something that we'll have to watch out for.
No, I also don't have a particularly great source for socket error handling. I first found the explanation of ECONNREFUSED w/sendmsg UDP here: https://docs.oracle.com/cd/E36784_01/html/E36875/sendmsg-3socket.html. As a more pristine source, this can probably be concluded from https://www.rfc-editor.org/rfc/rfc1122#page-79 (p. 4.1.3.3 suggesting that UDP should relay ICMP errors to user). And the exact code is probably a mapping of ICMP error code. And we know from the tests that ICMP is ignored for UDP on Windows.
I only wanted to say that we already rely on specific error codes in many places and that is hardly avoidable, even if lack of clear and understandable specification is concerning. My source of optimism is only that as it looks to me historically Unix socket implementations were taking de-facto behaviour compatibility seriously (and that includes error codes).