Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ØMQ – The Guide (2011)

zguide.zeromq.org

Post reply on HN
Print view View original

101–110 of 117 posts

Re: ØMQ – The Guide (2011)

#101

Post by ComputerGuru »

calpaterson wrote: post #59

I have to say that I have never really had a positive impression of zeromq. I feel like it is particularly unsuccessful and that seems to be for some pretty good reasons. Zeromq is a bag of tools and it's not really clear to me how a novice would put them together safely. This is important for a message system because everyone has to start somewhere and it really shouldn't be "step 1: build your broker with our subro…

Forgive me as you seem to be aware of many of the details of zmq’s history but is there a chance you’re missing something? You are comparing a thin, semantic-enforcing layer just above TCP to actual message queues/servers featuring persistence to disk, etc.

We’ve used ZeroMQ in production as an alternative to HTTP message passing and it was great for that. We would build something like RabbitMQ atop of ZMQ, the only similarity between the two being the name, really.

Re: ØMQ – The Guide (2011)

#103

Post by Guthur »

sgtnoodle wrote: post #56

ZeroMQ's variety of socket semantics is great, and it does a good job abstracting away the messy details of TCP. You can build rather complicated systems on top of it much easier and faster than you could using raw sockets. The implementation itself has some rough spots, such as the multi threading. I really like the elegance of nanomsg, but it never really got the same polish that ZeroMQ did. I wouldn't expect the s…

Pieter Hintjens, whom you are referring to, was actually not so much involved in the development of the core ZeroMQ library, though he certainly contributed. His main role was building a community and he did develop a high level C binding czmq.

Martin Sustrik was actually what could be referred to as the lead engineer for the initial ZeroMQ project, though he left it quite some time ago.

Re: ØMQ – The Guide (2011)

#104

Post by stephenhuey »

hnarn wrote: post #86
luizfelberti wrote: post #76

Earlier quoted context omitted.

The ∅ symbol (U+2205 in Unicode), even though it's inspired by, is not the same as the letter Ø (U+00D8 in Unicode), and has been, for almost a century already, the "correct" way to represent an empty set in mathematical notation (alongside {}). That is the meaning everyone that does not primarily use the Northern European alphabet (aka most people in the world) assume it has. Maybe suppress your instinctive outrage…

I copypasted the character from their website, which is why I know it’s not U+2205 being used. They’re also easy to tell apart. Maybe suppress your instinctive correction next time until you know that the person you’re correcting is in fact mistaken. Or just use a nicer tone to begin with.

Perhaps an intern used the wrong character when updating the website?

Re: ØMQ – The Guide (2011)

#105

Post by calpaterson »

ComputerGuru wrote: post #101
calpaterson wrote: post #59

I have to say that I have never really had a positive impression of zeromq. I feel like it is particularly unsuccessful and that seems to be for some pretty good reasons. Zeromq is a bag of tools and it's not really clear to me how a novice would put them together safely. This is important for a message system because everyone has to start somewhere and it really shouldn't be "step 1: build your broker with our subro…

Forgive me as you seem to be aware of many of the details of zmq’s history but is there a chance you’re missing something? You are comparing a thin, semantic-enforcing layer just above TCP to actual message queues/servers featuring persistence to disk, etc. We’ve used ZeroMQ in production as an alternative to HTTP message passing and it was great for that. We would build something like RabbitMQ atop of ZMQ, the only…

I could well be missing something! I get that zeromq is not quite equivalent to rabbit or Google pubsub but you do presumably still want the same kinds of patterns: pubsub, queues and maybe a bit of routing?

So it is an alternative to (eg) Google pubsub and I think can be compared with it. Is there any case where it would be used for a different /purpose/ than the others?

Re: ØMQ – The Guide (2011)

#106

Post by avinassh »

cetra3 wrote: post #92

I've implemented bindings for ZeroMQ with Tokio in rust ( https://github.com/cetra3/tmq ). I found ZeroMQ great for interop with Python/Java if you just want some simple cross-process broadcast/task management.

(noob here) I just looked into the ZeroMQ code and the API seems to be sync and blocking. So, how does one provide async bindings for such code?

Re: ØMQ – The Guide (2011)

#107

Post by avinassh »

theamk wrote: post #21

I looked at zeromq, but it seemed like it had very bad debug-ability and visibility into internal operations. Their FAQ [0] says things like: > How do I determine how many messages are in queue? > This isn't possible. [...] rather than provide incorrect information the library avoids providing any view into this data. > How can I retrieve a list of all connected peers? > This is not supported. Those kinds of decision…

Found a related post by Armin Ronacher which mainly deals with disconnection issues - ZeroMQ: Disconnects are Good for You [0]

[0] - https://lucumr.pocoo.org/2012/6/26/disconnects-are-good-for-...

Re: ØMQ – The Guide (2011)

#108

Post by avinassh »

umvi wrote: post #23
fiatjaf wrote: post #3

I have a feeling that ØMQ is a very good thing, but all these years I have never managed to understand what it is and what problem does it solve.

You can think of ZeroMQ as legos for building message queue-based messaging systems. ZeroMQ gives you different pieces - pushers, pullers, publishers, subscribers, routers, etc. and it's up to you to then hook them up in different ways to create the system you want. The guide gives you some different ideas of how to hook up the different pieces for common use cases, but there's nothing stopping you from building a cu…

> You can think of ZeroMQ as legos for building message queue-based messaging systems.

Are there are any, preferably open source, message queue based messaging systems using ZeroMQ?

Re: ØMQ – The Guide (2011)

#109

Post by hkon »

ComputerGuru wrote: post #101
calpaterson wrote: post #59

I have to say that I have never really had a positive impression of zeromq. I feel like it is particularly unsuccessful and that seems to be for some pretty good reasons. Zeromq is a bag of tools and it's not really clear to me how a novice would put them together safely. This is important for a message system because everyone has to start somewhere and it really shouldn't be "step 1: build your broker with our subro…

Forgive me as you seem to be aware of many of the details of zmq’s history but is there a chance you’re missing something? You are comparing a thin, semantic-enforcing layer just above TCP to actual message queues/servers featuring persistence to disk, etc. We’ve used ZeroMQ in production as an alternative to HTTP message passing and it was great for that. We would build something like RabbitMQ atop of ZMQ, the only…

Why would you build something similar to RabbitMQ ontop of ZeroMQ instead of just using Rabbit?

Re: ØMQ – The Guide (2011)

#110

Post by tsimionescu »

neurostimulant wrote: post #85
tsimionescu wrote: post #84

Earlier quoted context omitted.

How does 0mq achieve that? For all I have read and tried to use of it, 0mq explicitly offers no message delivery guarantees, instead relying on your own implementation to achieve them. So, I don't doubt that your system works like you described, but I think you may be overvaluing 0mq's contribution to it.

The ZeroMQ Guide has a chapter dedicated to reliability stuff: https://zguide.zeromq.org/docs/chapter4/ Maybe there is no guarantee, but it can handle unreliable connection just fine, at least when I used it a few years ago.

Yes, I have read the guide pretty thoroughly. What all those things have in common is that they are your responsibility to implement - all that 0mq does is reconnect the socket, and queue up messages. Anything else that could give you reliability is either TCP's problem or yours. That includes timeouts, retransmit, ACKs, keepalives, heartbeats, rate control, message storage, everything that ensures reliability - with 0mq you get to implement it. Lazy pirate indeed.
Post reply on HN