8 ms·

ZeroMQ is just sockets

201 points by bmaeser 13y ago

nly 13y ago
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 13y ago
  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 13y ago
    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 13y ago
      These "patterns" exist because people like you want to gloss over the "loads of technical details". :)
      - nly 13y ago
        Just the opposite.
krenoten 13y ago
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.
rwmj 13y ago
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.
- exo762 13y ago
  Yes, because 0mq is just sockets.
- bmaeser 13y ago
  zmq is not simple a messaging framework. its more like a concurrency library. and there are a lot of reliability and high availability patterns for zmq: http://zguide.zeromq.org/page:all#Chapter-Reliable-Request-Reply-Patterns http://zguide.zeromq.org/page:all#Chapter-Reliable-Request-R...
- leokun 13y ago
  If you read the name as "zero message queue" is it surprising that it doesn't have persistence? There's no message queue.
  - skue 13y ago
    > 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 13y ago
      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.
PeterisP 13y ago
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.
eliben 13y ago
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.
strumptrumpet 13y ago
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 13y ago
  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).
  - illumen 13y ago
    TCP/IP does multiple endpoints as well (multicast, multipath, broadcast, server to many, iptables/pfw rules) etc. Various queue control methods are available in TCP/IP also. UDP is the only way to get decent performance if your application is designed around it. Why bother resending data if it is too old now to be useful, or if the data arrived via another route? TCP often has more variable latency than UDP, which is the main performance killer for certain types of apps. zeromq isn't multipath aware either.
josteink 13y ago
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?
- thraxil 13y ago
  The zeromq guide (http://zguide.zeromq.org/page:all#The-Zen-of-Zero http://zguide.zeromq.org/page:all#The-Zen-of-Zero) explains it thusly: "The Ø in ØMQ is all about tradeoffs. On the one hand this strange name lowers ØMQ's visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like "ØMG røtfl", and "Ø is not a funny looking zero!" and "Rødgrød med Fløde!", which is apparently an insult that means "may your neighbours be the direct descendants of Grendel!" Seems like a fair trade. Originally the zero in ØMQ was meant as "zero broker" and (as close to) "zero latency" (as possible). Since then, it has come to encompass different goals: zero administration, zero cost, zero waste. More generally, "zero" refers to the culture of minimalism that permeates the project. We add power by removing complexity rather than by exposing new functionality."
  - bcbrown 13y ago
    That's a fantastic insult.
    - neilc 13y ago
      Although that Danish phrase actually refers to a dessert (https://en.wikipedia.org/wiki/R%C3%B8dgr%C3%B8d https://en.wikipedia.org/wiki/R%C3%B8dgr%C3%B8d)
- rahoulb 13y ago
  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.
  - 13y ago
calineczka 13y ago
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.
kimagure 13y ago
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 13y ago
  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 13y ago
    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.
    - GrinningFool 13y ago
      For me, if there hasn't been any activity for several years yet it's still commonly used, I assume it's stable.
    - hintjens 13y ago
      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."
  - kimagure 13y ago
    i find that there are at least a couple dozen issues/defects that haven't been addressed, and it doesn't seem like they're going to be
macspoofing 13y ago
ZeroMQ markets itself as sockets on steroids, and this hypothetical exchange is to clear up any (hypothetical?) confusion stemming from their own messaging?
do_easy 13y ago
And asserts. Sockets and asserts.
- hintjens 13y ago
  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.
pflanze 13y ago
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

201 points by bmaeser 13y ago

nly 13y ago

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 13y ago
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 13y ago
  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 13y ago
    These "patterns" exist because people like you want to gloss over the "loads of technical details". :)
    - nly 13y ago
      Just the opposite.

krenoten 13y ago

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.

rwmj 13y ago

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.

exo762 13y ago
Yes, because 0mq is just sockets.
bmaeser 13y ago
zmq is not simple a messaging framework. its more like a concurrency library. and there are a lot of reliability and high availability patterns for zmq: http://zguide.zeromq.org/page:all#Chapter-Reliable-Request-Reply-Patterns http://zguide.zeromq.org/page:all#Chapter-Reliable-Request-R...
leokun 13y ago
If you read the name as "zero message queue" is it surprising that it doesn't have persistence? There's no message queue.
- skue 13y ago
  > 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 13y ago
    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.

PeterisP 13y ago

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.

eliben 13y ago

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.

strumptrumpet 13y ago

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 13y ago
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).
- illumen 13y ago
  TCP/IP does multiple endpoints as well (multicast, multipath, broadcast, server to many, iptables/pfw rules) etc. Various queue control methods are available in TCP/IP also. UDP is the only way to get decent performance if your application is designed around it. Why bother resending data if it is too old now to be useful, or if the data arrived via another route? TCP often has more variable latency than UDP, which is the main performance killer for certain types of apps. zeromq isn't multipath aware either.

josteink 13y ago

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?

thraxil 13y ago
The zeromq guide (http://zguide.zeromq.org/page:all#The-Zen-of-Zero http://zguide.zeromq.org/page:all#The-Zen-of-Zero) explains it thusly: "The Ø in ØMQ is all about tradeoffs. On the one hand this strange name lowers ØMQ's visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like "ØMG røtfl", and "Ø is not a funny looking zero!" and "Rødgrød med Fløde!", which is apparently an insult that means "may your neighbours be the direct descendants of Grendel!" Seems like a fair trade. Originally the zero in ØMQ was meant as "zero broker" and (as close to) "zero latency" (as possible). Since then, it has come to encompass different goals: zero administration, zero cost, zero waste. More generally, "zero" refers to the culture of minimalism that permeates the project. We add power by removing complexity rather than by exposing new functionality."
- bcbrown 13y ago
  That's a fantastic insult.
  - neilc 13y ago
    Although that Danish phrase actually refers to a dessert (https://en.wikipedia.org/wiki/R%C3%B8dgr%C3%B8d https://en.wikipedia.org/wiki/R%C3%B8dgr%C3%B8d)
rahoulb 13y ago
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.
- 13y ago

calineczka 13y ago

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.

kimagure 13y ago

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 13y ago
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 13y ago
  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.
  - GrinningFool 13y ago
    For me, if there hasn't been any activity for several years yet it's still commonly used, I assume it's stable.
  - hintjens 13y ago
    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."
- kimagure 13y ago
  i find that there are at least a couple dozen issues/defects that haven't been addressed, and it doesn't seem like they're going to be

macspoofing 13y ago

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

do_easy 13y ago

And asserts. Sockets and asserts.

hintjens 13y ago
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.

pflanze 13y ago

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