Difference between ZeroMQ and IPC
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
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?