MQTT, once the cornerstone of IoT communication, is starting to show its age | Hacker News Reader

MQTT, once the cornerstone of IoT communication, is starting to show its age

infinyon.com

18 pointsdebadyutirc18 comments

> Resolve Intermitent Connectivity Issues

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.

Isn't it interesting that plays like the thing industries cant offer beyond QoS 0? Why do you say the gap is?

That is why there is a QoS parameter.

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.

No you don't. The open source project is here. You can self host and try it easy - https://www.fluvio.io/docs/fluvio/quickstart

https://github.com/InfinyOn/fluvio

Apache 2 Should replace Kafka + Flint.

This feels like an AI-generated ad for Infinyon.

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?

Possibly the click baity title combined with a basic lack of understanding of the topic. See sibling comment by milesvp.

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.

Humans have been writing this kind of thing for a long time before LLMs got good at it. Sure hasn't helped the training data.

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.

> 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?

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.

That sounds like an interesting approach.

I am curious about the details of how you do it.

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.

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:

   Deploy AI Features at the Edge

Reply on news.ycombinator.com