[kerblang]

I don't buy the b.s. around MQTT being so lightweight/efficient/etc. It's just using TCP/IP. Maybe by the standards of the day that was comparatively special, but I've never seen any real evidence for the claim besides this constant bragging.

I guess it's nice that MQTT is a standard and so you have a way to connect to off-the-shelf devices that are enabled. I still think there are better options for pub/sub and message queues, esp. if you need to failover on the consumer side.

[bdamm]

What better options? The neat thing about MQTT, and that almost all other pub/sub implementations that I've seen get wrong, is that the core data structure in MQTT is the subscribing client, not the queues & topics. That means you can map as large an address space as you want into the topic tree. The topic tree can be trillions and trillions of endpoints, even an embedded server could have a topic tree with one endpoint for every ipv6 address, if you wanted. So the topic tree is rich, your subscriptions can be as selective as you need, and the server can be fast on a low footprint.

[mmcnl]

Exactly. Even shorter summary: MQTT broker is stateless thus easy to manage and hard to break. This makes MQTT reliable.

[xnyan]

> I still think there are better options for pub/sub and message queues, esp. if you need to failover on the consumer side.

Sincerely, what are these options?

[kerblang]

The various message-queueing products, Kafka, et al. Sorry for late response and not responding sooner...