Detecting when a socket has been closed.

[Kurt]

I have a client & server app which communicates using the socket class. If I
shutdown the server closing the socket the client still thinks the socket is
open. Even calling send does not throw an exception.

Thanks
Kurt

[Markus Stoeger]

Kurt wrote:

I have a client & server app which communicates using the socket class. If I
shutdown the server closing the socket the client still thinks the socket is
open. Even calling send does not throw an exception.

The Receive function returns the number of bytes received. When the
connection has been closed it returns 0. Can you get it to work that way?

Max

[Kurt]

If I am using BeginRecieve it won't fire until data is received.

"Markus Stoeger" <sp******@gmx.atwrote in message
news:OW**************@TK2MSFTNGP05.phx.gbl...

Kurt wrote:

>I have a client & server app which communicates using the socket class.
If I shutdown the server closing the socket the client still thinks the
socket is open. Even calling send does not throw an exception.

The Receive function returns the number of bytes received. When the
connection has been closed it returns 0. Can you get it to work that way?

Max

[Markus Stoeger]

Kurt wrote:

If I am using BeginRecieve it won't fire until data is received.

It also fires when the connection is closed. In that case the call to
EndReceive will return 0.

You should also put a try/catch around EndReceive. If it throws, you can
take it as closed too.

Max

[Goran Sliskovic]

Kurt wrote:

I have a client & server app which communicates using the socket class. If I
shutdown the server closing the socket the client still thinks the socket is
open. Even calling send does not throw an exception.

Thanks
Kurt

Hi,
First send will not throw exception, because there is no way for TCP
stack to know that other end has actually closed its receiving side.
Second send may throw or may not, depending on the timing. It takes some
time for packet to reach other side and return information that server
side is gone (it may take as long as 2-3 minutes). This is by design of
TCP protocol.

Few things you should note:
a) if send succeeds, that doesn't mean data is received by other side.
It means only that it is buffered by the OS
b) only when TCP stack timeouts on send (if foreign computer becomes
unreachable due to connection going down) TCP will know something is
wrong. You will not be notified until next operation (send or receive).
This may take minutes.
c) in case other end has closed socket and network is still operating
after first send TCP RST segment will be returned to TCP stack notifying
it connection has gone down. That send will succeed however, next should
fail. This takes also some time, though generally is much faster than
TCP timeout mechanism.
d) on idle connection, there is no exchange of data over socket.
Meaning: if you pull out the cable of server computer, you will never be
notified of this unless you try to send something (read will block
forever). First send will succeed, than after timeout next send/read
should fail. There is a keepalive option that can prevent this.
e) if you pull cable of client computer, you may get immediate
notification due to windows media sense feature.
f) Markus is right, async receive should complete when connection
tear-down is detected. But when exactly it is detected, is different story.
g) to close connection gracefully, both server and client must follow
some constraints. Check:
http://msdn.microsoft.com/library/de..._closure_2.asp
Regards,
Goran

[Kurt]

That works.

Thanks!

"Markus Stoeger" wrote:

Kurt wrote:

If I am using BeginRecieve it won't fire until data is received.

It also fires when the connection is closed. In that case the call to
EndReceive will return 0.

You should also put a try/catch around EndReceive. If it throws, you can
take it as closed too.

Max