[nanomsg] Re: publisher side filtering
- From: Dirkjan Ochtman <dirkjan@xxxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 3 May 2014 21:09:18 +0200
On Sat, May 3, 2014 at 8:32 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
> There are some good reasons for this to be that way — not least of which is
> that subscriber filtering is CPU intensive, and is frankly incompatible with
You meant publisher filtering here?
> multicasting on a medium that supports multicast. (Note that nanomsg
> currently lacks multicast support, but I consider that possibly a temporary
> limitation. While inappropriate for req/rep or push/pull or pair,
> multicast media would be useful for pub/sub, bus, or my experimental star
> protocol. Anyway, this isn’t about multicast — at least not really.)
> Certainly, the more I think about this, the more I see the simple elegance
> of just subscriber filtering, and the more I want to simply dispense with
> publisher side filtering. But people are asking…
>
> Thoughts?
It was implemented in crossroads and zeromq, I think. One of the use
cases where I really liked it was that it was possible to do a PUB/SUB
device (i.e. bridge) for e.g. a WAN linking several LANs, and it
really made a lot of sense there. In my mind, publisher-side filtering
is a better conceptual fit with the "publish-subscribe" idea; i.e. I
think the natural expectation for publish/subscribe systems is that
all of the unsubscribed messages should not traverse the link.
Cheers,
Dirkjan
Other related posts:
