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

91–100 of 117 posts

Re: ØMQ – The Guide (2011)

#91

Post by stanski »

hnarn wrote: post #88
CivBase wrote: post #75

Earlier quoted context omitted.

Incidentally... > The Ø in ZeroMQ is all about tradeoffs. On the one hand this strange name lowers ZeroMQ’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 fa…

I saw that, and it doesn’t do anything for me personally than paint the authors as petulant. Clearly “some danish folk” are the obvious other here and they themselves can’t be bothered because they don’t read the character. If they want to refer to the mathematical character as mentioned in other comments, why not use that instead of one from an actual alphabet? They’re free to do whatever they want but anyone famili…

I'm pretty sure that's supposed to be a joke. Also the main dev is not American but Belgian.

Re: ØMQ – The Guide (2011)

#93

Post by lllr_finger »

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…

The only times I've ever reached for zeromq are when I needed sockets and didn't want to deal with the hassle of programming sockets - it worked great then.

I'd happily use it as the glue between two processes that I control, but would grab one of the other tech you mentioned for anything exposed on the boundaries of my app.

Re: ØMQ – The Guide (2011)

#94

Post by lllr_finger »

DominikD wrote: post #41
smitty1110 wrote: post #34

Earlier quoted context omitted.

If I remember correctly, they’re written by the original zeromq author. He has a blog post about how he realized that C++ was not ideal for the architecture he was using, and decided to make a clean break. Edit: Found it. https://250bpm.com/blog:4/

He changed his mind over time. ZeroMQ is still maintained and nanomsg is pretty much dormant.

Look up "nanomsg is not dead" and nanomsg's replacement nng for even further confusion.

My takeaway is that even though these newer libs seem to be simpler and avoid some issues, they've just never caught on.

Re: ØMQ – The Guide (2011)

#95

Post by lllr_finger »

harel wrote: post #48

I am actually using it in production as an easy mechanism to add non critical rpc calls between services. The only thing I can say about it is that zeromq hasn't given me a reason to look for a replacement. Yet.

I believe that zeromsg does not support true zero-copy messaging which might be a reason to look at nanomsg or nng if you need every last ounce of performance.

Re: ØMQ – The Guide (2011)

#96

Post by rndgermandude »

hnarn wrote: post #88
CivBase wrote: post #75

Earlier quoted context omitted.

Incidentally... > The Ø in ZeroMQ is all about tradeoffs. On the one hand this strange name lowers ZeroMQ’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 fa…

I saw that, and it doesn’t do anything for me personally than paint the authors as petulant. Clearly “some danish folk” are the obvious other here and they themselves can’t be bothered because they don’t read the character. If they want to refer to the mathematical character as mentioned in other comments, why not use that instead of one from an actual alphabet? They’re free to do whatever they want but anyone famili…

And they say us Germans lack a sense of humor...

Re: ØMQ – The Guide (2011)

#97

Post by ocschwar »

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…

In 2011 I was a novice and got that bag of tools dropped in my lap, and I did struggle with how to put them together, but safely was not. problem. It was considerably better for a novice to play with those tools than to have to do it at the socket level.

Re: ØMQ – The Guide (2011)

#98

Post by froskur »

ReactiveJelly wrote: post #71
nurgasemetey wrote: post #26

In 2015, in one project one "clever" co-worker decided to use "zeromq" in project where is the guarantee of delivery was must. I think that because he wanted to attach this technology as fancy stuff in his cv. Later he left and we had to rewrite message sending and converted to basic http.

About the same time, I used zeromq in a project for similar reasons: - I wanted easy message framing - I didn't know much about networks - HTTP servers that can be embedded in C++ aren't great, and I didn't know anything about HTTP - It is nice that you can ignore application startup order if you don't care much about reliability, which I didn't If I knew then what I know now, I would probably have picked something e…

> I couldn't make it integrate with my main event loop

You can get a file descriptor from ZMQ to use with your own event loop (depending on your event loop of course). I have done this successfully in the past with an epoll (iirc) based event loop.

The documentation is at [1], the ZMQ_FD option. You do have to read the instructions very carefully though.

[1] http://api.zeromq.org/master:zmq-getsockopt

Re: ØMQ – The Guide (2011)

#99

Post by Boxxed »

justinsaccount wrote: post #27
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…

the [...] that you removed is > At any given time a message may be in the ZeroMQ sender queue, the sender's kernel buffer, on the wire, in the receiver's kernel buffer or in the receiver's ZeroMQ receiver queue. Furthermore, a ZeroMQ socket can bind and/or connect to many peers. Each peer may have different performance characteristics and therefore a different queue depth. Any "queue depth" number is almost certainly…

But how do I implement backpressure in zeromq? I've used it in production and it was great when it worked, but it was scary because its queue of messages could get arbitrarily large. I think I even saw an OoM when a service went down and something just queued indefinitely.

Edit: just checked the FAQ and apparently it will now block or drop messages. I sort of wish it would explicitly error instead of block, so as not to require the caller to queue in a thread or something.

Re: ØMQ – The Guide (2011)

#100

Post by theamk »

justinsaccount wrote: post #27
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…

the [...] that you removed is > At any given time a message may be in the ZeroMQ sender queue, the sender's kernel buffer, on the wire, in the receiver's kernel buffer or in the receiver's ZeroMQ receiver queue. Furthermore, a ZeroMQ socket can bind and/or connect to many peers. Each peer may have different performance characteristics and therefore a different queue depth. Any "queue depth" number is almost certainly…

The reasonings assumes I don't know what's going on. This approach is precisely why I never tried ZMQ.

How do you know my circumstances? Maybe this system has tuned rmem_max/wmem_max so I don't care about kernel buffers? Maybe my programs have problems with multi-gigabyte queues? Why are you assuming stuff for me?

The right answer of course is you don't expose a single "queue size" value, but you don't hide it either. Instead, expose something like "list of sockets: for each, here is an fd and a size of userspace queue". I'll then query the kernel myself to get sender's and receiver's kernel buffer size and so on.

Life is hard enough without libraries hiding stuff from you!

Post reply on HN