Detecting socket closed on TcpClient

[Michael Kennedy [UB]]

Hi,

I have a project using the TcpClient and its associated NetworkStream.
Everything works well except for one condition which I haven't found any
information about dealing with:

How do I detected when the socket connection was closed on the
server-side?

That is, if my client connects to the server and everything is initialized
correctly the system runs well. But how can I tell if the server is shut
down or otherwise closes my connection without my involvement (that is
without my calling close on the TcpClient)?

Thanks,
Michael

Michael Kennedy
United Binary
http://www.unittesting.com

[Michael Kennedy [UB]]

Hello,

Thanks for the response. I was afraid that that was the case. I am using
try/catches to catch the errors but I would like to be able to let the user
know if the connection was closed by the server.

I know this can be done using straight winsock / Win32 API sockets and C++.
Is there an equivalent in .NET? Can this functionality be accessed using
some sort of interop along side the TcpClient (short of just using the C++
sockets via interop of course).

Thanks,
Michael

"Tian Min Huang" <ti******@online.microsoft.com> wrote in message
news:cD**************@cpmsftngxa06.phx.gbl...

Hello Michael,

Thanks for your post.

But how can I tell if the server is shutdown or otherwise closes my

connection without my involvement?

I suggest you to use try-catch statement to catch the exceptions thrown
from tcp operations. Generally speaking, the client side will not be
notified when the connection was damanged on the server-side until it

fails to communicate with the service. For example, when the connection is
somehow not available, it will throw the following exception if you call
NetworkStream::Write or NetworkStream::Read on client side:

Unhandled Exception: System.IO.IOException: Unable to read data from the
transport connection. ---> System.Net.Sockets.SocketException: An existing
connection was forcibly closed by the remote host

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.

[Chris Langsenkamp]

On my solution I send some sort of 'bye' message to the client telling it the connection is being dropped, and I do so from the server with no expectation of response. The client is coded such that receiveing that from the server is the end of things. Your server connection is dropped for only a few reasons, one of which you can't control inside your program (ISP/connectivity failure), the rest should be app errors that you should be able to trap and kick out your bye messages as the server does it's finishing work. The key is making sure the server can't by any means abruptly halt, but must terminate gracefully, and telling all the clients is part of that. Even so, the client must be insulated from connectivity failings because certainly the clients are much more likely to have them than the server (i.e. dialup drop) which is no different to the client than the server hanging up - the read/write fails and client must deal with it.

Chris Langsenkamp
Chat Live at http://www.cleverchat.net
--------------------------------------------------------------------------------

"Michael Kennedy [UB]" <mk******@REMOVETHIS.unitedbinary.com> wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl...
Hello,

Thanks for the response. I was afraid that that was the case. I am using
try/catches to catch the errors but I would like to be able to let the user
know if the connection was closed by the server.

I know this can be done using straight winsock / Win32 API sockets and C++.
Is there an equivalent in .NET? Can this functionality be accessed using
some sort of interop along side the TcpClient (short of just using the C++
sockets via interop of course).

Thanks,
Michael

"Tian Min Huang" <ti******@online.microsoft.com> wrote in message
news:cD**************@cpmsftngxa06.phx.gbl...

Hello Michael,

Thanks for your post.

But how can I tell if the server is shutdown or otherwise closes my

connection without my involvement?

I suggest you to use try-catch statement to catch the exceptions thrown
from tcp operations. Generally speaking, the client side will not be
notified when the connection was damanged on the server-side until it

fails to communicate with the service. For example, when the connection is
somehow not available, it will throw the following exception if you call
NetworkStream::Write or NetworkStream::Read on client side:

Unhandled Exception: System.IO.IOException: Unable to read data from the
transport connection. ---> System.Net.Sockets.SocketException: An existing
connection was forcibly closed by the remote host

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.

[Michael Kennedy [UB]]

Hi,

Thanks for the info. I know about interporating with the API using PInvoke.
But what I was asking for was a .NET way of acheiving the same
functionality. This limitation is not important enough for me to build whole
wrapper classes for the winsock API.

Also, I do catch the exceptions and they do contain the information about
the socket being closed. However, what I need is some way to determine if
the socket has been closed without traffic to the server. Consider that the
client connects to the server and everything is good. Sits there idle for
awhile, then the server is shutdown. Now the client will sit there for an
indefinite period of time (until it tries to talk again) before it knows the
server is gone.

Our C++ apps which use the Win32 API are notified immediately when the
server is shutdown. I was asking if there is the same functionality in the
..NET sockets. I guess the answer is no.

Thanks again,
Michael
"Tian Min Huang" <ti******@online.microsoft.com> wrote in message
news:Ko**************@cpmsftngxa06.phx.gbl...

Hello Michael,

Thanks for your reply. I'd like to share the following information with you:
1. According to the SocketException, it's clearly indicate that the
connection was closed by the server.
"System.Net.Sockets.SocketException: An existing connection was forcibly
closed by the remote host"

2. You can also call winsock APIs directly by using Platform Invoke. Please refer to the following MSDN article:

Consuming Unmanaged DLL Functions
http://msdn.microsoft.com/library/de...us/cpguide/htm l/cpconconsumingunmanageddllfunctions.asp

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.

[Tian Min Huang]

Hi Michael,

Thanks for your response. I am now performing further research on this
issue, and will come back with my information.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.

[Tian Min Huang]

Hello Michael,

Now I'd like to share the following information with you. Generally
speaking, we should set the SO_KEEPALIVE option (by using setsockopt) to
monitor the connection. Please refer to the following KB article:

How to Determine Loss of Client/Server Connection
http://support.microsoft.com/default...b;en-us;140325

In .NET Framework, please refer to the corresponding KeepAlive option:

SocketOptionName Enumeration
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfsystemnetsocketssocketoptionnameclasstopic.as p

Please feel free to let me know if you have any problems or concerns.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.

[Michael Kennedy [UB]]

Hi,

Thanks for the response. That does look like it might be helpful to me. I'll
let you know how it goes.

Thanks,
Michael
"Tian Min Huang" <ti******@online.microsoft.com> wrote in message
news:FO**************@cpmsftngxa06.phx.gbl...

Hello Michael,

Now I'd like to share the following information with you. Generally
speaking, we should set the SO_KEEPALIVE option (by using setsockopt) to
monitor the connection. Please refer to the following KB article:

How to Determine Loss of Client/Server Connection
http://support.microsoft.com/default...b;en-us;140325

In .NET Framework, please refer to the corresponding KeepAlive option:

SocketOptionName Enumeration
http://msdn.microsoft.com/library/de...us/cpref/html/ frlrfsystemnetsocketssocketoptionnameclasstopic.as p

Please feel free to let me know if you have any problems or concerns.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! ¨C www.microsoft.com/security
This posting is provided ¡°as is¡± with no warranties and confers no rights.