Hello,
Is there any plan to add MQTT support to NServiceBus?
I clearly understand it lacks a lot of the underlying features the other queuing systems already covered support. However, it is extremely popular in all sorts of IoT solutions. It becomes quite common use case to have to integrate/bridge a highly reliable processing implementation (based on NServiceBus) with the inherently unreliable nature of IoT input/outputs.
NServiceBus already adds quite extensive layer of logical isolation and having it (partially) covering MQTT as a transport can ease developers on achieving a more homogeneous solution.
Best Regards
Marin
Hi Marin
At this stage we are actively tracking the interest of our customers in MQTT but have no immediate plans to support it. Other than the benefits you mentioned do you mind sharing some more background information why MQTT is a great fit for your solution?
Have you evaluated other transport options than MQTT and why have they been dismissed?
Regards
Daniel
Hi,
We are already using AMQP (0.91) for quite broad number of IoT devices. Unfortunately, RabbitMQ turns to be the only commercially available broker that supports this protocol (AMQP 1.0 is a completely different one, no matter only the version had been changed). RabbitMQ proved to be quite heavy resource hog, especially in our use case where devices are using TLS connections with individual client SSL certificate (most likely related to Erlang’s own SSL implementation). Additionally, the performance does not scale well in cluster setups and simple operations on paper to bring down one of the nodes or add new one to the cluster often causes all sorts of havoc.
MQTT has an oversimplified, but still very flexible model of pub/sub. There is usually no persistence involved for messages (basically there are no explicit queues, only those internally organized to cope with clients disparity in speed of production/consumption). That means the transport is unreliable in its nature, but that is rarely needed in IoT device world. MQTT also supports the notion of last will message for each client, which makes it very easy to track device disconnections without any additional infrastructure.
Not lastly, there are multitude of open source and/or commercially supported products to choose from for the broker solution.
Best Regards
Marin
Thanks Marin I’ve added your comment to our technology tracker for now. Unfortunately that I is all I can provide at this stage.
Technically nothing would prevent you from implementing your own transport. The interfaces are fairly straight forward and we have plenty of acceptance and transport tests you could pull in to make sure the transport complies with the feature set required by NServiceBus. I’m happy to do occasional light reviews should you put the code as OSS somewhere on github.
Regards
Daniel