0
votes

My client connects with the following parameters:

  1. Clean Session: False
  2. Client ID: Fixed (same every time)
  3. Subscribed with QoS=1
  4. Message Published with QoS=1

I am trying to verify that if the broker receives messages when the client is offline, the messages are queued on the broker and sent to client when it comes online again.

However, I find that the broker does not send anything to the client on reconnect.

This is how I tested: Connect client to broker using the four parameters mentioned above. Subscribe to topics of interest with QoS=1 Disconnect client

Using another client program and another client id, connect to the broker Publish message to the same topic that was subscribed to by the now offline client. Wait for a few seconds, now reconnect the offline client with the same connection settings as before.

Expected Result: As soon as connection is re-established the client will receive messages that were sent to its topic while it was offline.

Actual Result: Client gets no messages. It is able to receive any new messages that are sent AFTER it is connected, but no offline messages.**

I have verified using Wireshark that the SUBSCRIBE and message PUBLISH packets sent to the server have QoS=1 and clean session flag is false in CONNECT packet.

Broker: Mosquitto v1.4.11

MQTT Config File:

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log
log_type debug

listener 9001
protocol websockets

listener 1883
protocol mqtt

allow_anonymous false
acl_file /path/to/acl_file
password_file /path/to/password_file
1
are you resubscribing to the the topic when you reconnect?hardillb
I should not have to because the broker is supposed to remember my previous subscription since even the previous connection was started with cleanSession=false.Dojo
Anyway, I did try resubscribing as well. I got nothing.Dojo
Update the question with your mosquitto config filehardillb
Added the config in questionDojo

1 Answers

2
votes

It was a case of misbehaving GUI clients. Three of them!

I am posting it so that others don't waste time on something similar.

I tried three clients, all had different probelms as mentioned below:

MQTT.fx: The broker does deliver message immediately after connect but the topic has not been subscribed to in the current session so MQTT.fx does not have any designated place to show the received message. So it does not show the message on screen. MQTT.fx also complicates Wireshark debugging by subscribing to $SYS logs topic which floods Wireshark and the main message from broker is lost in the flood of packets.

MQTT Spy: Unlike MQTT.fx, it has a catch all tab, so if the broker sends a message that was not subscribed to in the current session, it will show it in the catch all tab. Unfortunately, the implementers of MQTT Spy have decided that their application will unsubscribe to all topics before disconnect. Since the client is no longer subscribed to the topic, the borker does not queue any messages for it.

MQTT Lens: It has a bug. It does not save the connection settings for Clean Session. Even if you set clean session to false, it always opens connection with clean session=true.


Finally, I wrote a test program with Paho Java library and found everything to be working as expected.

I wonder why there is not reference implementation GUI client for MQTT all the current implementations are either broken or so unnecessarily "smart" that they prevent you from testing a legitimate test case.