How can I reliably detect a disconnected TCP socket using MsgWaitForMultipleObjects?

Question

Twisted includes a reactor run on top of MsgWaitForMultipleObjects . The reactor seems to have problems that reliably notice when the TCP connection ends, at least in the case where the peer sends a few bytes, and then quickly closes the connection. It seems to be happening:

• The reactor calls MsgWaitForMultipleObjects using some socket descriptors and QS_ALLINPUT .
• The call ends and indicates that the handle to the socket in this state (that is, it has bytes waiting to be read and closed by the peer) is active.
• The reactor sends this notification to a common TCP implementation.
• The TCP implementation reads available bytes from the socket. There are some, they are delivered to the application code.
• Control returns to the reactor, which eventually calls MsgWaitForMultipleObjects again.
• MsgWaitForMultipleObjects no longer indicates that the handle is active. A TCP implementation will never be able to see the socket again, so it will never be able to detect that the connection is closed.

This makes it look like MsgWaitForMultipleObjects is an edge triggered notification mechanism. MSDN documentation says:

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

This is not like running over the edge. It sounds like a trigger level.

Is MsgWaitForMultipleObjects actually called front? Or is it caused by the level, and this wrong behavior is caused by some other aspect of his behavior?

Adding MSDN docs for WSAEventSelect explain what is going on a bit more here, including indicating that FD_CLOSE is basically a one-time event. After his one-time signal, you will never receive it again. This somewhat explains why Twisted has this problem. I am still interested in learning how to use MsgWaitForMultipleObjects effectively with this limitation in mind.

Answer 1

To use WSAEventSelect and differentiate actions, you need to call WSAEnumNetworkEvents . Make sure that you process every reported event, not just the first one.

WSAAsyncSelect makes it easy to determine the cause and is often used with MsgWaitForMultipleObjects .

That way you can use WSAAsyncSelect instead of WSAEventSelect .

In addition, I think you have a fundamental misunderstanding of the difference between edge triggering and level triggering. Your reasoning is more about auto-reset vs manual-reset events.