LOL. AI generated the image. But as far as I understand AJ wrote the rest. But it's a dry subject. I am curious what makes you say it is an AI generated Ad?
Many words to say nothing, overall pretty difficult to follow, not bringing anything interesting other than vague claims, all that bringing to "but we have a solution for you".
Feels like AI is good at generating that kind of noise.
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.
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.
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.
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.
If I have to book a call with an expert just to test…it’s a total waste of my time for both personal and enterprise. MQTT lives…old-ish, faithful and reliable. It’s easy to setup - personal and enterprise. It’s scalable. I can pub and sub…that’s all we’re asking of it.
They lost me at this header. MQTT was quite literally designed for satellite based communication. Its biggest strength is dealing with intermittent connections. If you’re going to fire and forget important data with MQTT you’re already using it wrong.
I think that this article is just an advertisement for some shitty company that was generated by AI/chatgpt and co because it doesn't have any sense at all. For example:
19 comments
[ 424 ms ] story [ 4270 ms ] threadFeels like AI is good at generating that kind of noise.
Do you do anything to handle packet loss, or operate under the assumption it should be minimal on a LAN?
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.
I am curious about the details of how you do it.
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.
Apache 2 Should replace Kafka + Flint.
They lost me at this header. MQTT was quite literally designed for satellite based communication. Its biggest strength is dealing with intermittent connections. If you’re going to fire and forget important data with MQTT you’re already using it wrong.