of Things protocol.
We used the latest version of MIMIC MQTT Simulator to test several MQTT
brokers with MQTT 5 support, and in a short time have discovered some
differences in protocol behavior between them.
Test 1 - CONNECT with Maximum Packet Size set to low value
In the case of 0, one broker disconnects immediately, and the other sends aCONNACK with Reason Code. In this case, the spec clearly says
It is a Protocol Error to include the Maximum Packet Size more than once,
Both behaviors are legal, since protocol errors must result in disconnect, butor for the value to be set to zero.
at the discretion of the server it may send a CONNACK with reason code, as
detailed here.
Curiously, if the value is 10, again one broker disconnects immediately, but
the other does not send anything, presumably because the CONNACK would
have violated the limit. This results in a timeout at the client.
Test 2 - PUBLISH with empty topic name and no topic alias
In this case, one broker disconnects and the other sends PUBACK withReason Code. In this case, the spec clearly says
It is a Protocol Error if the Topic Name is zero length and there is no Topic Alias.Protocol errors must result in disconnect as detailed here.
Test 3 - PUBLISH to wildcard topic
For example, to handle the error of a PUBLISH with QOS = 1 to an illegalwildcard topic, one broker returns a PUBACK with the Reason Code of 0x90,
whereas another returns a DISCONNECT with that Reason Code. This
behavior is expected with QOS 0, but since it is not defined as a protocol
error, for QOS 1 and 2 the PUBACK and PUBREC response should be used.
This is what our logs show:
INFO 02/06.10:58:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO 02/06.10:58:25 - MQTT[AGT=1] - rcvd PUBREC rc=0x90 Reason String The topic is not valid: ...
vs.
INFO 02/06.11:01:25 - MQTT[AGT=1] - sent PUBLISH (110 bytes)
INFO 02/06.11:01:25 - MQTT[AGT=1] - rcvd DISCONNECT reason 0x90 (Reason String PUBLISH with wildcard character (#/+) was sent.)
Test 4 - PUBLISH with Payload Format property
For a PUBLISH with property Payload Format set, the spec saysA Server MUST send the Payload Format Indicator unaltered to all
subscribers receiving the Application Message [MQTT-3.3.2-4]
One of the brokers discards the Payload Format Indicator property if it is 0.
If this property is missing, it can be assumed to be 0. While not breaking
anything, this is technically incorrect.
Test 5 - Shared vs. non-shared subscriptions
The new shared subscriptions allow multiple subscribers to receive mutually
exclusive subsets of the messages of a particular topic filter. This 90-second
YouTube video illustrates the behavior
Conclusion
Since MQTT 5 is so recent, you need to test many features of your selected
MQTT brokers and IoT applications with different scenarios to mitigate
costly surprises before deployment. MIMIC MQTT Simulator can really help
with that.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.