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).
Related
What protocol is used for mobile push notifications?
Take android as an example.
First, make a HTTP request from a third-party server to the Firebase server.
The question is next.
How does the FIrebase server select the required mobile from many and send push notifications?
Of course, I know I can send push notifications without worrying about that.
However, I am curious about interest.
On TCP / IP, IP address and MAC address are required for communication, but how do you send push notifications to mobile?
Links used for studying
Protocol used for sending push notification in Android
Google Cloud Messaging - CCS (XMPP) vs HTTP server
thanks.
On iOS, when an app registers for remote notifications it receives a token. Apple stores this token against the device's actual unique identifier in their database.
The iOS device itself maintains a persistent TCP connection to Apple's servers on port 5223. The protocol itself is proprietary to Apple.
When a push notification is sent to Apple's servers, they cross reference the token specified in the push to determine the actual device that the push is for.
The notification is then delivered to the device on the already established TCP connection.
If the device isn't currently connected (say it is in Airplane mode) then the payload is held until it reconnects or the message is discarded for being too old.
I imagine Android would work much the same
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
I need to implement a group chat server which can support more than 50 users at a time.
The users will be only on mobile clients which include Android/Windows Phone.
Sending push notifs to the apps will not be difficult, as the server needs to do a basic curl request. So "polling" is not an issue.
My current skill set includes.
Flask
Google App Engine( I intent to use it or a web hosting
server.)
Basic php
So from what I know, I can make http requests to the server with user specific information+chat msg.
The server processes this and sends a broadcast using push notifs to all the devices stored in database.The server identifies the device from the data in the http request.
How efficient will this be?
If this is not the correct approach, what all do I need learn(sockets programming?) and any framework which can make my work easier (it will help if it is also supported on GAE).
I think you need XMPP messaging. It's support by App Engine but not in PHP : https://developers.google.com/appengine/features/
XMPP permit to send and receive chat messages.
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
stackoverflow fellows,
Since I am very new in Cloud Computing matters, I would like to ask you a question: Google Cloud Messaging for Android works from server to client, but also viceversa(from client to server)?
I am asking you this, because I am currently developing an Android application. The structure, in general lines, it's something like: I would like to use my laptop as a server - and perform all the computations here. Then, from my server (laptop), to send everything in the cloud, and from the cloud, directly to my Android running device. I want to perform the computing and database storage on my local server (because, since I am a student, I won't have enough money to actually pay for a server from google (let's say), so I am focusing on what's free and suitable to my needs) and just communicate with my Android device using Google Cloud Messaging for Android. (I want my application to be independent from the hardware of my mobile device, and also, I want to write the program that will perform the computations on my server in Java).
I know that I can send messages from the server to my device(through cloud), but the question is: can I also send messages from my device to the server ? I am asking this, because the computations will be made after I submit something from my device (basically, my Android application will be an interface, from where I can send the data to my server (through cloud) and then receive (also through cloud) the results of the computation on my device)
According to what I've been currently reading (http://developer.android.com/google/gcm/index.html) it seems that I can only send messages from the server to my device, but I decided to ask, since, so far, was the only free messaging framework(using cloud) I have found.
Thank you.
You can use GCM Cloud Connection Server to send messages from device to server.
Paragraph from this page:
http://developer.android.com/google/gcm/ccs.html
The GCM Cloud Connection Server (CCS) allows third party servers to communicate with Android devices by establishing a persistent TCP connection with Google servers using the XMPP protocol. This communication is asynchronous and bidirectional.
Google Cloud Messaging for Android works from server to client, but
also viceversa(from client to server)?
Sorry but GCM(Google Cloud Messaging) is only made up for sending Push Notification from server to device. Not for Viceversa.
I know that I can send messages from the server to my device(through
cloud), but the question is: can I also send messages from my device
to the server ?
For sending the message or anything(For Example: Photo,files..) to Server why Don't you Use Web services for it. I think it will Be suitable according to your Needs.
It is correct what KashifB wrote:
You can use GCM Cloud Connection Server to send messages from device
to server.
But keep in mind that Messages with Payload have a size limit of 4kb per message.