Also, at mqtt.fluux.io you can test one of the few first public brokers that supports MQTT 5.0 spec - there are instructions using Mosquitto in the announcement.
I'm not aware of anyone using it in production, or asking to - so it's not received a lot of attention. For my own projects I've tended to prefer bridging to XMPP in other ways, but it was fun to work on.
I found a number of things surprising in MQTT, for example the lack of errors in response to commands (such as publishing), with the only solution to be just closing the connection entirely.
Didn't know about the Prosody module. However, MQTT in ejabberd is at the core level, not module, so it is able to access all the performance and scalability features used by XMPP - and in that sense, ejabberd MQTT is production-ready.
I think the surprising behaviours of MQTT are its strength - it's minimal and perfect for low-energy devices. For heavy lifting, there's XMPP.
Not sure what you mean by "at the core level", exactly. Prosody is quite modular, and everything is implemented as a module with access to the same APIs. Modules do not have performance limitations. I know ejabberd's architecture less well though.
Our internal XMPP pubsub (XEP-0060) support has a native code API designed for use by internal modules, so there is no need to marshal everything from MQTT into the appropriate XMPP stanzas for example, it's a direct mapping from MQTT to our internal API.
When you talk about MQTT and IoT, scalability and clustering is the deciding factor. When you deploy an IoT stack, it is common to have to manage hundreds of thousands or millions of devices.
The stack is leveraging ejabberd clustering and scalability.
8 comments
[ 5.0 ms ] story [ 29.0 ms ] threadI'm not aware of anyone using it in production, or asking to - so it's not received a lot of attention. For my own projects I've tended to prefer bridging to XMPP in other ways, but it was fun to work on.
I found a number of things surprising in MQTT, for example the lack of errors in response to commands (such as publishing), with the only solution to be just closing the connection entirely.
I think the surprising behaviours of MQTT are its strength - it's minimal and perfect for low-energy devices. For heavy lifting, there's XMPP.
Our internal XMPP pubsub (XEP-0060) support has a native code API designed for use by internal modules, so there is no need to marshal everything from MQTT into the appropriate XMPP stanzas for example, it's a direct mapping from MQTT to our internal API.