You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ondrej Kupka created an issue 2014-04-27
Just checked the source code for pubsub out of curiosity and as far as I understand it, the messages are filtered on the receiver side. If that is true, I would propose to use something like go-patricia (radix tree written in Go) to filter messages on the sender side.
Actually I am the one who wrote go-patricia, needed message filtering as well :-)
Regards, Ondrej Kupka
Comments (4)
Garrett D'Amore
This is an interesting idea; but note that sender filtering is not part of nanomsg itself. So we'd need to have some new protocol exchange for the subscriber to tell the publisher what it wants. I propose that this could be done using a simple message format along the lines of + to add a sub, - to remove a sub, and no notification from the publisher. (The subscriber would intrinsically know.) I'll discuss this on the mailing list.
Edit Mark as spam Delete 2014-05-03
Ondrej Kupka
Sure. Hmm, I thought that nanomsg is doing sender-side filtering...
Mark as spam Delete 2014-05-03
Ondrej Kupka
It is true that this complicates things, of course. You need to handle subscriptions, you need to clean them up when the subscriber is not there any more etc. But in any case I guess that you could use something else than just a list of subscriptions in mangos, perhaps this trie. But that is also questionable, I am wondering how many subscriptions you would have to manage for the subscriptions list to become a bottleneck...
Mark as spam Delete 2014-05-03
Garrett D'Amore
I sent a message to the mailing list detailing my thoughts on this. There are some non-trivial challenges. The biggest problem is ensuring that you handle subscription requests reliably -- you cannot simply have a best-effort solution like we have today.
Basically, until we get a standard protocol for this in nanomsg, we can't do this. We could invent a protocol or pattern only for our use, but that seems of limited value.
The text was updated successfully, but these errors were encountered:
This won't happen in mangos v1 for sure. Maybe in mangos v2, but only if we get a portable design for this. I have some ideas but haven't had time to write it up.
Originally: https://bitbucket.org/gdamore/mangos/issue/18/pubsub-filter-messages-on-the-sender-side
Ondrej Kupka created an issue 2014-04-27
Just checked the source code for pubsub out of curiosity and as far as I understand it, the messages are filtered on the receiver side. If that is true, I would propose to use something like go-patricia (radix tree written in Go) to filter messages on the sender side.
Actually I am the one who wrote go-patricia, needed message filtering as well :-)
Regards, Ondrej Kupka
Comments (4)
Garrett D'Amore
This is an interesting idea; but note that sender filtering is not part of nanomsg itself. So we'd need to have some new protocol exchange for the subscriber to tell the publisher what it wants. I propose that this could be done using a simple message format along the lines of + to add a sub, - to remove a sub, and no notification from the publisher. (The subscriber would intrinsically know.) I'll discuss this on the mailing list.
Edit Mark as spam Delete 2014-05-03
Ondrej Kupka
Sure. Hmm, I thought that nanomsg is doing sender-side filtering...
Mark as spam Delete 2014-05-03
Ondrej Kupka
It is true that this complicates things, of course. You need to handle subscriptions, you need to clean them up when the subscriber is not there any more etc. But in any case I guess that you could use something else than just a list of subscriptions in mangos, perhaps this trie. But that is also questionable, I am wondering how many subscriptions you would have to manage for the subscriptions list to become a bottleneck...
Mark as spam Delete 2014-05-03
Garrett D'Amore
I sent a message to the mailing list detailing my thoughts on this. There are some non-trivial challenges. The biggest problem is ensuring that you handle subscription requests reliably -- you cannot simply have a best-effort solution like we have today.
Basically, until we get a standard protocol for this in nanomsg, we can't do this. We could invent a protocol or pattern only for our use, but that seems of limited value.
The text was updated successfully, but these errors were encountered: