NATS is the ZeroMQ of today.
ZeroMQ: High-Performance Concurrency Framework
11–20 of 58 posts
Re: ZeroMQ: High-Performance Concurrency Framework
#12NATS is the ZeroMQ of today.
They aren't really the same thing. NATS is a message queue/MOM, ZeroMQ is a smarter abstraction over sockets.
Re: ZeroMQ: High-Performance Concurrency Framework
#13I 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.
Re: ZeroMQ: High-Performance Concurrency Framework
#14Re: ZeroMQ: High-Performance Concurrency Framework
#15ZeroMQ 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.
> And it is so damn easy to use it's amazing to me the whole world doesn't use it.
Perhaps many of them are locked into “the cloud” and “serverless”, by default choosing the proprietary solutions offered by these providers on their platforms?
Re: ZeroMQ: High-Performance Concurrency Framework
#16I 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.
Imo, ZMQ is more of an abstraction with which to design protocols, rather than a message queue ready to use, Kafka-style. I found unexpectedly that I needed to really read the entire manual and work through the worked examples and some of my own to start getting it, rather than the usual incremental read.
So, you can set up a protocol using ZMQ such that you become aware when a client times out, and you can set behavior regarding the high water mark, and other things, but you have to actually do it explicitly - it's not required that you do it, because you can choose to maximize throughput or minimize latency instead.
But, whatever protocol behavior / performance you want, you can pretty much build it with ZMQ. In Python, ZMQ was the only "feasible for my not-a-network-engineer-self" to get a system with 100μs latency with sufficient throughput and guarantees (when used for IPC, although not using the IPC transport type). gRPC was a lot less performant for me, granted it would've been more convenient, but the low latency was a hard need.
Although, networks are one of my noobier areas, so I might be blind in many ways here.
Re: ZeroMQ: High-Performance Concurrency Framework
#17Earlier 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?
Making the software easier to use from a legal point of view was indeed the reason.
They explained why they did this here: https://github.com/zeromq/libzmq/issues/2376
Bottom line is that their licensing with a static linking exception was kind of weird and creating a lot of issues combining zeromq code even with other open source licenses (like Apache 2.0).
Interesting to see how they gathered permission to do this from the developer community. License changes like this are usually hard to realize unless you insist on copyright transfers. But in this case they managed to do it without that. So it was a collective decision. Hard to argue with that.
Re: ZeroMQ: High-Performance Concurrency Framework
#18As 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.
Re: ZeroMQ: High-Performance Concurrency Framework
#19ZeroMQ 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 been looking at these recently for a project.
nng looks promising, but the guide from zmq seemed like a killer feature. It describes all sorts of high level patterns, gotchas, etc.
For nng I mostly found API documentation, which made me a bit more cautious (though to be fair, I've not tried it yet).
Re: ZeroMQ: High-Performance Concurrency Framework
#20ZeroMQ 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 been looking at these recently for a project. nng looks promising, but the guide from zmq seemed like a killer feature. It describes all sorts of high level patterns, gotchas, etc. For nng I mostly found API documentation, which made me a bit more cautious (though to be fair, I've not tried it yet).
I have used ZeroMQ with C, Dlang, and Python -- mostly for learning.
However, I have used NetMQ.. a C# implementation of ZeroMQ in live software and the results are very positive!
I used a Pub-Sub pattern for one program to keep users informed on progress of a task, which could have taken hours to complete. They had a GUI program which spits out updates. It worked really well.
I was also tasked updating a Till software, which the integration of orders to the central system was extremely slow. I used NetMQ which was looking extremely successful but was put on hold due to IT manager not understanding Software Developers -- if something starts taking more than a week to do (which I stated I needed a month) they get itchy and move onto to something else. Sadly, that never got completed.
Now, I have played with NNG and there are some interested articles (or hidden pages from memory) about companring NNG to ZeroMQ - it seems the "patterns" are simplified.
I am currently in the progress of creating bindings for NNG. Seems to be pretty good, so far. I plan to move away from NetMQ (C#) in favour of this language moving forward.
Whether you use ZeroMQ or NNG - I dont think you can go wrong. It is all about the process more than anything, ensuring you do not lose data.