Are there teams considering using ZeroMQ for new projects in 2017/2018?
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 ] threadZeroMQ is not popular among Go developers, because the language and standard library subsume its functionality.
https://grpc.io/
The Java and C++ implementations seem to be the most active. Which makes sense, coming out of Facebook-land.
* 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.
[0]: http://wamp-proto.org/
What's your use case?
FYI we combine it with protobuf. Protobuf handles the data formatting. ZMQ handles the communication.