ØMQ – The Guide (2011) • Hacker News Board

Re: ØMQ – The Guide (2011)

#41

Post by DominikD » Sat, Oct 24, 2020, 6:55 PM UTC

smitty1110 wrote: post #34

pcglue wrote: post #29

Anyone know how nanomsg ( https://nanomsg.org ) or nng ( https://github.com/nanomsg/nng ) compares? Interesting that nanomsg tries to better zeromq ( https://nanomsg.org/documentation-zeromq.html ) and then nng tries to better nanomsg ( https://nng.nanomsg.org/RATIONALE.html ) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.

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.

Re: ØMQ – The Guide (2011)

#42

Post by kjeetgill » Sat, Oct 24, 2020, 6:56 PM UTC

nuxi wrote: post #18

m463 wrote: post #13

what I'm wondering is: we have https://xkcd.com/927/ with sockets in frame 1, and zeromq in frame 3 Are there some clear wins of zeromq over sockets/udp/tcp?

ZMQ is not a replacement for sockets, it's a library that uses sockets (and other transport mechanisms) underneath. For more details: https://zguide.zeromq.org/docs/preface/#ZeroMQ-in-a-Hundred-...

When people say that they mean it's a replacement for the use of sockets in your program, not that it replaces sockets ... Across the technological landscape? Within the tech stack?

Hmm.

Re: ØMQ – The Guide (2011)

#43

Post by random3 » Sat, Oct 24, 2020, 6:59 PM UTC

m101010 wrote: post #37

random3 wrote: post #16

0mq is great; however, the 0mq Guide is the golden standard for technical documentation and one of the best tech writings there are.

100% agree. I think what stood out to me the most was that it did explain a lot of the decision making. I feel like often other docs don't explain the decisions that did go into their software at all

This is also what sets good code comments and code level API documentation apart - explaining the reasoning and intention for both implementation and for intended use. Essentially the why and how, not that what...

Re: ØMQ – The Guide (2011)

#44

Post by hblanks » Sat, Oct 24, 2020, 7:06 PM UTC

nurettin wrote: post #38

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.

> we had to rewrite message sending and converted to basic http. What are the delivery guarantees for basic http?

(Yes to the earlier post - had a similar experience with an early metrics system for Twilio in 2012-2013)

The 1st issue is that ZMQ implementations generally have an IO thread handling all socket IO. REQ/REP patterns tend to work out just fine, because the client is going to wait for a reply from the server. But things like PUSH/PULL become...harder to follow. You can push things in the client, but how do you know when they've flushed out of the IO thread and made it to the server? Those sorts of things matter when shutting down a process, running integration tests, etc. In contrast, with an HTTP request, you're basically always doing REQ/REP, and so you know when the data has been pushed.

The 2nd issue is that ZMQ implementations tend to be harder to observe / operate than a more common path like HTTP requests. (HTTP requests can go through a load balancer, have standard response codes, use headers for authorization, etc.) For these reasons, I've tended to avoid ZMQ ever after -- it seems like often, you're best off either using REST or GRPC if by HTTP, or raw TCP if it's purely a data push kind of operation (e.g. forwarding structured logs, with framing, to a remote TLS endpoint).

Re: ØMQ – The Guide (2011)

#45

Post by vlmutolo » Sat, Oct 24, 2020, 7:08 PM UTC

punnerud wrote: post #30

Ø - The 28. Letter in the Norwegian alphabet, pronounced as the beginning of the sound ‘uuuuh’ (like when someone is making a sound when thinking). It’s a join between O and E, and was at first written as Ө. The same sound in Swedish is Ö

> 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 fair trade.

https://zguide.zeromq.org/docs/preface/#The-Zen-of-Zero

Re: ØMQ – The Guide (2011)

#46

Post by omginternets » Sat, Oct 24, 2020, 7:12 PM UTC

fnordsensei wrote: post #8

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.

From the site, ”ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) is a high-performance asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker.” I read it as a low-level abstraction for when you want to build a custom messaging infrastructure.

This tells your “what” not “why”.

I prefer the “replacement for socket” pitch, personally.

Re: ØMQ – The Guide (2011)

#47

Post by omginternets » Sat, Oct 24, 2020, 7:13 PM UTC

eeZah7Ux wrote: post #19

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.

ØMQ promises being "socket on steroids" but I used it quite a bit and it's not so beneficial. It hides the scalability problem of having many TCP sockets without solving it (e.g. pub-sub over TCP). It does not solve the ahead-of-line blocking issue. It requires reading a lot of documentation and doing experiments to find out what is the right combination of " fan-out, pub-sub, task distribution, and request-reply" th…

The biggest limitation I found was the lack of reliable delivery semantics.

Re: ØMQ – The Guide (2011)

#48

Post by harel » Sat, Oct 24, 2020, 7:16 PM UTC

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.

Re: ØMQ – The Guide (2011)

#49

Post by easytiger » Sat, Oct 24, 2020, 7:18 PM UTC

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.

It's an alternative to writing your own complex networking code for any kind of distributed communications.

A lot of people these days might use something like flink or spark to build a pipeline whereas I'd prefer to write a number of small servers with various fan out or fan in operations, broadcast style operations, request/reply semantics etc where appropriate

Makes way more sense and much simpler to my mind and allows much better control over performance characteristics.

Re: ØMQ – The Guide (2011)

#50

Post by carrja99 » Sat, Oct 24, 2020, 7:20 PM UTC

justinsaccount wrote: post #7

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 know how people often bill sqlite as a replacement for (postgresql|mysql|oracle) but it is really best thought as a replacement for fopen()? zeromq is the same way. It's not a replacement for something like kafka or rabbitmq, it's a replacement for socket()

This is a great way to put it.