Hmm. That DOESN’T MAKE SENSE, does it?

Aaron Zupancic (from web archive) says its Microsoft’s fault.

This is basically what the Microsoft article says:

If sending a datagram using the sendto function results in an “ICMP port unreachable” response … the subsequent call to recvfrom does not work with a WSAECONNRESET (10054) error response.

Isn’t that STUPID?? Isn’t that like, totally against the spirit of UDP? Isn’t the UDP protocol supposed to like, “not care” if the message doesn’t get there? Why are you throwing this error in my face now when I don’t expect it, Microsoft?

Anyway, here it is again: On a UDP-datagram socket this error indicates a previous send operation resulted in an ICMP Port Unreachable message.

Anyway, it only happens once PER TIME you call sendto() on an (address,port) that isn’t set up to receive a UDP packet. Basically, when you send something to an (address,port) that CANNOT RECEIVE IT, you get this error on your NEXT call to recvfrom(). Its a pretty roundabout and counter intuitive way of doing stuff, but hey, so are a lot of other things in sockets (EWOULDBLOCK on nonblocking socket when you try to receive, zero-length packet when someone closes a TCP connection..), but it CAN BE pretty useful to know that SOMEONE has gone away and you should check the whether each of the clients you THINK is there, if any of them has gone away (which one of them certainly has).