NATS – An open-source, high-performance, lightweight messaging system
nats.io
nats.io
* clustering - what kinds of clusters are supported? How do they scale? Do they favor availability or consistency?
* security - is there any authentication? authorization for certain resources? TLS?
* guarantuees for delivery? Transactional modes?
* what does the wire protocol look like? Support for meta data?
I clicked around the website and documentation a bit, and didn't find any answers.
There is no persistence so consistency is irrelevant. NATS does everything in the name of availability to the point of dropping connections for slow consumers.
> * security - is there any authentication? authorization for certain resources? TLS?
TLS is planned, not sure on timeline. It sounds like Apcera has plans for some form of authentication and multitenancy as well.
> * guarantuees for delivery? Transactional modes?
At-most-once delivery. No transactions. There may be some form of more reliable delivery coming in the future, but I'm not sure of the details.
> * what does the wire protocol look like? Support for meta data?
Very simple text-based protocol. I don't think it's formally documented anywhere currently though.
(Disclaimer: I work for Apcera)
Cloud Foundry still has a bunch of NATS-based services because Derek was one of the founders of the first versions, back when Cloud Foundry was a VMWare skunkworks effort (VCAP).
Disclaimer: I work for Pivotal Labs, a division of Pivotal, which contributes the largest amount of engineering effort to Cloud Foundry. Apcera is, nominally, a competitor. I should also mention that my understanding of CF's early history is based on accounts I've heard and might be flawed.
For many use cases, the lack of persistence might be a showstopper, though.
Please feel free to ping me with further questions, comments, ideas etc if you'd like to chat further: brian@apcera.com
It would be helpful to understand what you are trying to achieve, and what characteristics in messaging infrastructure are most important to you?
http://bravenewgeek.com/dissecting-message-queues/
"ZeroMQ is capable of sending over 5,000,000 messages per second but is only able to receive about 600,000/second. In contrast, nanomsg sends shy of 3,000,000/second but can receive almost 2,000,000."
So.. nanomsg is 10x faster. Why would one use nats?
The article comparing the performance of all those messaging systems conveniently "groups" them into two groups. Brokerless, and brokered. Putting Nats into the latter, despite it not sharing any of the main things that we are used to with a brokered system. I.e. Transactions and persistance.
So, it's safe to say that in that context and those properties, there is no reason to use NATS over nanomsg.
NATS requires a broker, ZeroMQ doesn't (though it generally supports a "forwarding device", which -- in the absence of transactional semantics as it is in NATS -- is mostly indistinguishable from a broker).
From the user's perspective, ZeroMQ provides a superset of the functionality, and a superset of the topologies. Why would you say the comparison is unfair?
A proper comparison would need to include the forwarding device for ZeroMQ.
> Obviously the latency of going over the wire once is going to be lower than going over the wire twice.
Latencywise, and all things being optimal, yes. But not all things are optimal.
Throughputwise, and all things being optimal, there shouldn't be any difference. But there is a huge one on both receive and transmit.
NATS and ZeroMQ are obviously not equivalent, but I maintain that this is an apples-to-apples proper and useful comparison, even without the forwarding device.