Is Winsock Error 10054 (WSAECONNRESET) "normal" with UDP to / from localhost?

Question

"What could be wrong with using UDP for interprocess communication on the same Windows PC?" I thought ... and set about implementing it.

But, despite the fact that you send only hundreds of bytes and only very sporadically, and despite the fact that UDP is used as a connectionless protocol (the sendto() function is used), I am tormented by random error errors 10054 - "connection reset" . I find it very confusing. It:

• completely normal, as you would expect, and in this case ... what does this mean happened?
• completely unexpectedly and I probably took advantage of something wrong
• completely unexpectedly, so I have to check for conflicting software (e.g. for such problems )
• something else?

I read somewhere that it may indicate that there is no receive port on the other end ... but it doesn’t even make sense to me - isn’t UDP just supposed to send a datagram and doesn’t care what happens to it? Or is there some special case when the transfer occurs to / from ports on one computer (localhost)?

Answer 1

In my specific case, I had a server running on the local host that was listening on the UDP socket associated with a particular port. He also had a second UDP socket connected to the same port (this makes sense in context), used only to send responses to packets received on the first socket.

Clients also working on the local host will create a temporary socket, send a packet to the server, wait for a response, and then close their socket. The client side timeout was very short (for reasons related to the application), with a retry if the time of the initial attempt expired.

Sometimes it happens that the client sends a packet to the server, waiting for a response to be sent, and closes its socket. Then the server will receive (on the listening socket) a packet from the client and send a response (on the sending socket). However, Windows "helpfully" sends an ICMP response stating that there are no more listening sockets on the target port. It is important to note that this packet is ultimately delivered to the listening socket, and not to the sending socket (since they both use the same port). The next time you read from the listening socket on the WSAECONNRESET server, a WSAECONNRESET error indicates that the previous packet that it sent (which was actually sent from another socket) was not delivered.

In my case, the fix was to simply ignore WSAECONNRESET errors on the listening socket. The listening socket continued to accept other packets successfully after such errors occurred, and the sending socket continued to successfully send packets after the packet was not delivered.