Delay in getting GCM notification

22,736 views
Skip to first unread message

NibaLabs

unread,
Sep 8, 2012, 12:06:21 AM9/8/12
to android-gcm
> Hai All,

> I was experimenting with GoogleCloudMessaging (GCM-C2DM). After lot of
> efforts i set up an environment with following Sepc


> Client : Android
> Server : ASP.Net hosted in the cloud


> Problem: I am getting immediate response in Intel XOLO, running
> Android Gingerbread immediately, were as i am getting the messages in
> Samsung Galaxy S2 running ICS after a long delay (say 3-5+ mins).


> Questions:
> 1> Is this a design feature of GCM, or a known
> issue.
> 2>Is there is a fix, so that messages get delivered
> immediately


> Thanks

flyingbag

unread,
Sep 11, 2012, 12:17:23 AM9/11/12
to andro...@googlegroups.com
Stating the obvious - but you already have "delay_while_idle" as false ? TTL set to "0" seems to work best in our tests so far - since GCM does not need to store them - it shoots them off immediately


Aditya Adusumalli

unread,
Oct 8, 2012, 9:38:17 AM10/8/12
to andro...@googlegroups.com
Hi,

In our applications also we are facing considerable delay in receiving messages, around 10 - 15 mins at least. Is this delay expected?

Would there be any improvement if we take a enterprise account?

Please let us know.

Regards,
Aditya

Seshu Saragadam

unread,
Nov 7, 2012, 9:17:45 AM11/7/12
to andro...@googlegroups.com
Hi Aditya,
       I am using GCM in my application. I am facing this issue. some times i am getting push notifications earlier and sometimes i am not getting even single message also. Have you found any solution means then plz share to me and my mail id is s(dot)seshu143(at)gmail(dot)com

Rupert Rawnsley

unread,
Nov 16, 2012, 12:44:44 PM11/16/12
to andro...@googlegroups.com
We are seeing this issue as well and I notice it has been raised a few times in this forum, but never answered. It is very serious for our application, which relies on real-time control of the devices over an extended period of time.

The behaviour is this:
  1. Application starts (GCM registration is initialized)
  2. The device is sent a message from our server (via the GCM server) and responds instantly
  3. We wait 10 minutes. Note that the device is responding to user input during this time, the screen is on, WiFi is connected and the indicator is blue (denoting a valid path to some "pilot light" Google server I believe).
  4. Device is sent a message and fails to respond for up to 15 minutes.
I am not certain if this is a delay from the server or the client, but my gut says client. There is nothing unusual in our request, and previous requests that are exactly the same are processed immediately. I.e. we are not enabling the delay_while_idle flag, the TTL is 0 (positive numbers also exhibit the same behaviour), the GCM server accepts the request successfully, the load is very light (one device, no more than 1 message per hour).

I have not investigated cellular connections, but this behaviour occurs on all Wi-Fi networks that I have tested on so far.

I think there are several possible causes (in order of likelihood):
  1. The connection is terminated silently somewhere between the client and the Google servers to preserve network resources.
  2. The GCM client on the device abandons the persistent connection after 10 minutes
  3. The GCM server abandons the persistent connection after 10 minutes
There is nothing in the device logcat to indicate the connection has been broken, however just before it starts responding to messages again the log looks like this:

11-16 17:32:53.292: W/Smack/Packet(498): notify conn break (IOEx), close connection
11-16 17:32:53.462: W/AlarmManager(273): setRepeating, pkgName=com.google.android.gsf, alarmType=3
11-16 17:32:54.532: D/dalvikvm(498): GC_CONCURRENT freed 459K, 11% free 6675K/7495K, paused 16ms+3ms, total 43ms
11-16 17:32:56.462: D/ConnectivityService(273): handleInetConditionHoldEnd: net=1, condition=0, published condition=100
11-16 17:32:59.992: W/AlarmManager(273): setRepeating, pkgName=android, alarmType=3
11-16 17:33:05.752: I/GTalkService/c(498): [AndroidEndpoint@1098027832] connect: acct=1000000, state=CONNECTING
11-16 17:33:06.412: W/AlarmManager(273): setRepeating, pkgName=com.google.android.gsf, alarmType=3
11-16 17:33:06.442: V/GCMBroadcastReceiver(2869): onReceive: com.google.android.c2dm.intent.RECEIVE
11-16 17:33:06.442: V/GCMBroadcastReceiver(2869): GCM IntentService class: co.learnpad.config.GCMIntentService
11-16 17:33:06.452: V/GCMBaseIntentService(2869): Intent service name: GCMIntentService-221787536506-10

I have seen this behaviour in Android 4.0.3, 4.0.4, 4.1.1, and 4.2. The device type doesn't seem to matter either (Nexus 7 and generics tested).

Does anyone have any ideas what might be going on here or how we could drill into the problem?

Nacho Ordorica

unread,
Nov 23, 2012, 6:09:45 AM11/23/12
to andro...@googlegroups.com
As i said in other thread, i have the same issue than Rupert Rawnsley.

I have tested the same GCM Client on a Tablet with wifi and NO 3G, and in a Phone with Wifi and 3G.

I can confirm that the problem occurs only with WIFI. If i disable wifi on Phone, GCM works fine over 3G always.

If i turn on wifi, over 15 minutes GCM Client receives push well, but after that, suddenly stop from receiving. If i turn off wifi and then turn on, suddenly receives the previous  push messages, but after 15 minutes stops works again.

We need to know if thre is a problem with de GCM Client(new version) because with the OLD API C2DM always worked well over wifi.

Thanks.

Tom Cat

unread,
Nov 27, 2012, 10:33:38 AM11/27/12
to andro...@googlegroups.com
Can you try simple test for this issue?

 1) Turn off and on WiFi. (Now WiFi has fresh connecton.)
 2) Send Gmail to this device from another device or PC.
 3) The device gets pushed for new Gmail (which uses same network connection as C2DM/GCM).
 4) Wait for 15 mintues or whatever.
 5) Send Gmail again. Gets pushed?
 6) Send GCM message. Gets pushed? (If step 5 fails, step 6 should fail.)
 
From my experience, when WiFi connection has problem, even new Gmail can't be pushed. So in above case, if you don't get pushed in step 5, it is not GCM specific issue. It's a much broader issue.

Best regards,
Tomcat

2012年11月23日金曜日 20時09分45秒 UTC+9 Nacho Ordorica:

Dave Cameron

unread,
Dec 5, 2012, 12:40:09 PM12/5/12
to andro...@googlegroups.com
We are seeing similar problems here, although we hadn't narrowed it down to WiFi only.

Given that this is happening on WiFi after a period of activity, I wonder if the connection is being dropped from routing or NAT tables in between the Android device and the GCM server? Admittedly I haven't yet looked at the code, so I don't know if there are workarounds to this problem in the implementation.


Dave

Rupert Rawnsley

unread,
Dec 6, 2012, 4:06:22 AM12/6/12
to andro...@googlegroups.com
@Tomcat You are probably right. Regardless of the underlying cause, it is stopping GCM working in the way I need it to.

@Dave Cameron That is our current theory. Consistent with this diagnosis is that it happens on our home routers, but not on our office routers. We have built a test application that demonstrates the problem and are running packet traces, but we don't have a definitive diagnosis yet. What we know so far is this:
  1. The problem doesn't happen if you send a GCM message every minutes
  2. The GCM servers do not send periodic acknowledgement packets to keep the connection alive, which might be why the connection is dropped by some routers.
AFAIK [2] is not necessarily a "bug" as such, but it might be something that the old CD2M system did that the new GCM doesn't, which would be why the new system exhibits this behaviour. It would be just the sort of thing you would do if you wanted to limit the load on the Google server and still satisfy the majority of users.

Our packet traces so far have only been on working networks, so we are waiting to see if the connection is explicitly closed by either side or is silently dropped by the network at some point. I will post more results when we have them.

Rupert.

Praveen Kumar

unread,
Dec 7, 2012, 4:45:22 AM12/7/12
to andro...@googlegroups.com
SEVERE: Servlet.service() for servlet SendAllMessagesServlet threw exception
com.google.android.gcm.server.InvalidRequestException: HTTP Status Code: 401
at com.google.android.gcm.server.Sender.sendNoRetry(Sender.java:177)
at com.google.android.gcm.server.Sender.send(Sender.java:121)
at com.google.android.gcm.demo.server.SendAllMessagesServlet.doPost(SendAllMessagesServlet.java:90)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)


EVEN I'VE TRIED ALL POSSIBLE WAYS TO FIX THIS PROBLEM. BUT NOT YET ! SOMEBODY PLEASE HELP ME TO FIX IT. EVEN I HAVE CHANGED API KEY ALSO . BUT IT IS NOT SOLVED ! 

Nick T

unread,
Dec 12, 2012, 3:43:59 PM12/12/12
to andro...@googlegroups.com
Likewise a problem for me from time to time. However on wifi the message is always received instantaneously but over 3G a delay of 30 minutes can occur. When messages are being delayed, then turning airplane mode on then off always causes queued messages to come through over 3G. The device is a Samsung Galaxy S2 running ICS.

Rupert Rawnsley

unread,
Dec 19, 2012, 4:47:45 AM12/19/12
to andro...@googlegroups.com
We think we have an answer for our network environment at least.

TL;DR: A colleague and I ran some tests using a man-in-the-middle gateway to record packet activity between the Android device and the router and came to the conclusion that the router (a Virgin Media "Super" Hub AKA a Netgear CG3101D) is deliberately forgetting the port mapping after 5 minutes of inactivity.

The setup was as follows:
  1. An Android tablet with a custom app that receives GCM messages containing timestamps (so the send and arrival time can be compared)
  2. For simplicity, the same app also sends the GCM requests to the Google server, which goes out via SSL and has no effect on the test (certainly no positive effect on the result) 
  3. Messages are sent when the app starts, then 2 minutes later, then 4 minutes later, then 6 minutes later, etc... This pattern is designed to mimic the pathology of the problem; i.e. GCM stops working after a period of inactivity. In case it's not clear: the gap is getting bigger each time.
  4. A laptop that is connected to the router via ethernet and is running as a WiFi access point for the Android tablet
  5. Wireshark running on the laptop collecting all the IP traffic for analysis. Note that the HTTPS GCM message requests are not recorded, only the pure TCP GCM packets (local port 5228).
  6. No other GCM apps are running on the tablet as they may get called and disturb the experiment
The first few GCM requests go through fine with measured latencies of around 1 second. After the 6 minute gap, the message is sent but not received immediately. Exactly 15 minutes after the last successful message was received, the "lost" message arrives along with any other messages that have been sent during that period (the 8 minute message for instance).

When we look at the packet trace (attached) we can see that there is no activity around the time of the failure and no indication that the connection has failed. This indicates that neither party (the Android device or the Google servers) have terminated the connection explicitly. 15 minutes after the last successful connection, the Android device sends out a packet to Google. We think this is a cooee packet designed to tell Google, and all the routers in between, to keep this connection alive. This packet is not acknowledged, and the client goes through several retransmissions before giving up, sending a termination request for this connection (which is probably useless, but is good IP manners). It then sets up a brand new connection with the Google servers (new port on the Google side). Very shortly after that, the "lost" message are sent to the client via this new connection.

What is causing this problem? The home hub will be storing the mapping from the Google side port to port 5228 on the client device. It appears that the hub deletes this entry after around 5 minutes of inactivity (no packets from either side). Our suspicion is that Google tries to send the 6 minute message, but the hub refuses to acknowledge because there is no known route from Google to the client. Google then gives up on that connection (possibly mirroring the cooee packet exchange we see later on our side of the hub) and sends a reset, which we of course cannot see.

Why does the router behave in this way? It may be to limit the size of the routing tablet (although that must surely be small), it may be some sort of anti-P2P measure (but I can't see how it would be effective), it may simply be a lazy choice of setting. These routes must be forgotten at SOME point, but the normal behaviour is order-of days. The cooee packet suggests that Google has anticipated this problem, as well as the problem of devices roaming from IP address to IP address, and implemented a keep-alive strategy to try and control the number of live connections they have to consider on the server side. If the router forget the connection after, say, 20 minutes, this problem would not occur.

How do we fix it? This particular case is not a bug with GCM, rather it is an over-zealous router. We found we could keep the connection alive with a ping every two minutes from the GCM server (which is free). There may be battery life implications for the device as I suspect the 15 minute timer that triggers the cooee is the same one you are supposed to align internal alarms with to minimize battery use.

The test application is small and simple and I'm happy to supply the source code if you wanted to reproduce it on your own networks. Although you can confirm you have a similar problem by sending an empty packet every two minutes, which should stop it happening.
gcm-latency.cap

Clint Webb

unread,
Dec 19, 2012, 9:23:24 AM12/19/12
to andro...@googlegroups.com
Very useful information, thank you.  It explains some behaviour that I have been experiencing also, although my network is less predictable.  I believe my router is only dropping mappings under load, so it has been difficult to determine.
I intend to use this information to build into my service the ability to detect when this situation is constantly occurring for particular users and implementing the ping as you suggested.

--
You received this message because you are subscribed to the Google Groups "android-gcm" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-gcm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/android-gcm/-/YxnCkaPRHRQJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
"Be excellent to each other"

Dave Cameron

unread,
Dec 19, 2012, 12:04:42 PM12/19/12
to andro...@googlegroups.com
Thanks Rupert. This is some amazing analysis.

Someone on our team already wrote a similar app, but we haven't got to the stage of running wireshark yet. I'm going to encourage the posting of the test app source somewhere publicly. I'll post here if we are able to do so.

One question about the very tail end of your post...


How do we fix it? This particular case is not a bug with GCM, rather it is an over-zealous router. We found we could keep the connection alive with a ping every two minutes from the GCM server (which is free). There may be battery life implications for the device as I suspect the 15 minute timer that triggers the cooee is the same one you are supposed to align internal alarms with to minimize battery use.

Is the ping from the GCM server just taking the form of an empty GCM push?


Dave

Rupert Rawnsley

unread,
Dec 19, 2012, 12:18:06 PM12/19/12
to andro...@googlegroups.com
@Dave Cameron

An empty GCM message should be enough. Ours may have still had the time stamp in it when we tested the theory, so it's conceivable it would need a dummy payload, but I doubt it.

I'm attaching the client test app we used in case you need to compare it with your own one. It has a server key embedded in the code that is from a temporary GCM project. It can be used as-is for now, but at some point in the future it will be turned off and would need to be replaced.
GCM Latency Bug.zip

John Brohan

unread,
Dec 22, 2012, 7:09:48 AM12/22/12
to andro...@googlegroups.com

This is a most useful discussion. I can implement the ping as a message from the Google GCM server to the Android. I wonder if it has to come **from** the local router to be effective.
My situation is that I have very low frequency transactions (1 per day or per week) but I would like them to happen quickly when they happen. There are many android tablets running independently and the messages are triggered by other people sending a picture to a particular tablet from maybe a web browser.

My plan is to implement a php script which will send an empty GCM message to all my logged in androids. I can run this script on a cron. Will this do the trick?

I expect that the engineers at Google will solve this soon, and I do not want to have all my android pinging uselessly. 
I will post my results here
Thanks John

Gernot Pansy

unread,
Jan 2, 2013, 11:47:37 AM1/2/13
to andro...@googlegroups.com
i think it's better todo the ping in the app. the app know if you are connected to Wifi or not.

also it's not only dependent on router, it's also has something todo with phone wifi driver. on my old samsung android phone it's working with a specific driver, while it's not working with the original one.
my company uses an expensive cisco wifi router where problem also not occurs.

you can install this app, which tries to solve the issue: https://play.google.com/store/apps/details?id=at.pansy.droid.gcmWifiFix
after install you need to reconnect wifi.

we have removed the logic from our main product, because it raises the alarm usage taken by our app and doesn't solve all problems. depending on device the battery usage is not really increasing.

gernot

rram...@gmail.com

unread,
Jan 19, 2013, 5:07:17 PM1/19/13
to andro...@googlegroups.com
Hello to all, I developed an application that used at first C2DM and now GCM. I have same problems as other users, but I don't use a Wifi connection but only 3G.
The strange thing is when my phone doesn't receive the push message for a long time, I try to disable 3G connection (via areo mode) and when the connection comes up the notification will appear instantanely.
It seems my phone (galaxy s iii with jb) after a while from received first notification break down the communication with Google, and when the 3G connection restarts the communication with Google also restarts and the phone receives the notification.
This problem never occurred with C2DM.

Rolando

Pedro Pagani Margarido

unread,
Jan 22, 2013, 10:12:08 PM1/22/13
to andro...@googlegroups.com
I was having problems to receive gtalk messages and gmail push notifications after 15 mins of phone sleeping. Searching in the internet trying to solve it I found this thread on XDA forum: http://forum.xda-developers.com/showpost.php?p=36926738&postcount=83

The guy found a partial solution for the problem, changing gservices.db he increased the Gtalk "Heartbeat" messages frequency, and doing that he solved the problem. But, this isn't a persistent solution, so need to be done after every phone restart.

I don't know if it is the same problem you guys are getting, but if it is, I hope I helped.

Rupert Rawnsley

unread,
Jan 23, 2013, 6:14:05 AM1/23/13
to andro...@googlegroups.com
@Pedro

Nice find! This is definitely the same problem and I can confirm that this change "fixes" it. If you don't want to install a DB editing app, you can edit the database entry from ADB (probably requires root access) as follows:

View current settings...

adb shell sqlite3 /data/data/com.google.android.gsf/databases/gservices.db "SELECT * FROM main WHERE name LIKE 'gtalk_%heartbeat_ping_interval_ms';"

Change settings...

adb shell sqlite3 /data/data/com.google.android.gsf/databases/gservices.db "UPDATE main SET value = 300000 WHERE name LIKE 'gtalk_%heartbeat_ping_interval_ms';"

After updating the database, I Stopped the Google Services Framework and cycled Wi-Fi off / on (which kick starts the GSF service again). Note that you have to restart the service because it only reads from the DB at start time (this is typical Android system app behaviour).

I re-ran my GCM test app and the connection was no longer lost after the critical 5 minute period of inactivity. For testing I made the heartbeat interval 1 minute because I felt 5 minutes was too close to the router drop time to be a reliable test.

I bet the old C2DM system simply had a 5 minute timeout by default, and that's why we are only seeing this problem on GCM.

While this explains it and gives us a workaround, in production terms you will not be able to make these changes yourself on non-routed devices, and even on routed devices it would be both invasive (without informed consent) and technically a bit fiddly.

Pedro Pagani Margarido

unread,
Jan 23, 2013, 6:28:20 AM1/23/13
to andro...@googlegroups.com
You are right, for me it's just personal use, no problems updating the table and stopping the service, but I think you guys are dealing with commercial software and it is not acceptable. Maybe you could try put a pressure on Google to fix it, there is a thread on Android page reporting it (http://code.google.com/p/android/issues/detail?id=22570&q=gtalk&sort=-stars&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars), but it is very old and has only 66 "stars", Google is probably ignoring.

rram...@gmail.com

unread,
Feb 19, 2013, 5:29:04 AM2/19/13
to andro...@googlegroups.com
It's impossible for a published application to modify anything.

The problem is NOT present for old devices (e.g. Gingerbread), the notification comes in few seconds.
For new devices, instead, the notification comes in many minutes (15, 20). When the connection is rebuilt (stop/start, aereo mode), the notification comes immediately.

This is a big problem for applications that need to receive notifications in real time (score results, events).

Why Google has changed the GCM behavior?

Tomcat

unread,
Feb 19, 2013, 10:47:35 PM2/19/13
to andro...@googlegroups.com
As far as I know, this issue exists since OS2.2, and is a headache for both C2DM and GCM. Even Gmail suffers, believe it or not.


2013年2月19日火曜日 19時29分04秒 UTC+9 rram...@gmail.com:

David Spicer

unread,
Mar 15, 2013, 7:23:12 PM3/15/13
to andro...@googlegroups.com
I have been struggling with the migration from C2DM to GCM and have done some research. Filed this bug with Google explaining what's going on and how to fix it.

Tom

unread,
Mar 15, 2013, 8:14:47 PM3/15/13
to andro...@googlegroups.com
Wow, assuming that what you (David) have discovered is accurate, that is really crazy.

Leaving aside my issues with GCM as a dev, this explains why incoming calls on my VoIP service no longer work.  I was quite pleased to find a VoIP service that used GCM as I thought this was 'the right way' (as opposed to keeping their own UDP or TCP connection alive).  All their users are now blaming them for what is actually a good design.

Your observations coincide with what other people are reporting, but I'm still a bit puzzled that Google would have done this intentionally - it would seem to go against one of the core design principles of a notification service.  I still think it is possible that the problems being encountered result from a range of bugs.

You mention discovering this when you switched to GCM - are you saying that C2DM worked properly on Android 4 devices?  I would have thought that the two services shared the same device socket, so if Android 4 moved to a new comm scheme then it would affect C2DM and GCM equally.

I think it would be useful if you could mention in the issue roughly how many (different model) devices you observed this on.  Also, did you observe this on Wi-Fi and cellular?

I hope to have time to look into this myself in a few weeks.

Ultimately, I think the best solution is for apps to maintain their own TCP connections.

Tom

Tomcat

unread,
Mar 16, 2013, 9:42:02 AM3/16/13
to andro...@googlegroups.com
Hi David,

Issue you filed is not true for my environment. Galaxy s3a running OS 4.1 responds instantly in sleep mode. I don't think this delay issue depends on OS version itself.

Tomcat

2013年3月16日土曜日 8時23分12秒 UTC+9 David Spicer:

David Spicer

unread,
Mar 20, 2013, 1:41:29 PM3/20/13
to andro...@googlegroups.com

Tom and Tomcat: Will try to address both your questions here:

I have two Android machines I use for testing:

An old HTC Incredible running 2.3.4 (I like testing on OLD devices….)

and a Samsung Galaxy Express running 4.0.4

If the delay problem is fixed in 4.1 that would be great. Tomcat: Can you confirm this with any other machines in addition to the one you mentioned??

I have made the migration from C2DM to GCM and never tested C2DM on my Samsung (4.0.4) machine.

The reason Google would do this intentionally is financial… The only way to establish the push channel is to have the device initiate the connection. The server cannot possibly know the ever-changing IP address of every device. Since the server has a fixed IP address and one or more well known ports, it is up to the device to create the connection. If every device maintains this connection while locked and unlocked, you can imagine the number of sockets that will need to be maintained on the server. My investigation indicates that the device in a locked state creates a new push connection every 10 minutes, with t=0 at the time the machine last entered the locked state. This has two effects: it randomizes the polling so that all the devices are not polling at the same time, and accounts for the fact that GCM push messages can go from 'instantaneous' if  sent just before the poll occurs, to up to 10 minutes if the GSM push is sent just after the last poll, which means a given push should occur with a 5 minute delay on average. The benefits to Google are substantial since a given device spends a LOT more time in the locked state than in the unlocked state.

As for doing this ourselves, that really runs counter to what the Android platform should be doing for us. That would mean each of our apps would need to run as a daemon process consuming battery, and we would each need dedicated server sockets for every device registered. As I mentioned in the bug report, Apple iOS does this correctly and they pay the cost of the dedicated push connection in both locked and unlocked states.

This issue has nothing to do with WIFI or Cellular connections. The algorithm is the same: the device establishes the persistent socket connection periodically regardless. A side effect could be that in the absence of WIFI and with only a bad Cellular connection the poll will not occur, which would have the effect of delaying GSM pushes further.

Dave

David Spicer

unread,
Mar 20, 2013, 4:26:05 PM3/20/13
to andro...@googlegroups.com
Tom: One more thing I left out.  The fact that GCM and C2DM use the same socket has nothing to do with the polling algorithm they run over that socket. If Tomcat is correct and this problem goes away with 4.1 then that's an example of modifying the polling algorithm to alleviate the delays...

Tomcat

unread,
Mar 20, 2013, 11:48:04 PM3/20/13
to andro...@googlegroups.com
Hi David,

I have another phone which runs OS 4.0.3 (Galaxy s2) that can respond instantly to any GTalk related functions in sleep mode. That functions include Gmail, C2DM/GCM.

Tomcat

2013年3月21日木曜日 2時41分29秒 UTC+9 David Spicer:

Pedro Pagani Margarido

unread,
Mar 21, 2013, 12:40:52 AM3/21/13
to andro...@googlegroups.com
it's not related to the OS version because it is a gtalk problem, not android itself. It is explained in the first post, some router and carriers drop the TCP connection if it stays for more than X minutes with no communication, the gtalk default heartbeat is 15 minutes under wifi and 28 under 3g, if you have a crappy carrier or router it will result on closing your TCP connection to google servers.

David Spicer

unread,
Mar 21, 2013, 9:21:01 AM3/21/13
to andro...@googlegroups.com
Tomcat/Pedro: Thanks for the replies. In my case, it might just be that I bought a cheaper Samsung... Galaxy Express... If, on the other hand it is my carrier/isp dropping long-lived socket connections then they would also be doing that to my iPhone, which, like the Samsung, has AT&T as the carrier. All Android needs to do is detect when the socket is interrupted (the read socket call will fail) and reestablish the connection. iPhone handles this as does my IMOK app.

Thanks again for the info.

Pedro Pagani Margarido

unread,
Mar 21, 2013, 10:23:10 AM3/21/13
to andro...@googlegroups.com
Wow, know I got the problem, we are at the wrong Google Groups (this one discusses Android problems, but it is a Gtalk problem). The correct one is: https://productforums.google.com/forum/#!msg/mobile/X0j2BgCVQjI/rOPajKo5vDEJ

Rene Dohan

unread,
Oct 21, 2013, 7:21:37 AM10/21/13
to andro...@googlegroups.com
This is GCM problem , cant you read ? G-Talk uses GCM , I have this problem in my app also... I found example to solve this by sending upstream gcm messages periodically using Sender.class from gcm package ...

Pedro Pagani Margarido

unread,
Oct 21, 2013, 8:27:37 AM10/21/13
to andro...@googlegroups.com

Yes, I can read. Stills a Gtalk problem and you have no idea how GCM works.

Pedro Pagani Margarido

--
You received this message because you are subscribed to a topic in the Google Groups "android-gcm" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-gcm/Y33c9ib54jY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-gcm...@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.

John Brohan

unread,
Oct 21, 2013, 8:37:10 AM10/21/13
to andro...@googlegroups.com
Are you American Politicians? Be polite!  Be helpful!
We are trying to solve a real problem here...How to implement GCM properly. If it can work properly then we can do away with these periodic "messages to keep it alive".  These intermittent problems are the hardest to solve. It seems, in my humble opinion to be partly a feature of connection strength. Works better in a strong wifi environment.




For more options, visit https://groups.google.com/groups/opt_out.



--
John Brohan http://www.stay-in-touch.ca      tel 514 995 3749
Medication Scheduler http://www.PillTimes.com
email jbr...@Stay-in-Touch.ca

Ferran Maylinch

unread,
Oct 24, 2013, 4:16:57 AM10/24/13
to andro...@googlegroups.com
Hello,

Can anyone post the code to ping GCM from an Android app so we can keep the GCM connection alive?

Thank you very much.

Ferran Maylinch

unread,
Oct 24, 2013, 4:18:56 AM10/24/13
to andro...@googlegroups.com
I forgot to say that I would like to know how to ping GCM and also how to do it. From where and how frequently.

Thanks!
Reply all
Reply to author
Forward
0 new messages