Environment Details:
IBM MobileFirst Platform 7.1.0
Channel: Android & IOS
Notifications to be triggered for 15,000 users.
I would like to understand a point how WL.Server.sendMessage(applicationId,notificationOptions) API works?
Means, I am able to trigger the broadcast notification using the above API and providing the necessary information and received the same in 3 devices.
There is a limitation in GCM that 1000 messages can be sent at a time as per the limit-of-android-gcm-push-notification.
Does the above mentioned API can handle this scenario? Because more than 1000 there should be another request to be sent as per the above link.
As per Scalability and hardware Sizing a MobileFirst Server can push a notification message to over 22,500 iOS devices, 50,000 Android devices and 350 Windows Phone devices per second.
If my understandings are correct than this API should be able send the 15,ooo notifications without fail by considering the above value as max.
In case of GCM multicast notifications, all Push APIs used by IBM MobileFirst (broadcast or multicast), handle the case of at most 1000 registration tokens at a time. Note that this limit is set by GCM and any GCM client must abide by it.
In case of 15,000 notifications , it will be 15 times 1000 push notifications.
The value of 50,000 Android devices per second, in the Sizing and Scalability calculator, has been derived keeping this limit (1000 messages at a time), in consideration.
Related
I have the firebase SDK integrated in my system and is taking live traffic now.
I`m basically using FCM for sending simple DataMessages to the app.
We are seeing inconsistency in the time taken for the ping to reach the device, for instance 3 pings are sent for 3 consecutive update actions out of which 2 pings were received immediately, but the third one took around 5 minutes to reach the device.
Do we have a control on the SLA of a firebase ping, can we fine tune and reduce the delay in recieving the Firebase pings on the app?
I know that APNS will ban a client who attempts to send multiple push notifications to inactive devices. What is the policy for keeping on sending push notifications to 'NotRegistered' devices in GCM and ' response code 410' channels in WNS? There would be any banning or blocking of the client?
Thanks in advance.
For the GCM part, it seems there is no defined policy when it comes to sending to Unregistered Devices. I did find this answer to a post that discusses the limitations of GCM. Some significant quotes from the answer:
The only limits you run into the GCM documentation is this: http://developer.android.com/google/gcm/adv.html#lifetime
Quote from the above link:
Note: There is a limit on how many messages can be stored without collapsing. That limit is currently 100. If the limit is reached, all stored messages are discarded. Then when the device is back online, it receives a special message indicating that the limit was reached. The application can then handle the situation properly, typically by requesting a full sync.
I also found this post where the GCM blocks a server, and as per the answer:
There is usage limit for GCM and if you automate the GCM request they consider as a threat as DOS attack
We have an app (Ruby on Rails) that sends push notifications to an android app and we're facing an issue with GCM where some of these notifications are either delayed or never received. Considering the fact that these notifications are being sent to employees and not end-users my questions is:
What the best way to send these push notifications without any delay or drop and is there a way to send push notifications independently from the available services such as GCM and SNS?
Please keep in mind that we're looking for a solutions that can send these notifications without any delay as for the app to perform well the notification must be received within 1 to 20 seconds from the time it was sent.
Thanks in advance for anyone that will reply to this question...
Have a look at "Pushy":
They state the following on their website:
The most reliable push notification gateway, perfect for real-time
applications.
Google Cloud Messaging simply doesn't cut it for time-sensitive,
real-time apps, due to its instability and push notification
throttling.
Pushy works by maintaining a dedicated background socket connection
using the MQTT protocol, an extremely light-weight pub/sub protocol
that consumes very little network bandwidth and battery, which makes
it perfect for mobile.
You can use it for free with up to 100 devices, so you could just give it a try to see, if it fits your needs. I didn't try it.
I am trying to understand how exactly push notification services work.
Are these real push services with constant connection to server or just mimics by polling?
How does a server with heavy traffic maintain so many connections?
In general push notifications work both by establishing a long-lived TCP connection, or using long-polling. The maximum number of connected clients is determined by the server resources.
Take a look at the Socket.io protocol stack for an example. Or better yet, at the XMPP/Jabber protocol, which relies on TCP principally and falls back on long polling.
Fusio is correct. For mobile phones, a single push service is typically used (Google cloud messaging for android, Apple Push Notification Service for Apple/iPhone) to limit the amount of connections from the phone. 3rd party applications register to these services and push messages through them.
What are push notifications and how do they work? Also what is the difference with googles cloud to device messaging? Is c2dm also a push notification? Also do I need Special server setup to implement push notification?are push standard or every device has different implementation?
Basically the server maintains a list of connected clients. Whenever something of interest occurs, the server sends the data/notification/updated state to the connected clients. This is in contrast with pull, where the clients poll the server for changes.