I've been reading about MQTT and I understand it uses TCP for network transport. So if I have a mobile app that will send subscribe request, I presume this will be an full-duplex connection so the client can be notified for incoming pushed data.
How then is this more battery and network efficient? I mean you still established an open TCP connection. Also how does it handle disconnection, does it auto-reconnect to the broker?
Taking into account my comment on the question, assuming you want to compare to HTTP Long polling these 2 links may help to answer your question:
https://www.ibm.com/developerworks/community/blogs/sowhatfordevs/entry/using_mqtt_protocol_advantages_over_http_in_mobile_application_development5?lang=en
http://stephendnicholas.com/archives/1217
TL;DR version:
The message sizes tend to be significantly smaller with MQTT vs HTTP (especially when you take into account all the http headers that get sent), this saves on network usage and in turn battery usage.
As for the reconnect side of things, the client libraries do not automatically reconnect but they do trigger a call back when the connection drops so you can handle reconnecting as required.
Related
I was under the impression that in NB IoT world, if the client device enters PSM mode, it can actually retain both the IOT network registration and also the TCP IP connection session. so when it wake up from PSM, it can quickly send data and go back to sleep again. but in my case, it imitates disconnection of the PDP session before it enter PSM. Is this normal ??
Currently I am using a dev client system based on Qualcomm 9205 modem connect to LTE Cat-M1 network.
the client will wake up every 10min to send a small chunk of data (100byte) to the AWS IOT service, it uses MQTT as the messaging protocol .
ideally I prefer the device to initiate the MQTT connection with the server once, then after it goes to PSM sleep, the client side remembers the MQTT connection, so when it wake up, it can just send the data via MQTT without re-establish the MQTT connection again.
Unfortunately, I realise the real behaviour is: when I ask the modem to go to PSM sleep, it will drop the PDP connection (which means the TCP/IP session is lost, so does MQTT ), so when it wake up, it will take extra 5-10 seconds also to re-establish MQTT connection again before sending data. this is a waste of both time and additional data communication.
Any suggestions?
I am using esp32 mqtt client library. In this, whenever a valid mqtt message is received with QoS1, mqtt_client library sends a Puback message automatically without waiting for application layer to authenticate the payload. There are two ways to overcome this situation -
Holding Puback message untill application layer process it
Opening a new topic between client and broker to implement application level authentication mechanism?
Could you guys please suggest the best approach ?
This is the right behavior because the ack is at protocol level. Holding PUBACK, if the MQTT library you are using allows doing that is not the right thing to do imho because you break somehow the contract at protocol level and if the application spends too much time processing the message without sending the PUBACK, the broker will resend the message not receiving the PUBACK on time.
Imho the best solution is relying on a different topic on which the client publish an "ack at application level".
Puback ack packet is being sent without validation from Application level because that's how it is supposed to work. Quality of Service (QoS) factor in MQTT doesn't mean that ack packet is sent when data content in packet is validated. It is meant to acknowledge the reception. That's all.
For what you are trying to do, you need to implement an application level protocol to serve or discard the packets after validating the data (and then notify the sender with another packet).
I've searched the web extensively but haven't found a good answer to this.
Im writing a socket based application in C++ using posix sockets on iOS/Android.
When switching from wifi->3g, SOMETIMES the socket goes dead without giving any errors when reading/writing.
I can use the reachability API on iOS (and similar on android) to detect when the network switches.
I am destroying/recreating the socket when this occurs. The problem is if the socket is alive, the server will receive the signal when I close the socket. If the server receives the close signal, it will assume the client disconnected intentionally and notify others about this, which is not what I want. If the socket is dead, the server doesn't receive this signal and everything is OK.
How do other people handle this scenario? I really don't want to use a timeout to detect this.
Why does it only sometimes die too? And how can I tell the socket is actually dead?
Just to close this issue, this is the approach I'm taking.
When switching networks, I'm sending a ping-and-reconnect packet to the server, AND creating a new socket.
Which ever responds first, I close the other connection.
Required a bit of server side changes to handle this correctly too
If I want to make sure that a device receives a message, over the network, for an app used by sellers in a shop for example.
I heard push notifications are not 100% reliable, sometimes some of the notifications don't arrive, or not on time.
The app could be in a shop, where the staff communicate with one another, and there could be 10 devices connected. (ipad, iphones)
edit 1: I heard about sockets, is it the right direction to go?
EDIT 2:
I am not sure why a socket should be used, rather than a webserver for example, I found these 2 sentences (source raywenderlich) :
You can send connected clients data whenever you want, rather than requiring the clients to poll.
You can write socket servers without a dependency of a web server, and can write in the language of your choice : don't understand what the "dependency" is?
Does it also mean :
Sockets let 2 (or more) specific devices to connect one another in a private connection, compared to webservers where everybody could connect if there is no login/password?
EDIT 3 : Maybe a bluetooth solution with MultiPeerConnectivity would be better...
Sockets, and push notifications in general, are only as reliable as the network the user is connected to. If your looking to circumvent network reliability where a 100% success rate is guaranteed, in a Shop environment where users are in close proximity, you can look into GKSession as part of the GameKit.framework
Or you could look into Bonjour or client/service discovery protocols that makes the process of "knowing" peers in a network
I see you tagged Parse.com, again, the reliability of Push Notifications is highly dependent on the reachability, however, most issues that arise with Parse is dev-end related, not product related.
EDIT I forgot to mention MultiPeerConnectivity
If you use TCP sockets, you are guaranteed the message will be delivered, and very quickly too.
However, the application would have to be open (and most likely in the foreground) to receive the messages. You can always have the server wait till the client connects to send the message.
I would suggest using a combination of both TCP sockets and push notifications (for when the app is closed).
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"