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.
Related
problem is that im not receiving messages from mqtt client running on a device.
i have a hardware device. on this device there is a mqtt client.
what i did:
i connected this device with laptop running mqtt broker mosquito and jmeter with mqtt plugin as client listening on 1883 port.
i tried: i have added rules in windows firewall for inbound and outbound opened port 1883.
now if i check in wireshark on laptop i see device sending messages to connect broker. from ipadress of device connect messages sent to ipadress of laptop at port 1883. it was expected that broker will send messages back to device but as no messages received by broker so no messages sent from broker to device.
neither i get messages in jmeter subscriber.
i tried: i installed mqtt client "mqttlens" locally on laptop. connection tested with broker and it works. so broker is ok.
can someone help
I have started exploring MQ series and I noticed Sender channel in RETRYING status after SHORTRTR are exhausted. I have also noticed client applications couldn't connect to MQ when Sender channel was in RETRYING status.
Is my understanding correct that client applications can't connect to MQ if Sender channel is in RETRYING status?
What happens client start connection with MQ and Sender channel is not RUNNING?
Does Sender channel status matter when client is initializing MQ connection?
The ability for a client application to connect is almost entirely unrelated to the state of a sender channel. (I say almost because theoretically you could use up all the resources in your queue manager by having loads of retrying senders and then maybe they could affect clients).
When a client application makes a connection to a queue manager, the network connection is first caught by the listener, and then a running channel of type SVRCONN is started. This is a different type from a SENDER channel, and so there is no requirement to have a SENDER channel running for the client connection to be successful.
Sender channel status does not matter for the client to be able to connect.
Lets' try to diagnose your two problems. Look in the queue manager AMQERR01.LOG (found in the data directory under \Qmgrs\<qm-name>\errors) and edit your question to add the errors you see in there. There should be errors that explain why the sender channel is retrying, and some to explain why the client cannot connect.
It is possible that the problem with the client not being able to connect is because it is not even reaching the queue manager machine - in which case there will be nothing about that in the queue manager error log. In this case, you should also look in the AMQERR01.LOG on the client machine, this time in the data directory just under the errors folder (as no queue manager name there). You should also have seen some sort of error message or MQRC Reason code from the client application - you should tell us that too.
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).
We are using tomcat websocket implementation in our web application. Messages are pushed from server to client through websockets. Web socket messages are not pushed when intermittant connection drop or network is switch over but still web application is connected.
Let say for example i am connected to LAN and logged in app, now i connecting through wifi after wifi successfully connected i am disconnecting LAN with in fraction of second network is switched from LAN to wifi But after this messages are not pushed from server to client through websockets.
After network switch if i check the state of the websocket(readyState) which says 1 which means websocket connection is open but actually its not.
Can anyone faced this issue earlier and provide your suggestions.
Thanks
You must create a connection drop detection mechanism. The WebSocket protocol has ping/pong frames, but I don't know if Tomcat has that functionality. In some Webscoket frameworks you can define a timeout interval, and the server will ping the client regularly, if the client miss some pongs is disconnected.
If that functionality is not provided by Tomcat, you can still create your own. Just define a special type of message and repeat it to the server from the client. If you do not get any of those messages for a while, disconnect.
I have observed the following behavior in Firefox 4 and Chrome 7:
If the server running the websocket daemon crashes, reboots, loses network connectivity, etc then the 'onclose' or 'onerror' events are not fired on the client-side. I would expect one of those events to be fired when the connection is broken for any reason.
If however the daemon is shutdown cleanly first, then the 'onclose' event is fired (as expected).
Why do the clients perceive the websocket connection as open when the daemon is not shutdown properly?
I want to rely on the expected behavior to inform the user that the server has become unavailable or that the client's internet connection has suffered a disruption.
TCP is like that. The most recent WebSockets standard draft (v76) has a clean shutdown message mechanism. But without that (or if it doesn't have a chance to be sent) you are relying on normal TCP socket cleanup which make take several minutes (or hours).
I would suggest adding some sort of signal handler/exit trap to the server so that when the server is killed/shutdown, a clean shutdown message is sent to all connected clients.
You could also add a heartbeat mechanism (ala TCP keep alive) to your application to detect when the other side goes away.