GetQueuedCompletionStatus - ReadFile - closed socket

[h9n]

Hello,

we are developing a network application using IO Completion Ports.

We issue asynchronous read operations on a socket with "ReadFile" and get
the result via GetQueuedCompletionStatus.

There are two situation, where we can see what happens (via debugging), but
I can not figure out, where this behaviour is documented.
Maybe you can shed some light on the two issues:

There is an open socket/handle and a asynchronous ReadFile was issued on
that handle.


1) If locally "closesocket" is called, GetQueuedCompletionStatus (for the
ReadFile operation) returns with "false" and
GetLastError returns ERROR_OPERATION_ABORTED (995).

This makes sense, but this is nowhere documented.

2) If the remote partner is closing the socket, GetQueuedCompletionStatus
return with "true", numberOfBytesTransferred is 0.
(If I continue to issue another "ReadFile" also this operation returns
"true" and numberOfBytesTransferred=0.)

It looks like this is the indication that the socket was closed. Also this
is nowhere documented.

Are there other ways to detect, that the socket was closed by the remote
station.

I would appreciate, if somebody can confirm these observations and if
somebody can point out where this behaviour is documented.

Thanks for your help,

Hans-Jürgen

[vasanth]

This is msdn recv documentation:
" If the connection has been gracefully closed, the return value is zero.
Otherwise, a value of SOCKET_ERROR is returned"
If the connection closed gracefully then "no error return".

You can use WSAEventSelect with FD_CLOSE to get notification abt the
socket close. WSAEnumNetworkEvents is used to get the extended errors of the
socket notification.

Thanks for your reply. You confirmed my observations.
Still I am wondering where this is documented.
Your advice, to implmenent the "close" in the protocol does not work in my
situation, because my component is an abstraction of the socket. (The
protocol is on top of this abstraction.).
If it is expected behaviour, that a read-operation on a socket, which was
remotly closed, returns successfully, how can I figure out that the socket is
not operable any more? Is there an API to query the status of the socket?
Thanks for your help,
Hans-Jürgen.

First case, your forcefully closing the connection while a read call is
pending.
Second case, the connection is gracefully closed, so it won't give any error
code that's documented in windows. You can have a close command in your
application layer protocol to notify about the connection close. Don't rely
on the socket layer close & error messages.

Post by h9n
Hello,
we are developing a network application using IO Completion Ports.
We issue asynchronous read operations on a socket with "ReadFile" and get
the result via GetQueuedCompletionStatus.
There are two situation, where we can see what happens (via debugging), but
I can not figure out, where this behaviour is documented.
There is an open socket/handle and a asynchronous ReadFile was issued on
that handle.
1) If locally "closesocket" is called, GetQueuedCompletionStatus (for the
ReadFile operation) returns with "false" and
GetLastError returns ERROR_OPERATION_ABORTED (995).
This makes sense, but this is nowhere documented.
2) If the remote partner is closing the socket, GetQueuedCompletionStatus
return with "true", numberOfBytesTransferred is 0.
(If I continue to issue another "ReadFile" also this operation returns
"true" and numberOfBytesTransferred=0.)
It looks like this is the indication that the socket was closed. Also this
is nowhere documented.
Are there other ways to detect, that the socket was closed by the remote
station.
I would appreciate, if somebody can confirm these observations and if
somebody can point out where this behaviour is documented.
Thanks for your help,
Hans-Jürgen