Are you communicating on your socket synchronously or asynchronously?
If you are using a synchronous pattern, one thing I have done in the
past is use the .DataAvailable attribute of the NetworkStream object
derived from the socket (I know, getting complicated). The idea was, if
there is no information available, go ahead and test the connection. To
test the connection I simply tried to send a predetermined "test
packet" over the connection, and if this attempt is placed in a
try/catch block then you'll know when the connection has been lost.
That said, as someone mentioned in this thread before, if you're not
using a socket you might not care if it's connected until you need it.
I guess it depends on what you're trying to do. Often times with
wireless networks, connections will be lost for a couple of seconds and
then regained. If during that time your app wasn't doing anything,
there's no reason to go through a bunch of connection lost code if the
connection will just be re-established before you're done dealing with
the fact you lost connection. Again, depends on your goals.
Hope this helps. If you think you need to see some sample code I could
do that with a better idea of your goals. Good luck!
Peter Duniho wrote:
"Court Jester" <co************@hotmail.co.ukwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
Hi all,
Excuse me if this is wrong forum for this but I've implemented a
protocol handler for my socket server using the state pattern and it
works fine until I attempt to introduce heartbeats which are sent
independently of the client process on the same socket to the server.
Now the state can be processing commands and finds that it has received
a message for the client and this contravenes the protocol and state
transition is inconsistent.
So much for trying something new. What have other people used to solve
this?
Most people don't bother with "heartbeats". You try sending, and if it
works, everything is okay. If you aren't sending, you don't care whether
the connection is valid at that moment. It could become valid by the next
time you actually need it, and so detecting that it's invalid at that moment
is counter-productive.
This oversimplifies a bit, but the bottom line is that it usually doesn't
make sense to intentionally cause an error to occur when none would
otherwise happen.
As far as your specific issue goes, well...the problem is entirely
architectural, within your own code. If you insist on using heartbeats,
then you need to build logic into your network code that can tolerate extra
communications occuring while you are "processing commands". The answer to
that has nothing to do with .NET or C#.
Pete
