11–20 of 117 posts
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.
Like you can tell it to use sockets if the machines are remote, or different inter-process communication if they're running on the same machine, etc.
It also has some common patterns like pub/sub and others.
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.
Some places you might use it: real-time financial data streams, multi-agent worker task/management, distributed database syncing. It’s basically a networking lib that makes common patterns easier. E.g send this message to everyone, list connected peers, handle these messages this way if the peer can’t take the message, and so on. They support doing this in a bunch of languages over a bunch of communication protocols.
Now all the Async/coroutine/ipc verbiage is mostly just because synchronization is a communication problem which is what zeroMQ happens to solve as well.
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?
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.
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?
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?
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 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" that you have to use.
e.g. https://zguide.zeromq.org/docs/chapter4/ https://zguide.zeromq.org/docs/chapter5/ https://zguide.zeromq.org/docs/chapter3/
Plus a lot of "magic" happening in the library involves queues that you have no control over. You get applications that hang and fill buffers instead of failing early.
I suspect this is the reason why it never became a new layer in the TCP/IP stack
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.
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…
I had exactly the same (disappointing) experience.