python - 如何使用 MsgWaitForMultipleObjects 可靠地检测断开的 TCP 套接字？

Question

Twisted 包括 a reactor implemented on top of MsgWaitForMultipleObjects .显然， react 器无法可靠地注意到 TCP 连接何时结束，至少在对等方发送一些字节然后快速关闭连接的情况下。似乎发生的是:

1. The reactor calls MsgWaitForMultipleObjects with some socket handles and QS_ALLINPUT.
2. 调用完成并指示处于此状态(即，有字节等待读取并已被对等方关闭)的套接字句柄处于事件状态。
3. The reactor dispatches this notification to the common TCP implementation.
4. TCP 实现从套接字中读取可用字节。有一些，它们被交付给应用程序代码。
5. 控制返回到 react 器， react 器最终再次调用 MsgWaitForMultipleObjects。
6. MsgWaitForMultipleObjects 再也不会指示句柄处于事件状态。 TCP 实现永远不会再查看套接字，因此它永远不会检测到连接已关闭。

这使得 MsgWaitForMultipleObjects 看起来像是一种边沿触发的通知机制。 MSDN documentation说:

Waits until one or all of the specified objects are in the signaled state
or the time-out interval elapses.

这听起来不像边缘触发。这听起来像是电平触发。

MsgWaitForMultipleObjects 实际上是边缘触发的吗？或者它是水平触发的并且这种不当行为是由其行为的其他方面引起的？

附录 The MSDN docs for WSAEventSelect进一步解释这里发生的事情，包括指出 FD_CLOSE 基本上是一次性事件。在发出一次信号后，您将永远不会再收到它。这在某种程度上解释了为什么 Twisted 有这个问题。不过，鉴于此限制，我仍然很想知道如何有效地使用 MsgWaitForMultipleObjects。

Answer 1

为了使用WSAEventSelect 和区分事件，您需要调用WSAEnumNetworkEvents。确保您正在处理报告的每个事件，而不仅仅是第一个。

WSAAsyncSelect 可以很容易地确定原因，并且经常与 MsgWaitForMultipleObjects 一起使用。

因此您可以使用 WSAAsyncSelect 而不是 WSAEventSelect。

此外，我认为您对边沿触发和电平触发之间的区别存在根本性的误解。您的推理似乎与自动重置事件和手动重置事件更相关。