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

查看:59
本文介绍了Winsock 错误 10054 (WSACONNRESET) 是否“正常"?UDP 到/从本地主机?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在单个 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)?

推荐答案

在我的特定情况下,我有一个服务器运行在本地主机上,监听绑定到特定端口的 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.

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

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 (WSACONNRESET) 是否“正常"?UDP 到/从本地主机?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆