LWT - unclear LWT behavior with client takeover in 3.1.1 and 5 specs.

[Jiří Kubias]

Hi,
I would like to rise a question about LWT and client takeover - ( Client A with name 123 gets kicked with client B with name 123 - ie it is the same client but is is connected from different location - moving node).

The question is if the broker may or may not sent a LWT in this case?

In spec 3.1.1 in chap. 3.1.2.5
Will Flag is written that the message should be sent when the connection is closed without receiving DISCONNECT packet. This explanation is a bit confusing as the connection close the MQTT broker. From my point of view it is regular closing because the client cant send DISCONNECT packet as the server ends the communication - the client dont have any way hot to send this packet.

The MQTT 5 specs says in chap. 3.1.2.5 Will Flag
The Will Message MUST be published after the Network Connection is subsequently closed and either the Will Delay Interval has elapsed or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with
Reason Code 0x00 (Normal disconnection) or a new Network Connection for the ClientID is opened before the Will Delay Interval has elapsed. In this case it should not send LTW as the Client A is alive until Client B kick out the Client A. But what should happen when the connection timeout is 0sec?

Im rising this question because for example mosquitto send LWT when this take over happen but some another broker doesnt sent LWT so it seems that the explanation is unclear. (Issue from mosquitto https://github.com/eclipse/mosquitto/issues/904 )

Just for saving time here are MQTT specs:
MQTT 3.1.1

MQTT 5

Best regards, 

Jiri 

[Andy Stanford-Clark]

Hi Jiri

that’s a good question.

LWT is intended for when a client unexpectedly disconnects from the network, and it’s “the message you would have sent to say goodbye if you knew you were about to get disconnected”. 

So I would say that in the event of forced take-over by another client coming in, the LWT *should* be sent.

Andy

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

[Jiří Kubias]

Hi Andy,

that depend on the point of view. From my point of view the client is still alive then it is not necessary send LWT. We have a moving node so when the node moves to another location then reconnects again as it could not connect via the old path. This cause that the LWT is fired and the node is removed from server backend and gui. Then in next few ms it rises again as it is alive and this produce a lot of overhead and bad look. Another problem is that the different brokers doesn't behave in the same way  - mosquitto sent LTW but  hiveMQ and flespi dont. We have patched mosquitto to not send LTW and it will be sent as PR to mosquitto, but it will be configurable via compile option (default OFF).

I thing that the regulatory need to add better description of this behavior. Currently there are two point if view and nobody know what it correct. 

Regards, 

Jiri.   

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.

To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--
To learn more about MQTT please visit http://mqtt.org
---

You received this message because you are subscribed to a topic in the Google Groups "MQTT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mqtt/cdFEHZXRvuY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mqtt+unsubscribe@googlegroups.com.

To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--

===================================================
Ing. Jiri Kubias
 
e-mail: jiri....@gmail.com
mobile: 775 593 956
===================================================

[André Fatton]

Hi Jiří,

as a funny coincidence, VerneMQ has made this configurable in release 1.5 (released today). There's a new config value "suppress_lwt_on_session_takeover" that you can set to on or off.

André (from VerneMQ)

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

[Andy Stanford-Clark]

Yes, I completely agree - this needs to be made clear in the documentation. I *can* see both sides of this :)

Andy

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

[Andy Stanford-Clark]

Thinking about this some more, I think it *is* right to send the LWT.

It’s a matter of where you draw the line:

If a device gets into a state where it thinks it needs to reconnect, then it must have been unable to send messages for some period of time.

If the time is more than the keep alive time (plus a bit), the broker kicks you off and sends LWT.

If the time is less than the keep alive, you are still offline, otherwise you wouldn’t have decided to reconnect.

If the device actually did disconnect unexpectedly (say the power failed or the network dropped) for … 10 seconds let’s say, and then the power/network came back and you reconnected, would you expect LWT then? How about 30 seconds? At some point you’ll say “yes”.

See, it depends where you draw the line. It’s just a function of whether the device detects that it’s offline before the keep alive timer pops and you get kicked off.

The best way to filter out these “blips” is to put a filter on the death certificate (LWT) and birth certificate notifications, and if they are just a few seconds apart (whatever is acceptable to your application) then ignore them and don’t raise the alert.

The clientID take-over is really no different from a disconnect / reconnect cycle due to a network outage or power fail… it’s just noticed by the client before the broker sees it.

Andy

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

[Jiří Kubias]

Hi,

might I agree with you.  I have started to reading spec this again and I thing that I have a final resolution of this problem:

MQTT 3.1.1 -  It is a bit unclear if client take over is protocol error or not (regarding to the  note: The Server closes the Network Connection because of a protocol error). Probably this depend on programmer opinion. My opinion is that it is not protocol error, it could be be network glitch. But regarding to your point of view it is a questionable.

MQTT 5   I have discovered that  chapter 3.1.3.2.2 Will Delay Interval (http://docs.oasis-open.org/mqtt/mqtt/v5.0/cs02/mqtt-v5.0-cs02.html#_Will_Delay_Interval_1)  gives me tools for solve this situation. How ever there are two Non-normative comment which I dont fully understand.  The first says "One use of this is to avoid publishing Will Messages if there is a temporary network disconnection and the Client succeeds in reconnecting and continuing its Session before the Will Message is published." - Im happy with this. But the second says "If a Network Connection uses a Client Identifier of an existing Network Connection to the Server, the Will Message for the exiting connection is sent unless the new connection specifies Clean Start of 0 and the Will Delay is greater than zero. If the Will Delay is 0 the Will Message is sent at the close of the existing Network Connection, and if Clean Start is 1 the Will Message is sent because the Session ends." . From my point of view this two comments are in conflict.  The first comment doesnt make sense when I dont reconnect with the same Clinet identifier.  And what is "temporary network disconnection"? They mean when the node send DISCONNECT or when the connection die?

Regards, 

Jiri

[Jiří Kubias]

Hi,
I didnt understand the second Non-normative comment correctly. After discussion with my colleague it works in the way we need. So with MQTT 5 might be enough to set LWT delay and it should work in the way we need. 

Regards, 

Jiri