search

fusesource / mqtt-client

A Java MQTT Client
http://mqtt-client.fusesource.org/
Apache License 2.0
1.27k stars 369 forks source link

MQTT 3.1.0 clients should be able to unsubscribe. #43

Closed hekonsek closed 8 years ago

hekonsek commented 9 years ago

Hi,

Moving from Mosquitto to A-MQ we are facing an issue with some older legacy clients during unsubscribe operations. These clients conform to MQTT version 3.1.0; they send an unsubscribe message with header setup like the following:

0x90 (Message type: 1010, DUP flag: 0, Qos level 00, RETAIN: 0)

In MQTT 3.1.1 specification these messages are explicitly classified as incorrect while in MQTT 3.1.0 they are admitted.

While testing A-MQ 6.1 with these MQTT 3.1.0 clients we noticed that these unsubscribe messages cause an error (ProtocolException: Invalid message encodig) making the unsubscribe to fail. From that point on, the connection is frozen (every operation fails, and disconnect is not accepted) until the connection timeout itself expires.

In Mosquitto there are no restrictions on these messages so they are correctly processed. We would need to have these legacy MQTT 3.1.0 clients to continue to work seamlessly also with A-MQ without upgrading the MQTT client because this would be very hard and often impossible as devices are already on the field.

One option would be to add a transport flag to control whether such legacy messages should be allowed. Out of the box A-MQ configuration can be strictly following MQTT 3.1.1; if the “legacy” transport flag is enabled, the broker is a bit more relaxed in accepting 3.1.0 messages. A similar approach has been adopted from the “dollar” topic support.

hekonsek commented 9 years ago

Hi, this is pull request created on the behalf of the customer. Can somebody review it? :)

fusesource-ci commented 9 years ago

Can one of the admins verify this patch?

hekonsek commented 9 years ago

Any updates on this?

dejanb commented 8 years ago

Implemented this a bit differently with https://github.com/fusesource/mqtt-client/commit/bfb213b675447518bac14fbb7bfc5b8cdf1ca7b2 The codec should always decode message id, and the app using it should check if QoS is set to the right value.