do**********@gm ail.com wrote:
I have an Asynchronous socket that sends data to a server for credit
card approvals. The socket is kept alive by the server through a
heartbeat that sends a "beat" every 90 seconds. Trouble is that the
network is unreliable at times and thus the server will drop my
connection from time to time. I need to code around this so I can
reconnect to the server whenever this happens.
THE PROBLEM:
The Connected, Poll, and Available properties and methods are all
telling me that I am working, but I know for a fact that the server is
expecting me to reconnect because I stopped my heartbeat. This is all
verified so please don't question the scenario, I just need help
finding out that my connection is no longer valid through some
property on the .NET Socket or something in the Async callbacks that I
may be missing. Any help, please!!!!
There is no such property. This is an inherent feature/limitation of TCP/IP.
None of these properties work unless the connection is being actively used
(including active disconnection).
The *only* way to detect a broken connection is to send data on it and find
out that it doesn't work. You will only get an error on receiving data if
the other side shuts down the connection and your side sees it (which is not
the case for unexpected drops). In other words: you (the client) should be
sending heartbeats, and as soon as that fails, your connection will break
and you should reconnect. Ideally, the server should send replies to that
heartbeat that you can timeout on, so you can detect a one-sided connection.
The other way around works as well, but the bottom line is that you should
be sending.
If you *are* doing all that and you're still not detecting a broken
connection, you should check your firewall configuration (on either end). It
may be keeping the connection open improperly.
Note that even with heartbeats, you get no guarantee of uninterrupted
service, and sending a request can always fail, even if you just had a good
heartbeat. Your protocol should work exactly as well without using *any*
heartbeats and rebuilding the connection on the first send failure (since a
TCP/IP connection can remain open indefinitely through failures, as long as
it's up when it's actually used). Your protocol should have reasonable
timeouts for detecting these failures in an acceptable timeframe. The only
advantage to heartbeats is that you stand a better chance (on average) of
having a usable connection when a request comes in.
--
J.