hintjens

RabbitMQ has always been an extraordinarily good piece of software, from the very first versions. I think this is very good news for anyone using Docker.

Perhaps that is how you saw it. However you are dramatically wrong. ZeroMQ v4 does full end-to-end encryption, supports protocols like TIPC, and (you knew this but choose to forget it for reasons I never understood) entirely changes how we write multithreaded applications.

The only plausible reason you could disregard the magic of using the same semantics for secure internet messaging and inter-thread messaging is that you don't write applications.

Yes, god forbid you'd stop your production chain just because you found an internal consistency error that could potentially wreak havoc with your data. Oh, wait, that's exactly what you should be doing. If you write C/C++ without asserts, you are driving fast and drunk without a seat belt.

Luckily it's a free world so you are more than welcome to take libzmq, strip out all the asserts, and launch your new improved fork! Why even debate this? Please remember us when you get rich and famous.

That's a fair assumption and accurate for a lot of the bindings. It is true that there are a lot of bindings for ZeroMQ and many were weekend projects for a single project. However it's normal and expected in a large community. To treat that as significant is like saying, "I find a lot of abandoned HTTP server projects, so this 'Web' thingy sure looks doubtful."

It's no different than any significant technology that has few antecedents. Once you know the background and cast away assumptions and fallacies, it's much easier of course.

Yes, the over-conceptualized abstractions can be annoying. However if you read the RFCs that specify the patterns, http://rfc.zeromq.org/spec:28, http://rfc.zeromq.org/spec:29, http://rfc.zeromq.org/spec:30, and http://rfc.zeromq.org/spec:31, you will see that each pattern encapsulates more than just the routing model.

When you send() you also need to express how exceptions are handled -- what happens when there are no peers, and what happens when their buffers overflow.

Martin Sustrik did a fine job when he designed those patterns because they are (so far) watertight containers for rather tricky semantics.

Most people just type "zmq", and the name is "ZeroMQ", with the unwriteable shorthand acting as a kind of text logo.

Indeed. The original "sockets on steroids" story was wrong, though sincere. Sockets are the API but the actual machine underneath is nothing like a BSD socket. ZeroMQ has in the last years moved away from the "it's a BSD socket" metaphor as it is a tediously limiting API in many ways, and created the unnecessary confusion that I wanted to pick on in this story.

You do realize the page is humor, right?

A serious explanation of ZeroMQ takes 500 pages and several weeks to read.

In 1.75 to 3.5 billion years? Not for long?

It's not an either-or choice. Salt's security is good but it's been a request from that team, as from others, to get security into the libzmq core. Doing it at the application level is problematic for many reasons. It's unreasonably complex, and does not play well with 0MQ sockets (many of which like PUB-SUB and PUSH-PULL are unable to do two-way negotiation).

With CurveCP you can still use TLS for key exchange itself; what CurveCP provides is a highly robust answer for the actual connection: short term keys and nonces. It's new but so is Salt's crypto algorithm, which was not built to quite the same level of paranoia as CurveCP.

We're still some time away from working code in libzmq and as much as a year or two from a crypto layer that's properly hardened. Having it in libzmq will mean it gets much more attention, which can only be good.

The Salt security layer is great, and I've worked with Thomas Hatch on abstracting it for wider use. We wrote this http://www.zeromq.org/topics:pubsub-security some time ago.

While it's good, it has a number of weaknesses that CurveCP addresses, and which CurveZMQ includes. The parts of CurveCP that we don't implement are quite specifically to do with traffic control over UDP, name resolution, etc. and not security.

The second problem with Salt's security is that it's not inside 0MQ but layered on top. This has a number of consequences such as interoperability and reusability.

Our goal with CurveZMQ is to put this into the 0MQ kernel so it's available across all socket types. It will work over PUB-SUB as well as ROUTER-DEALER or PUSH-PULL. It will work over any intermediaries and since it's basically CurveCP, it will let you do things like migrate your clients (changing IP address) without re-establishing the secure session.

CurveCP is really awesome and worth learning. It is really the security model we've been looking for for years, for ZeroMQ.

The big difference between CurveZMQ and TLS is this: using TLS is complex.

One of the visions of NaCl and thus CurveCP and CurveZMQ in turn is that simple is more secure than complex. Users can't make as many mistakes.

CurveCP and CurveZMQ are simple. The current code for CurveZMQ is under 700 lines of C (assuming you have libsodium) and I didn't try to abstract any of the encryption calls; it's a flat implementation of the CurveCP handshake.