I need to send a large number of web push notifications via FCM, all which are personalized (so I can't use broadcast messages. It's 1 push per token). Let's say the number of subscribers is 500K-2M, so that means 500K-2M API requests I think?
I've read several articles about the topic, such as how discord does it. They use the XMPP API which I would love to use, but currently I'm doing this in ruby and I don't think any of the current libraries support what's discussed in that article (100 requests at a time, connection draining, etc), and I don't want to build something from scratch.
So I think I'm stuck with the HTTP API for now.
The thing I'm having difficulty with is how to actually run the requests asynchronously... I've tried using Typhoeus gem with 2000 connections at once, and many of the connections timed out.
I've tried researching FCM docs for HTTP API rate limits and connection limits but can't find anything...
What is the fastest strategy to send 1M non-broadcast FCM messages using the HTTP API?
Related
I have a IOT project where multiple devices update their current locations to the IOT server. The server parses the hex data received and stores them in a MySQL database. I have a independent REST API server that queries this database to retrieve the current position of the device and display it on a map in Android.
Now because of the refresh rates of the device and the Android API request, there is a considerable latency in updating the positions on the map. How can I convert this to a real-time design, eliminating the need to read from the database but just directly sending the data to the Android client?
Note: Multiple android devices may request live updates of the same GPS device.
I am considering using firebase GCM push notifications to deliver the position to an Android/iOS device which has requested for the live view updates. However, I think this would be inefficient. As this would not be very stateless as I would have to monitor the list of devices currently requesting push notifications and do some handshaking to start/stop the notifications.
Can I use web sockets instead to make a connection between the android and the server app itself? Does the quality of the internet connection matter excessively here? I realize that somewhat like UDP for updating the position the most recent packet alone matters here and any skipped position data won't contribute much.
based on our discussion
I think GCM is a good enough option for this kind of problems.
Your total number of users and concurrent users are not that much, As I know there is a limitation for FCM that is " For each sender ID, FCM allows 1000 connections in parallel." you can find it here
The other limit is about number of stored messages at FCM. Offline users do not receive messages until the become online and the limit is 100 messages. so this can be a problem, but when the user become online FCM will send a message that can be handled in client, I mean you will informed of the situation so you can ask the server to send last update messages, but if the only last one is important for you, this is not the case and you do not have any problem, because the client will receive the last update very soon.
Anyway, based on GCM/FCM you just need to worry about sending messages when you will get updates. Consider that GCM is not about only push notifications, you can handle the messages inside BroadcastReceiver.With FCM, you can send two types of messages to clients: reference
Notification messages, sometimes thought of as "display messages."
Data messages, which are handled by the client app.
in this case you need to use data messages.
So, based on these information, I suggest following scenario :
Devices send updates to the server side.
server will send GCM messages for the interested clients
on the server side, you can handle the interested clients and you need to make it parallel.
Hope this helps you. if there is any other aspect we should consider, let me know.
thanks
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'm trying to make a chat application using GCM, but I'm a little confused about what the best practices are.
The tutorials I've seen recommend using the XMPP-protocol because you can use existing connections and pass bi-directional messages which makes it faster. The problem is that the GCM payload is limited to 4kb. I wonder whether it's safer to use the push notifications to actually deliver the messages or just to notify the clients that there more messages to download using the HTTP-protocol.
There is also the security problem. I use the OAuth resource owner flow to secure many of HTTP-endpoints. It feels bad to also include the client-id, user-id and access-token/refresh-token in my GCM upstream messages since the payload is already limited. Also, it would require me to write a lot of code ensuring that the access-token has not expired and when to retry and include a refresh-token instead and so on.
So I wonder if it's better to just send the upstream messages using the HTTP-protocol and then using GCM to notify the receiver to download the message.
Lastly, I wonder if it's worth using the XMPP-protocol if you are using HTTP for upstream messages anyway. Is the XMPP-protocol still faster, or is it just faster if you are going to use it to send upstream-messages?
Hope I was able to explain my problem well.
I want to implement an instant messagign service analogously to whatsapp.
The messages are delivered, even thoug sender and receiver do not need to be online at the same time.
Is there a framework existing to do so (btw I use a linux server). Is the Google Clouse Service suitable for this? Thank you
Google Cloud Messaging (GCM) is a service that manages small messages to / from android. It does require users to be using google play.
What makes it so cool is they will manage the connections for you. They will queue stuff up for a period of up to four weeks, and after that will send a message telling you that its been more than weeks, and you will need to process a new request to obtain the original messages again.
Its a free service. There are some rate limits, but they seem pretty reasonable. i.e. You can't use it for sending frequent game moves, but its totally fine for normal text messages. As I understand it, GCM is only a server interface. You will have to roll your own XMPP server to store and manage messages. Note: there is a payload limit on GCM messages, I think its 4k or so... not big enough for images. You'd have to manage those via http, and send image names via GCM.
They will also broadcast messages to users (1000 at a time). Did I mention this is a free service?
Something like this link will get you started. The API keys thing and registration #'s is sorta confusing. Once you figure that out, it all works. You can test to your emulator via curl messages to the google server, etc..
Oh, and GCM also keeps track of all your user analytics as well..
You can try openfire. It has offline message and everything. Server can be hosted in linux as well.
There is Layer (Android and iOS support for the moment)
Hey Checkout this easy way to implement chat
Quickblox Api
I am currently building a messaging application that allows users to send and receive messages on their Android mobile phones over an internet connection to each other. I have decided that I do not want to use polling because it means that a user may not receive another user's messages as instant as possible. I have my own server available for use.
I am currently tied between using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device. The other option is to keep a live TCP connection between my server and the Android device via a service, and send 'keep alive' messages every 5 minutes for example.
From your best opinion, what is the best way to do this - or is there a better way? I don't want to use third parties apart from Google to do this. There are similar answers available, but they don't address this specifically.
Alex
using Google's Cloud Messaging for Android platform in order to send the notifications from the server to the Android device.
This is not a realtime notification either; the notifications may be delayed longer than you experienced with polling. Also GCM is meant for broadcasting messages to a number of users, not for targeting a message to one specific user.
The other option is to keep a live TCP connection between my server and the Android device via a service
I don't know how many users you are expecting, but this may not scale. You are limited in the number of TCP connections to one server.
No need to re-invent the wheel here, use an existing implementation such as XMPP.
Take a look at this:
https://pusher.com/docs/client_libraries
https://github.com/pusher/pusher-test-android
It may be what you're looking for