[zeromq-dev] One to Many synchronous messaging

Jasper Jaspers jaspers01995 at gmail.com
Fri Mar 27 23:14:14 CET 2020


What if I want the publisher to broadcast the message using a multicast
like transport.  Some published messages can be quite large and would like
to limit amount of traffic on the wire if possible.  Any way that can be
supported?

On Fri, Mar 27, 2020 at 3:55 PM Brett Viren <brett.viren at gmail.com> wrote:

> Jasper Jaspers <jaspers01995 at gmail.com> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20200327/679eaf07/attachment.htm>


More information about the zeromq-dev mailing list