Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C...
by KaiserPro on Sunday June 27, 2021 @11:42AM
(#27652454)
MQTT is simple. You open a single connection, and thats about it. You can use an off the self TCP implementation, which you almost certainly don't have to worry about. The hard part is managing certificate.
Even though I don't have to, I'm pretty sure I can implement a MQTT client on my own. I'm not sure I can do it with HTTP3, and thats before I implement the pub:sub bits on top. And you still have to manage certificates.
But reading the paper there are some glaring issues. firstly its using MQTT over QUIC is not the greatest choice. They don't compare it to raw MQTT over tcp. They seem to be labouring over the assumption that UDP is "faster". Given that ideally your message size for MQTT is < than MTU, in most cases UDP has little advantage. (depending on how you cost the connection initialisation.)
Second, peak memory usage for the Http3 implementation is 10 megs, thats more ram than an ESP32 can address (4/8megs). I'm not sure what kind of target hardware they are aiming for.
The total data transmitted per 1kb of message appears to be off as well. I'm not sure how 1K of message turns into 24k of network traffic.
In short, it might be an alternative, but not as implemented in this paper.
Even though I don't have to, I'm pretty sure I can implement a MQTT client on my own. I'm not sure I can do it with HTTP3, and thats before I implement the pub:sub bits on top. And you still have to manage certificates.
But reading the paper there are some glaring issues. firstly its using MQTT over QUIC is not the greatest choice. They don't compare it to raw MQTT over tcp. They seem to be labouring over the assumption that UDP is "faster". Given that ideally your message size for MQTT is < than MTU, in most cases UDP has little advantage. (depending on how you cost the connection initialisation.)
Second, peak memory usage for the Http3 implementation is 10 megs, thats more ram than an ESP32 can address (4/8megs). I'm not sure what kind of target hardware they are aiming for.
The total data transmitted per 1kb of message appears to be off as well. I'm not sure how 1K of message turns into 24k of network traffic.
In short, it might be an alternative, but not as implemented in this paper.