Nanomsg postmortem and other stories

Post by PieterH » Tue, Feb 09, 2016, 6:49 PM UTC

_pmf_ wrote: post #12

So, what is the spiritual successor of 0mq? I think a lot of use cases that would have been covered by 0mq are now handled by more higher level abstractions like consensus protocols or more heavy weight message queues (which absolutely makes sense), but what would be a modern (i.e. maintained) alternative for the simple "pub-sub via TCP" use case of 0mq?

ZeroMQ is a community of projects that has grown and evolved significantly in the last years. It was never threatened by Nanomsg, which we saw as an interesting experiment, and potentially an engine for a pure C stack. We have pure Java, C#, C, and C++ stacks, and a new pure Go stack.

Above that, you will see many language bindings, especially PyZMQ and CZMQ, each with a large community on top. CZMQ provides things like actors and CurveZMQ authentication, and has wrappings in many languages. I'm writing a Node.js one at the moment, and did a Java one a few weeks ago.

Above that, we have Zyre, a clustering library that is somewhat like Nano's bus pattern, yet rather stronger. It was designed for flaky WiFi networks, and does not lose messages as long as a node reconnects within a reasonable time.

And above that, we have a message broker, Malamute, which does pub-sub and workload distribution.

All the C libraries have rich packaging (builds for every conceivable platform, and bindings in a growing number of languages), provided by zproject. So you can start a Malamute server (a CZMQ actor) from Python, or Node.js, trivially.

We have run Malamute on a $25 OpenWRT router. This stack is small, efficient, and very alive.

Post by IshKebab » Fri, Feb 12, 2016, 6:03 PM UTC

hendzen wrote: post #7

IshKebab wrote: post #5

Yeah I dunno, the "solid technical reasons" are pretty unconvincing. The reasons are: 1. Exceptions are awkward because they separate the error handling from the context that is usually required to correctly handle an error (i.e. where it occured). 2. Exceptions are the only reasonable way for a constructor to fail. You can't return error codes from a constructor. I actually agree with the point about exceptions, and…

Your connect method can still throw std::bad_alloc.

You could easily catch that within the method though. But in general I think throwing an exception on memory allocation failure is much better than the alternative, which is - in practice - assuming it succeeds and segfaulting.

Re: Nanomsg postmortem and other stories

Re: Nanomsg postmortem and other stories