zeromq

Understanding ZeroMQ

So as I have asked in a previous post, I want to be able to make programs or functions written in different languages to communicate between them.

I have come across zeromq recently and I'm trying to figure out whether or not this is something that could help me since it provides some sort of sockets. Can zeromq for example exchange data (or pass arguments) between a program written in python with a program or a function written in C++ or is its function for something completely different?

Solution

  • A: Oh Yes, exactly that is the power of ZeroMQ or nanomsg frameworks

    Both of these are not sockets but rather BEHAVIOUR created within a context of a Zero-* -- a set of courageous maxims the Scaleable Formal Communication Pattern Framework was designed, developed and finetuned to meet.

    That will enable you to assemble your own fast & smart messaging layer(s).

    Q: What is the best next step?

    In spite of your first impression, simly do forget anything you know about sockets and multithreaded synchronisation tricks.

    Yes, rather forget and build your new understanding on "green field".

    Take Pieter HINTJENS' book "Code Connected, Volume 1" (accessible in PDF ) and spend a few weeks on understanding both the motivation and the typical errors Pieter has hammered into this must-read bible of ZeroMQ.

    Code-snippets are dangerous in case you did not get or completely missed the full-context of the bigger picture.

    Believe me. I could not give you better advice. You may check my other posts on ZeroMQ & nanomsg, to see the difference.

    You will definitely benefit from this book and ZeroMQ will give you many powers you would never ( and believe me never ) would be ready to program from scratch on your own. The power is so immense ( if well re-used ).

    nota bene

    For real-world inter-process communications, there is one minor issue to be aware of. Various ZeroMQ versions' inter-operability. Yes, the power of ZeroMQ is immense, nevertheless, it is necessary to keep the version control built in your messaging layer so as to solve situations, where some platforms do not have an update-path to "newer" releases available. Went into this issue with re-integration of a trading system with a component, where as old as zmq.__version__ == 2.1.11 was necessary, while recent are versions well above 14.x.y, so as to be assured to be 100% end-to-end backward-compatible.

    Still, the overall potential is so immense, it makes sense to persevere and get the job done. G/L on that.