I want to know which protocol is used to send push notification to android devices and which to send push notification requests to GCM.
Whether it is HTTP, HTTPS or some thing else?
The protocols of the communication between the 3rd party server and GCM server (HTTP or XMPP) were already mentioned in the other answers.
The protocol of the communication between the device and GCM server is not discussed in the GCM documentation, since you never have to access it directly as an Android application developer, and therefore you don't need to know about it.
However, here's a quote from a Google developer from the team that created GCM, which says a few things about the connection. From what he says, you can only know that it's a long-lived TCP connection.
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.
(The quote is taken from an answer by that person)
There are two protocols http and xmpp which you can use to send message to GCM server.
Now its up to you what you want to use. If you want to broadcast message then u should go with http.
you can broadcast 1000 message in a single http request. And only one message through xmpp in a request...
Http can be used only for down streaming(3rd party app server -gcm-mob device)
But gcm won't support up streaming using http.
for that you should use xmpp.Xmpp can be used for both up streamlining and down streaming.
Implementaction of push notification can be very easy if you are going with http and that much more hard if you are going with xmpp.but Google has provided detail tutorial how to implement xmpp.
So please have a look On Google developer site.
Looking at #user3523641's answer and further conversation, I'll try to explain further:
The way of delivering messages is based on the protocol that you've chosen, either HTTP or XMPP (i.e., it's the same). The magic and basic way of working is leaving a socket opened between the GCM server and the user's device.
This way, when an user should receive a message, this opened socket will be used and send the message through itself. This also helps the GCM server knowing which devices are connected or not. So this way, if your third party server says a message should be sent to a user and the GCM server knows the user is not connected, it won't send it at that time, but will try once the connection is again established, so it won't waste connection attempts in vain. The default timeout is 4 weeks, however, it can be changed.
As per the official GCM documentation:
If the device is not connected to GCM, the message will be stored until a connection is established (again respecting the collapse key rules). When a connection is established, GCM will deliver all pending messages to the device, regardless of the delay_while_idle flag. If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage. The default timeout is 4 weeks, unless the time_to_live flag is set.
Finally, when GCM attempts to deliver a message to the device and the application was uninstalled, GCM will discard that message right away and invalidate the registration ID. Future attempts to send a message to that device will get a NotRegistered error. See How Unregistration Works for more information.
You can find more info here.
It uses both HTTP and XMPP
When the message is processed successfully, the HTTP response has a 200 status and the body contains more information about the status of the message (including possible errors). When the request is rejected, the HTTP response contains a non-200 status code (such as 400, 401, or 503).
iOS however, requires a dedicated TCP connection on a proprietary port, and GAE environment doesn't allow any external protocol except HTTP over port 80.
The message size limit is 1024 bytes.
Google limits the number of messages a sender sends in aggregate, and the number of messages a sender sends to a specific device
This is how these components interact:
Google-provided GCM Connection Servers take messages from a 3rd-party application server and send these messages to a GCM-enabled Android application (the "client app") running on a device. Currently Google provides connection servers for HTTP and XMPP.
The 3rd-Party Application Server is a component that you implement to work with your chosen GCM connection server(s). App servers send messages to a GCM connection server; the connection server enqueues and stores the message, and then sends it to the device when the device is online. For more information, see Implementing GCM Server.
The Client App is a GCM-enabled Android application running on a device. To receive GCM messages, this app must register with GCM and get a registration ID. If you are using the XMPP (CCS) connection server, the client app can send "upstream" messages back to the connection server. For more information on how to implement the client app, see Implementing GCM Client.
Check out this for more details -->
Google Cloud Messaging for Android (GCM)
Android Cloud to Device Messaging Framework
Cloud Messaging
Cloud to Device Messaging
Related
I like to develop a web app for mobile devices (Android) that will be served by a local server. The server should be able to send push notifications to the phones via the Push API.
The setup will have no connection to the internet and I can't find a note if the explained setup needs to connect to some cloud service in order to send the push notifications.
mmm I'm afraid you can't, each browser vendor subscribe the serviceWorkers to its own Message Server (Chrome: fcm.googleapi.com, Firefox: updates.push.services.mozilla.com, etc.), so it is something we don't have control over...
Although technically there's a solution, it would require you to sort of "hack" your network, namelly, it would require a Man In The Middle attack. You would have to code a program to redirect all your network traffic to that program (probably using raw sockets, and sending ARP packets), and then make that program listen for request to those Message Servers (those request will be over HTTPS - port 443), then your program has to send exactly the same response the real Message Server would send. It's is not an easy task.... but it is the only solution I cant think of.
Note: Your browser will block any serviceWorker registration that is not over a "secure connection", that means that your server MUST be serving request over HTTPS or you could install your web app locally on your users devices (so that they can be accessed by "localhost").
#Mounica: May be I am a bit late, but just posting my answer in case it is helpful to you or others coming on this page. Your scenario can be addressed using MQTT Protocol within the Wi-Fi network. You will have to set up an MQTT Broker within the network and Make an MQTT Client in your iOs App. You can subscribe the MQTT Client to the MQTT broker on a topic same as GCM works and use MQTT Broker to send Push Notification to topics subscribed by MQTT Clients.
MQTT with Android Applications
When I receive a notification on my phone, how was the push server able to communicate with the device?
Is there a constant connection between client and server? As far as I know something like WebSockets will put a huge load on the server side with all these devices.
Is it some kind of polling mechanism by the client? Seems still like a huge load of requests.
Does the client keep the server up to date with his IP address? How comes no firewall blocks this request (like the one of the router when using Wifi)?
Thanks!
Push notification for iOS and Android are services from Apple (APN) and Google (Cloud Messaging) respectively. For example for APN, the server sends the message to Apple's APN server, including a token that identifies the device. In fact the token is unique for your app running on a device. Obviously the channel is secure and your server need credentials (certificate).
Do XMPP Servers such as Openfire require implementation of their own in order to handle messages. Do I need a web language such as PHP in order to handle messages with Openfire?
Because according to posts such as this How to make Chat Application in Android Using XMPP and GCM, I do not need to write PHP scripts in order to handle messages, Openfire (it being a XMPP server) will do all the heavy lifting. So when creating a messaging program is the only thing I need to worry about the client side code?
I've also run into contradictory information that I hope someone can clarify on. It was to my knowledge that one needed to use a XMPP server along side GCM; as GCM is not reliable in delivering messages by itself and requires an XMPP server to fully be reliable. Is this true, the above link suggests that it isn't, but according to this it is https://www.youtube.com/watch?v=5wXGcu9H91s
Some clarification would be great, thanks.
GCM allows you to use both HTTP and XMPP to send messages down from your application server through GCM to your devices.
Only with XMPP though can you send messages from your device through GCM to your server. This allows your device to send acknowledgment messages back up to your server. This does not necessarily make GCM more reliable but it does allow you to have a better audit of what messages were actually received by devices.
Openfire is a server that supports XMPP so you will still have to implement the protocol maybe using Smack.
Note that you could skip GCM and have a connection directly between your app and your XMPP server, however this is not recommended since your app would have to be constantly connected to your server which would be very hard on the battery of the device. This is where GCM comes in, allowing your app to receive messages even when it is in the background but still being kind to the battery of the device.
I am using GCM for Chat App. If User is Offline(not Connected to App but internet is active) then i Send push notification to devices It receive perfectly.
But when Device is totally offline(neither connected to App and nor active internet) at that time GCM send me response like { id: XXXXXXXX,success: 3,failure: 2{message_id:xxxxx,ect:..}} on my App server.
two device are totally offline they don't have active internet connection..
when device will connect to internet GCM Send them message.
but how can my App server will Know that Message is delivered by GCM.
I Search a lot but can't get any satisfied answer.
I tried that on messageRecive at client device(Android device) i will send httpRequest to my App server but it not suitable for my app it makes App very slow.
So Question is how Can i know that my failure 2 message are delivered.
First of all, you do not need to update your app server in case of a downstream message after it is sent to GCM Server. As explained here, GCM server stores the message in case of an offline device and delivers it once the device is online.
(Now assuming that what you want is to handle network tasks on the client)
You can use GcmNetworkManager to batch network discovery and connectivity related tasks across the system through Play Services. Go through the documentation.
You can use GCM Statistics and Diagnostics from Google Play Developer Console, too. This gives you details of messages handled by a particular app (through Registration token) down to status of specific messages (through message IDs). More explanation here.
(However I am not too clear exactly what you want)
EDIT
but how can my App server will Know that Message is delivered by GCM.
Sorry, reading through again I realised this is the real question. Answer is pretty straight forward here.
.
I am trying to understand the concept of gcm upstream messaging.
Well what I came to know till now after browsing for hours is this :
1)My client app sends upstream message to gcm server.2)GCM server then sends it to my 3rd party app server.3rd party app server responds to it my sending ACK to GCM server.3)Then GCM server echoes the message to the recipient device(recipient Id is included in the upstream message sent from the app).
I don't if its what actually happens.
Now that I am sure that in some step GCM server sends mesaage to my server, how actually GCM server
sends message to my app server. How does it come to know about my app server as there is nowhere where we put my server's address
I have searched the whole Internet but couldn't find anything about this.I have gone through several SO questions but I couldnot find my answer.
I want to know the entire series of steps what happens during this entire process. I am very confused.I want to know the entire concept and what's going on behind all this.
Any detailed explanation with all steps will be appreciated.
To inform I have read the Google docs.
You have much of the flow correct but I think another read of the Docs will clear things up.
Your application server must act as an XMPP client, and connect to CCS (GCM's XMPP server). Your server connecting to CCS is how GCM knows the "address" of your server.
Cleaning up the flow you suggested:
Your app server connects to GCM's CCS.
Your client app (android app) gets a registration token.
Your client app (android app) sends that token to your app server.
Your client app send upstream message to GCM.
GCM fwds that message to your application server.
Your application server send Ack to CCS.
Your application server handles the received message.
Note the above flow is a possible one, there are many others, also downstream messages are not part of the flow. Again refer to the docs for more details.