
ZeroMQ is just sockets - bmaeser
http://zeromq.org/topics:omq-is-just-sockets
======
strumptrumpet
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.

~~~
rumcajz
Original 0MQ author here. Pretty good analysis. The only real difference
between 0MQ and sockets (i.e.traditional L4 transports such as TCP or UDP) is
that it implements messaging patterns such as pub/sub or req/rep. You can
think of it as a L5 layer designed to orchestrate communication between N
endpoints (as opposed to 2 endpoints as is the case with TCP).

~~~
hintjens
Perhaps that is how you saw it. However you are dramatically wrong. ZeroMQ v4
does full end-to-end encryption, supports protocols like TIPC, and (you knew
this but choose to forget it for reasons I never understood) entirely changes
how we write multithreaded applications.

The only plausible reason you could disregard the magic of using the same
semantics for secure internet messaging and inter-thread messaging is that you
don't write applications.

~~~
mjs
(FWIW, parent commentator more or less co-founded ZeroMQ with the grand-parent
commentator; rumcajz left the project and is now working on
[http://nanomsg.org/.](http://nanomsg.org/.))

------
calineczka
It is worth looking at Sustrik next project:
[http://nanomsg.org/](http://nanomsg.org/) which is still in alpha version.
ZMQ rewritten. He's got awesome blog
[http://250bpm.com/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](http://250bpm.com/blog:23) (I hate ZMQ
contexts) and [http://250bpm.com/blog:22](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.

------
nly
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).
    

Forgive me if these mappings are flaky, it's been a while since I used 0MQ.

    
    
      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_ROUTER

~~~
hintjens
Yes, the over-conceptualized abstractions can be annoying. However if you read
the RFCs that specify the patterns,
[http://rfc.zeromq.org/spec:28](http://rfc.zeromq.org/spec:28),
[http://rfc.zeromq.org/spec:29](http://rfc.zeromq.org/spec:29),
[http://rfc.zeromq.org/spec:30](http://rfc.zeromq.org/spec:30), and
[http://rfc.zeromq.org/spec:31](http://rfc.zeromq.org/spec:31), you will see
that each pattern encapsulates more than just the routing model.

When you send() you also need to express how exceptions are handled -- what
happens when there are no peers, and what happens when their buffers overflow.

Martin Sustrik did a fine job when he designed those patterns because they are
(so far) watertight containers for rather tricky semantics.

~~~
nly
Yeah, I'm sure there are loads of technical details... but I can't help
feeling there are parallels with the over zealous use of 'patterns' in OOP.

When I started out with 0MQ I felt sucked in to a world of combinatorial
explosion where I always have to think about what _type_ of socket is at the
other end of of a connect()... it just doesn't feel right to me.

~~~
angersock
These "patterns" exist because people like you want to gloss over the "loads
of technical details". :)

~~~
nly
Just the opposite.

------
PeterisP
The 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.

------
josteink
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?

~~~
rahoulb
I assume it means "zero with a line through it" which was used on older
computers to distinguish zeroes from the letter O on low res screens.

~~~
lloeki
Or empty set as noted by Bourbaki. I can't help but read it that way anyway.

~~~
tel
That's always been my reading as well.

------
pflanze
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](http://www.youtube.com/watch?v=9foi342LXQE)

------
rwmj
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.

~~~
leokun
If you read the name as "zero message queue" is it surprising that it doesn't
have persistence? There's no message queue.

~~~
skue
> There's no message queue.

I believe all the socket types except REQ and REP do have incoming/outgoing
queues. There's just no requirement for a broker to serve as an independent
queue.

~~~
memracom
Yes, your applications do have queues for incoming/outgoing messages but there
is no "message queue" A "message queue is an external thing that provides some
kind of service but with ZeroMQ that external thing does not exist. If you
sometimes need an external thing to provide delivery guarantess and
persistence, then it is easy to connect RabbitMQ to accept/send ZeroMQ
messages. Or just make your own shim process that translates to/from AMQP.

------
kimagure
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](https://github.com/zeromq/jeromq))

the name reminds me of jero, the american-born enka singer
([https://www.youtube.com/watch?v=ba9rKhVAz80](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

~~~
cremes
The library API hasn't changed much in the past 2 years, so why would you
expect the bindings to change? Just for the hell of it?

The latest release (version 4) has added a few new functions, so all of the
bindings are undergoing some _minor_ revision now to support the new calls.

~~~
buckbova
For me, if there hasn't been activity for several years and I can't find it
being widely used then I assume it abandoned.

~~~
hintjens
That's a fair assumption and accurate for a lot of the bindings. It is true
that there are a lot of bindings for ZeroMQ and many were weekend projects for
a single project. However it's normal and expected in a large community. To
treat that as significant is like saying, "I find a lot of abandoned HTTP
server projects, so this 'Web' thingy sure looks doubtful."

------
eliben
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.

------
krenoten
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.

------
do_easy
And asserts. Sockets and asserts.

~~~
hintjens
Yes, god forbid you'd stop your production chain just because you found an
internal consistency error that could potentially wreak havoc with your data.
Oh, wait, that's exactly what you should be doing. If you write C/C++ without
asserts, you are driving fast and drunk without a seat belt.

Luckily it's a free world so you are more than welcome to take libzmq, strip
out all the asserts, and launch your new improved fork! Why even debate this?
Please remember us when you get rich and famous.

------
macspoofing
ZeroMQ markets itself as sockets on steroids, and this hypothetical exchange
is to clear up any (hypothetical?) confusion stemming from their own
messaging?

