Are there teams considering using ZeroMQ for new projects in 2017/2018?

15 points by gjkood ↗ HN
I am considering using ZeroMQ for a project that I am working on.

I am learning my way through the example documentation on the website (ZeroMQ - the guide) and the ZeroMQ O'Reilly book (copyright 2013). The book mirrors the website in terms of C examples. I have to say that this is some of the best documentation I have seen in a while.

However on using the examples now in 2017 I notice that some of them are using deprecated APIs and I am having a hard time refactoring them to use the current APIs. It doesn't help that I am just learning and using ZeroMQ for the first time.

In compiling sample code I find that I have to refactor it to use v4.2 APIs since the code refers to pre v3.0 code in some case.

Finding out how I can find the right substitute for say the deprecated zframe_t or zframe API methods and what I should use instead is getting hard. How can I replace all references to zthread_* in the sample code to use the zactor model instead? etc.

All my googling is just bringing back the same 2013/2014 samples or others referring to the old deprecated samples.

I know the code is being updated but the example documentation seems to be from the 2013/2014 time period.

9 comments

[ 3.5 ms ] story [ 23.4 ms ] thread
Write to zeromq-dev@lists.zeromq.org, you might find some of your answers there.
Would you consider Go? Have a look at the net library. https://golang.org/pkg/net/

ZeroMQ is not popular among Go developers, because the language and standard library subsume its functionality.

Most use gRPC. Easier setup. And becoming part of a lot of modules. ZMQ can probably handle more traffic though

https://grpc.io/

I've lately seen some interest in RSocket: http://rsocket.io/

The Java and C++ implementations seem to be the most active. Which makes sense, coming out of Facebook-land.

I just wrote and open sourced pile of code with ZeroMQ (https://github.com/rantydave/messidge) and found it to be a mixed bag. In short:

* The encryption/authentication stuff is bordering on pointless - once a client has authenticated you cannot then be sure that a particular message is coming from that client. I binned it and used libnacl in a "by the book" implementation. It's not ideal.

* The routing, fanning etc. etc. stuff always made me uncomfortable - it's difficult to understand, introspect, debug, whatever.

* It's attitude to threading is idealist but a PITA - I got over it, eventually, by creating a sort of per-thread socket factory. Recent ZMQ's deal with both this and the above by introducing gloriously plain "server" and "client" sockets that are thread safe.

* The event monitoring sockets are cool but IMHO are a sign of things going pear shaped. In short, if you're monitoring connections then you're using messages to do a connection's job. I got this just, completely, wrong.

But: it works. It's reliable. It seems fast. In terms of basically doing what it promises, it delivers, and I think that counts for a lot.

Development has slowed down over the past year unfortunately. One of the most notable contributions recently was the addition of GSS API support. Overall the API is pretty small and easy to learn. The biggest advantage is that it takes care of reconnect logic for you and buffer management. It's also async by default which is nice. It's also pretty fast and can easily process 1M msg/s if you need that. I would ignore the czmq API entirely and only use the core API and roll your own stuff around it
Why not https://nats.io/ ? It is imho simpler and livelier (as in people are still working/using it)

What's your use case?

We use it extensively at work to connect multiple apps/blocks together. It’s great because you don’t need to really worry about all the network management. It just works. We can even deploy across multiple ips and its transparent to our code. We work in c++ and python mostly.

FYI we combine it with protobuf. Protobuf handles the data formatting. ZMQ handles the communication.