As for clarification, this question is not duplicated since the
situation differs from other related questions.
We are working on an client side application which will receive data from a server side PHP-powered web application. Data are critical and must be delivered to user as soon as possible. It doesn't matter if client request for data from server or server push data to client, the only thing we need is a reliable and fast option.
There are several methods but non of them fit our project:
Use GCM push notification ability:
This is a great option but in practice, we lost several pushes so it's not reliable and in other hand, delay is so much. I repeat, the situation is critical so it must be fast.
Request data from server by the client with a 1 or 2 second interval:
This is what we think is the best solution so far but is really expensive. It's reliable and fast. But in other hand, the pressure on our disturbed servers get extremely high and they become useless even with our current client numbers. If the number of clients get larger, we'll be down.
SMS based push:
The other option for us is to send SMS to client phones and use that data to operate application. Using this method, the pressure on our server will get really low (just like GCM option). But sending SMS in our countries mobile network is usually delayed, normally, 10 seconds. Although this option have good reliability but the speed so low that we can't use it.
FM radio signal based push:
We can use clients FM radio receiver to get data from local broadcasting stations. This method is reliable and very fast but the cost of stations will kill us! and even if we handle it (read: we can't), clients does not connect their earphone to the smartphones always.
So, what are the alternatives? what is a reliable and almost fast method which does not make a lot of pressure on our servers?
Would probably recommend using WebSockets for case you describe (using OkHttp library for example) - see following for nice overview of it's use https://medium.com/#ssaurel/learn-to-use-websockets-on-android-with-okhttp-ba5f00aea988. A common pattern would be use of WebSockets with Http REST requests (for an initial catch up query for example). Also you would typically only use WebSockets while app was in foreground and rely on push notifications otherwise.
Related
Let's say have an app that has 10s of millions of installs and 10s of thousands of active users at a given point of time. I need to log my users' activity data to my servers. Currently, I make HTTP requests from the device to my servers. I have a bunch of machines running a web server, sitting behind amazon's ELB. They parse the data coming from the devices and put it in mongodb.
Now, I would like to capture device data by using upstream CCS provided by Google' GCM (so that I can piggyback on GCM for more reliable delivery of data) I have written a prototype XMPP server and I can make whole thing work, but I am worried about scaling it up. What will happen if Google starts sending me messages at a rate faster than I can consume? Earlier, I was able to use multiple servers behind load balancer to tackle high request rate. Is there a concept of load balancing here?
If I open multiple connections from my server to Google's server (Google says I can have till 1000 connections for a given sender id), will the incoming requests be load balanced between these connections?
Finally, is there recommended solution which takes care of solving most of the problems above? Will using ejabberd solve some of the problems above?
Thanks a bunch.
What will happen if Google starts sending me messages at a rate faster than I can consume?
At the end https://developers.google.com/cloud-messaging/ccs you may read
Conversely, to avoid overloading the app server, CCS stops sending if there are too many unacknowledged messages. Therefore, the app server should "ACK" upstream messages, received from the client application via CCS, as soon as possible to maintain a constant flow of incoming messages. The aforementioned pending message limit doesn't apply to these ACKs. Even if the pending message count reaches 100, the app server should continue sending ACKs for messages received from CCS to avoid blocking delivery of new upstream messages.
In the same document, you find partial answer to your second and third questions
If at any point the connection fails, you should immediately reconnect. There is no need to back off after a disconnect that happens after authentication.
For me it means, that Google implemented a simple redundancy logic and probably not a fair load balancing system (anyway I hope so). If you have that high volumes, I suggest you to contact them directly.
For the last ones, ejabberd is a good product, there are a lot of deployed systems with a clustered infrastructure and a plenty of documents on how do taht. I suggest you to start from here http://docs.ejabberd.im/admin/guide/clustering/ .
Anyway, for your high volumes I would evaluate RabbitMQ which is another Erlang jewel.
ejabberd can be clustered and placed behind a load balancer to distribute connections. A 3 or 4 server cluster should be able to handle that load fine and give you fail over protection. You can add servers if needed. Once you get close to 10 servers you may want to consider using Redis for the in memory DB rather than mnesia.
I know, it's so. But I don't understand, why?
Why not simply send queries to server periodically? Sure, it may discharge battery and increase internet traffic. I understand it. But how usage of Google Cloud Messaging can eliminate this problems?
I have found an answer. But it isn't pretty clear for me.
Can anyone give me a clear explanation?
Let's say you have 50 applications on your phone that do not use GCM. Each app developer decides it is appropriate to poll their respective backend once a minute.
Since these are all separate applications, each call will likely not happen at the same time as another api call. The biggest kill to battery is when the radio within an android device has to turn back on after being off to make an API call, so multiple calls happening with blocks of time in between drains battery faster (read this article on the radio state machine to better understand why this is https://developer.android.com/training/efficient-downloads/efficient-network-access.html)
In addition, each application will be hitting a separate endpoint. Each time you make an API call, you have to go through the connect process for a given server. With batched api requests or HTTP 2.0, multiple calls going to the same server can be optimized by not having to re-do a handshake or the connect process.
Now imagine, all 50 applications used GCM. GCM will poll an endpoint at some regular time interval on behalf of all 50 apps. Let's say GCM polls once a minute to a server that all the respective apps' backends send their notifications to to send to a device. You have reduced 50 different oddly timed API calls that are likely turning on and off the battery to one api call. You will use less data for polling. You do not incur the cost of the connect step of an HTTP call to 50 different servers. In addition, google is using the same polling already in place checking for OS updates, so there is no additional network overhead from using GCM (this info is based on old docs What technology does GCM (Google Cloud Messaging) use?)
Also, see this explanation straight from the Android website in an article entitled "Minimizing the Effects of Regular Updates" (http://developer.android.com/training/efficient-downloads/regular_updates.html):
Every time your app polls your server to check if an update is required, you activate the wireless radio, drawing power unnecessarily, for up to 20 seconds on a typical 3G connection.
Google Cloud Messaging for Android (GCM) is a lightweight mechanism used to transmit data from a server to a particular app instance. Using GCM, your server can notify your app running on a particular device that there is new data available for it.
Compared to polling, where your app must regularly ping the server to query for new data, this event-driven model allows your app to create a new connection only when it knows there is data to download.
The result is a reduction in unnecessary connections, and a reduced latency for updated data within your application.
GCM is implemented using a persistent TCP/IP connection. While it's possible to implement your own push service, it's best practice to use GCM. This minimizes the number of persistent connections and allows the platform to optimize bandwidth and minimize the associated impact on battery life.
I'm trying to make a mobile application and I found ionic framework which seems cool.
It seems that REST is a common way to do things and I don't understand one thing with this protocol. How does the server notify that he has data to send. If we have a text application, how does the server notify the application (without push notification, or maybe they're mandatory ?) that another client sent you a message ?
It seems like REST is only good for the requests coming from the client. Does it means that I have to send request for update every X milliseconds to have a responsive application ? Do I have to use websockets for such purpose ? I also saw Comet, is it a good way to use rest ?
The REST architecture doesn't really address "Publication/Subscription" (pub/sub) paradigms. It's much more coarse than that.
The major issues with pub/sub are technical, especially today. In a fully connected internet where everything is online at known locations all the time, then the basic REST architecture just works. Simply, the roles of Client and Server swap back and forth (i.e. the Server becomes a Client when it needs to send an notification).
But that's not the real world.
The real world is while we have a lot of connected devices, we do not have a lot of known locations. Your phone moves around all the time, and who knows what IP address it's at at any one time. DNS doesn't help because your phone is likely not registered under any particular known name. Then there's infrastructure issues where the vast majority of clients are locked away to where they can send messages, but can not receive them, even if we did know who and where they were.
So, REST doesn't explore that area simply because it typically violates a few key attributes.
One is that the URL goes away. Since we don't know where or who you are, we can't get to you by name. So, one way folks get around it is through long lived connections. Your client hooks up to the server and retains its connection so that the server can talk back. But this is an implicitly stateful connection. REST drives towards statelessness, and is effectively connectionless at the architecture level.
So, in that environment, REST is not an appropriate architecture, since the mechanics can not support some of the fundamental precepts.
We have implemented rabbitmq chat in android. but java client of rabbitmq is power hungry.is rabbitmq good for android chat?. we have used direct exchange individual queue for persons and individual routing keys. what is the best design pattern for one to one chat in rabbitmq.
and also ways to reduce battery usage
I don't think that use RabbitMQ directly for developing a chat is the better solution.
There are other solution more light please read this post about MQTT.
Another standard solution is use XMPP protocol (for example whatsup uses a custom XMPP).
We made some test and we also had some problem about battery consuming.
BTW, you can mix the technologies, mixing RabbitMQ as back-end and some other server (XMPP,MQTT) as front-end.
Read this post about the MQTT.
MQTT used by Facebook Messenger
EDIT
I would add this post MQTT vs. XMPP Which Should I Choose?
EDIT2
Please read also this and this on the official rabbitmq-group
Maybe you could combine RabbitMQ with GCM to save power as GCM gets triggered by the system and doesn´t need to keep any extra connection alive.
For example:
The app gets notified via GCM when any new event comes in.
Then a new Rabbit connection gets established, retrieving the data and timeouting after a short while again, if no messages are coming in again.
So the actual "hungryness" exists only for a short moment and only when neccessary.
You can also analyze which users are tending to always write multiple messages close behind one other and vary the timeout based on that value
I think chat applications for real time delivery is sending messages over network instantly rather than reliability. Reliability means confirm receiving against delivery. But in real time chat application does not make sure it. RabbitMQ is a message broker server and it is dedicated for reliability first, but it is not responsible for real time message communication. You may use RabbitMQ for real time communication but sometimes may not be in real time.
You can use STOMP-WebSocket(For simple messaging), Firebase(easy development for instant messaging), but most professional and usable protocol is XMPP(Extensible Messaging and Presence Protocol) for real time communication.
If you have any suggestion or query against this answer, let me comment bellow.
What's the best way to send constantly updating data from a server (over a REST API or a socket) to an iOS or Android app? Should I create a socket connection and have a socket server that pumps out data, or should I have the app periodically poll a backend resource? Thanks!
Should I create a socket connection and have a socket server that
pumps out data
This is an option. I know some top apps on the play store that use web sockets for streaming data.
Have the app periodically poll a backend resource
I would recommend against this. Polling drains the battery. The android OS will keep the CPU in idle mode at times and constant polling can wake the CPU up and cause a drain in battery. Users wont like that. You are also wasting processing power when there are no results from the server.
The easiest way to send push notifications / minor updates to the android phone is via GCM. The GCM messages are delivered in near real-time (I noticed a lag of about a second for my apps). The payload is limited to 4k and the messages are stored for up to 4 weeks. This is another option you can consider based on your use case.
The typical model I follow is to hit the server on a specified interval and download the updated data.
Polling is bad, it drains out the battery
If you want to update the screen when the application is in the foreground, it is better to go with Socket Connection. You can see the changes in realtime.
For this, you need to create a socket server and open a connection between the device and the server.
https://www.raywenderlich.com/3437391-real-time-communication-with-streams-tutorial-for-ios
I would suggest to use MQTT protocol to publish and subscribe data. Libraries for iOS(Moscapsule) and Android(Paho) for integrating MQTT protocol are available and can easily be integrated in mobile apps.
Backend needs to be configured to support MQTT also. Detail information about how MQTT works can be found here.
I am going to paste my accepted answer from a similar question that was posted a few hours ago.
It can be done using sockets or polling the server but I wouldn't recommend either for a production level app. You will eventually need security features and as a frontend developer, it would be difficult to start from scratch.
I would suggest using a third party service. Take a look at Space Cloud. It is an open source alternative to Firebase where you can use your own database and has built in security features. If you want to go deeper, it uses Apache Kafka for realtime database features.
If those don't suit you then the best option would be to go with GCM.
should I have the app periodically poll a backend resource?
this must be the last option to put in consideration. as long as the client number increases you need to scale out backend/server and this is not as simple as putting an another server next to existing one.
the perfect solution will be a push oriented design and best approach will be to register clients to events and server will push clients if that specific events occur.
you need to be more specific about your business case. you had mentioned real-time in your question but what kind of real-time is that. is it a video streaming, chat application or just ordinary rest calls?
Typically, you'll want your server to push updates to the clients because polling is expensive, may not scale well with N number of clients, and will drain your phone batteries faster. Depending on your server technology:
.NET/Core:
May want to take a look at SignalR to push notifications from the backend to your client apps.
Java:
May want to take a look at Atmosphere to push notifications from the backend to your client apps.
I have used SignalR with good results publishing to phone clients. Have not used Atmosphere, but it has good reviews.