A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT

Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C... by SV_BubbleTime on Sunday June 27, 2021 @10:50AM (#27652015)

I ran into a lot of difficulty when dealing with devices that needed a bridge to access the internet. So device doesn’t have a tcp stack and requires a socket-like connection to an intentional-man-in-the-middle.

Implementing payload end to end encrypted MQTT was easy enough.

Any thoughts on TLS for that scenario? At best I could have a simulated socket, but always to an untrusted middle man.

[ Parent | on HN ]

Re:A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-C... by SV_BubbleTime on Monday June 28, 2021 @01:29AM (#27658413)

Turns out ONE answer is that DTLS is TLS for datagram connections (ie: UDP) and it’s pretty easy to forward along UDP packets at a proxy (as there is no need at all to track what sent or needs a retry).

It should be noted (if anyone reads this) that DTLS has protections and reliability on packets to establish the connection, but once it’s established it just goes back to being UDP although now encrypted, so you need to be ok with losses.

If you need messaging on top of that, CoAP adds in the counters and retries and reliability to UDP. Making UDP a little more like TCP but features to get this are one level higher in the CoAP packet. It’s a little weird, but gets you relatively reliable request/response HTTP-like (CoAP CONFIRMATION) and also event driven async MQTT-like (NON-CONFIRMATION). So that’s pretty cool.

Although near for me as GCP and Azure support CoAP but for some reason Amazon seems to refuse to and I’m locked in to Amazon for other reasons.

[ Parent | on HN ]