We are working on a multi-process program like chrome ipc.
The communication between parent and child process will utilize ZeroMQ. The parent will send specific messages to specific child. And the child will also transmit messages to parent at a higher frequency say 50 times per second.
I found the instruction of ZeroMQ. As the suggested, the current plan is a router socket in the parent as a separated IO thread and a dealer socket in each child process.
Is this a good design?
Q : "Is this a good design?"
That Hell depends ...
Most of my distributed-computing implementations have many ZeroMQ Formal Communication Archetype patterns co-operating at once, as the system design is built on top of the ZeroMQ messaging/signalling-plane layer. No single archetype pattern suffice. That is both granted & natural - the Zen-of-Zero is built around performance, so no single archetype pattern was designed for having a single feature more, than indeed needed and all the rest (above) is achievable by application-level composability of these toolbox primitives.
The Zen-of-Zero prefers to be laser-focused on low-latency, almost-linear scalability of as high performance as possible.
If there were any such archetype, that would match One-Size-Fits-All dedication, the add-on costs of latencies-added, degraded-performance penalties would be unavoidable, yet having negative impacts on all such use-cases, that do not need any other but the very minimal design properties that the toolbox primitives were built around, while any more complex needs still could be implemented on an as needed basis.
