Difference between ZeroMQ and IPC

NiCk Newman picture NiCk Newman · Sep 20, 2015 · Viewed 8.8k times · Source

Q1: What exactly is the difference between using ZeroMQ to send messages to child processes, as compared to the default inter process communication explained here?

Q2: For direct process to child communication, which would be more appropriate? (Faster)

Q3: The docs say: Creates an IPC channel, what kind of IPC does it use? TCP? Sockets?

Answer

user3666197 picture user3666197 · Sep 21, 2015

A good point to state in the very inital moment - ZeroMQ is broker-less


A1: The difference between using ZeroMQ to send messages & IPC

well, put in this way, ZeroMQ concentrates on much different benefits, than just the ability to send message & scale-up ( both of which is helpfull ).

ZeroMQ introduces ( well Scaleable ) Formal Communication Patterns

This said, the core application-side focus is directed into what ZeroMQ-library pattern primitives could be used to either straight fulfill the actual needed behaviour model between participating agents ( one PUB + many SUB-s / many PUB-s + many cross-connected SUB-s )
or
how to compose a bit more complex, application specific, signalling-plane ( using available ZeroMQ building blocks behaviorally-primitive-socket archetypes + devices + application logic, providing finite-state-machine or transactional engines for signalling-plane added functionality ).

Standard IPC provides a dumb O/S-based service, no behaviour

which is fine, if understood in the pure O/S-context ( i.e. "batteries included" is not the case ).

Nevertheless, any higher level messaging support and other grand features ( alike fair-queue, round-robin scheduling, mux-ed transport-agnostic service composition over any/all { inproc:// | ipc:// | tcp:// | pqm:// | ... } transport-classes, millisecond-tuned multi-channel pollers, zero-copy message handovers and many other smart features ) are to be designed / implemented on your own ( which is the very case, why ZeroMQ was put in the game, not to have to do so, wasn't it? many thanks, Martin SUSTRIK & Pieter HINTJENS' team )


The best next step?

To see a bigger picture on this subject >>> with more arguments, a simple signalling-plane picture and a direct link to a must-read book from Pieter HINTJENS.


A2: Faster? I would worry if anybody grants an easy answer. It depends... A lot...

If interested in a younger sister of ZeroMQ, a nanomsg, check even a more lightweight framework from Martin SUSTRIK nanomsg.org >>>.

Fast, Faster, Fastest ...

For inspiration on minimum-overhead ( read as a high potential for speed ) zero-copy ( read as efficient overhead-avoidance ) read about inproc:// transport classes for inter-thread messaging:


A3: It uses IPC.

IPC is a transport-class on its own. There is no need to re-wrap/align/assemble/CRC/encapsulate/dispatch|decode\CRC-recheck\demap... the raw IPC-data into a higher abstraction TCP-packets if being transported right between localhost processes over an IPC-channel, is it?