this statement is a bit confusing. because with zeromq, one side plays the broker (I dont mean the broker pattern). I mean it in the sense that someone, somewhere, needs to listen on a port. which in the end is the same as having a central mqtt broker sitting somewhere listening on a port. hence the statement "no broker needed" is a bit confusing.
I think you can also connect in a random order, so bind doesn't need to happen before connect.
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 mess…
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.
Reposting my comment from five years ago: I once had a client where the only port available for me to use on their firewalls was for MQTT (1883) because that's how we were getting sensor data from them. They would not open anything else for us no matter how we implored them so I wrote a live TCP wrapper over MQTT to get around it. It was a local multithreaded TCP daemon that listened for outbound requests on a certai…
So you basically implemented an MQTT-Sockets protocol. Which you could then use to connect to a WebSockets server on the other side.
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 mess…
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 endpo…
Exactly. Even shorter summary: MQTT broker is stateless thus easy to manage and hard to break. This makes MQTT reliable.
I think my first project that's still "in production" and used daily was taking an existing SVG map of a water distribution system (snowmaking and fire suppression pipelines/pumps/valves/etc at a major ski resort). I made a MQTT topic for each pump, valve and section of pipe along with some state for each (water direction, pump or valve on/off, pressures, etc). It's a website, so I used mqtt.js and jQuery to update t…
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 mess…
> I still think there are better options for pub/sub and message queues, esp. if you need to failover on the consumer side.
Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…
> There are a lot of options in the protocol where it's not immediately clear what they do and why they are important I totally disagree, your expectations for the protocol seems unusual. They are not frameworks, and need to game many options. MQTT specification is like 3 pages. For comparison try to read specification of HTTP3, or AMQP - those are hideously complicated.
Also, they are options. Basic pub/sub usage doesn't need any of them, though some are pretty nice to have.
Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…
I read someone somewhere saying "why not just use TCP" and for my IOT project plain TCP was fine. MQTT didn't have infinite queuing which was important for my use case, and if I'm going to have to track message ids to feed into MQTT which tracks its own message ids to send to the broker, why use it at all.
I'm not sure what the sweet spot is, unless it's just interfacing with projects that have already committed to MQTT.
Having recently used MQTT for a project, I can't say that I'm a huge fan. There are a lot of options in the protocol where it's not immediately clear what they do and why they are important, or in what combination they need to be used to make sure things work as intended, and the documentation is often not great at explaining. Part of this may also be on the Eclipse Mosquitto Python client that I had been using. I to…
I read someone somewhere saying "why not just use TCP" and for my IOT project plain TCP was fine. MQTT didn't have infinite queuing which was important for my use case, and if I'm going to have to track message ids to feed into MQTT which tracks its own message ids to send to the broker, why use it at all. I'm not sure what the sweet spot is, unless it's just interfacing with projects that have already committed to M…
MQTT is pub/sub protocol with a concept of brokers and clients. It's not in anyway comparable to TCP. You could rewrite an equivalent of MQTT on top of TCP in a fairly straightforward way - MQTT is simple by design - but I think you take the question from the wrong end. Why would you write a new protocol when MQTT already exists and does the job?
I think my first project that's still "in production" and used daily was taking an existing SVG map of a water distribution system (snowmaking and fire suppression pipelines/pumps/valves/etc at a major ski resort). I made a MQTT topic for each pump, valve and section of pipe along with some state for each (water direction, pump or valve on/off, pressures, etc). It's a website, so I used mqtt.js and jQuery to update t…
Holy shit Docker is 11 years old.
It was early days, yeah. The other part of the project that's been depreciated now was running node 0.4, if I am not mistaken. The watermap was part of a bigger asset tracking system, node + jade templating (before jade became pug, even). The watermap was actually embedded in a jade template, but when I depreciated the other system, I ended up just copy and pasting the output from the jade file into an index.html, and everything just kept working :D