Winsock 错误 10054 (WSAECONNRESET) 是否“正常"?使用 UDP 到/来自本地主机? [英] Is Winsock error 10054 (WSAECONNRESET) "normal" with UDP to/from localhost?

问题描述

在单个 Windows PC 上使用 UDP 进行进程间通信可能会出现什么问题?"我想...并着手实施它.

"What could possibly go wrong with using UDP for inter-process communications on a single Windows PC?" I thought... and proceeded to implement it.

但是尽管仅发送了数百个字节并且只是非常零星地发送，并且尽管 UDP 被用作无连接协议(使用了 sendto() 函数)，但我还是被随机出现的错误 10054 所困扰 -连接重置".我觉得这很令人困惑.是吗:

But despite sending mere hundreds of bytes and only very sporadically, and also despite UDP being used as a connectionless protocol (sendto() function employed), I am plagued by random occurrences of error 10054 - "connection reset". I find this very confusing. Is it:

• 完全正常，意料之中，在这种情况下……这意味着发生了什么?
• 完全出乎意料，我可能实现了一些错误
• 完全出乎意料，所以我应该检查有冲突的软件(例如 这样的问题)
• 还有什么?

我在某处读到它可能表明另一端没有打开接收端口......但这对我来说更没有意义 - UDP 不是简单地应该发送数据报而不关心会发生什么它?或者当发送到/来自同一台机器(本地主机)上的端口时是否有一些特殊情况?

I read somewhere that it could indicate that there is no receiving port open at the other end... but this makes even less sense to me - isn't UDP simply supposed to send the datagram off and not care what happens to it? Or is there some special case when the send occurs to/from ports on the same machine (localhost)?

推荐答案

在我的具体情况下，我有一个在 localhost 上运行的服务器，监听绑定到特定端口的 UDP 套接字.它还有一个绑定到同一个端口的第二个 UDP 套接字(这在上下文中是有意义的)，仅用于发送对在第一个套接字上接收到的数据包的响应.

In my specific case, I had a server running on localhost listening on a UDP socket bound to a specific port. It also had a second UDP socket bound to the same port (it makes sense in context), used only for sending responses to the packets received on the first socket.

同样在 localhost 上运行的客户端会创建一个临时套接字，向服务器发送一个数据包，等待响应，然后关闭它们的套接字.客户端的超时时间非常短(出于应用程序特定的原因)，如果初始尝试超时，则会重试.

Clients, also running on localhost, would create a temporary socket, send a packet to the server, wait for a response, then close their socket. The timeout on the client side was very short (for application-specific reasons), with a retry if the initial attempt timed out.

有时会发生的情况是客户端向服务器发送一个数据包，在发送响应之前超时，然后关闭其套接字.然后，服务器将(在侦听套接字上)从客户端接收数据包，并(在发送套接字上)发回响应.但是，Windows 有用"地发回一个 ICMP 响应，说明目标端口上不再有任何套接字侦听.至关重要的是，这个数据包最终被传递到侦听套接字，而不是发送套接字(因为它们都共享相同的端口).在下一次从服务器上的侦听套接字读取时，会收到一个 WSAECONNRESET 错误，指示它发送的上一个数据包(实际上是从不同的套接字发送的)未能传递.

What would happen on occasion is a client would send a packet to the server, time out before the response could be sent, and close its socket. The server would then receive (on the listening socket) the packet from the client, and send back a response (on the sending socket). However, Windows "helpfully" sends back an ICMP response stating that there's no longer any socket listening on the destination port. Crucially, this packet ends up being delivered to the listening socket, and not to the sending socket (since they both share the same port). On the next read from the listening socket on the server receives a WSAECONNRESET error indicating the previous packet it sent (which was actually sent from a different socket) failed to get delivered.

在我的情况下，修复只是忽略侦听套接字上的 WSAECONNRESET 错误.发生此类错误后，侦听套接字继续成功接收其他数据包，而发送失败的数据包传递失败后，发送套接字继续成功发送数据包.

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

这篇关于Winsock 错误 10054 (WSAECONNRESET) 是否“正常"?使用 UDP 到/来自本地主机?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！