I planning the application pushes a newsletter to all registered users.
Number of users is approximately 200,000 ~ 300,000.
I'm caring about the traffic issue with google c2dm server.
Can I request to c2dm server in a loop with large number of users using HttpURLConnection?
Will I banned?
I heard something about in this case I must use http 1.1 protocol with keepAlive set true.
C2DM does have quotas, both on the messages per device and total number of messages. you can find the details here:
http://code.google.com/android/c2dm/quotas.html
as it says, 200k is the default limit but you can request a larger quota. i've done this at a company and it was no problem, but i can't say for sure how helpful they will be to the average developer.
as far as i know, there's no quota on the rate that you send them. you can send them as fast as the google servers will accept your requests.
I planning the application pushes a newsletter to all registered
users.
you should make sure you aren't trying to push a payload through C2DM. that's clearly a misuse of the service. C2DM must be used to wake up the device only. in your case, the message itself should be "hey device there's a new newsletter on the server, go get it". assuming that's happening but a few times a day at most, it will be within the accepted use for C2DM.
Related
We're building an application server which will be used to send push notifications to android and ios clients via GCM connection server. Our plan is to use HTTP interface to connect with GCM as we only want downstream messaging. could you please tell me what is the performance of GCM for HTTP interface? I'm looking for some kind of performance data like how many push notifications messages per second GCM can support? I checked GCM site but couldn't find this. Please help to guide from where i can get such data?
as per the official Google answer
The rate limit exception code indicates that you are sending messages from a backend server too frequently. To ensure a stable service, there is a per minute / per device app upper limit on the number of messages that can be sent from a backend server. This limit is set high so most well behaving apps should not be affected, all apps should however be prepared to receive this error code.
They do not specify the "actual limit" but they do say This limit is set high so most well behaving apps should not be affected so as long as you re not spamming a single device like crazy you should be ok with whatever you send at it.
However please note that you can get throttled and have the messages be delayed
I am developing mobile client for emailing service. One of the key features is notifications about new messages in the mailbox. As recommended by GCM architecture guidelines we are using a "Pusher" that is responsible for sending messages to the Google servers once we received a new message. The issue is that testing process has reported about serious problems with push notification delivery to devices.
So the question: is there an approaches for monitoring average statistics about push notification delivery percentage, time etc? Or maybe somebody have experience in how to set up test environment for efficient monitoring of how much notifications are getting lost during the application work?
All the "tips&tricks" related to the improving Android GCM experience are welcome.
Google claims that the processing at their GCM server takes less than a millisecond. Link below for a great video on GCM from Google's developer. And it's believable coz I could get push notifications almost instantaneously using my company's server to my device now.
http://www.youtube.com/watch?v=YoaP6hcDctM
They don't guarantee delivery, but they try for a max of 4 weeks to deliver the message depending on the duration you set in the message you send to Google's GCM servers and if you wish to let Google keep the data for eventual delivery of message to the device in case the device was offline when the message was to be delivered.
However, there are certain conditions under which the GCM messages are not delivered.
Background data is unchecked under Account and Sync settings.
Prior to 4.0.4.(ICS), a Google account on the device is a pre-requisite for GCM. Maybe, Users are not logged into their Google account.
The only way to do so is to report back to your server with the timestamp of the received push.
You can either
Report back to the server once you receive the notification in your GCM service. To implement, you will have to add a push id for your push notifications and send the id along with the push data. The client will have to get the timestamp once it receive the message and send it back along with the notification id. A simple php script can be done (when you send a push notification, you set the time of the send-notification and once it receives the device's timestamp it sets the receive-notification. This boils down to two fields in your database (marked in bold). In this approach you will probably not so much care about errors since it is very probable that the device will have a connection when it receives the notification and as such its request to your server will go through.
Keep a list of notifications received in your app and their timestamps. And when the sync is done, send the this data in your sync operation. This is ultimately the same approach but your server's data won't be as realtime as the first approach. However, the extra request is not required from the client's side but saving the received notifications and their timestamps is.
All in all, you will have to keep track of the notifications sent using a notification-id and their sending time (send-notification) and their receive time (receive-notification). A simple query will help you analyze this data.
Google has added support so that you can receive delivery receipts from Cloud Connection Server (CCS):
You can use upstream messaging to get delivery receipts (sent from CCS to your 3rd party app server) when a device confirms that it received a message sent by CCS.
To enable this feature, the message your 3rd-party app server sends to CCS must include a field called "delivery_receipt_requested". When this field is set to true, CCS sends a delivery receipt when a device confirms that it received a particular message.
https://developer.android.com/google/gcm/ccs.html#receipts
Google does not make these statistics available to you. There are some statistics available on the android developer console. This only shows the number of messages and registrations.
You would have to implement your own data collection, which could be done fairly easily. You could record the time & id of each message sent and have your android client report back to your server with the time of message receipt. You could then store the data on your server and query as needed.
Since that time Google has provided developers with advanced monitoring tool.
The Gcm Diagnostic Tool is available in Google Play developer console. Additional information is here https://support.google.com/googleplay/android-developer/answer/2663268
So you can easily track the particular message status via registration token.
Since I want to build reliable communication in mobile apps, could I get push failed reports(maybe device is offline) from the third party push services (C2DM, APN, urban airship) ?
Or We need to build it by ourselves?
The intended purpose of Android C2DM is to be a battery-saving way for your server app to signal the mobile device that it wants to start reliable communications.
You can structure your message so that each new C2DM encompasses everything that has occurred since the last two-way interaction with the server (i.e., "come and get whatever I've got"). Your failed delivery report is implicit in the mobile device not responding promptly (you can do this because you know C2DM activates your app with an Intent).
Is that really any worse than guaranteed delivery of each message in a lossy medium? Okay, it's worse in that you also have to implement a primary communication method. But you had to do that anyway because C2DM is inbound-only, right?
As Vinay says, MQTT may offer you the feature you desire. When a client connects to the server, it can register a "last will and testament" message with the server. If the client disconnects unexpectedly, the server sends this message to the topic it was instructed to do.
In this scheme, your client could send a message "online" to something like client//status and register the message "offline" as a LWT for the same topic. You could then have a server local client that listened to the topic client/+/status and it would know which clients were online and which offline.
I would suggest that the tokudu demo isn't the best place to look. This blog post by Dale Lane gives insight into using MQTT on Android: http://dalelane.co.uk/blog/?p=1599 and there is a review of MQTT power usage (again on Android) at http://stephendnicholas.com/archives/219
There are client implementations to suit both IOS and Android, see http://mqtt.org/software
No one service does not provide reports about failed pushes.
Failed push report makes little sence with APN/C2DM/Helium
All services are aimed to deliver the push-message under all circumstances.
If device is offline now, then push will be delivered when device becomes online.
Moreover, for iOS push-message is just a notification for a user, not for an application!
Simple case will illustrate it:
Assume that push is received when the application is turned off. In that case, notification for the user will occur. But, application will receive data from push, only if user taps on that notification! If user will tap on application's icon, then data will not be received.
So techically, push is delivered to the iOS device and application is started, but data is not delivered.
UrbanAirhip with APN and Helium
You can consider to implement your own transport for pushes. MQTT seems to be a good option.
But in this case, you have to deal with keepalives, device sleeps and battery optimisations.
All that hard work is already done by engineers from Apple, Google and UrbanAirship.
Depending on your business needs, it can be easier to adapt your architecture for existing solutions, then reimplement push-service again.
Take a closer look to UrbanAirship. In fact, C2DM has some limitations and sometimes timings for delivery of push-message is too big. Because of that UA has implemented their own transport - Helium, it works pretty good. Helium is a paid service, but UA provides good SLA.
I am suggesting for push notification IBM MQTT protocol. This fine enough for push notification.
see the demo from https://github.com/tokudu/AndroidPushNotificationsDemo
I did something similar where I had a database keep track of push queues to known subscribers and had reporting when failed. It was very simple and went something like this...
The schema was like so:
pushMessages
messageID , GUID, PK
message , nvarchar (256),
expires , datetime
messageQueues
subscriberID , GUID, PK
messageID , GUID PK
failedPushMessages
subscriberID, GUID, PK
messageID , GUID PK
(subscriber table omitted)
Once a client received the message successfully, the client would ping back to the push server and notify it via the unique queueItems ID that it received on the push notification. There would also be a daily database process that would check for expired push messages. When found, it would do a join on the queueMessages matching the messageID then remove them from the messagesQueues table and copy them to the failedPushMessages table.
This was very easy to understand and maintain but I don't have experience doing it another way.
Push Services are an efficient and reliable way to alert your users. They allow even background applications to inform users of new information in real-time. Push Services are widely used for a variety of fields in mobile applications, such as weather updates, messaging services, mail notification, coupon services, and so on. Push Services are no longer optional but have become essential.
I have one single Gmail account signed up for C2DM.
What I would like is that my app, thanks to this account (after having requested registration IDs and auth tokens for each device), could be able to provide messages to all the devices in which the app is installed.
I want to know if is it possible to use the C2DM in this way..
Thanks a lot
(for any details, just ask me.. )
ps I made the c2dm work on the emulator, but of course I cannot try what written before because I would need several phones..
Going off your question and comments, it sounds like you're just wondering if you can send c2dm notifications to an indeterminate number of devices using only one sender id.
That is exactly the way c2dm is supposed to work. You create one sender id to use on your backend servers, and that sender id is used in your app to register for c2dm notifications. Your backend then gathers all registrations ids and uses your one sender id to push notifications interested parties.
If I understood your issue correctly, the answer is: you can't.
You will have to send one http request, to google servers, for each device you want to reach.
There's no way to broadcast a message to all the users who have registered to your service.
It' frustrating because in my case I send a newsletter for all my users, so opening a connection to millions of users is expensive.
To solve the scalability issue I have created a simple appengine map-reduce task that loops through all the user registrations and create the http connection to the google services, it's the fastest you can go because it dynamically instantiate new servers for your delivery needs.
C2DM has been deprecated. GCM has replaced it, and it allows you to send messages to 1000 devices with one HTTP POST.
C2DM->GCM Migration Guide:
http://developer.android.com/guide/google/gcm/c2dm.html
Does anyone know device quota per day for Android c2dm?
PS: Im not interesting in application quota that is 200 000.
C2DM quotas is indeed based both on number of messages to a device or messages sent for any device.
It doesn't however seem to be stated anywhere what the amounts for a single device is.
When you sign up you give an estimate of how many messages you expect your application to send. (And are assigned a default quota of 200,000)
You can read about the limitations of c2dm here
And you can read about the quotas here. Here you will also be able to request more than the default 200,000 messages.
Device quota is 1000 per application per device. Here is answer on Google groups