Does NATS support MQTT?

[hoang17]

I would like to use NATS as MQTT broker. Is it possible?

[derekcollison]

Not yet. ;)

[hoang17]

Thanks @derekcollison for your amazing product. So you mean it is in the time line?

[derekcollison]

We have tentative plan for it 1H 2019. /cc @ColinSullivan1

[hoang17]

cool thanks 🙏🏻

[robinbowes]

Any more concrete plans yet, @derekcollison ?

[derekcollison]

Yes we are planning on support, aiming for 1H 2019.

[goireu]

I'd be happy to help "beta" testing whenever possible !

[sonwa]

Is there a beta?

[derekcollison]

Not at the moment. Will keep everyone posted.

[sonwa]

I saw that it was already release 2.0.0. Does this version support MQTT?

[derekcollison]

No it was not planned for the 2.0 release but is still on the roadmap for 2019, but may slip depending on other priorities.

[nmarcetic]

Really looking forward to seeing MQTT support! Let us know if we can help somehow @derekcollison

[derekcollison]

Some feedback would be great. For now, what QoS do you most commonly use. Which MQTT servers are you using now? What auth/security is in place?

Thanks.

[goireu]

Derek,

we have 2 kind of brokers here :

• shared ones with no message "persistence" (publish QoS 0/1, subscribe QoS 0, no retain messages, no will messages). These may be VerneMQ or Mosquitto.
• dedicated ones, with message "persistence" (any QoS, retain & will messages). These are Mosquitto ones, thinking about VerneMQ too now they have a new non-leaking distributed store.

Security is handled by a home made MQTT reverse proxy checking client IDs and/or TLS device certificate. This proxy also handles MQTT protocol limits' enforcement.

Kinda non-standard usage. Fact is we don't use our brokers, our customers do.

While we're talking about MQTT, please note MQTT5 has recently been published, it adds long awaited features, I'd recomment you directly go for it.

One last thing : a common problem with MQTT brokers is memory usage, it is 99% dependent on usage pattern and the protocol says little about how the broker should behave when customers send in terabytes of messages and politely ask the broker to retain them. Proper configuration items, such as memory limits, are to be kept in mind when designing a broker implementation.

[derekcollison]

Great feedback, thank you. I am aware of MQTT5 and even the SN version as well. Some good stuff in there, so agree with you on making sure we can support it.

[timonsku]

We usually use MQTT with QoS 0 or 2, practically never QoS 1. Broker is always Mosquitto and we make a lot of use of persistence, mostly for retained messages, almost never for will messages. We seldom use encryption as we usually deploy in secured networks that have no access to the internet. When we do we use the built-in support for TLS with username and password auth.

[derekcollison]

Thanks!

[nmarcetic]

Hey Folks,

We at Mainflux works a lot with MQTT and some of our clients/partners has huge deployments and we faced with real-life problems a lot. Ofc Thanks to NATS, which is the core of our platform, We are handling those deployments just fine ;)

Here are my 50cents, First of all, great feedback from @goireu he already mentioned important stuff :) Regarding QoS, there is no such thing as "preferred QoS", All QoS is must have, really it's not just optimistic advice, its reality. To be concurrent, NATS must support full MQTT spec at least 3.1.1 (which is not so big and complicated) and make plans for v5 in future :), besides this +1 for TLS and the very important stuff is modularity, NATS is pluggable used as lib I can hook into events and whatever I need to do, this is a huge drawback most brokers. For example, at Mainflux we use a different kind of AuthX and AuthZ methods and if I want to check the identity of publisher I must hook into onPub event and make some gRPC's, etc... this is not possible with most of the brokers and it's a deal breaker for most of the proejcts IMHO. Ofc, not just onPub, there are plenty of events which gave you freedom.

We wanted to start with our own MQTT broker in Go, because we find missing features and problems in every broker so far... but always some other priorities :)

@derekcollison If there are plans for opensource it and chance to join, we are very interested to help and contribute.

[nuharaf]

While I don't have big deployment, I like to chime in to. First,I wonder what qos1 and qos2 will affect nats complexity as server need to track message delivery. Even on qos0, there is this related issue #802 . Second, will it be implemented in the core nats or as proxy/connector keeping the core as simple.

Third, there is this

[nmarcetic]

This is a good idea @nuhamind2

We are also discussing to build an MQTT proxy which will wrap the communication, do AuthX/AuthZ, etc... then just proxy messages so you can use any broker you want, keeping the core simple just plug and play. IMHO this is good for NATS MQTT support but again full blown MQTT broker in missing :)

[derekcollison]

I am considering the support being part of the core. We already have a way to bridge auth domains with leafnodes from NATS 2.0 which is a very powerful concept and think we will see that in use quite a bit for IoT, deployables, mobile and web.

[ujwal-setlur]

Any updated timeline for availability?

[ColinSullivan1]

We're looking at Q4, for 3.1, 5, and SN support.

[drasko]

@ColinSullivan1 is this still on-track?

[derekcollison]

Depends on JetStream TBH but yes, late Q4 though.

[iotgopher]

is this still on-track?

[derekcollison]

Most likely Q1, JetStream taking up alot of time.

[vinayxbox]

We will be very happy if the NATS Server support MQTT out of the box. We use QoS-1. We use Mosquitto broker with Auth and ACL with Redis Plugin. We are exploring alternatives as we have observed Mosquitto performance is not sufficient for us.

[derekcollison]

Yes this is on the roadmap. We are doing the work on JetStream first which will be bundled into the server and provide persistence engine that will be needed for QoS-1.

Plan is Q1/Q2. We will start with v3.1 and QoS 0 and 1, but have plans for v5.0 and SN.

[igolaizola]

Any chances of having a "QoS-0 only" early version in order to avoid dependencies with JetStream/persistence?

[derekcollison]

NRE is possible, but lacking that most likely not. But I promise we are working as fast as we can. ;)

[max-koehler]

Is there a document to read up on what's planned for the first version or some way so see the current process?

[derekcollison]

Not yet, but fairly straightforward. Allow MQTT clients, even binary ones, to point to a NATS server and get full connectivity to all other MQTT clients (possibly bound to an account) and all other NATS clients for any size NATS extended cluster topology. We will support user/pass and client cert auth as specified by their spec. Plan to support QoS 0 and 1 for 3.1, 5.0 and S/N eventually.

[vinayxbox]

@derekcollison: When can we expect a tech preview for evaluation ?

[derekcollison]

We are hoping in Q2.

[vinayxbox]

Nats with MQTT will support the same performance as stock Nats protocol ?

[derekcollison]

We will aim to have the highest performance we can get, but since the protocol is very different there may be constraints there from a blocking request/response pattern.

[nmarcetic]

I do not doubt you will get great performance, the biggest concern is clustering & message persistence (QoS 1 and 2, retain message etc...) . This is where most of the brokers on market fails, at least in the opensource version. I am currently doing MQTT load test-ing with various brokers (both Mainflux impl but also native brokers). So far, I am really not happy...This is where I am expecting boom :bomb: from NATS and finally scalable MQTT broker that just works! :crossed_fingers:

[derekcollison]

As we complete clustering fro JetStream, the QoS 1 will use that so will inherit JetStreams persistence layer. Not sure about QoS 2 yet, does not seem to be wildly used and IMO is rarely implemented correctly. I think we did implement it correctly for TIBCO's EMS back in the 90s, but do not think it was worth it TBH.

The protocol, if it has any synchronous interactions, could also be a limiting factor.

[goireu]

QoS 2 (deliver at most once) is a very interesting pattern.

Suppose you want to send an SMS when a message is published on some topic. You want your subscribe-and-relay-to-sms software to send only 1 SMS per published message, not 2 because-of-some-network-issue.

More generally speaking I'd say:

• QoS 0 is for updating some unimportant value
• QoS 1 is for updating some important value
• QoS 2 is for triggering something (relaying, storing, reacting, ...)

[derekcollison]

QoS 2 or Exactly Once is extremely hard to get correct in practice. Most implementations get it wrong IMO.

[derekcollison]

We will look at it though, our team has done these before, but most customers really never used it in production.

[goireu]

That's the technical side of the coin, just talking about usage patterns here.

I would say "exactly once" needs to go along with a strong data storage mechanism, which is something MQTT brokers typically are weak about compared to, let's say, AMQP brokers. I agree MQTT users typically want updates more than triggers, eventually implementing triggers by deduplicating updates.

Maybe NATS can bring the best of both worlds, that would be amazing! 😃

[derekcollison]

Will do our best!

What AMQP brokers do you feel are good at data storage? Just curious.

[goireu]

What AMQP brokers do you feel are good at data storage? Just curious.

I'm not technical enough to answer this question with rock-solid arguments. I just observed in many places AMQP brokers being used to dispatch jobs and MQTT brokers being used to dispatch data. When dispatching jobs you want to avoid losing any of them. When dispatching data (especially updates) there are cases where you may lose some.

[timonsku]

We use QoS2 all the time in production. Whenever we have a trigger that absolutely has to happen and not more than once we rely on MQTT to do its thing and guarantee delivery of exactly one message. This is often hard to handle reliably on the client side otherwise.

[derekcollison]

I understand it is desirable, but in practice it rarely gives you what you want. Much longer conversation but you need to look closely at your state for processing a message and any state transformations, etc. and how they are linked to delivery and ack of a message.

[timonsku]

I never looked closely at how mosquitto implements QoS2 or our client libraries but in practice we never experienced an issue where it wasn't doing what its supposed to. What I did notice a lot is that many broker services and clients do not implement QoS2 at all. Amazon IoT and MS IoT service being a notable example.

[nmarcetic]

Hehe exactly @PTS93 , AWS IoT is a good example they have also a lot of limitations regarding connection. Google also doesn't provide QoS2. There must be a good reason :) I agree that most impl are wrong and in practice you with QoS 1 you will rarely get the message more than once + you can handle this on client-side. Both QoS 1 and 2 are actually hard to handle on client-side, storing msg etc...

[goireu]

My semi-educated guess for AWS/Azure not providing QoS2 is their underlying messaging infrastructure is not designed to provide this use pattern. Both offer an MQTT gateway to their messaging system, not an MQTT native broker.