Can anyone from Google comment on this matter?
On Feb 17, 11:42 am, Gil <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>:
>
> > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
