Detecting when a socket has been closed.

  • Thread starter Thread starter Kurt
  • Start date Start date
K

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
 
Kurt said:
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.
Click to expand...

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 said:
If I am using BeginRecieve it won't fire until data is received.
Click to expand...

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
 
Kurt said:
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
Click to expand...

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/d...tdown_linger_options_and_socket_closure_2.asp


Regards,
Goran
 
That works.

Thanks!

Markus Stoeger said:
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
Click to expand...
 
Back
Top