A: Yes, there is
ZeroMQ
is a wonderfull toolbox. After many years I would dare to say, any of it's pre-built Scaleable Formal Communication Pattern to be a basic pattern. Each one is rather an example of a formal behaviour and sure, there are many cases, when these trivial behavioural pattern do not fit the needs the software Projects would like to have and advanced scenarios are coming to the stage.
There we go.
Consider ZeroMQ
to be rather an enabler toolbox, not a solution provider. So, let's put sleeves up and start designing the very mix of behaviours, that are needed for the Project.
Messaging and signalling components benefit from built-in features of ZeroMQ
elements. The design shall make the missing parts and the glue logic to match the Project specification.
Once ZeroMQ
socket-end-point does not give you any code-driven control on it's blocking behaviour, you need to add such one.
Let's imagine the A to have an incoming socket A_IN
( being PULL
on A
-side ). This way your code can control when and for how long it will ( will not ) PULL
next incoming message, based on your Project-specific logic, implementing the mutually bonded buffering/blocking policies, based on states from monitoring both buffering-watermarks and messaging-socket-state of exgress-traffic directed sockets A_OUT_2_B
and A_OUT_2_C
).
This way your code can add controls for explicit, Project-specific, management of the blocking state of A_IN
, add element-state inspection features, it's reflectivity to other external control / system signals and many other features one may wish to have in place.
Welcome to the worlds of ZeroMQ
& nanomsg
and enjoy it's powers for both messaging and smart signalling in the distributed systems
If interested in more answers on elementary & advanced ZeroMQ topics, feel free to read other ZeroMQ
& nanomsg
related posts.