250bpm

I love reading about this, I'm currently researching on a good way to build a pubsub system for command-and-control for a possibly very large network. I think ZeroMQ will be more than sufficient (even Redis will do, which I'm also looking into because it could work as both a db and a pubsub system). However that doesn't stop me from reading op on good or better ways to do it in my spare time!

You're writing style is very clear (and the pictures help a lot too). Is the work on nanomsg every going to be merged into zmq or will it forever be separate? Does it have other goals or…?

Thanks for the article,
Nicolas

Thanks for kind words!

The two projects will stay separate. The main reason is that they have incompatible licenses (LGPLv3 for ZeroMQ, MIT/X11 for nanomsg.

In theory nanomsg, thanks to its permissive license, could be merged into ZeroMQ, however, that would leave users with a need for permissive licensing locked out, so it's not going to happen.

Good to know!

I was just browsing the source on github, and it usually strikes me that well-written C is such a joy to read compared to most C++ projects I encounter (another good one that's totally unrelated: BlendELF on github). Of course, clear directory structures and file naming always help. Good luck with nanomsg, it's very interesting and I hope to do some work with it once it matures a bit more (unfortunately don't have the time to help out developing it right now, maybe later!)

I've written two lengthy article about why I opted for C instead of C++, but in the end you are right: C code just looks better :)

Have you considered making subscriber matching algorithm pluggable? For example a matching algorithm with a small subset of regex could be implemented using finite automata.

Yes. That's the plan. Pluggable filters were once implemented in Crossroads I/O and I would like to implement the same thing in nanomsg.