On my device using wifi network sometimes I have to refresh internet connection to receive notifications.I have set time_to_live = 5 to receive instant notifications only. It seems that connection of device with gcm servers is broken some times. But as soon as I refresh wifi internet, notifications start to come properly. This is strange and practically unreliable because I have to refresh internet connection again and again to receive notifications. Please help in this regard! Thanks in advance.
I have read about this same problem in Products Forum - Push notifications delayed, Hearbeat Interval not reliable. According to the old thread:
Android push notifications works through one TCP connection on the port 5228 between the phone and google servers. This connection is established when the phone connect to a network. All android push apps (gmail, whatsapp, hangouts, etc.) use Google Cloud Messaging (GCM) to send and receive push notifications thought that connection.
By definition a TCP connection does not have a timeout. But in the real world, wifi routers and mobile carriers have some rules to limit the number of opened tcp connections. So they usually close/kill what they think to be an inactive connection after some times that no packets are transmitted. For example my wifi router kill connections after 300 seconds (5 minutes) of inactivity (no packets on the tcp connection).
Then, it was given in this Google thread - Delay in getting GCM notification that this particular case is not a bug with GCM, rather it is an over-zealous router.
To fix it:
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.
Along with my searches, I also found this SO post - Do not receive GCM message while android device bein connected to WIFI which suggests upgrading to FCM as one that solved the issue and maybe it will work for you too.
Related
I created an Android app that can receive push notifications. I've installed the app on two different phones and verified that both can receive GCM push notifications. This test was done in the United States.
The following week, one of the phones traveled to Asia. But push notification could not be received on the phone in Asia. It had internet access but could not receive push notification.
Does anyone know why? Does there need to be special configuration. Can network block GCM messages?
It must be blocked by the country. e.g. google is blocked in China.
Do other google services work on the device.
If you tried your application in Asian phones, surly it will work. or else You can change your location by changing IMEI number based on the country.
In developing countries, some telecom networks / home routers will aggressively disconnect idle TCP connections to save resources, preventing your GCM/FCM notifications from arriving on time.
FCM uses a heartbeat mechanism to keep its connection alive, by sending a "keepalive" packet every X minutes to the FCM servers. However, the heartbeat intervals used by FCM do not take into account aggressive networks in developing countries which will terminate idle connections.
This makes GCM/FCM quite unreliable in such developing regions:
https://eladnava.com/google-cloud-messaging-extremely-unreliable/
As per China, GCM/FCM are blocked entirely by the Great Firewall of China.
As a workaround, check out Pushy which uses a fine-tuned MQTT connection with a faster heartbeat interval to prevent the connection from being terminated, and is not blocked in China.
Full disclosure - I founded Pushy.
I know that notifications can be pushed to servers using http/s but can mobile phones really be pushed to from those servers? Technically it is my guess that mobile devices actually poll the notifications servers to see if there are any new notifications and that this is a sort of 'pseudo push'.
So that's my question - do mobile phones truly receive live, pushed notifications or are they actually polling? The reason I ask is that it would seem to be incredibly expensive on the network for mobile phones to have a constantly open channel to masts as a user moves around. Anyone know what the technical detail is?
Apple Push Notifications are delivered to the device over a TCP connection. The iOS device initiates a TCP connection on port 5223 (with a fallback to 443 on WiFi if 5223 cannot be reached).
Once the TCP session is established very little traffic is required to keep the TCP connection alive - just an occasional keep-alive packet.
When a push notification is to be delivered, the Apple servers look for an existing connection to the device. If a connection is found then the data stream is sent over the already established connection, so in that sense it is a "push".
If there is no existing connection to the target device then the message is held on the Apple server until the device connects (or the message expires), so at this level it is more like a "pull" - with the device initiating the connection when it can.
I imagine GCM works in a similar way.
There is simply a TCP socket waiting in accept mode on a cloud Google server. The TCP connection had been initiated by the Goggle Play application. That's why Google Play must be installed on the device for making Google Cloud Messaging (GCM) (formerly Android Cloud to Device Messaging Service - C2DM) work.
When this TCP client socket receives some message, the message contains information such as the package name of the application it should be addressed to, and of course - the data itself. This data is parsed and packed into an intent that is broadcast and eventually received by the application.
The TCP socket stays open even when the device's radio state turns into "idle" mode. Applications don't have to be running to receive the intents.
More information at http://developer.android.com/google/gcm/gcm.html
I have an Android client working in tandem with ejabberd XMPP server.
Observations:
Scenario 1: When I swipe-right the app (kill the app), the user goes offline on the server immediately. Its status is changed to offline at that very instant.
Scenario 2: However, when I simply shut-down the Wi-fi connectivity (data) of my Android Jabber client, there is a noticeable lag of a few minutes for the user to be marked offline on the server.
I can’t figure out what is the fundamental difference in the two processes.
What could be done in Scenario 2 to make it go offline immediately?
Scenario 1: When I swipe-right the app (kill the app), the user goes offline on the server immediately. Its status is changed to offline at that very instant.
In above case your Android xmpp client is sending presence as unavailable before closing your Android application, maybe your Android XMPP client is maintaining a background service which in turn maintains a persist XMPP connection (TCP socket) to XMPP server, when you close your application onDestroy() method of service will be called and in that one can check if XMPP connection is still connected. If yes then send presence as unavailable which will safely make user as offline on server and then disconnect XMPP connection (socket).
Scenario 2: However, when I simply shut-down the Wi-fi connectivity (data) of my Android Jabber client, there is a noticeable lag of a few minutes for the user to be marked offline on the server.
As I mentioned earlier, Android devices can maintain a persist XMPP connection in a service, when you turn off wifi and your XMPP connection (TCP socke) to server is still connected, there is no safe removal of user from XMPP server [client can't send presence as unavailable] means connection is just-hang up and Android client/XMPP server doesn't have knowledge of it. In such case now server will figure out client is hangup by client ideal time period [i.e there is no communication on socket for a fixed interval], and make user as offline. This process is time consuming so that you are seeing lag of a few minutes.
What could be done in Scenario 2 to make it go offline immediately?
You can configure XMPP server and make client
As this problem can be handled from XMPP client and server, from client you can fixed interval time ping, if you keep ping duration small enough you can detect lost connection (like broken pipe on socket), same way on server side if you keep ping inter [remember this is server to client ping] small you can detect loss of connection.
As I can see you are using ejabberd as your XMPP server, details given on this link says,
How to detect a dead connection?
One way to detect a dead connection is to ping the client periodically
and to kill the connection if the client doesn't respond. This can be
done using mod_ping. However, these ping packets might wake up the
client's radio, so a short ping interval might drain mobile batteries.
Therefore, it's not generally recommended to use an interval of less
than a few minutes. Either way, there's always some time window where
messages can be lost.
After searching a lot on Internet we have came to one conclusion in order to ensure an persist connection with XMPP server we have to create a service,
We have created one which uses Smack library to connect with XMPP server and it is working fine with mobile and wi-fi network.
Every time you make something design approach always matter!!!, Smack have this reconnection mechanism already implicitly implemented in there library which listen to connection and if connection drops Smack try to reconnect with XMPP server at some interval of time.
Our use case scenario::
INTERNET connectivity can be because of wifi or data network,here if connection go is idle state of someone turn off screen cpu goes to sleep now any data is sent to server on this connection there will be no response because server is no more listening to client ,on client side XMPP connection is already in connected mode connection listener is not detecting any disconnection from server,so here flow gets completed.
After searching on INTERNET we found that possible solution to solve this is to ping server after a fix (we are using 1 min as fix period),after ping fail detected ,we have implemented reconnection mechanism same as smack(idea taken from Smack reconnection mechanism itself)by making use of timer task.
Problem:: only problem we have is battery draining ,if user is still connected with INTERNET and reconnection interval increases it will drain batty.
1). What is the possible solution of above problem?
2). Should we have to take another approach?
How To Create Service In Android Which Makes Persist Xmpp Connection
With XMPP Server?
Two things
Reestablish the connection, by listening for CONNECTIVITY_CHANGED intents and determine if the currently used data connection went down (and was replaced by another).
Ensure that the connection is established by pinging the server
Remarks about
Listening for CONNECTIVY_CHANGED is not enough, you need to compare the previously active connection with the now active one. And if it's not the same, re-establish the XMPP connection.
Smack 4.1 comes with ServerPingWithAlarmManager, which will check if a ping is required according to the settings of PingManager every 30 mintues. This value is hardcoded an can not be changed.
Using 1 minute as Ping interval is way to much! As you have experienced, it will drain you battery very fast. A reasonable ping interval is something > 15 minutes and I recommend 30 minutes. Smack 4.1 will also ensure that a ping is only send if there was no received stanza withing the Ping interval.
Also use XEP-0198: Stream Management when possible.
I recommend looking at the various open source apps that follow these guidelines and achieve a stable, permanent connection without draining the users battery1.
1: Just following these advises can not guarantee that the battery will drained. There are more factors to take into consideration.
I successfully integrated my app for receiving push notification using GCM. Its working correctly, I just saw a strange behavior while receiving push notification on one of my android set which is using my wifi network, in the same time others whose are using EDGE or 3G network are receiving notifications correctly. When I try to switch off and switch on the wifi, it receives the pending notification.
I tried opening the ports which normally used by GCM i.e 5228,5229 and 5230 in my router's firewall however with no success.
NB: After seeing this, I tried to configure the app for Parse API and its working as same as GCM so I think it depends upon the network packet receiving or something.
I believe, what you're facing is a known issue about TCP connection between GCM servers and your handset is timing out because of inactivity. Network devices (like your Wi-Fi router, your ISP hardware, etc.) between your handset and GCM servers could kill the TCP connection if no packets are sent every now and then.
There are some workarounds for this which you might try. For example, there are apps on Google Play that modify the default Android behavior and make it update this connection more often, increasing chances that it will not timeout. You could try them and see if it fixes the problem for you.