halfgaar
commented
4 months ago There is a lot to unpack here.
First, I see you connect with MQTT3. I'll already note these difference from the spec:
- MQTT3: a Will Message MUST be stored on the Server and associated with the Network Connection.
- MQTT5: If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session
FlashMQ currently does not properly distinguish, and uses MQTT3 logic. This was recently discovered and still needs to be fixed.
Then, you publish with 'retain' on. This can muddle the waters, because the message will stick once published. This is probably the reason you see instant output on your first FlashMQ example. Can you be sure you start with an absolutely clean slate and no saved state? And did you actually intend to set a retained message? Note, this does not mean 'retain the will'. It means 'set a general retained message on this topic once the will is published'.
Then, you publish with a conflicting client id. So in your first example, publishing with mosquitto_pub kill kick out the existing mosquitto_sub. FlashMQ will send a will in that case. The effect of this is very subtle. You will see it instantly on a 3rd client, because it's published. But, your first mosquitto_sub will see it once it reconnects and resubscribes to the topic, because subscribing to a topic that has a retained value set, will get you the message.
Can you tell me if getting the 'crashed' message on your first client is about half of a second after you run the mosquitto_pub command, or is it instant? In my tests, it's half a second, and that means you're seeing the message as a retained value, as part of the reconnection + subscription as a result of being kicked out.
The specs differ in what to do in cases of conflicting client ID:
- MQTT3: unclear: "If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client". It says nothing of wills.
- MQTT5: If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in section 4.13 and MUST close the Network Connection of the existing Client [MQTT-3.1.4-3]. If the existing Client has a Will Message, that Will Message is published as described in section 3.1.2.5
I think the MQTT3 behavior is actually correct, provided that they intended the will to be sent on kicking out a client with existing ID. The other confusion is probably caused by the 'retain' flag on your will messages.
Head
I think LWT is not working as it should in FlashMQ. I had some alerts in my uptime monitor that are not working after I changed my Server to FlashMQ.
I try to compare Mosquitto and FlashMQ with two shell windows. First I connect to my Mosquitto Server: On the 1st I do:
mosquitto_sub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -v -h localhost --disable-clean-sessionno output yet. 👍On the 2nd I do:
mosquitto_pub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -m online -h localhost -r --disable-clean-sessionnow the 1st outputs:foobar_topic online👍I only get the
crashedLWT once Ikill -9themosquitto_subprocess.Now I try my FlashMQ Server: On the 1st I do:
mosquitto_sub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -v -h localhost --disable-clean-sessioninstant outputfoobar_topic crashed👎On the 2nd I do:
mosquitto_pub --will-topic foobar_topic --will-payload crashed --will-retain -i foobar -t foobar_topic -m online -h localhost -r --disable-clean-sessionnow the 1st outputs:foobar_topic crashed👎Also I watch the topic with MQTT Explorer and once I pub, I get both topics, crashed and online afterwards. This is different from Mosquitto.