[zeromq-dev] v3.1 publisher filtering

Steve steve.friendly at gmail.com
Tue Mar 13 14:06:48 CET 2012

Joshua, thanks, that clears it up.

The v3.1 XPUB / XSUB keeps the system really scalable and efficient if you
have cascading publishers / subscribers.  However, the last leg to the
subscriber is still going to have 'unwanted' messages going to certain
subscribers (Subscriber 'A' in my example).  I would think that this would
be a natural use case to solve but maybe it introduces scaling problems
since the publisher has to keep a detailed subscriber list?

As far as using the Router / Dealer, I need to look at that more. I'm
assuming this will allow my to 1) intercept subscription requests so that I
can keep a list of subscribers and their subscriptions and 2) only send
messages to subscribers that have subscribed to the message.  If a
subscriber drops off, you mentioned that there is no way to detect this so
what would be the ramification of this happening?  Would messages to
dropped subscribers get queued in ZeroMQ internals?  Is there a way to
mitigate that by setting the High Water Mark to something low or even zero?

Writing an alternative PUB socket seems like it would be the best option.
However, since I just started looking at ZeroMQ I think it is a bit too
much for me as I'm sure there are lots of internals to consider.



On Mon, Mar 12, 2012 at 6:43 PM, Joshua Foster <jhawk28 at gmail.com> wrote:

>  3.1 works the same way as 2.1 in your example. The changes in 3.1 is that
> the subscription is forwarded to the PUB socket. This allows you to create
> a publisher device. It would sit between the parent publisher and the
> subscriber. The XPUB keeps track of the subscriptions and allows them to
> apply to the XSUB socket. This effectively filters out any messages that do
> not match a subscription. In your example, you are matching against "a" and
> "" so all messages would be passed through.
> You can of course use a ROUTER socket and manage the subscriptions
> yourself in the application (with DEALER). The main downside is that you
> won't be able to detect client disconnections. You may also want to
> consider creating an alternative PUB socket implementation in ZeroMQ.
> Joshua
> On 3/12/2012 6:48 PM, Steve wrote:
> I have a high level question about how a v3.1 publisher handles sending
> updates to subscribers.  I understand that v3.1 can push the subscription
> filtering further towards the publisher but to what degree I'm unclear on.
> Here is a very simple usage example:
> 1) Publisher has a list of topics that are randomly updated 10 times a
> second.  There are a total of 26 topics and each is a single lowercase
> alpha character representing the English alphabet (a - z).
> 2) Subscriber 'A' subscribes to just a topic matching "a".
> 3) Subscriber 'B' subscribes to all topics ("").
> In version 2.1, I believe Subscriber 'A' would receive all the messages
> and that the zeromq client library would filter them so the client would
> only see updates on 'a'.  In version 3.1, is it possible to filter the
> messages at the publisher so that Subscriber 'A' only receives updates on
> topic 'a' (no filtering done on the client) and that Subscriber 'B'
> receives all updates on all topics (a-z)?
> Thanks,
> Steve
> _______________________________________________
> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120313/6897da5e/attachment.htm>

More information about the zeromq-dev mailing list