TCP will either deliver the packets, in the order specified, or it will call
the connection broken; that's the benefit of TCP over UDP where you can't
guarantee delivery or know what the delivery order will be.
Just standard TCP stuff is what you will probably want for detecting loss of
connection: keep-alive and time-outs. When you're sending data over the
socket regularly, you should detect a lost connection in about 30-40
seconds. If you're passively sitting there waiting for new data from the
other end of the connection, you'll have to have keep-alive enabled for the
socket or there'll be no detectable difference between losing the connection
and just never having the other end send you anything. Since keep-alive was
never designed for real-time notifications that hey, there's no signal from
an AP right now, etc., you'll have to change the time-out to get real-time
information (and this costs you more packets sent periodically to verify
that that other end of the connection is still there).
I've been over this before with people, so you might want to look up "keep
alive" in the archives and see what's been said before, and then ask
questions, rather than waiting for a new tutorial...
http://groups-beta.google.com/group/...UTF-8&oe=UTF-8
Paul T.
"Jumu" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello,
>
> I am trying to build an application on the .NET pocketPC platform that
> transmits and receives data through TCP sockets. Ideally I want the
> application to work on all types of connections like GPRS, Wifi and any
> other technologies that support TCP sockets.
>
> This means there is the possibility of connections going down and
> coming back again. For example, a Wifi user might go out of range of
> the base station and then come back. So my specific questions are:
>
> 1. How do I inform my application that the link is no longer available.
>
> 2. How do I inform it that the link has come back up.
>
> 3. What is the way to handle open TCP sockets while the link is down
> and then comes back up.
>
> Also, if the link becomes very slow for some reason (say bad GPRS in an
> area) do I have be mindful of how much data my application is writing
> to my TCP socket send-buffer. Could it get overwhelmed and drop packets
> at the OS level itself, even before the packets get "airborne"?
>
> Any suggestions, ideas, further reading pointers will be appreciated.
>
> Thanks for reading
>
Similar Threads
