5 ms·

I'm developing a mqtt client/broker and the protocol is all but simple to implement. I didn't found any implementation, mosquitto included, that was really lo

by Kuinox 5y ago

I'm developing a mqtt client/broker and the protocol is all but simple to implement. I didn't found any implementation, mosquitto included, that was really lossless.

RedShift1 5y ago
The protocol is simple (I've written my own implementation in php), what do you mean with lossless?
- Kuinox 5y ago
  That when you use QoS 2 "ExactlyOnce" (or 1), you will never loose a message.
luma 5y ago
Is that true if you set QoS to a value other than 0 in your application? https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-qual...
- Kuinox 5y ago
  No, even when you set the QoS to 2, "ExactlyOnce", you may still hit edge cases where you loose data, without knowing it, especially on enterprise networks, or if there is an high throughtput.
xnyan 5y ago
I've worked quite a bit with MQTT - can you tell us a little more about what you mean by "really lossless"?
- Kuinox 5y ago
  To never loose a packet on QoS 1/2.
nicolaslem 5y ago
Could you expand on the difficulties you are facing? From the outside the protocol looks quite simple.
- Kuinox 5y ago
  The Packet ID logic is not enough restricted. For exemple, the emitter is not restricted in the ID it should use for it's packet, it can be any unsigned 16 bit number. In contrast, a lot of protocol the ID must be incremental, and the receiver can detect that a package is missing (which result in smaller network overhead, the client can ack, or re-ask for a dropped packet, which result in a single roundtrip when there is no issue, instead of having the double round trip that mqtt have). It means that, the receiver can't know if it missed a packet. Because you don't have to waits for the acks to propagate the message, it mean the message delivering is unordoned. It also mean that if the same message keep dropping, the protocol should continue to work. Now if you implemented your mqtt with an i++, this where you can start to have dataloss, because now that you sent 65k messages you finished you start to need actually free packet id. And it cause a lot more issues that what I said there, that I hope I covered every case in my implementation: https://github.com/signature-opensource/CK-MQTT/blob/develop/CK.MQTT.Common/Stores/IdStore.cs https://github.com/signature-opensource/CK-MQTT/blob/develop... Then, this is just the PacketID Logic. MQTT 3 doesn't do enough things, while MQTT5 do too much things. MQTT 3 Have design issues which MQTT 5 acknowledged it, and tried to fix it with duck tapes. One issue for exemple is the credentials being sent after the last will packet, which lead to a huge DOS issue, because now an attacker can attack you with your maximum last will packet, that you will want to save to disk, then wait to timeout without ever sending credentials. MQTT 5 is not really a breaking change as this behavior still exist, but you can enforce a credentials packet for the connexion. All this highlight that MQTT could be a far smaller, faster, simpler protocol if correctly done (and a protocol like this probably exist, I didn't looked at a lot of popular protocols for now, only a dozen of hardware custom ones). If I knew all the above before starting to implement my MQTT client, I would had want with another protocol.
eska 5y ago
Paho-mqtt implements QoS and also has an option to store unsent messages to disk for later sending.
- Kuinox 5y ago
  The issues I spotted are how the protocol is implemented, not how the packets are stored.
idatum 5y ago
+1 on paho-mqtt for python and mosquitto. All of my fun projects such as XBee3 sensors and HA + Z-Wave go through MQTT. It has been rock solid and a joy to develop against.
- Kuinox 5y ago
  It will work fine for your small scale IoT, but when they said "for IoT" they never meant it for high scale.
kitd 5y ago
"Really lossless" really boils down to a client having handled the message completely, which is outside the remit of a transport protocol.
- Kuinox 5y ago
  Yes, but no. If your protocol or your implementations have holes, you may loose messages because of that, and in a lot of applications, it's unacceptable to have the transport protocol dropping packets.

by Kuinox 5y ago

I'm developing a mqtt client/broker and the protocol is all but simple to implement. I didn't found any implementation, mosquitto included, that was really lossless.

RedShift1 5y ago

The protocol is simple (I've written my own implementation in php), what do you mean with lossless?

Kuinox 5y ago
That when you use QoS 2 "ExactlyOnce" (or 1), you will never loose a message.

luma 5y ago

Is that true if you set QoS to a value other than 0 in your application? https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-qual...

Kuinox 5y ago
No, even when you set the QoS to 2, "ExactlyOnce", you may still hit edge cases where you loose data, without knowing it, especially on enterprise networks, or if there is an high throughtput.

xnyan 5y ago

I've worked quite a bit with MQTT - can you tell us a little more about what you mean by "really lossless"?

Kuinox 5y ago
To never loose a packet on QoS 1/2.

nicolaslem 5y ago

Could you expand on the difficulties you are facing? From the outside the protocol looks quite simple.

Kuinox 5y ago
The Packet ID logic is not enough restricted. For exemple, the emitter is not restricted in the ID it should use for it's packet, it can be any unsigned 16 bit number. In contrast, a lot of protocol the ID must be incremental, and the receiver can detect that a package is missing (which result in smaller network overhead, the client can ack, or re-ask for a dropped packet, which result in a single roundtrip when there is no issue, instead of having the double round trip that mqtt have). It means that, the receiver can't know if it missed a packet. Because you don't have to waits for the acks to propagate the message, it mean the message delivering is unordoned. It also mean that if the same message keep dropping, the protocol should continue to work. Now if you implemented your mqtt with an i++, this where you can start to have dataloss, because now that you sent 65k messages you finished you start to need actually free packet id. And it cause a lot more issues that what I said there, that I hope I covered every case in my implementation: https://github.com/signature-opensource/CK-MQTT/blob/develop/CK.MQTT.Common/Stores/IdStore.cs https://github.com/signature-opensource/CK-MQTT/blob/develop... Then, this is just the PacketID Logic. MQTT 3 doesn't do enough things, while MQTT5 do too much things. MQTT 3 Have design issues which MQTT 5 acknowledged it, and tried to fix it with duck tapes. One issue for exemple is the credentials being sent after the last will packet, which lead to a huge DOS issue, because now an attacker can attack you with your maximum last will packet, that you will want to save to disk, then wait to timeout without ever sending credentials. MQTT 5 is not really a breaking change as this behavior still exist, but you can enforce a credentials packet for the connexion. All this highlight that MQTT could be a far smaller, faster, simpler protocol if correctly done (and a protocol like this probably exist, I didn't looked at a lot of popular protocols for now, only a dozen of hardware custom ones). If I knew all the above before starting to implement my MQTT client, I would had want with another protocol.

eska 5y ago

Paho-mqtt implements QoS and also has an option to store unsent messages to disk for later sending.

Kuinox 5y ago
The issues I spotted are how the protocol is implemented, not how the packets are stored.

idatum 5y ago

+1 on paho-mqtt for python and mosquitto. All of my fun projects such as XBee3 sensors and HA + Z-Wave go through MQTT. It has been rock solid and a joy to develop against.

Kuinox 5y ago
It will work fine for your small scale IoT, but when they said "for IoT" they never meant it for high scale.

kitd 5y ago

"Really lossless" really boils down to a client having handled the message completely, which is outside the remit of a transport protocol.

Kuinox 5y ago
Yes, but no. If your protocol or your implementations have holes, you may loose messages because of that, and in a lot of applications, it's unacceptable to have the transport protocol dropping packets.