4 ms·

ZeroMQ was followed by nanomsg (https://nanomsg.org/ https://nanomsg.org/) and nng (https://nng.nanomsg.org/ https://nng.nanomsg.org/) Some of Martin's rationa

ZeroMQ was followed by nanomsg (https://nanomsg.org/ https://nanomsg.org/) and nng (https://nng.nanomsg.org/ https://nng.nanomsg.org/) Some of Martin's rationale here: https://250bpm.com/blog:23/index.html 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.

jvanderbot 2y ago
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.
- throwaway984393 2y ago
  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.
  - rcxdude 2y ago
    zmq was pretty dang trendy for a while. It had a well styled website and very wide language support. I think it just failed to deliver on its promise for most users.
- AnonHP 2y ago
  > 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?
- rcxdude 2y ago
  I've had some bad experiences with zeromq in robotic systems contexts: it's very assert-happy, and therefore tends to bring down the whole process in corner cases, and it's quite difficult to debug. It caused me quite a lot of headache and I'm no longer particularly enamored of the approach (the internal architecture is one which makes error propagation very difficult, so even if the individual bugs were fixed there's not a good overall handling strategy).
- taspeotis 2y ago
  > it's amazing to me the whole world doesn't use it. I Googled nng and apparently it's this? [1] It's written in C so if you click the issues tab the second and third issues are "IPC - Use After Free" and "Setting TLS config option via nng_socket_set_ptr causes access violation if you free config." Why would you want the world to build other software on this? [1] https://github.com/nanomsg/nng https://github.com/nanomsg/nng
  - jvanderbot 2y ago
    Well good to know, but I've never used TLS, since the apps were P2P over a secure overlay, so encrypting payloads was sufficient.
mindslight 2y ago
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 much of the point of using 0mq?
- nurettin 2y ago
  Without knowing any details, it sounds like a hard problem whether you use 0mq or not.
  - mindslight 2y ago
    The problem generally needs to be solved by the transport protocol. Having two sockets communicating in parallel means the problem needs to be solved again.
- exe34 2y ago
  news = -setup broadcast socket- orders = -setup req rep socket- while 1: ----order = orders.read (with timeout) ----orders.send(ack) ----if order: --------do stuff differently ----news.send(status)
  - mindslight 2y ago
    And then how does a client know whether an `order` was processed before or after a specific `status`? If you start talking about adding sequence numbers or duplicating application data between `status` and `order` (and its reply), that's the creation of an ad-hoc ordering protocol I'm talking about.
    - exe34 2y ago
      that doesn't sound like a socket level problem, it's more like an application level problem? how long does it take to obey-orders()? do you want to keep spitting out logs while doing it? maybe give orders a number, and the logs can include the order number and the progress?
nlnn 2y ago
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).
- masfoobar 2y ago
  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.
  - CharlieDigital 2y ago
    In 2014, I was tasked with rebuilding an event processing engine to increase throughput and performance. Used ZeroMQ with C# and also had a very positive experience. It was very easy to build a multi-node, distributed event processing engine (think Apache Flink) that could scale by simply adding more nodes or threads. ZMQ makes coordination and management of messages easy and low-fanfare. In our use case, it was stable and it was the least problematic part of a relatively complex platform.
    - 2y ago

jvanderbot 2y ago

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.

throwaway984393 2y ago
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.
- rcxdude 2y ago
  zmq was pretty dang trendy for a while. It had a well styled website and very wide language support. I think it just failed to deliver on its promise for most users.
AnonHP 2y ago
> 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?
rcxdude 2y ago
I've had some bad experiences with zeromq in robotic systems contexts: it's very assert-happy, and therefore tends to bring down the whole process in corner cases, and it's quite difficult to debug. It caused me quite a lot of headache and I'm no longer particularly enamored of the approach (the internal architecture is one which makes error propagation very difficult, so even if the individual bugs were fixed there's not a good overall handling strategy).
taspeotis 2y ago
> it's amazing to me the whole world doesn't use it. I Googled nng and apparently it's this? [1] It's written in C so if you click the issues tab the second and third issues are "IPC - Use After Free" and "Setting TLS config option via nng_socket_set_ptr causes access violation if you free config." Why would you want the world to build other software on this? [1] https://github.com/nanomsg/nng https://github.com/nanomsg/nng
- jvanderbot 2y ago
  Well good to know, but I've never used TLS, since the apps were P2P over a secure overlay, so encrypting payloads was sufficient.

mindslight 2y ago

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 much of the point of using 0mq?

nurettin 2y ago
Without knowing any details, it sounds like a hard problem whether you use 0mq or not.
- mindslight 2y ago
  The problem generally needs to be solved by the transport protocol. Having two sockets communicating in parallel means the problem needs to be solved again.
exe34 2y ago
news = -setup broadcast socket- orders = -setup req rep socket- while 1: ----order = orders.read (with timeout) ----orders.send(ack) ----if order: --------do stuff differently ----news.send(status)
- mindslight 2y ago
  And then how does a client know whether an `order` was processed before or after a specific `status`? If you start talking about adding sequence numbers or duplicating application data between `status` and `order` (and its reply), that's the creation of an ad-hoc ordering protocol I'm talking about.
  - exe34 2y ago
    that doesn't sound like a socket level problem, it's more like an application level problem? how long does it take to obey-orders()? do you want to keep spitting out logs while doing it? maybe give orders a number, and the logs can include the order number and the progress?

nlnn 2y ago

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).

masfoobar 2y ago
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.
- CharlieDigital 2y ago
  In 2014, I was tasked with rebuilding an event processing engine to increase throughput and performance. Used ZeroMQ with C# and also had a very positive experience. It was very easy to build a multi-node, distributed event processing engine (think Apache Flink) that could scale by simply adding more nodes or threads. ZMQ makes coordination and management of messages easy and low-fanfare. In our use case, it was stable and it was the least problematic part of a relatively complex platform.
  - 2y ago