I’m confused why this post is on the front page of HN. This isn’t new and they haven’t done a new release or something. Mosquitto is good and used all over the place but not sure why this is being posted.
I'm the OP - I just stumbled upon this project because I setup a self hosted MQTT server to read/write to/from a small PDU. Mosquitto worked great for that!
I hadn't heard of it, and thought to share it here. I'm not sure why people are upvoting it - but it's not impossible that others are interested in this topic as well..! Cheers
Maybe NanoMQ 0.25, Rabbitmq 4.4, EMQX 6.3 or VerneMQ 2.2 would have been a bit more newsworthy. Mosquito seems to the rather boring but but stable reference for MQTT for years now.
Exactly, I honestly checked link thinking there's v6 of mqtt protocol and I slept something and was confused. So I checked comments because maybe I'm to stupid but nope. There's literally nothing
Since we are into it, just sharing then: I had a lot of success with RabbitMQ + it's MQTT plugin. AFAIK, it actually has the MQTT plugin now baked in by default. Never had any issue at scale, plus you get AMQP in your stack, and you can actually use AMQP to consume the messages originally received over MQTT.
I had a terrible time with a cluster of RabbitMQ servers, the cluster was partitioning often, impacting the application. It seemed like it was very sensitive to transient network problems.
At the end we moved from a cluster to a single instance running on a over provisioned machine, that worked pretty well.
At a previous job (many years ago) we used to run RabbitMQ. I hadn't configured it originally, but I was certainly left with it in pieces when it entered split-brain mode in the face of some bizarre network failure.
So we had our application talking to two nodes of a cluster, both working normally without talking to each other (nevermind the fact that the connectivity between the machines was fine). Some workers picked up jobs, others didn't. IIRC the app read requests from a queue and wrote replies to another one, so we'd have half of the jobs being picked up, and then half of the replies not being picked up (ergo, 75% of the requests failed). It was bizarre and nothing seemed to indicate there were issues with RabbitMQ itself. I don't even remember how we figured it out at the time.
It's been nearly 10 years, I'm sure that it's better, that I was inexperienced, that the original setup wasn't great. But that left me so sore on it that I have actively avoid it ever since.
Bonus points for having dealt with this while Django Celery apparently had two independent configuration mechanisms, and both were being used in this app. Fun times.
I've used this for quite a while as a gateway for sparkplugB such that things like ignition can pull our telemetry data (we do agtech monitoring, smart meters, power, water, soil moisture, temp, etc etc)
Oh boy. You're going to hate to know what programming language is used for apache, nginx, postfix, postgres, MySQL/mariadb, redis, wireguard and the majority of network hardware.
Now the default seems to be EMQX, there's also a possible project to include MQTT5 compatibility in NATS (but they push back because they are selling this in their Entreprise version), what stack do people use here for MQTT?
We use HiveMQ and some mosquito. Rabbitmq did not have good qos2 support. I would like to see more options in this space. Mosquito did not have good cluster support from my perspective.
I’m confused why this post is on the front page of HN. This isn’t new and they haven’t done a new release or something. Mosquitto is good and used all over the place but not sure why this is being posted.
I'm the OP - I just stumbled upon this project because I setup a self hosted MQTT server to read/write to/from a small PDU. Mosquitto worked great for that!
I hadn't heard of it, and thought to share it here. I'm not sure why people are upvoting it - but it's not impossible that others are interested in this topic as well..! Cheers
Combining the old with the new. Agentic pubsub?
Maybe NanoMQ 0.25, Rabbitmq 4.4, EMQX 6.3 or VerneMQ 2.2 would have been a bit more newsworthy. Mosquito seems to the rather boring but but stable reference for MQTT for years now.
Exactly, I honestly checked link thinking there's v6 of mqtt protocol and I slept something and was confused. So I checked comments because maybe I'm to stupid but nope. There's literally nothing
Since we are into it, just sharing then: I had a lot of success with RabbitMQ + it's MQTT plugin. AFAIK, it actually has the MQTT plugin now baked in by default. Never had any issue at scale, plus you get AMQP in your stack, and you can actually use AMQP to consume the messages originally received over MQTT.
Are you running a cluster? What clustering strategy guarantees and what’s your recovery story?
I had a terrible time with a cluster of RabbitMQ servers, the cluster was partitioning often, impacting the application. It seemed like it was very sensitive to transient network problems.
At the end we moved from a cluster to a single instance running on a over provisioned machine, that worked pretty well.
At a previous job (many years ago) we used to run RabbitMQ. I hadn't configured it originally, but I was certainly left with it in pieces when it entered split-brain mode in the face of some bizarre network failure.
So we had our application talking to two nodes of a cluster, both working normally without talking to each other (nevermind the fact that the connectivity between the machines was fine). Some workers picked up jobs, others didn't. IIRC the app read requests from a queue and wrote replies to another one, so we'd have half of the jobs being picked up, and then half of the replies not being picked up (ergo, 75% of the requests failed). It was bizarre and nothing seemed to indicate there were issues with RabbitMQ itself. I don't even remember how we figured it out at the time.
It's been nearly 10 years, I'm sure that it's better, that I was inexperienced, that the original setup wasn't great. But that left me so sore on it that I have actively avoid it ever since.
Bonus points for having dealt with this while Django Celery apparently had two independent configuration mechanisms, and both were being used in this app. Fun times.
I've used this for quite a while as a gateway for sparkplugB such that things like ignition can pull our telemetry data (we do agtech monitoring, smart meters, power, water, soil moisture, temp, etc etc)
Is it yet becoming more common to have brokerless protocols like ZeroMQ and Zenoh that do not require having a broker that is deployed separately?
a PITA to scale. or maybe i just don't know how to infra?
i picked mosquitto but had to ditch it for AWS IoT Core and have not looked back.
These days I'd go with NATS if you need to scale, especially with on-prem servers.
It's written in C. At this point, this is an instant disqualification for a network service.
I looked at MQTT options earlier last year, and the best one was Mochi ( https://github.com/mochi-mqtt/server ), written in Go.
I added TLS support with Let's Encrypt provisioning to it: https://github.com/Cyberax/lenc-mochi
Oh boy. You're going to hate to know what programming language is used for apache, nginx, postfix, postgres, MySQL/mariadb, redis, wireguard and the majority of network hardware.
Absolutely. And I'm not using Apache, nginx, or postfix as a result. I'm also using userspace Wireguard, written in Rust.
For services that can't be avoided, I try to limit their exposure. I run Postgres with strictly controlled network access. Same for Redis.
Now the default seems to be EMQX, there's also a possible project to include MQTT5 compatibility in NATS (but they push back because they are selling this in their Entreprise version), what stack do people use here for MQTT?
We use HiveMQ and some mosquito. Rabbitmq did not have good qos2 support. I would like to see more options in this space. Mosquito did not have good cluster support from my perspective.
My company is using mosquito for multi source event stream. This is why I was so confused