The server doing a graceful close can be detected on the client:
read() will return -1.
A lost connection (not gracefully closed) generally can't be detected on
the client. TCP/IP does not transmit data unless your application does,
so a lost connection looks the same as a connection that simply doesn't
have any data to receive.
There is a TCP/IP option to do keepalives at the protocol level,
SO_KEEPALIVE, but I wouldn't count on it working reliably all the way
from the phone to the server.
I recommend you look at Google C2DM (Cloud 2 Device Messaging).
-- Kostya
06.09.2010 11:37, Cydrike пишет:
Hi everyone,
I'm facing an annoying problem here.
My application is connected to a server that sends some data from time
to time. It's some kind of eventing server. In order to receive data,
I'm connecting to the server with an HttpURLConnection, retrieve the
response InputStream and loop on it with the read method. The
connection is always open.
The distant server is cutting the connection every 5 minutes (for test
purpose). When connection is closed, my application has to reconnect
again. We detect a Connection Reset by Peer exception when the server
closes the connection. The problem is that most of the time, I never
receive the Connection Reset by Peer exception. So my application
can't know that is has to reconnect and it's stucked on the read
instruction.
The InputStream.Read() method shouldn't always raise an exception if
the connection is closed?
What can I do to always detect Connection Reset by Peer exception?
Thanks for any help,
Android 2.1
HTC Desire
Cédric
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
