Just for the record: WSK disconnect event callbacks are for real. (Look for WSK_EVENT_DISCONNECT on MSDN.) They may be awkward to set up properly, but I use them in my WSK client code, and I see them getting called, with or without the WSK_FLAG_ABORTIVE qualifier, depending on the kind of disconnect that they have to report. (Pro tip: Connections aborted by the other host and all graceful disconnects get reported. But if you abort the connection yourself, you get no callback, you just have to remember what you did.)
Disconnect notifications may be a less obvious feature if you grew up with Berkeley sockets, but they exist in user mode, too: For both WSAAsyncSelect and WSAEventSelect you can set FD_CLOSE as one of the events you are interested in. (And that works as advertised, too. Been there, done that.)
1 Like
Just noticed that When I'm listening for Data (receive) and the Server disconnects the Client it gives me an error status code perhaps thats how I could detect Disconnection instead of these Events (I have no idea how to work with them)
Sure, that's a reasonable approach. Always keep a receive operation pending, and it will return when something interesting happens, either incoming data or a disconnect.
(The reason why I prefer event callbacks is history from a long, long time ago: On the checked build of Windows NT, closing a connection with a receive IRP still pending would trigger a debug assertion. And what might seem like an obvious solution to this problem was not pretty, either: Canceling the pending receive IRP first caused the connection to be immediately aborted, i.e. with RST packets on the network, not even a proper FIN.)