Yeah, the behavior definitely changed in RC33, I am still having difficulties to close a socket while the 3G connectivity has been lost.
On 19 fév, 03:52, Gil <[email protected]> wrote: > Yes, the phone still has the connection to the router however what > matters is the status of the TCP socket which needs end-to-end > connectivity. Applications need to know when TCP connectivity is lost. > > Not all TCP based protocols require a response for a request. For > example in XMPP you sendkeep-alivepackets to the server the server > does not actually respond. Also, sending packets just to see if the > TCP connection isaliveis a waste of battery power. > > It is wrong for a disconnected socket not to throw an IOException when > trying to send data as well as when executing a blocking read. It also > needs to throw and EOFException when the server disconnects. While > this behavior is not in the documentation one would expect the same > API behavior in dalvik and JVM from this standpoint. I want to > reiterate that prior firmware versions (RC28/maybe RC30 and earlier) > exhibited the correct behavior from this standpoint. Even the current > emulator works fine by throwing an IOException from a blocking read 20 > to 30 seconds after the TCP connection is lost. > > On Feb 18, 5:28 pm, "Justin (Google Employee)" <[email protected]> > wrote: > > > 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 <[email protected]> wrote: > > > > 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 IkeepWi-Fialiveby 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 -~----------~----~----~----~------~----~------~--~---
