
0MQ: A new approach to messaging - signa11
http://lwn.net/Articles/370307/
======
sophacles
One of the really nice things about 0mq is that it takes care of all the
annoying bits, without doing too much to your "networking model". By way of
example: I was at the middlware2009 conference, and I was implementing
algorithms that presenters and their papers discussed, and doing it very
quickly because of 0mq. Basically hundreds of lines of code about 'crap i need
to send that to x,y and z' went away. Lots of other little details like that
went away too -- sockets without the mess. On the other end, I did not have to
try and rework various algroithms in terms of overt pub/sub channels, or
message queue parameters. It is a good product.

------
simonw
Good article, and some excellent comments at the end including a discussion of
AMQP v.s. 0MQ v.s. RestMS from someone who has been involved in the design of
all three.

------
moe
I'm still hoping for a _simple_ protocol with strong guarantees and
persistence. RabbitMQ seems to be a very good backend implementation but its
the choice of AMQP for the main protocol is a pity.

AMQP is a ridiculously over-engineered monstrosity and a saturn-sized ball on
a chain for any project.

~~~
mahmud
Seriously. Roll your own over Redis.

Redis is faster than BeanStalkd, a tiny message queue server written in C that
uses libevent and a simple memcached-like protocol. Redis kicks ass, specially
the beta versions.

~~~
moe
Redis is a k/v store, not a queue.

~~~
mahmud
Key == mailbox/slot, and value == message. All you need are concurrency
primitives, and broadcasting (in the case of a distributed queue)

People have modeled message queues with far more primitive solutions:

[http://www.freeopenbook.com/php-hacks/phphks-
CHP-5-SECT-18.h...](http://www.freeopenbook.com/php-hacks/phphks-
CHP-5-SECT-18.html)

A Redis based solution might not be as elaborate as RabbitMQ, but it will be
very clean and straightforward, not to mention blindingly fast, and will get
the job done.

~~~
moe
Well, I'm quite skeptical about the "blindingly fast" part (network overhead?)
but agree that in the light of the current mq-options that's indeed one of the
more appealing ideas.

That said, I'm not really in the mood to reinvent that particular wheel myself
here, but would probably give someone else's shot a try.

------
vegai
I've been looking at beanstalk, and I like what I see.

Simple protocol, main implementation 6000 lines of non-awful C, libevent...
What's not to like?

<http://kr.github.com/beanstalkd/>

------
z8000
From one of the comments on that page:

"Likewise, neither 0MQ nor AMQP works on Internet scales, where RESTful
principles become more important than immediate performance."

I don't follow this logic. Can someone help me understand why 0MQ would not be
appropriate at "Internet scales" (and I presume "should" be relegated to
LANs)?

I ask because (1) it looks great for a general transport at any "scale" and
(2) the article itself discusses a scenario in which 0MQ could be used over a
WAN (branch offices, the forwarder, etc.).

What am I missing?

~~~
Nwallins
I think what he is saying is that a general internet "service" is better off
providing a higher-level REST interface instead of a 0MQ interface.

~~~
z8000
OK, I suppose the keyword there is "general". In that context I cannot argue
with the idea.

------
mleonhard
Looks interesting, but the documentation is still incomplete. For example, the
zmq_connect() docs don't list error codes for name lookup failure, connect
timeout, or connection reset. There also don't seem to be sockopts for setting
timeout lengths.

Looking at the API, how could my application detect that messages aren't being
delivered to a particular peer?

~~~
mato
We're working on the documentation, but don't let that stop you from joining
in and helping us improve it!

As for detecting that messages aren't being delivered to a particular peer, at
the moment that is not possible since zmq_send() is asynchronous from the
point of view of the caller, i.e. the actual sending gets offloaded to a
background thread.

Unfortunately there's no straightforward way to map asynchronous error
handling onto the socket API. I guess we could experiment with hitting the
calling thread with a SIGPIPE or similar but signal handling on a lot of
systems is suboptimal (to put it politely) and we also need to support Win32.
So this whole area requires more thought...

------
mahmud
It's usually written as ZeroMQ, FWIW.

~~~
sophacles
Im not sure where you get your info, on the dev list 0mq, zmq (and
zmq_$COMPONENT) and zeromq are pretty evenly distrbuted...

(edit: yoru -> your)

~~~
lambda
Actually, all over the front page I see ØMQ, not 0MQ. It's read "zero", but
it's spelled with a slashed capital O.

~~~
Nwallins
Many fonts use a slash or a dot in the center of the zero in order to
distinguish it clearly from capital-oh. i.e. It's clear to me they are
branding this as 0MQ.

~~~
mahmud
True story. In my teens I got a hold of the BBC Micro assembly programming
manual; 6502, in all its 8-bit glory. I didn't understand much English, and I
haven't had much 1-on-1 time with a computer in my life (paper hacking) so
when I got that book, I was completely dumbfounded and confused by the zero
with a strike through. I have never seen this symbol before in my life, and
now I don't see it anywhere on the keyboard. _sigh_.

Good news though. A few months later I was programming in Forth, learning from
a self-xeroxed copy of Starting Forth, and it had the zero-slash everywhere. I
am not sure when did I realize that Ø == 0. (It looks like the empty set, aka
"phi" Φ)

[Edit: <http://en.wikipedia.org/wiki/%C3%98_%28disambiguation%29> ]

