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
Related
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.
I decided to build an android app to implement a chatting mechanism. this mechanism is a bit different of the usual chat systems.
It is not peer to peer messaging system rather we have a message sender and multiple repetitions. every reception after getting the message from source, repeats and resend it to others. the below image shows our broadcasting system:
in this system every message has an unique id so very client broadcasts the message just once.
i know socket programming and also UDP based solutions but in implementation phase the networking foundation is challenge. we don't have any centralized server so every clients should do listen a particular port and resend the given message.
I guess the reception need UDP to announce its listening open. also sender lists the its neighbors receptions over UDP protocol. then connect with them and sends the message. BUT here we don't have any access point or connectivity among sender and receptions.
Should I use hot spot? I am completely confused.
Please give me help or suggestions to implementing the network.
Try this, it seems to fit your specification.
The Wi-Fi peer-to-peer (P2P) APIs allow applications to connect to nearby devices without needing to connect to a network or hotspot (Android's Wi-Fi P2P framework complies with the Wi-Fi Direct™ certification program). Wi-Fi P2P allows your application to quickly find and interact with nearby devices, at a range beyond the capabilities of Bluetooth.
can someone to confirm that in order to use MQTT protocol, the APP on the smart device (Ios or Android) embedding MQTT client code, must be active? If so, how can i wake-up the App from my remote server to enable mqtt conversation? Maybe a push notification should alert the smartphone user to open the APP because some important messages are outstanding for him?
For Android the app can start a service that will run in the background and receive published messages all the time.
For IOS you will need to wake the application up to get it to connect to the broker, the usual approach to this is to use the Apple Push Notification Service to wake the app up.
The main thing is that the TCP socket (so the connection) between client and broker must be active so that broker can push messages to the client (as subscriber to some topics).
The only way to handle "disconnected" scenario from the client side is to connect to the broker with "clean session" at false. In this case, the broker will store all messages for that client if it's offline and then send them when it'll be online.
Paolo
Most of you are aware that iOS and Android use push notifications to inform the phone of any arbitrary event. I am interested in how one would implement such a server-initiated notification system. As the clients most probable use NAT, the server can't open a new TCP connection to them.
As far as I can see, the phone only has TCP and UDP connectivity. TCP uses keepalive to terminate the connection on the server after some idle time. Although keepalive can be disabled completely, that would expose the server to all sorts of DoS attacks by creating lots of connection contexts.
So I think there is some kind of timeout involved after which the phone re-establishes the connection. Additionally, if using TCP connection with disabled keepalive, how are changing IP addresses on the phone handled? Or does the phone establish a new connection periodically? What are the used timers?
Hope somebody knows a bit more about it.
UPDATE to clearify: I do not want to use iOS or Android Libraries (APNS or GCMS). I want to know how Google/Apple implemented it on the lower OSI Transport- and Networklayer (APNS and GCMS are Application layer or at least above Transportlayer). This is a very TCP specific question, that has nothing todo with iOs or Android programming.
I've been digging into android push notifications recently. I guess, I understood the overall architecture and message flow.
I imagine it like this:
[Own server] --> [GCM] --> [Device] --> [Application]
The only mysterious part of the route is between [GCM] and [Device].
Long story short, what infrastructure is used to deliver message from [GCM] to [Device]?
I've read somewhere a bit, that probably, device keeps an opened connection to the GCM. If this is the case, what kind of connection is open?
About the CGM there are a lot of informations on the Android Developers center.
The device keeps a connection open to the CGM (I think IP). If there is no connection between the server and the device, the CGM will store the incoming messages to deliver them later.
The iOS push technology keeps an IP connection open between the APNS (Apple Push Notification Service) and the device (cf: wiki). So it could be sensibly the same thing as the GCM.