5 ms·

My philosophy is to remove gratuitous abstractions. Years ago I used MQTT for almost everything. These days I use server sent events with http connected device

My philosophy is to remove gratuitous abstractions. Years ago I used MQTT for almost everything. These days I use server sent events with http connected devices. For many IoT use-cases I find UDP broadcasts require far less overhead.

bschwindHN 2y ago
> For many IoT use-cases I find UDP broadcasts require far less overhead. Do you do anything to handle packet loss, or operate under the assumption it should be minimal on a LAN?
- jkestner 2y ago
  Missing are the exact use cases. For Twine (general purpose IoT monitor from way back), we used UDP for the steady monitoring stream, serving the purposes of a dashboard data stream and keeping the connection open, while saving power. Used TCP just for the events we wanted to be sure got received, but with UDP, Twine still got several 9s of packets getting delivered over the internet.
- GianFabien 2y ago
  There are situations where packet loss can be an issue. In the configurations I have implemented, LAN packet loss is rare. Operations are idempotent and thus can be repeated. Everybody has their preferences. Personally, I avoid having too many layers and too many intervening abstractions. In my designs, keeping it lean maximizes throughput and simplicity means that I can debug it without tearing out too many hairs. In many projects that I have worked on we spent more time debugging third party modules than the stuff that we designed and implemented.
debadyutirc 2y ago
That sounds like an interesting approach. I am curious about the details of how you do it.
- GianFabien 2y ago
  Pretty simple really. Port numbers are effectively topic identifiers. The packet payload contains the data. Both producers and consumers run on a fire and forget basis. i.e. avoid any RPC patterns. Obviously, my designs are for systems that work well with those principles. It is by far not a generalized architecture. I still use MQTT, TCP, WebSockets, IPC, UDS etc where they provide essential and critical capabilities. My philosophy is simple. Use the simplest, easiest tool that gets the job done without needless complexity or difficulties. If you are having too many problems, then revise the design.

bschwindHN 2y ago

> For many IoT use-cases I find UDP broadcasts require far less overhead. Do you do anything to handle packet loss, or operate under the assumption it should be minimal on a LAN?

jkestner 2y ago
Missing are the exact use cases. For Twine (general purpose IoT monitor from way back), we used UDP for the steady monitoring stream, serving the purposes of a dashboard data stream and keeping the connection open, while saving power. Used TCP just for the events we wanted to be sure got received, but with UDP, Twine still got several 9s of packets getting delivered over the internet.
GianFabien 2y ago
There are situations where packet loss can be an issue. In the configurations I have implemented, LAN packet loss is rare. Operations are idempotent and thus can be repeated. Everybody has their preferences. Personally, I avoid having too many layers and too many intervening abstractions. In my designs, keeping it lean maximizes throughput and simplicity means that I can debug it without tearing out too many hairs. In many projects that I have worked on we spent more time debugging third party modules than the stuff that we designed and implemented.

debadyutirc 2y ago

That sounds like an interesting approach. I am curious about the details of how you do it.

GianFabien 2y ago
Pretty simple really. Port numbers are effectively topic identifiers. The packet payload contains the data. Both producers and consumers run on a fire and forget basis. i.e. avoid any RPC patterns. Obviously, my designs are for systems that work well with those principles. It is by far not a generalized architecture. I still use MQTT, TCP, WebSockets, IPC, UDS etc where they provide essential and critical capabilities. My philosophy is simple. Use the simplest, easiest tool that gets the job done without needless complexity or difficulties. If you are having too many problems, then revise the design.