[...]
so i think i have to try to send something to the client that has
crashed, and if an exception occurs, then the client is deconnected.
That would be one way to detect the situation, yes.
Or maybe, i have to use the timeout, the if timed out, i try to send
something to check if the client is still here
You can either use the timeout itself as an indication of connection
failure, or you can attempt to send data after the timeout. Either one
will work, and which one you want depends on your needs.
do you think it is a good idea ?
Not really. I mean, I don't know your particular situation but it's my
opinion that enforcing a failure for no immediate need or reason isn't
useful.
The server has no way to know if the connection has failed due to a
client-side crash, or simply due to a temporary problem with the network.
A temporary problem may resolve itself and so detecting that condition is
pointless and results in unnecessarily closing the connection.
IMHO, it would be better to simply let the server continue to assume that
the connection is valid unless there is some explicit, non-arbitrary
verification that it's not. This could include:
* The server actually needs to send data to the client and the error
is detected at that time
* The server receives a second connection request from the same client
(detected by IP address or by some unique client ID, such as a username
and/or password)
* Someone with access to the server (by whatever mechanism you
choose...could be a remote control interface, or simply a button on the UI
of the server on the same computer it's running on) explicitly closes the
connection
If you are concerned about the connection remaining open and consuming
resources that are needed for other valid connections, then you could
simply wait until such time as you need those resources (eg you get an
exception creating a socket or accepting a connection) and then close
existing connections that have been idle the longest, and idle for some
reasonable minimum amount of time (what time is "reasonable" depends
entirely on your needs).
Should I use the SendTimeout property with the Send() method ?
It seems to me that if it's the receive you want to apply the timeout to,
then it's the ReceiveTimeout property you want to set.
I don't know how the .NET Socket implementation of ReceiveTimeout works,
but if it's the same as the regular Winsock note that if and when the
socket times out, it is no longer usable. So, if you want to send data
after the timeout, you need to implement the timeout some other way (using
a timer, for example).
In other words:
* If you are simply going to close the socket after the timeout
occurs, use ReceiveTimeout
* If you are going to query the other endpoint to see if they are
still connected after the timeout, use your own timer and then when it
expires do the send. Of course, if the other end replies, your receive
will complete and you'll have to initiate it again to wait for real data.
If you are doing the latter, you may find that using SetSocketOption with
the KeepAlive option is preferable. Though, I don't see any way in .NET
to change the keep-alive interval, so if the default of 2 hours isn't
appropriate for your situation, you may have to implement the timeout
manually as above.
Of course, keep in mind my comments about. This timeout stuff may or may
not be the correct way to address the issue. As I said, I don't
personally think that arbitrarily timing out a connection is necessarily
the right thing to do. There are other ways to address the situation of a
crashed client...there are situations in which timeouts make sense, but
because of the chance of a false positive with timeouts, they should only
be used when you really want a timeout specifically, rather than when you
are trying to address some other issue.
Pete
