It's simply a rad guide. Highly recommended.
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.
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.
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.
If you're looking for an AMQP-compliant message bus that can be federated and clustered, RabbitMQ is pretty damn amazing.
In our stack it's the buggiest, most unreliable piece of software we are running, and it's falling over (losing cluster state, hanging, crashing, etc) on an almost daily basis.
We used to run 8 nodes, and it was a nightmare recovering from partitions. Now we've reduced it to 2 per cluster, and it's still a nightmare.
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.
IIRC, 0MQ launched with quite a lot of "why we're better than AMQP" marketing.
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.
I haven't used it much, since there's no way to switch from ZMQ without losing wire-protocol compatibility, and I haven't started any new projects that need IPC recently.
Pretty cool stuff.
I found that over time the memory consumption would rise horridly and I had to stop using it. I've just had another sanity-check of my code and don't spot an obvious leak, but I'm willing to believe it is there:
Otherwise though using nanomsg was a pleasure, and I have it in use elsewhere without problems.
there is a writeup in the docs how nanomsg differ from zmq: http://nanomsg.org/documentation-zeromq.html
This is an exceptionally strong argument for well-coded, self-contained, static pages.
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.)
It's an emergent problem. One good pattern that's emerging are clusters of clusters; e.g. each box supports a cloud of small services that talk to each other and to a single broker on the box, and the brokers on a network then discover each other opportunistically with a mix of broadcasts, manual assistance, and gossip.
There are many solutions to what you want to accomplish and each one has its fans. I personally like smartstack because it combines two very mature and battle tested technologies: Zookeeper and haproxy.
Your Python examples of server and client use the unicode ellipsis (\xe2) which breaks Python2.
ØMQ pronounced correctly would have been a horrible name anyway though.
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.
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
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 ;-)
The gaming industry is however a very competitive one, where every choice is critical. A company there could not survive if they took unnecessary costs. Yours might be different, so maybe the competition won't eat your lunch while you are busy reinventing wheels. Do a risk analysis and decide how much money and time it is worth, and ask yourself what happens if a competitor happens to be in the exact same spot and decided to instead go with the free alternative.
[ed: I see now that the latest version is just a release-candidate -- I accidentally thought 4.0 was "out"]
Version 4.0 is stable; there's a pending 4.1 update.
There are things you just cannot do with AMQP and thus RabbitMQ. The main one, and why we originally started ZeroMQ, was multicast from publishers to subscribers. How else can you get message rates of millions per second?
ZeroMQ (and Nano and the many similar efforts that have come to life since we started) gives every process the same capability. Your laptop can talk directly to ten thousand peers, and do it rapidly.
We do have a broker, Malamute, which works nicely for various patterns. I use this in lots of projects. However not in the conventional sense of starting a process on a box somewhere. I use Malamute as an actor thread, to coordinate events and workload between other actor threads, in a single process.
ZeroMQ makes this kind of scale magic quite easy. Take a look at the CZMQ library and you'll see how wise use of ZeroMQ transforms even an old language like C. Thread-to-thread messages work the same way as process-to-process messages. You can't even think of such things using AMQP.
It does change the way you build distributed systems.
I hate Celery and I hate RabbitMQ because it was so difficult to get stuff working the way I wanted which makes me wonder if it would've been better if I just wrote my own simple job queue.
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.
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".
It really requires that you can eat messages off as quick as you can put them on the queue, or else it slows down -- which means you can't pull them off as quickly, and then things basically get to "cascade failure" type problems.
Maybe others have other experiences - Rabbit is fast, but I'd probably evaluate other options if you want your queue to actually, well, queue.
recommended read: http://zeromq.org/topics:omq-is-just-sockets
"We investigated different solutions to find something suitable for our needs. We tried different message brokers (RabbitMQ, ActiveMQ Apollo, Kafka), but failed to reach a low and predictable latency with any of them."