I'm looking into this further, although I'm not sure that this is
actually wrong behavior. In terms of the network interface, there is
no change when the router loses internet connectivity. The phone is
still connected to the router. The only way anything can really deal
with this is to have a timeout. If no response is sent in X seconds,
assume the remote server died or there is no path to it. While
inconvenient, you should be able to extend BufferedInputReader to use
this timeout mechanism. Have a timer thread, that if the timer expires
and no bytes have been read, throw an exception.

I'll look into this further.

Cheers,
Justin
Android Team @ Google

On Feb 17, 5:02 pm, Gil <virgildobjans...@gmail.com> wrote:
> Can anyone from Google comment on this matter?
>
> On Feb 17, 11:42 am, Gil <virgildobjans...@gmail.com> wrote:
>
> > I did further testing and I was wrong about one thing: the disconnect
> > is not detected at all (not even after 5 minutes as I said initially).
> > The reason I though that the disconnection was detected after 5 min.
> > is because the W-Fi was going to sleep. If I keep Wi-Fi alive by not
> > allowing the phone to go to sleep the problem is quite evident. I also
> > looked at the GTalk debug messages and it turns out that it has the
> > same problem (it never detects that it is disconnected from the
> > server).
>
> > On Feb 17, 11:19 am, Gil <virgildobjans...@gmail.com> wrote:
>
> > > Unfortunately, watching the network state will not always work because
> > > it does not account for end-to-end TCP connectivity. The server may
> > > crash or its Internet connection may go down and you won't know about
> > > it.
>
> > > On Feb 17, 10:05 am, Guillaume Perrot <guillaume.p...@gmail.com>
> > > wrote:
>
> > > > Yes it's exactly what happens since RC33.
> > > > Kinda annoying. I have to close sockets in a separate thread when I
> > > > receive a connectivity event indicating the network is down or we
> > > > switched network. This thread becomes zombie most of the time because
> > > > the socket refuses to close (deadlock with a nativeread).
>
> > > > 2009/2/17 Gil <virgildobjans...@gmail.com>:
>
> > > > > What is disturbing is that event if you try to send data on a socket
> > > > > that is not actually connected (according to the situation I outlined
> > > > > initially) the socket does not throw an IOException. It simply thinks
> > > > > it is still connected.
>
> > > > > On Feb 17, 7:21 am, Guillaume Perrot <guillaume.p...@gmail.com> wrote:
> > > > >> I had the same problem too.
> > > > >> Plus when I loose connectivity, it's nearly impossible not to block 
> > > > >> on
> > > > >> socket.close();
> > > > >> It takes forever in that case.
> > > > >> I tried both plain and ssl sockets, same behavior in RC33.
>
> > > > >> On Feb 17, 1:23 am, Marc <gram...@gmail.com> wrote:
>
> > > > >> > I've seen inconsistent behavior from RC30 on in this regard.  The
> > > > >> > IOException happens anywhere from instantly to five minutes later. 
> > > > >> >  It
> > > > >> > seems like a bug to me.
>
> > > > >> > Marc
>
> > > > >> > On Feb 16, 2:29 pm, Gil <virgildobjans...@gmail.com> wrote:
>
> > > > >> > > I finally got to test some code on the RC33 release and I 
> > > > >> > > uncovered a
> > > > >> > > difference in the network code compared to earlier versions and 
> > > > >> > > the
> > > > >> > > emulator. I'm using a persistent TLS connection to a server and a
> > > > >> > > BufferedInputStream to read from the socket. The problem is that 
> > > > >> > > the
> > > > >> > > read method throws an IOException only 5 minutes after the Wi-Fi
> > > > >> > > connection looses connectivity (I unplug the Internet connection 
> > > > >> > > from
> > > > >> > > the router to simulate a connection problem). In RC30 and earlier
> > > > >> > > version as well as the latest emulator version (SDK 1.1) read 
> > > > >> > > throws
> > > > >> > > an exception after approximately 30 seconds after the 
> > > > >> > > connectivity is
> > > > >> > > lost. My code uses an infinite timeout for read 
> > > > >> > > (setSoTimeout(0)).
>
> > > > --
> > > > Guillaume Perrot
> > > > Software Engineer at Ubikod
> > > > BuddyMob developer
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to