It is worth looking at Sustrik next project: http://nanomsg.org/ which is still in alpha version. ZMQ rewritten. He's got awesome blog http://250bpm.com/blog where he mentions lot of things that he decided to do differently in nanomsg and the reasons behind it. Check out: http://250bpm.com/blog:23 (I hate ZMQ contexts) and http://250bpm.com/blog:22 (how we are doomed to rewrite protocols on top of existing protocols and solving same problems again). His other blog posts are also of a great quality.
The thing I most dislike about 0MQ is the overly conceptualized socket typing (ZMQ_DEALER etc), and the way the documentation tries to cram all the combinations in to idiomatic 'patterns'.
All I want to be able to express when I send() is:
1. Whether it's a Broadcast, Unicast or Anycast message
2. Whether I'm sending globally, or targeting a
subset of peers (subscribers to some filter).
Target Method ~0MQ socket type
Global broadcast -> ZMQ_PUSH
Global unicast -> ZMQ_PAIR
Global anycast -> ZMQ_DEALER
Subscribers broadcast -> ZMQ_PUB/SUB
Subscribers unicast -> ZMQ_REQ/REP
Subscribers anycast -> ZMQ_ROUTERThe core of "0MQ is just sockets" argument is that it doesn't do the main reason while MQ systems are used instead of, say, sockets - persistence and guaranteed delivery if some endpoints die.
All the arguments in the article are about the fact that it does messaging really good with lots of features, but it doesn't have the queue part at all.
Sure, you can build that yourself on top of 0MQ, but I'd say that building the 'guaranteed delivery' part properly is the hard part of an MQ system.
I may be nitpicking irellevant details, but I just can't help it.
Why are they using the Norwegian/Nordic letter Ø (pronounced almost like "uh" in English) in their name, a letter most people in the world can't type, if they want to get traction?
This may be a reference to 'What have the Romans ever done for us' in 'Life of Brian'. http://www.youtube.com/watch?v=9foi342LXQE
The important detail they miss out is that there's no broker and no (built in) persistence, and that sucks when parts of your critical messaging infrastructure go down and you lose messages you thought had been sent.
been looking into this recently. it seems like a lot of the bindings haven't been maintained in 2+ years, but the pure java implementation JeroMQ is very active and convenient to use (https://github.com/zeromq/jeromq)
the name reminds me of jero, the american-born enka singer (https://www.youtube.com/watch?v=ba9rKhVAz80)
i'm not entirely sure if i personally could come up with a good usage for zmq though, unless i were going through tons of data from sources like social media or scientific experimentation
Pretty good explanation. I really appreciate such presentation "by analogy", carefully comparing a technology with something very well known. It provides another angle from which understanding is improved.
I think of 0mq as being a really powerful prototyping tool. If you require guarantees or complex topologies, it will save you a good amount of work to get the thing running. I have never gotten low latency from it, but I know that others have with some effort.
And asserts. Sockets and asserts.
ZeroMQ markets itself as sockets on steroids, and this hypothetical exchange is to clear up any (hypothetical?) confusion stemming from their own messaging?
I like 0MQ a lot, but this is disingenuous. Let's break it down:
> portability
Sockets are just as portable, more so on UNIX descendants where one can rely on relatively consistent socket APIs. Beyond that, almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.
> message framing
Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
> super fast asynchronous I/O
Sockets have this.
> queuing
Sockets have buffers. The OS can use those buffers to implement flow control. This isn't the same as queueing, but the truth is that you rarely want blind background queueing of an indefinite number of messages that may or may not be delivered.
> support for every bloody language anyone cares about
Just like sockets.
> huge community
I don't think you can get 'huger' than the community around sockets.
> price tag of zero
Seeing as socket libraries ship with everything, does that mean they have a time/resource cost of less than zero?
> mind-blowing performance
Also, sockets.
> protection from memory overflows
This has essentially nothing to do with a networking library. Plenty of environments have safe/efficient zero-copy chained byte buffer implementations/libraries.
> loads of internal consistency checks
Library correctness isn't a unique feature.
> patterns like pub/sub and request/reply, batching
Ah-ha! Here finally we get to the meat of it!
If you need QUEUES, including pub-sub, fanout, or any other QUEUE-based messaging structure, than 0MQ is better than sockets!
> and seamless support for inter-thread transport as well as TCP and multicast
Inter-thread transport of already-serialized messages at the transport protocol layer doesn't make a ton of sense from an efficiency perspective.
> ZEROMQ IS JUST SOCKETS
No, 0MQ is a lightweight network message queue protocol. It's not competing with sockets.