can someone to confirm that in order to use MQTT protocol, the APP on the smart device (Ios or Android) embedding MQTT client code, must be active? If so, how can i wake-up the App from my remote server to enable mqtt conversation? Maybe a push notification should alert the smartphone user to open the APP because some important messages are outstanding for him?
For Android the app can start a service that will run in the background and receive published messages all the time.
For IOS you will need to wake the application up to get it to connect to the broker, the usual approach to this is to use the Apple Push Notification Service to wake the app up.
The main thing is that the TCP socket (so the connection) between client and broker must be active so that broker can push messages to the client (as subscriber to some topics).
The only way to handle "disconnected" scenario from the client side is to connect to the broker with "clean session" at false. In this case, the broker will store all messages for that client if it's offline and then send them when it'll be online.
Paolo
Related
I was wondering how the actual request from Server get routed to the Application if the browser is not running. Also, does the service workers maintain an active connection to the server so that it receives the push notification whenever the server publishes something?
I think for every iOS device, Apple keeps a socket open between that device and the Apple Push Notification Service. Which essentially acts as a router for all notifications across all apps and all devices. So your server can send messages to APNS saying "yo, hit up this guy with this message", and APNS will use the socket it has open with every device to send the notification.
Also check out https://developer.apple.com/notifications/.
And https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server
I know that notifications can be pushed to servers using http/s but can mobile phones really be pushed to from those servers? Technically it is my guess that mobile devices actually poll the notifications servers to see if there are any new notifications and that this is a sort of 'pseudo push'.
So that's my question - do mobile phones truly receive live, pushed notifications or are they actually polling? The reason I ask is that it would seem to be incredibly expensive on the network for mobile phones to have a constantly open channel to masts as a user moves around. Anyone know what the technical detail is?
Apple Push Notifications are delivered to the device over a TCP connection. The iOS device initiates a TCP connection on port 5223 (with a fallback to 443 on WiFi if 5223 cannot be reached).
Once the TCP session is established very little traffic is required to keep the TCP connection alive - just an occasional keep-alive packet.
When a push notification is to be delivered, the Apple servers look for an existing connection to the device. If a connection is found then the data stream is sent over the already established connection, so in that sense it is a "push".
If there is no existing connection to the target device then the message is held on the Apple server until the device connects (or the message expires), so at this level it is more like a "pull" - with the device initiating the connection when it can.
I imagine GCM works in a similar way.
There is simply a TCP socket waiting in accept mode on a cloud Google server. The TCP connection had been initiated by the Goggle Play application. That's why Google Play must be installed on the device for making Google Cloud Messaging (GCM) (formerly Android Cloud to Device Messaging Service - C2DM) work.
When this TCP client socket receives some message, the message contains information such as the package name of the application it should be addressed to, and of course - the data itself. This data is parsed and packed into an intent that is broadcast and eventually received by the application.
The TCP socket stays open even when the device's radio state turns into "idle" mode. Applications don't have to be running to receive the intents.
More information at http://developer.android.com/google/gcm/gcm.html
I'm working on app the share tasks between users. By Google Cloud Messaging, I can notify the user target that he has a new task shared. The problem is : GCM does not offer a delivery guarantee. Would someone use an app like WhatsApp if he took minutes to deliver a message or not come to hand? That's my problem with GCM.
So I've got a solution : Use Socket!!!
Using Socket.oi and Node.js, my dream came become really works like magic !!!
But as nothing is free, keep a socket connection has a very high cost for the battery. Some people argue that the use of Sockets when there is no communication, nothing in or out, no cycles, so there is no consumption.
My friends, I've read a lot of text and do not know what approach should I follow. I ask your help. Soket.oi? WebSocket ???
How to maintain a connection to my server permante preserving the most of the battery?
I appreciate everyone's help!
You need to use mix of a socket connection and GCM. Both connection types do no guarantee delivery so you need to implement mechanism which checks consistency of messages history.
Simplified scenario could look like this:
a user launches your client
the client app registers at GCM and sends google id to your server.
the client app establishes socket connection
your server sends messages to a client through GCM and socket connection (if it is establish with particular connection)
each message has unique id, therefore the client could just ignore second identical message from Google of a socket connection
About not delivered messages:
When client connects to the server through socket connection it should receive response where history of messages should be put. It shouldn't be full history, it could be just last message (in case you develop chat app). Then a client just checks if he has notified user about last message or not. If not then your client makes request(http or through socket) to your server and receives undelivered messages.
Battery consumption:
Do not acquire wake lock to maintain socket connection! A device must go sleep. GCM will wake up handset.
Socket.io is good, and certainly useful in many real-time applications, but what happens when the app is terminated by the user? Or if the user restarts their phone? How would you receive notifications then?
For all purposes, GCM is good enough.
I've been digging into android push notifications recently. I guess, I understood the overall architecture and message flow.
I imagine it like this:
[Own server] --> [GCM] --> [Device] --> [Application]
The only mysterious part of the route is between [GCM] and [Device].
Long story short, what infrastructure is used to deliver message from [GCM] to [Device]?
I've read somewhere a bit, that probably, device keeps an opened connection to the GCM. If this is the case, what kind of connection is open?
About the CGM there are a lot of informations on the Android Developers center.
The device keeps a connection open to the CGM (I think IP). If there is no connection between the server and the device, the CGM will store the incoming messages to deliver them later.
The iOS push technology keeps an IP connection open between the APNS (Apple Push Notification Service) and the device (cf: wiki). So it could be sensibly the same thing as the GCM.
I'm currently in the process of developing an app which has some very demanding needs.
The Project
An application which can communicate with a server is needed.
Small messages has to be send to the app which could display a notification or start an activity.
The Demands
Client needs to be sure that the phone is 'connected' at all times.
The client expects that the app can tell when it's no longer connected (or able to connect) to the server it tells the user.
Client needs to be able to send a message to individual devices
If the client needs to broadcast a message to the connected devices and to the individual devices.
My thougts (or problems)
Currently, the app is polling the server with a http request once a minute - if the app isn't able to connect to the server the user gets notified. The polling is able to tell which device is calling and telling it if it has a message for it.
But...
IMO this is a terrible design - it generates a lot of excess traffic, uses resources which probably wasn't necessary and it offers a lot of issues with connectivity (which I'm not sure I'll ever get past no matter which method is used).
I need your experience to select the right solution for my project.
I've been thinking of C2DM, but I'm not sure this could cover my needs?
Is polling for my only real solution?
Is there a third option I haven't thought about?
I stumbled upon a new service called Parse.com they seem to offer functionality for easy push-implementation for Android using their backend. It's commercial but they have a free plan too.
If you want to do your own implementation there seems to be a lot of articles about using MQTT which is designed for low-power devices. But I haven't seen any ready-to-use implementations of this yet.
I'd consider MQTT as a good solution, although it is what I'm most familiar with. Disclaimer - I write an Open Source MQTT broker. You could achieve what I think you want like this:
Have an MQTT broker running somewhere. The service on the phone connects to the broker and subscribe to a unique topic, e.g. device/23412364, where 23412364 is the per device unique id and referred to as <phone id> below. When your client wants to send a message to a specific phone, the message goes to device/<phone id>. If you want messages to go to all phones, then the phones could also subscribe to device/all for example.
If you make your subscriptions and messages have Quality of Service of 1 or 2 and set the "clean session" option for the clients to false, then messages will be queued up on the broker if the phone disconnects for whatever reason. QoS=1 means "at least once" and QoS=2 means "exactly once". When the phone reconnects, those messages will be delivered.
You could also have the phone send a message like "register <phone id>" to a fixed topic just after it connected (topic of "register" for example). A feature of MQTT that is very useful is the "Last Will and Testament". When you connect a client, you have the option of specifying a Will message and the topic that it should be delivered on, in the case that the client disconnects unexpectedly (ie. without telling the broker that it is going to disconnect). So you could set the will message to be "unregister <phone id>" and to be delivered to the same fixed topic as above ("register" in this example). You could then have another MQTT client at the server end sitting subscribed to "register". When a phone connects, it sends a "register <phone id>" message, when it gets disconnected the broker sends "unregister <phone id>". The MQTT client can therefore keep track of the connected clients at the server side.
At the phone end of things, you can get notified if the TCP connection goes down through normal network code.
Some relevant links:
Using MQTT in Android mobile applications: http://dalelane.co.uk/blog/?p=1599
Trivial MQTT Android project based on above: http://mosquitto.org/2011/11/android-mqtt-example-project/
MQTT Power Profiling: http://stephendnicholas.com/archives/219
MQTT features: http://mosquitto.org/man/mqtt-7.html
Facebook using MQTT: http://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920