u
On Mon, Apr 15, 2013 at 10:46 AM, Kostya Vasilyev <kmans...@gmail.com>wrote: > > > > 2013/4/15 Robert Greenwalt <rgreenw...@google.com> > >> >> >> >> On Mon, Apr 15, 2013 at 8:44 AM, Kostya Vasilyev <kmans...@gmail.com>wrote: >> >>> Robert, >>> >>> Could you elaborate on the "issues like these" part? Are there changes >>> in Android that developers should be made aware? >>> >> >> By "issues like these" I just meant the inevitable bugs that will crop up >> when making software. If there is a library on the platform that already >> does what you need it is risky to decide to create your own redundant code. >> > > > Yes, I understand the inevitable bugs, but GTalk / GCM work with those > bugs, perhaps becuase they do things a certain way. > > I've seen GTalk's service menu, it seems it has separate keep-alive logic > for mobile vs. WiFi.... Why? I can't tell just by reading the Android > networking docs. > Most ipv4 is behind nats. Even on the carrier side. Each NATing agent will have a timeout - no activity and they forget the connection state and your connection is broken. That timeout varies form network to network and the timeout GTalk or GCM use have been tuned from android experience. This sort of tuning is another reason why relying on GCM is better than trying to reinvent it. > > >> >> >>> I also have an app that uses long persistent server connection, and >>> using GCM is not an option either. >>> >>> Can you elaborate on why GCM is not an option for you? We want to make >> GCM useful, so if it's missing features or "is not an option" we want to >> know about it.. >> > > I have a little email app. > > Unless someone can convince Gmail, Yahoo, GMX, AOL, Dovecot, Courier, and > all the rest switch to GCM, I'm kind of stuck with IMAP IDLE, which is a > terrible protocol, but at least it's there. > > > >> >> >>> It seems that with Android 4.1 and 4.2, connections often go "dead" -- >>> even though technically connected (at the server side), data pushed by the >>> server stops getting through (this is verified by server logs). >>> >> >> Is that just on WiMAX as the original poster suggested? >> > > I don't have / use WiMax, the case I and one of my users investigated with > logging was WiFi. > > >> Do you have bugreports and/or packet captures? >> > > I have seen server logs captured by a very helpful user, and ran my own > app with logging, on two devices with 4.2.2, connected to the same WiFi > access point, and same mail server. > > The symptoms are -- I can outline them in just a few sentences. > > My Android code is in a socket read (in a worker thread, of course), the > device goes to sleep, the connection stays up. > > The server sends small packets of data from time to time. > > When the device has been asleep for a while (5-8-10 minutes, IIRC) and the > server sends data: > > - The app no longer wakes up and receives the data > - The next socket write from the server results in a socket write error > (so the first packet was not acknowledged) > > In the tests I ran, the connection was alive at my home router (it has a > UI where I can see the connections). > > If the device was not allowed to go to sleep, the issue did not occur. > > >> >> >>> >>> Android 4.0 does not seem to suffer from these issues, at least not to >>> the same extent. >>> >>> A Nexus 7 and a Galaxy Nexus running the same stock 4.2.2, connected to >>> the same server, over the same WiFi network, will experience dead >>> connections at different rates (confirmed by logging). >>> >> >> Can you share a bugreport and packet capture? There was no intention to >> kill long-lived connections in android, so if there is an issue with 4.2.* >> we need to hear about it. >> > > Don't have a packet capture, but will try to submit a bug report, since > there seems to be interest on your part. Thank you for this. > > Are there any changes to WiFi power saving in 4.1 - 4.2, perhaps it tries > to go deeper than before into some sort of sleep state? > > Is it possible that this power saving mode has a low-level bug, where the > WiFi radio stops responding to incoming packets? > > Would this be related to this old issue? I can only guess of course: > https://code.google.com/p/android/issues/detail?id=9781 > > >> >> >>> The suggestion to use GCM does not benefit everyone. >>> >> >>> It's nice that that Android has GTalk which provides GCM, and has its >>> own keep-alive logic, but with it being closed source, and with apparent >>> changes in recent Android versions, this leaves those developers who can't >>> use GCM dead in the water. >>> >>> It would be great if someone from Google could comment, and explain, >>> what's different in Android 4.1 - 4.2 with respect to long running >>> connections, and what sort of magic is now required to keep them alive, for >>> those apps that really need it. >>> >> >> As I said above we did not intentionally do anything to break long-lived >> connections. We encourage GCM use as it lets us do optimizations based on >> mobile network type, etc to save on signaling traffic and battery life, but >> you should still be able to roll your own if you wish. >> > > How about documenting those "optimizations, etc.", or specifically, the > special things GTalk has to do becuase it runs on Android? > > GTalk/GCM seem to work well, but is closed source. I assume there some > subtle parts, which benfit from knowing what the system does (something > more than "create a socket, and call connect() to connect..."). > > >> >> > >> There was a bug introduced in the 4.1 timeframe on mobile-data >> connections we stopped counting udp packets when determining if a mobile >> connection was hung - this could cause us to reset the mobile connection >> even when it was live if only udp packets were being passed. This doesn't >> apply to wifi OR to mobile with GTalk alive - only on a private mobile >> network where GTalk servers are inaccessible. >> > > Yes, I remember that discussion, and it doesn't apply in my case. > > -- K > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Android Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android-developers+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
