Mosquitto: An open-source MQTT broker

I have it respond with 418 as “I taste colors and the government spies on you with the ground in your house wiring”.

I like it for that more than actual tea pots which is far too on the nose.

[1] https://www.home-assistant.io/docs/mqtt/discovery/

I do run MQTT for a few wifi devices and communication between node red and custom client code on my laptop/desktop.

Yes, at JPL they let engineers cycle in and out of management. (Serving institution / projects in phases)

> Anyway - you mean I don't need static IP to form a network of distant IoT devices? This would be some really useful property.

Yes, wireguard will "keep alive" a connection to peers by sending udp packets. This fools stateful sufficiently to allow traffic to migrate across networks easily. Kind of how push notifications magically follow you.

On top of those connections, wireguard establishes its own IP addresses for each peer. If you set up wireguard, senging a packet over IP that is one of your wireguard peers will get tunnelled through UDP to the peer at its location and real IP. Thus, you know the node by the WG IP, but it gets delivered seamlessly via whatever means necessary.

VPNs have done this forever. Wireguard makes it trivial and portable and fast.

I'm not a REST+MQTT expert, but some people do combine them, why not?

One of the project I was working on (IoT, smart home), the mobile app received the current status from the REST API, then subscribed to changes via MQTT. Having MQTT was great for live updates on the mobile app, and for communicating with the IoT devices. HTTP was great for integrations with Google Home, Alexa, and we could test it easily as there are many backend frameworks focusing on CRUD REST HTTP backend apps.

Of course, if you actually have a problem you want to solve, be sure the to do your own research, there are more than one way to skin a cat, and there are so many services and platforms that could be "good enough" for your use case.

In IOT its hard to go past MQTT for the usual signals paired with CoAP for ad hoc. When I want to reduce dependencies or just being lazy even CoAP gets replaced with building a request/respond mechanism using a MQTT queue so a hub pubs a message to the devices command queue and device reads that queue and responds to it. How often device checks the command queue depends on whether or not device can run command queue monitoring asynchronously or must do a scheduled round-robin of the queues.

The Eclipse Paho libs have been great for me using across different OS and bare metal, Arduino, FreeRTOS.

From C or Golang (or a bunch of other language bindings) you can set up some nice pub/sub or req/res with fan in/fan out and all sorts of cool routing with low-level, high speed sockets with the added power that ZMQ provides, such as the queueing, high-watermarks etc. You can also enable encryption easily with CurveZMQ which is a refreshing change from TLS.

[0]https://zeromq.org/get-started/

[1]https://zguide.zeromq.org/

I agree it's super nice though, even with a single process.

I won't pretend to have done an audit of the best servers in terms of bugs or features.

Take note Paho MQTT Client is available for several programming languages(Py,Rust,Go,C,C#,etc)[2].

[0]: https://www.eclipse.org/paho/index.php?page=clients/js/index... [1]: https://www.rabbitmq.com/web-mqtt.html [2]: https://www.eclipse.org/paho/index.php?page=downloads.php

It also has a lot appeal to people who do not develop on a daily basis, eg. I'm pretty confident I could teach my dad to use nodered vs writing python in a day.

I myself just use it (after years of being on the second side) because I noticed, that it was somehow way faster to get stuff working and keep it maintained

[0]: https://docs.nats.io/nats-protocol/nats-protocol

[0] https://docs.nats.io/nats-server/configuration/mqtt

Well, yes, but QoS=1 or 2 with a reasonably large queue I haven't seen loss issues.

What kind of loss problems are you running into (that I should be worried about)?

For exemple, the emitter is not restricted in the ID it should use for it's packet, it can be any unsigned 16 bit number.

In contrast, a lot of protocol the ID must be incremental, and the receiver can detect that a package is missing (which result in smaller network overhead, the client can ack, or re-ask for a dropped packet, which result in a single roundtrip when there is no issue, instead of having the double round trip that mqtt have). It means that, the receiver can't know if it missed a packet. Because you don't have to waits for the acks to propagate the message, it mean the message delivering is unordoned. It also mean that if the same message keep dropping, the protocol should continue to work. Now if you implemented your mqtt with an i++, this where you can start to have dataloss, because now that you sent 65k messages you finished you start to need actually free packet id.

And it cause a lot more issues that what I said there, that I hope I covered every case in my implementation: https://github.com/signature-opensource/CK-MQTT/blob/develop...

Then, this is just the PacketID Logic. MQTT 3 doesn't do enough things, while MQTT5 do too much things. MQTT 3 Have design issues which MQTT 5 acknowledged it, and tried to fix it with duck tapes. One issue for exemple is the credentials being sent after the last will packet, which lead to a huge DOS issue, because now an attacker can attack you with your maximum last will packet, that you will want to save to disk, then wait to timeout without ever sending credentials. MQTT 5 is not really a breaking change as this behavior still exist, but you can enforce a credentials packet for the connexion.

All this highlight that MQTT could be a far smaller, faster, simpler protocol if correctly done (and a protocol like this probably exist, I didn't looked at a lot of popular protocols for now, only a dozen of hardware custom ones).

If I knew all the above before starting to implement my MQTT client, I would had want with another protocol.

MQTT requires a TCP stack, which limits to the higher end chips.

But, for embedded linux, you're probably golden.

>By default, a listener will attempt to listen on all supported IP protocol versions.

>If you do not have an IPv4 or IPv6 interface you may wish to disable support for either of those protocol versions. In particular, note that due to the limitations of the websockets library, it will only ever attempt to open IPv6 sockets if IPv6 support is compiled in, and so will fail if IPv6 is not available.

From the manual. Huh, seems like I might’ve misunderstood this paragraph. But I was only ever able to access the broker if the browser was using an ipv6 address. I’ll have to test again I suppose. Still, the performance and reliability was not good.