Jasper Jaspers <[email protected]> writes: > I have a publisher that needs to send a message to multiple subscribers and > wait for each of > the subscribers to receive and process the message. Is there a recommended > socket or > combination of sockets that can be used to achieve this messaging behavior?
I think PUB can not be used for this pattern. PUB + extra socket for feedback from subscribers seems problematic to me. Consider a variant of the "paranoid pirate" pattern from the guide. Just the broker-worker back end. The broker would be your publisher, the workers your subscribers. Instead of the broker doing a 1-to-1 meeting between client-worker your publisher would do 1-to-many. But each of your subscribers would be similar to the paranoid pirate worker. Here's how it might go: The publisher has a ROUTER and subscribers have a REQ (or a DEALER). Subscribers send initial request message which contains whatever subscription info may be needed by the publisher. Note, there's no subscription filter you get for free like with PUB so that would have to be implemented in the publisher. Publisher collect these requests but otherwise leaves them hanging until whatever criteria for a new publication is reached. Publisher then publishes the message by sending as a reply to each waiting request (here, applying a filter if relevant). Subscribers receive their message and do whatever processing they need. When finished, they make a new request which the publisher interprets as "all done". Cycle repeats. Consider how the publisher should detect and handle when a subscriber doesn't make that subsequent request. Likewise, vice versa. -Brett.
signature.asc
Description: PGP signature
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
