i have developed mqtt service on android device, the service work fine, reach notify, and in WIFI the battery is not drained, but when i pass on 3g network the service drain more battery over 40% in wifi is arround 3% the battery drains,
on low profile phones the problem not appear the service in 3g network drains arround 10% of battery, i have see it drain more battery on 4.4.2 Andorid version.. can help me?
p.s. i use paho client!
The MQTT client needs to send a keep-alive message every so often to maintain the connection channel and also to let the server know it’s still connected. Maybe the connection option "keepalive" is too short and it's draining the battery.
Try other keepalive settings and change publish, and subscribe message to QoS0. QoS1 and QoS2 get more traffic.
More details: http://stephendnicholas.com/archives/219
Related
I am using MQTT broker configured on a host machine with Windows 2012 server OS and a few embedded devices are subscribed to broker to receive commands.
I wanted to understand , does MQTT broker send any disconnect message to all its subscribed clients when the broker service on host machine stops because of any reason like the host machine is rebooted or shutdown. The reason I ask this question is below.
On my device, all the code (including mqtt client library)stops executing when device goes to sleep, and execution does not resume until device is woken up (by receiving data packet on WiFi channel or by a few other actions).
Now when I reboot the host machine, I am observing that my devices are waking up from sleep and are trying to reconnect to broker until MQTT broker is coming back. I think the devices are waking up only because they are receiving some data over WiFi channel because I am not taking any other action which could wake up the device.
So I am wondering what is that WiFi data packet that is waking up the device and causing the device to reconnect. Is it probably a disconnect command sent by Broker to the device?
No, the broker will not send any messages on shutdown. The MQTT Disconnect Message is only sent from the client to broker according to the spec.
I suggest you install some network monitoring software (e.g. Wireshark) to track what network activity is happening.
I am setting up an MQTT/Websockets server, my client is an flutter app, which connects to the broker on main screen, and in other screens it sends and receive messages from the broker. My understanding of keepAlive is how often the client and server should share ping/pong, so they make sure the connection is still alive. being said, if my flutter app, connects to the broker in main screen, of 3600/1 hour keepAlive, and suppose to share and receive messages on other screens, if i disconnect the client from the internet for 2 minutes, and reconnect after that, it will not send/receive messages, maybe my understanding of keepAlive is not correct. Well, How would i structure my app/server to reconnect automatically to the internet as soon as internet connection is back and up again.
I have also tried On.Disconnect method, which i noticed it will never get called, and the app even though still thinks its connected to the broker.
I mentioned websockets, on the tags as i could do mqtt over websockets.
I see that no-one else has responded, so I'll try (however I'm new to this also).
Also, have you looked at the Flutter connectivity package?
From my reading of the Mqtt specification, it seems the Mqtt client ** should** disconnect the TCP/IP connection if it doesn't receive a PINGRESP to its PINGREQ in the keep alive period (ie it's not required to disconnect).
My Flutter + Mqtt app checks the connection state, and reconnects if needed, every time it sends a message. I haven't needed to check for internet dropouts, but I have noticed the connection is lost on some application state changes. The main app widget. is notified of these using didChangeAppLifecycleState() and sends a dummy message if needed.
So this doesn't answer exactly what you asked, but I hope it's useful anyway.
I wan to make a chat app with AutobahnAndroid. My problem is that after opening a websocket connection, wifi icon in top left corner of mobile is in transferring data. Is there a way to solve this problem? For example when a new message received it show transfer icon and when there is no message it does not use network like Telegram?
WebSocket connections are persistent. They do not actually use networking resources when there are no messages being sent, but there is still an open socket. Maybe this triggers the transmission icon. And as pietro909 stated in one of the comments, to prevent the system or intermediaries from closing the connection, you may be sending keep alive pings.
In the end, you can't have both: A push channel from the server and network activity only when there are messages.
I have a regular cloud server set up, I have a mobile app talking to the server via HTTP requests. I also have a Wifi device that I need to send messages and I want to do that over MQTT. When some change happens on the mobile app, I want the cloud server to publish a topic via MQTT so that the wifi device can receive the message. Can a broker also be a client? Am I understanding it wrong?
I'm going to attempt an answer based on my understanding; sorry if I misunderstood your question.
The way I understand it, you will have three/four pieces of software:
HTTP Server / MQTT Broker (these two services could run in the
same application or in separate ones)
Mobile application (communicates over HTTP)
Wifi Device (communicates using MQTT protocol)
Scenario:
The Wifi device will open a connection to the MQTT Broker and subscribe to a well defined topic. You can use a subscription with a QoS of 1 if you cannot afford to lose the messages. Any messages published prior to adding the subscription will not be received by your client. It might also be useful to open an MQTT connection using a non-clean session if your wifi connection is unstable (again, if you don't want to lose any messages).
After a specific event, the mobile application which communicates with the HTTP server will send it information.
Upon reception of the information, the HTTP server will then send an MQTT message to the MQTT Broker on the predefined topic (a topic that will match the Wifi Device's subscription).
The MQTT broker will relay the message from the HTTP Server to the Wifi Device (and any other MQTT clients with a matching subscription).
I hope this clarifies, let me know if anything is unclear.
"Can a broker also be a client?" Not really, although I'm certain some specific brokers will publish messages to special subscriptions based on special events, it only acts as a broker. It receives messages from publishers and forwards messages to any client who has shown interest in that message using a subscription (the message could potentially be dropped by the broker if no subscriber (client) is interested in that message).
I have a client/server setup in which clients send a single request message to the server and gets a bunch of data messages back.
The server is implemented using a ROUTER socket and the clients using a DEALER. The communication is asynchronous.
The clients are typically iPads/iPhones and they connect over wifi so the connection is not 100% reliable.
The issue I’m concern about is if the client connects to the server and sends a request for data but before the response messages are delivered back the communication goes down (e.g. out of wifi coverage).
In this case the messages will be queued up on the server side waiting for the client to reconnect. That is fine for a short time but eventually I would like to drop the messages and the connection to release resources.
By checking activity/timeouts it would be possible in the server and the client applications to identify that the connection is gone. The client can shutdown the socket and in this way free resources but how can it be done in the server?
Per the ZMQ FAQ:
How can I flush all messages that are in the ZeroMQ socket queue?
There is no explicit command for flushing a specific message or all messages from the message queue. You may set ZMQ_LINGER to 0 and close the socket to discard any unsent messages.
Per this mailing list discussion from 2013:
There is no option to drop old messages [from an outgoing message queue].
Your best bet is to implement heartbeating and, when one client stops responding without explicitly disconnecting, restart your ROUTER socket. Messy, I know, this is really something that should have a companion option to HWM. Pieter Hintjens is clearly on board (he created ZMQ) - but that was from 2011, so it looks like nothing ever came of it.
This is a bit late but setting tcp keepalive to a reasonable value will cause dead sockets to close after the timeouts have expired.
Heartbeating is necessary for either side to determine the other side is still responding.
The only thing I'm not sure about is how to go about heartbeating many thousands of clients without spending all available cpu just on dealing with the heartbeats.