-
Notifications
You must be signed in to change notification settings - Fork 2.4k
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LWT and client takeover - mosquitto broker #904
Comments
This is an area that is not defined in the MQTT 3.1.1 standard that Mosquitto currently uses, so the two projects have interpreted the correct behaviour differently. I note that in MQTT 5, in the case that you describe the server is required to publish the LWT, so I argue that Mosquitto is giving the correct behaviour. |
If you have some information to back up that what you describe is the correct behaviour, other than just that it is what HiveMQ does, then please let us know. |
Hi, The MQTT 5 specs says in chap. 3.1.2.5 Will Flag In this case it should not send LTW as the Client A is alive until Client B kick out the Client A. Just for saving time here are MQTT specs: |
MQTT 3.1.1 doesn't adequately cover this situation, which means it is up for interpretation. My position is that the client does not send a DISCONNECT, so it is an unexpected end to the session. I would very much want to know that this was happening, so the LWT should be sent. For MQTT 5, I see the point that you make, but an alternative viewpoint would be that the Client B session is not active until after Client A has been removed, because it is not allowed to have two clients connected with the same client id at the same time, at which point if your Will Delay Interval is zero (which in MQTT 3 it is), then the LWT should be transmitted. Now I'm not sure I'd want to argue that in reality, but you see there is still ambiguity even version 5. Perhaps a bit of discussion with the committee would sort it out. I'd like to close this as "won't fix" or "not a bug", because I believe this is down to interpretation of the spec, not something that is spelled out explicitly and do not want to change the existing behaviour. I will certainly be looking at it closely for version 5 though. |
Hi, In our case we have developed mobile IoT devices (9k pcs at one place) which are mobile so they are changing their position and connecting to the broker from different places so they are kicking previous connection as it is obsolete. And this behavior are firing LWT so in this case client is alive but reconnects from new location and the old one is dead... Now multiple LWT firing by 9k each time when the device move to the new position. This product is going out next month. I have proposal: I have created a patch which cover this situation. I can make it as compilation option. Are you interested? |
Hi,
we have found a new bug in mosquitto broker. When client A connects with user name 123 to broker and set LWT then another client B connect to the broker with the same user name then the LWT from client A is fired by broker but it should not be. This is regular client takeover and the broker should not sent the LWT message. Same behavior was tested with HiveMQ and the broker didnt sent LWT during client takeover.
Example:
shell 1:
mosquitto_sub -d -h localhost -t home/sensor-problems - observe here the system output
shell 2:
mosquitto_sub -d -i Subscriber123 -h localhost -t home/living-room/temperature --will-topic home/sensor-problems --will-payload "Problem with SubscriberA" -u 123
shell 3:
mosquitto_sub -d -i Subscriber123 -h localhost -t home/living-room/temperature --will-topic home/sensor-problems --will-payload "Problem with SubscriberB" -u 123
Then mosquitto_sub in shell 2 and 3 will star kicking each other in cycles. and In shell 1 will be visible
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberA
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberB
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberA
Client mosqsub|12303-Hippafora received PUBLISH (d0, q0, r0, m0, 'home/sensor-problems', ... (24 bytes))
Problem with SubscriberB
....
Tested with mosquitto version 1.5
Regard,
Jiri
The text was updated successfully, but these errors were encountered: