It's probably a bad idea to use durable sockets for reliable pubsub (I know I documented this in the Guide but that was before it became clear that this functionality is kind of bogus).
Explicit identities are dangerous for servers since they create entropy (state accumulation) unless (and even) if you set strict high-water marks.
They're also a real pain internally and as part of simplifying 0MQ's construction we eventually want to get rid of them.
There are better ways to keep and synchronize state among a set of subscribers. See the detailed Clone pattern in Ch5 of the Guide, for example.
1. The 0MQ devs originally got asserts backwards, using them to validate external input (e.g. on sockets) instead of internal consistency. We've been fixing this for a year or two now, and it's pretty good. You'll get assertion failures if you e.g. use sockets from multiple threads. Not so much if you pass bad stuff onto sockets.
2. 2.1 was a great step forwards, and the use of "sleep" was in toy examples. Real networking apps tend to run forever, so this message loss at exit wasn't a big deal. You're right that the product is still young.
3. Totally agreed, this lack of peer presence detection is annoying, and the source of some debate on the lists.
4. Threading model works fine for me, I've used it extensively. A usable reactor is a hundred lines of code, no more. See the libzapi zloop reactor, in C, for example.
5. Demultiplexing sounds like useful functionality but should probable sit above sockets.
Before I opened the 0MQ Pandora box I'd given up coding and was happily writing my autobiography. 0MQ seemed like a pleasant way to spend a weekend. But before I knew it, I'd lost control. Days, weeks, months have passed now, all I think about are more subtle and perfect messaging patterns. They flash before my eyes. Weird names and topologies. It doesn't get better, but worse. Soon I'll be coding all nighters, my wife will leave me, my kids will forget me, and all I'll be doing is programming, motherfucker.
Seriously, 0MQ has made network programming fun (again) in a bad, addictive, way. Any design I can think of turns into real working code in a few hours, sometimes days. And I'm using C, a language that isn't normally fun to work in.
Right now, it's multithreaded clients and servers for resilient shared distributed hash maps. Tomorrow, network-wide logging. After that, another message broker. And so on.
Yes, it's a negative experience. I'd like my old lazy life back.
I've already been there working with all the apis I use on unscatter.com fortunately with 2 kids I have to stop. Though I have had some very tired weeks when I can't sleep cause I am up all night coding
It is challenging to explain anything subtle, when your viewpoint depends so much on what you already know, your preconceptions, and assumptions.
Sorry for the comic book style. It's how my mind works. Feel free to send a patch. :)
The benefits of 0MQ to me, as a programmer, are:
* Really easy to write utterly solid multithreading code, in a language (C) that has zero support for this;
* Really easy to take this same code and make it multiprocess, or multibox, with few changes.
* Built-in handling of asynchronous I/O, which I need in any real application.
* Speed, meaning I can be lazy and my code still runs very quicky. This is less obvious than it seems. 0MQ's critical path is extremely evil.
It's so hard to explain this with a diagram or a slideshow. The only way to understand is to use it, to write code with 0MQ. Certainly for me, when I started programming 0MQ apps, my understanding of what this library was about, and what it could do for me, totally changed.
Significantly simpler, faster, and more general. MPI is like one of the patterns ZeroMQ provides (the pipeline pattern) with a lot on top. That makes it great for parallel programming, but not so great for (e.g.) data distribution (pubsub) and other forms of message queuing.
Badly designed, anything can become hell. Crazy has no limits. The point of the talk was that message passing is fundamentally not at the same level as mutexes, semaphores, and monitors. Shared state does not scale linearly, no matter how well you use it, whereas message passing does, given cheap, fast, universal messaging.
A message queue is shared state. It may be more convenient shared state, and since it only needs to be got right once it might be more bulletproof shared state, but you have multiple threads that are serialising on access to a queue no matter how it is implemented.
You're right that a message queue is shared state and has to be gotten right but that can be done (and ZeroMQ does it) without locks. It's thus invisible to application developers. You're wrong to say that multiple threads serialize on a queue no matter how it's implemented. ZeroMQ lets threads write full speed to a queue while another thread reads full speed from the queue, without wait states.
:-) If you hope for enlightenment from watching a 10-minute talk, you're going to be disappointed. I do like your summary of the presentation... "Concurrency is hard... Actors... ZeroMQ... End scene!". Nice.
Enlightenment requires that you change in some way. For me, like many people who have taken the step of downloading and learning 0MQ, the feeling of "wow, this is too easy, where's the catch?" comes only after a few days writing code, and then your brain makes a slight adjustment, and it's all obvious, and that is a small but real enlightenment.
It's great to get feedback on the talk. Impossible to even introduce 0MQ properly in 10 minutes, so this presentation was really just to drive discussion. I'd apologise for the polemical title but that's just how I talk.
To some of the comments here...
- Parallel programming may be taught in CompSci courses, for sure, and it's a popular use for 0MQ, but (a) it's not applied to mainstream application development, and (b) it is not designed to scale to networks of any size.
- The Actor model is not key to building a successful message-based concurrent application, but it's a good example, and helps people understand that there are alternatives to shared-state concurrency.
- It's IMO useless to ask people to learn Erlang or Scala to get message based concurrency. People use Java, C, C#, PHP, Python, and probably still COBOL somewhere. So the challenge is how to give this mainstream a toolset that lets them build large parallel applications.
Perhaps next year at FOSDEM we can do a devroom and take the time to see a real application evolve from a simple stand-alone process into a real distributed one. 0MQ is very hard to grasp as a theory, one needs to actually use it for a few days before the beauty a cheap, universal, fast, intelligent, easy to use, and asynchronous queuing messaging fabric hits home.
I've glanced at the 0mq sources a bit, and I'm curious about the error handling. For example,
zmq::tcp_socket_t::read() handles following errnos from recv(): EAGAIN, EWOULDBLOCK, EINTR, ECONNRESET and EPIPE. If recv() fails for any other reason (e.g. ENOBUFS, ETIMEDOUT) and returns -1, the following is performed:
errno_assert (nbytes != -1);
which translates to
#define errno_assert(x) \
do {\
if (unlikely (!(x))) {\
perror (NULL);\
fprintf (stderr, "%s (%s:%d)\n", #x, __FILE__, __LINE__);\
abort ();\
}\
} while (false)
The first thing I noticed is the use of perror() and fprintf() for error reporting. Any daemon that closed its stdin/out/err and not had them redirected to /dev/null will most likely output errors to other file descriptors (sockets, other open files etc.). Is this by design or something that was missed?
Secondly, the use of abort() in an API is probably also not the best choice. Say I'm writing a (robust) database server and an error happens on one connection - the error will bring the whole server down, which kind of defeats the purpose. Is this also by design?
0MQ has what is called a high-water mark on (outgoing) queues. You can then decide whether to block if the queue gets full, or poll the socket to know when it's ready for output. This is also how TCP works. 0MQ abstracts the complexities of the network that you don't want to see, but it exposes those parts you still need to. It would make a very nice transport for file transfer, and I'll probably add such an example to the 0MQ Guide.
Explicit identities are dangerous for servers since they create entropy (state accumulation) unless (and even) if you set strict high-water marks.
They're also a real pain internally and as part of simplifying 0MQ's construction we eventually want to get rid of them.
There are better ways to keep and synchronize state among a set of subscribers. See the detailed Clone pattern in Ch5 of the Guide, for example.
http://zguide.zeromq.org/page:all#A-Shared-Key-Value-Cache-C...