While working on a little project that integrates with GCM, I've stumbled across a bit of a strange issue.
Some times when I start watching the log to see if messages are received, messages do not appear to be coming through until I have changed the network state (I.E. originally on WiFi, if I turn off WiFi and move to Mobile Data, the messages arrive fine). After I've changed the network state, messages start to arrive perfectly fine, and the same applies once I change the network state back to what it was before (in this case, WiFi) the messages continue to be received.
The project itself includes the ability to start on boot (starts the GCMBaseIntentService on boot), which again works perfectly fine, and I'm sure the app / service is running as I've manually started up the app when this issue occurs (which also checks to see if the service is running, and if it's not it runs it and checks to see if it's registered).
Has anyone else come across this issue, or has any pointers as to how I could resolve this? I'm not seeing anything of much help in the log between the time messages are not being received and when they are (after changing the network state). I've gone through the GCM docs and can't see any mention of messages not being received due to a time-out (on the device itself), or any config options that might affect this.
Appreciate any assistance - I can provide source if needs be, although it hardly deviates from the demo app provided in the android-sdk.
The first step in GCM is that a third-party server (such as an email server) sends a request to Google's GCM server. This server then sends the message to your device, through that open connection. The Android system looks at the message to determine which app it's for, and starts that app.
I've noticed this as well. Although I haven't dug into the actual code, here's my understanding of why this happens.
GCM (and most push messaging services) works by keeping a long-lived socket open to Google's push notification server. The socket is kept open by sending "heartbeat" messages between the phone and server.
Occasionally, the network state may change and this socket will be broken (because the IP address of the device changes, from 3g to wifi, for example). If the message comes in before the socket is reestablished, then the device will not immediately get the message.
The reconnection only happens when the phone notices the socket is broken, which only happens when it tries to send a heartbeat message.
Again, just my basic understanding of how it works and why it happens, and I could be wrong.
There are many causes for GCM message delays. If message start to arrive after you changed network state, or switched on/off airplane mode - the most likely cause is a network that closes the connection without sending FIN/RST.
GCM maintains a long-lived connection - and reconnects if it knows the connection was broken. A router/AP/NAT is supposed to send a FIN or RST to terminate the TCP connection - so GCM and servers will know the connection is dead.
However a number of routers and mobile operators don't do this, and then GCM needs to rely on the heartbeat, ~15 min on Wifi, more on mobile. There is a trade-off between battery life/network use and heartbeat frequency.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With