ØMQ – The Guide (2011)
zguide.zeromq.org
ØMQ – The Guide (2011)
1–10 of 117 posts
Re: ØMQ – The Guide (2011)
#2I recommend changing the landing page to include a clear description of what this is.
Re: ØMQ – The Guide (2011)
#3I 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.
Re: ØMQ – The Guide (2011)
#4I recommend changing the landing page to include a clear description of what this is.
This is the guide, which you would normally visit from the homepage. The homepage gives a very clear description of what it is.
Re: ØMQ – The Guide (2011)
#5I recommend changing the landing page to include a clear description of what this is.
The project landing page is very clear an clearly linked: https://zeromq.org/
Re: ØMQ – The Guide (2011)
#6I 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.
I believe the 'problem' that it solves is universal network transparency between pieces of anything. It's a library that can be used from basically any language that has a C FFI on any system with a C compiler to do IPC with anything else supporting same using a uniform and relatively simple API.
Re: ØMQ – The Guide (2011)
#7I 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()
Re: ØMQ – The Guide (2011)
#8I 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.
Re: ØMQ – The Guide (2011)
#9I 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.
[deleted]
Re: ØMQ – The Guide (2011)
#10I 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.
zmq is "a better socket()", but unlike sockets it's pretty hard to figure out what's going on. E.g. most (all?) socket types don't need the other side to be immediately available, it'll buffer a couple thousand or so messages and start blocking if it doesn't appear. From the app's point of view, everything seems fine until the queues are full (which you can't introspect, btw.) when suddenly everything starts blocking.
It does bring some nice things to the table, but using it has always felt at least a little bit "weird" to me. The docs are a little weird, and there are random caveats sprinkled around the library (e.g. you don't need to synchronize the startup of dependent services like described above, unless you were using certain transports in older versions and so on).
It used to be marketed somewhat towards developing multi-threaded applications, but it was always rather unclear what exactly the advantage of using, for example, the comparatively slow PUSH/PULL socket (ipc:// are pipes) over a MPMC (or as needed) queue ought to be.
It is also marketed towards resilient distributed apps, but, perhaps I was holding it wrong, but it'd always behave much like TCP and stuff like REQ/REP would pretty much always block forever if the peer goes away, while stuff like PUSH/PULL isn't reliable when peers go away, so for a distributed app these can't really be used anyway. So for this use case it always seemed rather too low-level and its guarantees too weak / non-applicable.