pub-end filtering

[tj]

for subscriptions. back when we were going the router/dealer route propagation would have been a bit more annoying but now that we would just relay with pub/sub all the way through this should be trivial

[gjohnson]

Interesting request today at work, wanted to jot it down before I forget... Wanted a nice way to know how many peers where listening to a given topic in pub/sub, obviously not possible with the current sub-end filtering, but something to keep in mind whenever we get around to this.

[brycebaril]

Yeah, this is the way Redis pub/sub filtering works -- and it tries to address the 'how many peers listening to a topic' by returning the number of subscribers who got the message when you publish. The problem is if you're publishing to a middle-man who re-broadcasts (say Master-Slave replication in terms of Redis) you can't ever really know how many actual listeners there were, at least not trivially.

My guess is in pretty much every case if you need read receipts you're probably better just adding a separate publish channel from the workers, which really should be up to the implementation as opposed to the library.

[tj]

we could propagate the subscribers upstream reasonably easily but I totally agree, in most cases, especially performance-critical cases you would likely have a dedicated socket anyway. I can see that being troublesome when N topics is a really large N but for myself at least that's never the case