Skip navigation

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



    • Anonymous
    • Posted December 3, 2009 at 6:41 pm
    • Permalink

    This behavior is different between XP and Vista apparently. The sockaddr_in struct will not be filled out in Vista with the info from the failed packet, whereas in XP it is.

    Need to find a solution for this.

    • Haitong
    • Posted December 11, 2009 at 1:06 pm
    • Permalink

    really helpful…I encountered this problem recently…this article help me find the root cause…

  1. Great thanks! This helped me.

  2. A thousand thanks for your post here! ;)
    This made me solve my issues when a client left without a proper close message.

    IMO it’s weird to just throw an exception at the next BeginReceive or EndReceive…
    And the worst part is that you can’t see what the remote endpoint was…

    • Irfan
    • Posted February 19, 2013 at 5:09 pm
    • Permalink

    Thank you for this post. Helped us debug why our UDP socket python code ran on linux and not on windows.

    • John Bendiksen
    • Posted September 11, 2013 at 10:59 pm
    • Permalink

    This post has save me many hours of painful diagnostics, head-scratching and cursing. It has also cured my gout, lowered my receding hairline and re-invigorated my sex life. Many, many thanks to you, RedundantBo.

    And yes, it IS wierd. DAMN wierd.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: