4 ms·

ZeroMQ gives you the same but better: messaging in any language. That means you can interface to any component you want written in any language you want. Also h

ZeroMQ gives you the same but better: messaging in any language. That means you can interface to any component you want written in any language you want. Also hiding native sockets, which means networking is not 1:1 but based on scalability patterns. At some point people will realize what a big deal that is.

Spearchucker 12y ago
Nobody needs reliable messaging: http://www.infoq.com/articles/no-reliable-messaging http://www.infoq.com/articles/no-reliable-messaging
- bachback 12y ago
  Tell that people who are trying to build scalable network applications. Saltstack uses ZeroMQ under the hood and the biggest cloud computing operations in the world use it. That article reads like from a past age, where you didn't have startups scaling to millions of users based on cloud computing. HTTP was invented for retrieving hypertext documents. Not for connecting millions of nodes.
  - Spearchucker 12y ago
    Scale covers lots of things, including statefull v. stateless and (appropriate to this discussion) asynchronous comms and the ability to queue requests. Scale in that sense is facilitated by retrying a remote call that failed - possibly because the server is at capacity. That implies store/forward, which is what the "queue" part of message queuing does. You can definitely use tools like ZeroMQ, MQ Series, MSMQ or WCF to achieve that. You can also use a database table with a flag indicating whether a message was delivered or not (ref. my link above). Not quite sure what HTTP has to do with message queuing, other than being a protocol one might use. If scale is so important, perf is a concern, in which case UDP would be a consideration. Would I go down that road? Doubt it, because I suspect the acceptable answer lies somewhere between HTTP and UDP, and I also suspect that better gains can be made by optimising end-to-end throughout and solution design rather than worrying about the semantics of a protocol. What's the benefit, for example, of streaming data over a TCP connection when that data is XML? TLV or some other binary format will serve you a lot better. Final words on scale - asynchronous delivery (such as message queuing) is one technique. Another is to scale servers out and/or up. Also, as already mentioned, server state and of course pipeline/routing efficiency. Whilst I stand by what I said, I've not had the opportunity to work at the scale you have, so I'd love to know what problems you've encountered when scaling to millions of nodes.
    - bachback 12y ago
      Examples can be found here http://zeromq.org/docs:labs http://zeromq.org/docs:labs AFAIK Twitter storm uses ZMQ under the hood.
      - Spearchucker 12y ago
        Not seeing anything that invalidates what I said.
- manishsharan 12y ago
  'Nobody ' is not quite correct. What you probably mean is not everyone needs reliable messaging. As a former TIBCO and MQ developer, I could not have done without them when developing trading applications.
  - Spearchucker 12y ago
    "As a former TIBCO and MQ developer..." I'm reaching here, please forgive (and correct) me if I'm wrong. This comment makes me think that you've not tried delivering the same functionality without TIBCO and MQS. I used to do a lot of MQS and MSMQ work, and have not encountered a scenario these products handle that I can't as described in my link above.
jeremyjh 12y ago
Gives you the same what? I cannot think of a single feature overlap. ZeroMQ has nothing to say about supervisors, binary stream pattern matching, inspection, static analysis etc. Erlang has nothing to say about reliable messaging, message brokers, fan-out, routing and other patterns enabled with ZeroMQ. Yes there is the word "socket" in the post.
- bachback 12y ago
  Better yet: ZeroMQ is not even a language. What ZMQ does it lets your write extremely performant and reliable distributed systems in any language. It is a layer over sockets. Any complex system will have to interact with other complex systems, which are written in other languages. Say you develop a service and a lot of people want to use it. What API are you going to expose? One that is only based on Erlang primitives? Certainly not, because then you have limited your user-base to a small number of people.
bachback 12y ago
HN is just mean and boring for downvoting this. Gotta leave this place.

Spearchucker 12y ago

Nobody needs reliable messaging: http://www.infoq.com/articles/no-reliable-messaging http://www.infoq.com/articles/no-reliable-messaging

bachback 12y ago
Tell that people who are trying to build scalable network applications. Saltstack uses ZeroMQ under the hood and the biggest cloud computing operations in the world use it. That article reads like from a past age, where you didn't have startups scaling to millions of users based on cloud computing. HTTP was invented for retrieving hypertext documents. Not for connecting millions of nodes.
- Spearchucker 12y ago
  Scale covers lots of things, including statefull v. stateless and (appropriate to this discussion) asynchronous comms and the ability to queue requests. Scale in that sense is facilitated by retrying a remote call that failed - possibly because the server is at capacity. That implies store/forward, which is what the "queue" part of message queuing does. You can definitely use tools like ZeroMQ, MQ Series, MSMQ or WCF to achieve that. You can also use a database table with a flag indicating whether a message was delivered or not (ref. my link above). Not quite sure what HTTP has to do with message queuing, other than being a protocol one might use. If scale is so important, perf is a concern, in which case UDP would be a consideration. Would I go down that road? Doubt it, because I suspect the acceptable answer lies somewhere between HTTP and UDP, and I also suspect that better gains can be made by optimising end-to-end throughout and solution design rather than worrying about the semantics of a protocol. What's the benefit, for example, of streaming data over a TCP connection when that data is XML? TLV or some other binary format will serve you a lot better. Final words on scale - asynchronous delivery (such as message queuing) is one technique. Another is to scale servers out and/or up. Also, as already mentioned, server state and of course pipeline/routing efficiency. Whilst I stand by what I said, I've not had the opportunity to work at the scale you have, so I'd love to know what problems you've encountered when scaling to millions of nodes.
  - bachback 12y ago
    Examples can be found here http://zeromq.org/docs:labs http://zeromq.org/docs:labs AFAIK Twitter storm uses ZMQ under the hood.
    - Spearchucker 12y ago
      Not seeing anything that invalidates what I said.
manishsharan 12y ago
'Nobody ' is not quite correct. What you probably mean is not everyone needs reliable messaging. As a former TIBCO and MQ developer, I could not have done without them when developing trading applications.
- Spearchucker 12y ago
  "As a former TIBCO and MQ developer..." I'm reaching here, please forgive (and correct) me if I'm wrong. This comment makes me think that you've not tried delivering the same functionality without TIBCO and MQS. I used to do a lot of MQS and MSMQ work, and have not encountered a scenario these products handle that I can't as described in my link above.

jeremyjh 12y ago

Gives you the same what? I cannot think of a single feature overlap. ZeroMQ has nothing to say about supervisors, binary stream pattern matching, inspection, static analysis etc. Erlang has nothing to say about reliable messaging, message brokers, fan-out, routing and other patterns enabled with ZeroMQ. Yes there is the word "socket" in the post.

bachback 12y ago
Better yet: ZeroMQ is not even a language. What ZMQ does it lets your write extremely performant and reliable distributed systems in any language. It is a layer over sockets. Any complex system will have to interact with other complex systems, which are written in other languages. Say you develop a service and a lot of people want to use it. What API are you going to expose? One that is only based on Erlang primitives? Certainly not, because then you have limited your user-base to a small number of people.

bachback 12y ago

HN is just mean and boring for downvoting this. Gotta leave this place.