How to reduce the time it takes a FCM to reach user's phone, which is not influenced by any restrictions like doze or task killers.
it can be particularly bad for signaling voip calls which firebase doesn't support natively (unlike apple's Pushkit).
I see some voip apps tend to maintain a socket for that, but i've seen that sockets usually don't last with some vendor's task killers
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I am about to implement GCM in my application, but I am unable to find the answers of the follow questions in the documentation :
My app requires time critical delivery of the changes in the server.
Will be the GCM deliver the notifications immediately ( no delay ) even when the device is sleeping ?
Will notification wake the device immediately ?
There will be about 2-3, up to 20 notifications per second, will this cause an issue ?
Will be there any cost of the service with these requirements ?
Will be the GCM deliver the notifications immediately ( no delay ) even when the device is sleeping ?
Yes, You can set the priority of a message as a High priority.
GCM attempts to deliver high priority messages immediately, allowing the GCM service to wake a sleeping device when possible and open a network connection to your app server. Apps with instant messaging, chat, or voice call alerts, for example, generally need to open a network connection and make sure GCM delivers the message to the device without delay. Set high priority only if the message is time-critical and requires the user’s immediate interaction, and beware that setting your messages to high priority contributes more to battery drain compared to normal priority messages.
Will notification wake the device immediately ?
It is been answered in the description above :)
There will be about 2-3, up to 20 notifications per second, will this cause an issue ?
I think this SO questions can help you with that question.
gcm how many devices can receive a push message at a time
Android Push Notification (GCM), is there any Daily Limit?
Will be there any cost of the service with these requirements ?
From Google Cloud Messaging: Overview
Google Cloud Messaging (GCM) is a free service that enables developers to send messages between servers and client apps. This includes downstream messages from servers to client apps, and upstream messages from client apps to servers.
Just take NOTE that Firebase Cloud Messaging
(FCM) is the new
version of GCM. It inherits the reliable and scalable GCM
infrastructure, plus new features! If you
are integrating messaging in a new app, start with FCM. GCM users are
strongly recommended to upgrade to FCM, in order to benefit from new
FCM features today and in the future.
Actually, GCM is not recommended at all for time-critical operations, due to its reliability issues [1] [2] [3]. Notifications may be delayed, rate-limited, lost in transit, or arrive in a different order than which they were sent.
There are alternative push notification gateways you could use instead, which are far more reliable for your time-critical operational needs.
Pushy (https://pushy.me/) offers a highly-reliable push notification gateway for Android apps that works independently from GCM, using its own background MQTT connection.
Full disclosure: I founded Pushy.
I'm going to implement a mobile game for Android and iOS in which each players' actions need to be broadcasted to other nearby players (nearby in the game) through a server that checks if the actions are permitted. The requirement is that the other players need to be notified about these actions as soon as possible. The actions don't need to be delivered in the order of sending, but the delivery should be reliable.
I'm considering using ZeroMQ to implement that. Nearby players could subscribe to the the same topic and publish/consume messages that contain other player's actions. Using a message queue seems to be very attractive compared to implementing the communication using some kind of RPC. I have the following doubts though:
Would ZeroMQ work well over a cellular network which isn't very
reliable?
ZeroMQ doesn't support sending messages using UDP, only
TCP. I don't require the messages to be received in an order. If a
message is lost, I'd like the receiver to be able to process the
messages that followed the lost one without waiting until the lost
one is resend. Is it possible to achieve that using ZeroMQ?
As an alternative, I was considering using ProtoBuf with Netty for example, with UDP + reliability implemented on top of that. However, this would be more work and I'm not sure if I'd be able to achieve better performance than ZeroMQ which is considered to be great in that matter.
Actually, is UDP communication over the cellular network/Internet a good idea? Wouldn't there be any issues with operator's firewalls, NATs or so? I'm assuming that it should be fine, since the communication is through a public server, not peer to peer.
Is there any fast and reliable message queue that supports UDP?
I do an application design for a soft real-time software application now.
The application will probably need to notify its mobile users about some events in the system. An event can happen during a 15-minute time frame which starts after the user's first interaction with the system. The event notification should be done in soft real-time: if a user notified later than 15-20 seconds he was supposed to be notified, then it is critical. Basically, I need to notify a mobile user about an event no later than 15-20 seconds after that event happens during a 15-minutes time frame.
I plan to do that with some kind of PUSH technology (XMPP/Jabber, native app with Comet connection or maybe PUSH email).
Unfortunately, the most obvious solution which is to have mobile web-site (example: http://www.lightstreamer.com/) with real-time push notifications is not suitable, because in that case the user will have to stare at the screen during all the 15-minute time frame. Notifying a user with a sound or a vibration would be a much more pleasant user experience (connect to the system via smartphone -> start interaction with the system -> put the smartphone back into the pocket or a bag -> get notified).
I have done a simple experiment by sending Jabber chat messages between my laptop (WiFi/100Mbit) and my Android smartphone (GPRS/3G). The thing is that some of the messages sent to the smartphone are late (it takes about 1 minute until they arrive at the smartphone) or just lost (they never arrive at the smartphone). Moreover, I have noticed that the Jabber client at the smartphone goes offline regularly for a few seconds. I do not know if it is because I have a very cheap Android smartphone or because the 3G connection is not very good, but this behaviour is not acceptable for the software application that I design.
Thus, I am interested in the following:
is there any technology standard that can guarantee pushed message delivery to mobile (GPRS/3G) consumers in soft real-time? I.e. a technology standard which guarantees that a mobile client will be notified no later than N seconds from now;
do you know any examples of mobile apps which have soft real-time push notifications?
what are the ways to address the issue of delivering/pushing soft real-time messages to mobile devices in soft real-time? (e.g. keep sending the same message until the mobile device confirms the receipt of the message)
P.S. The intended use of the software application is with any smartphone, be it iPhone, Android, WP or any other internet-connected smartphone.
Note: This question is similar to one of my previous questions, but this one is about on a completely different use-case with strong focus on soft real-time requirements.
I know that this question is 3 years old but it doesn't have any answer.
A PUSH notification is always Best Effort. It means that the server will do it's best to deliver it but can not guarantee that it will be done on time or if it will be delivered at all.
Never rely on PUSH notifications to achieve a critical job.
Consider a web application such as Google Chat, where the servers serve hundreds of millions of clients simultaneously. In such application, the servers have to push notifications to clients at near real time (in the chat example - incoming messages, presence notification etc.).
How do they implement it? Significant part of the clients are browser based. I suppose polling would overload even Google's servers. So, are they using something like Comet? If so - do they need to allocate a server for every 65536 clients (maximum TCP connections per machine)? I understand that there is a way to circumstance this limitation but I don't know how it's implemented.
Chat is not handled by single application / hardware / instance.
They definitely using many instances with load balancing that allows to scale chat system horizontally. It might be dedicated for regions or just single clustered system (I believe it is dedicated within regions but still clustered within region).
As well you can have as many connections as hardware and network will handle but not 64k.
Because 64k (actually less then that) is regarding Binding sockets (server sockets, but not client ones).
In case with google and based on supported browsers, they definitely use mixed technologies to communicate selecting the most powerful based on browser support. That can be long-polling, sockets and even oldest one: simple ajax.
As well for example facebook chat is based on erlang. And using erlang there is many examples having more then million connections.
I don't know how Google handle this, ans they probably won't tell us. But, today you can deal with http streaming, websockets or long polling to build such application. To give you an example Atmosphere framework
is a tool to build "real-time", efficient and scalable web application.
I have to devise a push notification plan for some mobile devices where push is not yet officially supported by C2DM / APNS / BES ,etc. MQTT was also a good option but I could not get an MQTT Client for my required platform. (Blackberry Playbook, ActionScript only)
Going back to basics, I had the options of Long Polling and streaming. Streaming using a high keep-alive value seems good to me, as the development of the mobile app (it is not a browser) and the server code are both in my control. To maintain the connection open, I just need to ping the server occasionally.
What issues I may be facing in this approach ? I understand this would constantly open an HTTP connection from the device to the server. Would the battery life of mobile device drain quickly just by persistently opening a server connection ? ...Afterall the data is not being transferred, just by keeping the connection open...right ?
You might want to consider Urban Airship or take a look at this realtime technologies guide.
If realtime really matters, I'm talking about seconds or milliseconds, then a realtime web technology using WebSockets or HTTP Streaming is your best option as they deliver updates the instant they are available. This sort of thing is best suited to the sort of application that a user is actively using during a reasonable period of time where they need instant notifications or are collaborating/chatting with others.
WebSockets are probably a better standard to be using with longer term technology considerations in mind since they are the first standard for full duplex bi-directional communication between a client (mobile, web, desktop) and server.
What platform could you not find an MQTT client for? http://mqtt.org/software lists clients in just about every language I can think of and more than I'd like to bother using. The mosquitto C client library is very portable.
For battery life, it really depends what you're doing between the keepalives...
If you app runs in a country where the network isn't in the best shape, then having all your clients keep a connection open can put strain on their infrastructure (assuming you are that popular).
Battery life is the other consideration, yes, a lot of devices aren't that efficient in keeping an idle radio/3g connection open and it drains the battery a lot faster than not having a connection open.