21–30 of 58 posts
Anything new with ZeroMQ? It's been around for a long time.
The licensing was changed about nine months ago. LGPL-3.0+ is out and MPL 2.0 is in. Very thankful for that.
:-)
ZeroMQ was followed by nanomsg ( https://nanomsg.org/ ) and nng ( https://nng.nanomsg.org/ ) Some of Martin's rationale here: https://250bpm.com/blog:23/index.html ZeroMQ is still widely used and popular, but I am not sure if it is still actively developed.
I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming broadcast updates, but is also controlled through request-reply. It would need two separate sockets. Then I'd have to reinvent some sort of ordering protocol across the two (as well as program logic to handle the partially-connected state), which would defeat…
As a new dev in 2011, I was unsuccessfully making a http worker thing in Python with Zeromq and I was distracted by their docs were encouraging replacing callback architecture with message passing with inproc queues.
Earlier quoted context omitted.
The licensing was changed about nine months ago. LGPL-3.0+ is out and MPL 2.0 is in. Very thankful for that.
Why are you thankful for the MPL instead of the LGPL? Is there any advantage to the MPL other than being easier to incorporate MPL code into proprietary software?
Several projects, including some I work on, only found out how much a mess (L)GPL v2 vs v3 is once important developers had passed away, meaning it's very hard to get out of the resulting mess.
ZeroMQ was followed by nanomsg ( https://nanomsg.org/ ) and nng ( https://nng.nanomsg.org/ ) Some of Martin's rationale here: https://250bpm.com/blog:23/index.html ZeroMQ is still widely used and popular, but I am not sure if it is still actively developed.
I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming broadcast updates, but is also controlled through request-reply. It would need two separate sockets. Then I'd have to reinvent some sort of ordering protocol across the two (as well as program logic to handle the partially-connected state), which would defeat…
orders = -setup req rep socket-
while 1:
----order = orders.read (with timeout)
----orders.send(ack)
----if order:
--------do stuff differently
----news.send(status)
As a new dev in 2011, I was unsuccessfully making a http worker thing in Python with Zeromq and I was distracted by their docs were encouraging replacing callback architecture with message passing with inproc queues.
Is this criticism still relevant? 2011 is 13 years (as in: a teenager's life) ago.
I would rather use sockets. Not getting errors when a client times out is a bad api design to me. I've used zeromq an only kept it around for IPC. I may have been doing it wrong, but i personally want to know when clients disconnect/reconnect/etc. the API seems to hide all that from you and your send or recv just block.
I always found it crazy how zmq gained any traction at all.
"Oh, I have a req/resp workload" - one of the sides restarts, goes out of rhythm with the state of the connection (whether its req or resp), unrecoverable errors.
Every system I've seen use zmq usually use it without these fancy patterns (use yeet messages in any order), and usually have some sort of "Is anybody there on the other side?" message to combat the fact there is no way to introspect connection state (otherwise your writes just block at the high water mark), at which point it would have been easier to just use tcp.
The whole thing to me reeks of mongo. It's great if you are completely incapable/incompetent of solving the problem properly.
ZeroMQ was followed by nanomsg ( https://nanomsg.org/ ) and nng ( https://nng.nanomsg.org/ ) Some of Martin's rationale here: https://250bpm.com/blog:23/index.html ZeroMQ is still widely used and popular, but I am not sure if it is still actively developed.
I've used zeromq, nanomsg, and nng. The differences are subtle and focused on native library support, background threading model, and other systems level things. All of them are based on specs that are widely published. I've had zero problems implementing real robotic systems in nng, zmq, etc. And it is so damn easy to use it's amazing to me the whole world doesn't use it.
Earlier quoted context omitted.
I've used zeromq, nanomsg, and nng. The differences are subtle and focused on native library support, background threading model, and other systems level things. All of them are based on specs that are widely published. I've had zero problems implementing real robotic systems in nng, zmq, etc. And it is so damn easy to use it's amazing to me the whole world doesn't use it.
I'm pretty sure the world doesn't use it more because it doesn't have a flashy marketing campaign and trendy developer tools/libraries don't have a plugin for it. If a whole bunch of developers aren't writing blog posts about it, does it even exist? Plus, it's old , so it's bad.
NATS is the ZeroMQ of today.