
ØMQ - The Guide - brudgers
http://zguide.zeromq.org/page:all
======
graffitici
This is probably one of the finest documentations of all time. Doesn't just
guide you through the features of ZeroMQ, but actually teaches you about the
horrendously complicated task of programming distributed systems in an elegant
way. Everybody should have a read!

------
spotman
The 0MQ guide is one of the best pieces of documentation ever written. I read
it years ago and continue to refer to it periodically for both projects that I
use 0MQ for, and projects I don't.

It's simply a rad guide. Highly recommended.

~~~
PieterH
Thank you for this, I appreciate it. The Guide took a long time to write,
around a year. It was the first ZeroMQ project where I merged all pull
requests without code review. The results were amazing: most of the examples
are now in many languages, a Rosetta stone of distributed programming. This
was what convinced me that a "merge first, fix later" approach would work well
more broadly (and it has).

I'm rewriting the Guide slowly, as the software has changed and we've found
nicer, simpler ways to solve some of the harder problems.

There is a lot of new ZeroMQ-related material on my blog, at hintjens.com.

~~~
mdpm
And thanks for the culture&empire writeup too :)

------
mpdehaan2
My general experience with 0mq in the past (with a past team) has not been
great. While a nice abstraction library over sockets, sending it the wrong
parameter is quite likely to crash in painful ways in rare instances. Maybe
it's gotten better over the past year.

Yes, it's fast. But if you want a message bus and are going to want for
advanced features, I'd recommend a proper message bus.

It's going to abstract away some of the socket details, but you can still get
bitten pretty easily - again, may have gotten better in the last several
months, I don't know.

Be careful also with distros carrying older versions, you are probably wanting
to make sure you get the latest than what your distro may contain for the same
reasons.

~~~
PieterH
The original codebase used asserts rather poorly, for error handling rather
than internal sanity checks. Four years ago we had fixed most of these
problems, and had a "futzing" project to try to crash the library. Over time
we've removed the edge cases... the codebase did take a long time to become
properly stable, one of the downsides of lots of new code written rapidly, and
one reason we insist on small gradual patches these days. (There have been
_very_ few new errors introduced since we switched to our decentralized
contribution process in early 2011.)

~~~
mpdehaan2
Good to know. For what it's worth, the majority of my bad experiences were in
2013 to late 2014, and usually through the python bindings.

Usually calling the functions in differnt ways was able to dodge the problem.
It's not always quite obvious what caused it to crash, but it was sort of "if
it hurts when you do that" sort of thing. Often these types of errors happened
only under heavy traffic and were hard to replicate except under stress or
lots of repeated calls.

If not using the python bindings, it might be better off for most people.

------
antimora
Just recently I have found out that nanomsg is the successor of ZeroMQ. Does
anyone have an opinion about this new lib? I am curious how mature and stable
it's.

~~~
PieterH
Nano is excellent in many ways, though it's not a successor, that's just
bombast from its author. ZeroMQ is far more than a library. It is a large
community and hundreds of projects, e.g. independent ZeroMQ versions in Java,
.Net, C++, Erlang, C. Nano is one library and bindings.

Take a look at the git repositories and the email list and you really see the
significant differences. These aren't technical. They're why the ZeroMQ
community merges pull requests rapidly, and products tend to be stable on
master, while Nano has pull requests hanging for months, and isn't stable.

Nano should have been compatible with ZeroMQ, then it would have been a
successor and the protocols could have evolved over time to become what
Sustrik wanted. Instead it tried to define itself by one-upping ZeroMQ,
missing many opportunities. ZeroMQ has so much stuff built on top. Nano? So
little.

This is not accidental or random. The ZeroMQ community is welcoming to people,
and every effort is welcome, unless it's really disruptive. Nano is just a the
wrong side of hostile, arrogant, and insecure and it shows in the arguments on
the mailing list (which we just don't get on zeromq-dev).

Edit: by "not stable", I refer to its "0.5 beta" status, not any technical
instability. The point being there is no guarantee of forward compatibility.

~~~
cbetz
Small correction: There is a pure Go implementation of nanomsg
([https://github.com/gdamore/mangos](https://github.com/gdamore/mangos)).

~~~
PieterH
Ah, indeed, thank you. This is encouraging and I'd like to see more of this.
We need spaces for experimentation and competition, and the more libraries
attack this "NoBroker" space, the better. I do wish Nano would stand on its
own merits rather than the cheap "why we're better than ZeroMQ" marketing.
Also I'm somewhat disappointed that Sustrik isn't using Nano in his own new
projects (like libmill). That's not a great vote of confidence.

~~~
dragonwriter
> I do wish Nano would stand on its own merits rather than the cheap "why
> we're better than ZeroMQ" marketing.

IIRC, 0MQ launched with quite a lot of "why we're better than AMQP" marketing.

~~~
PieterH
True, and perhaps Nano was inspired by this. However look carefully and you
will see that we never, ever, criticized RabbitMQ. I know the team that built
it, they are friends, and we both invested crazy amounts of time in trying to
keep AMQP alive. RabbitMQ is an excellent product, built with cool technology.
The protocol is not so good. I designed it, I know its weaknesses. It is way
too complex, and strangled by a committee that could not innovate and
preferred to bully and lie its way to a "1.0" version that broke everything
and delivered so little it's barely a messaging protocol, let alone
"advanced".

It is fun to compare products. The competition between RabbitMQ and ZeroMQ was
deliberate, useful, and good for both projects. However for a breakaway
project to claim "we're the successor" is downright silly IMO. Hostile and
negative, and sets a terrible tone for a young project. And if you can't
achieve that, what then?

I find this rather sad, and looking at Nano's commit history, another of those
entirely predictable stories. Why would you want to supercede the ZeroMQ
community? It's large and successful and friendly. Why not simply make a
better ZMTP engine? Make it smaller, cleaner, compatible, and then over time,
improve the protocols... simple and undramatic and guaranteed success.

But no, we need drama and argument and hostility and... no matter how good the
code, the outcome is that contributors don't stick, the core developer gets
burnt out, and the project dies.

It happened to Crossroads, and Nano appears to be really just the same, in C.
The waste in time and effort is sad. We need projects like Nano. We need space
for new experiments. We need choice and competition.

I've spoken to some Nano contributors who are replacing Sustrik (who seems to
have abandoned the project), and things may improve. One hopes.

------
edward
The HTML for this page is 2.7MB. Somebody on the train to FOSDEM was telling
me that they use it as a test case for web browsers and HTML parsers.

~~~
PieterH
That's kind of cool. It's a full, large book complete with examples with full
syntax coloring. And still fits into less than 1/100th of a cent of disk
space.

------
lobster_johnson
I've been thinking about using ZeroMQ for RPC, but the one problem it doesn't
solve is discovery, ie. finding a peer to talk to among a dynamic pool over
which you'd like to load-balance. zbeacon looks promising until I realized it
uses UDP broadcasts.

You can do it with ZooKeeper or Consul, but then you have to roll that glue
for every app, or write a library which only you are going to end up using,
and you'll end up doing it for every language you implement in. We write a lot
of microservices, in all sorts of languages, and we'd like to move away from a
centralized load-balancer, which is both a bottleneck and a SPoF.

(gRPC looks like a great start, but I'm puzzled why they chose to ignore/defer
discovery. Plain one-on-one RPC is trivial, the difficult part is making it
completely distributed and fault-tolerant, neither of which gRPC seem to
address at all.)

~~~
jkarneges
ZeroMQ sockets can connect or bind, and this is independent of the socket
type. If you want to load balance requests against a dynamic number of
responders, just have the responders connect their REP sockets to a set of
bound REQ sockets.

~~~
lobster_johnson
But you still need to know the IPs and ports of the endpoints to connect to.
This is what I mean by discovery.

~~~
chisleu
ZeroMQ merely solves exposure of sockets as queues. In all distributed
systems, there must be a set of known hosts, or discovery becomes tedious. DNS
is an easy way to solve this.

~~~
lobster_johnson
ZeroMQ is an abstraction that hides a lot of complexity for you in the name of
convenience, and there's no reason why it couldn't abstract discovery, too.
Instead you have to build it from scratch for every client app.

~~~
chisleu
I guess I just see it as too easy to solve w/o adding custom complexity to
ØMQ.

------
ninjakeyboard
Ya this is a good read. I cut my teeth on this stuff. This guy here is good if
you're working with scala. [https://github.com/mDialog/scala-
zeromq](https://github.com/mDialog/scala-zeromq) mDialog were actually bought
by google so I guess it worked out well for them too:
[http://techcrunch.com/2014/06/19/google-acquires-
mdialog/](http://techcrunch.com/2014/06/19/google-acquires-mdialog/)

------
yaiu
It annoys me that ø is representing "zero"

~~~
PieterH
We've stopped using "ØMQ" in text and now just use "ZeroMQ" in most places
(like in the Guide). The original choice was to annoy people into remembering
the name... it kind of worked though got tiresome after a few years. I still
like the logo.

~~~
provemewrong
The worst part is that now you're left with people who don't quite know how to
call it. Just looking at the thread, you can see variations like ØMQ, 0MQ, ZMQ
and finally ZeroMQ all in both upper and lowercase.

------
chengas123
When would you use 0mq vs Google's grpc? What are the main differences between
them? I rarely hear them mentioned as alternatives to each other, but I
haven't been able to grasp the differences.

~~~
chris-hexx
grpc is Google's flavor of RPC, with transport and semantics specified for
you.

0MQ is an abstraction over raw sockets that lets you worry less about how
different parts of a distributed application find and talk to each other.

There's no real direct comparison; you can implement request/reply patterns,
like RPC, using 0MQ for the networking parts, but that's not all it's limited
to.

------
pekk
As a disinterested third party, I know there is some criticism of ZeroMQ and I
am interested in what that is about. When or why would you want to avoid
ZeroMQ?

------
chetanahuja
The fact that it's a LGPLv3 licensed library gives me pause to use even in our
backend infrastructure (never ever in code running on client devices). The v3
situation is so complicated that even fsf had to come up with a matrix to
explain how their own licenses play with each other. Not a very comforting
situation:

[http://gplv3.fsf.org/dd3-faq](http://gplv3.fsf.org/dd3-faq)

~~~
agwa
This is pure licensing FUD.

First, as complicated as the licensing interactions around the GPL may be, the
quite simple fact is that the (L)GPL's requirements only apply if you
distribute code, so there is no more reason to take pause when using an LGPLv3
library in backend infrastructure than there would be if you were using a BSD-
licensed library.

As for client devices, it _is_ possible to distribute proprietary applications
linked with LGPL libraries, though there are requirements you must follow. The
amount of time it takes to figure out and comply with those requirements is
minimal compared to the person-hours that went into developing ZeroMQ, which
you are getting for free.

Edit: apparently ZeroMQ includes a static linking exception to the LGPL, so
you don't even have to comply with the LGPL's most onerous restriction when
linking with ZeroMQ!
[http://zeromq.org/area:licensing](http://zeromq.org/area:licensing)

~~~
chetanahuja
Well it's FUD in the sense that I really, actually feel Fear Uncertainty and
Doubt about using any code under GPLv3 license. There's good reason to
[[https://www.google.com/search?q=gplv3+for+commercial+use&oq=...](https://www.google.com/search?q=gplv3+for+commercial+use&oq=gplv3+for+commercial)
] worry. Large companies I've worked in before this (with teams of technically
savvy lawyers on staff) have been known to promulgate an outright ban of such
open source software in their production stack.

Now, nothing makes me happier than being proven wrong in this case (especially
with the static linking exception AND this little nugget _" It is the
intention of the ZeroMQ community to move gradually towards the Mozilla Public
License v2, as a replacement for the current LGPLv3 + static link exception"_
).

So in a sense, my comment here has had a positive result not just for me but
also for anyone else reading this thread and worried about the license. So on
balance, I'd credit this subthread more for clearing up of FUD than the
reverse ;-)

------
e12e
Is this outdated wrt security for zmq 4.0+?

[ed: I see now that the latest version is just a release-candidate -- I
accidentally thought 4.0 was "out"]

~~~
PieterH
Yes, it does not describe the current security mechanisms. I've written
articles on my blog to explain those; they need to be reworked into a new
Guide text.

Version 4.0 is stable; there's a pending 4.1 update.

------
coherentpony
Not familiar with 0mq, but I'm very familiar with MPI. Does anybody have any
experience for how these compare?

------
curiously
any real reason you should use zeromq over rabbitmq?

~~~
zo1
ZeroMQ (in certain configurations) is broker-less if I recall correctly. The
clients connect to each other, rather than going through a broker.

Last I checked, ZeroMQ is more of a "low-level" library/framework that
provides easy-paths to more higher-level functionality that would be
comparable with what you'd expect from a standard message queuing system.

Anyone got a different take from it? I only did the tutorials quite a while
back.

~~~
jkarneges
Yep, it's best to think of ZeroMQ as networking library than an "MQ". It makes
communication between processes easier than writing BSD sockets code by hand.

For example, the Mongrel2 web server uses ZeroMQ to drive backend handlers.
You probably wouldn't dream of transporting HTTP requests and responses over a
brokered message queue, but ZeroMQ is different since it's "just sockets".

