1

I have N subscribers to a Publisher. The message is a simple boolean value. The messaging pattern is slightly different from the regular PUB/SUB :

  • When one subscriber receives a true, all the other subscribers are supposed to receive a false.

So I would love to publish a false to all but one subscriber. This exceptional subscriber is not fixed, but selected by user.

One idea I have right now is to PUB/SUB a false to all, then send a true to the exceptional subscriber with a PUSH/PULL or PAIR/PAIR pattern. But this feels like a hack.

Will there be an easy solution based on PUB/SUB pattern instead of looping through a 1-to-1 pattern?

kakyo
  • 10,460
  • 14
  • 76
  • 140

2 Answers2

1

Q : "Will there be an easy solution based on PUB/SUB pattern instead of looping through a 1-to-1 pattern?"

Oh sure, there will.

Use XPUB/XSUB Archetype. Each XSUB starts with sending it's "subscription"-message, a UUID#-hash or likewise.

The XPUB, as it .recv()-s the XSUB-s "subscription"-message, registers a new peer, it's UUID#-hash and in cases, when it indeed wants to send some message to this very peer and no other now, it simply .send()-s such a message, having made the UUID#-hash put as a binary-prefix to it ( i.e. prepended "on the left" side of the actual message, as you know it from the PUB/SUB ), as this is the way the topic-filtering works.

So easy.
So cool...

user3666197
  • 1
  • 6
  • 50
  • 92
1

Don't use topic filter at all. It's not sophisticated enough for what you want to achieve. So you'll have to have the filtering done by the application.

So if the PUB sends a message containing a single number, e.g. '3', so long as the SUB node that is #3 knows its own identity, it will get the message '3' and accept that as a "true" intended for itself.

Meanwhile all the other SUB nodes also receive the message '3', but know that they're not #3, and so interpret this as a false intended for themselves.

Where you may get into trouble is if the client PUB nodes have no way of knowing their own identity. But solving that sounds fairly easy with run time configuration. Another way would be to use XPUB/XSUB, and use the subscription message from XSUB to XPUB as a way for a client to "announce itself" to the PUB, but then immediately undo that to revert to a blank topic (so as to receive every XPUB message).

bazza
  • 7,580
  • 15
  • 22
  • Wow. That sounds super convoluted. I think I'll probably just use a app-side logic to filter with a simple loop. Thanks for the explanation though. – kakyo May 21 '20 at 07:01
  • @kakyo Good luck! – bazza May 21 '20 at 07:10
  • Yes, "knowing" is just the first part of the problem, the next is to handle, if not avoided *weakly* if not un-*managed* at all "identity" duplicates, the next is how to detect an added node, the PUB is unaware about, that was not present so far, the next is how to detect a lost node, sending any future messages to is of no impact, yet the PUB is unaware of it. ( The subscription management, that is the topic). Anyway, if the implementation is not critical, sending a bit-field with one and only one bit ON, will work for naive, bit-position mapped signalling at the lowest costs possible **:o)** – user3666197 May 21 '20 at 07:34
  • @bazza BTW, does your **assumption to "*immediately undo that*"** hold? AFAIR, the topic-filter (now, in post v4.x+ API operated on (X)PUB-side) can have multiple (many) subscriptions, so having the first one being the ""-blank ( i.e. subscribe to anything ) + having the any next subscription topic the *{ id }* and / or whatever else, will still deliver all messages to this (X)SUB-side, as the ""-blank still does match any such message, doesn't it? So if we ignore the issues with management of dynamically (dis-)appearing peer-nodes' identities, the XPUB/XSUB is a free to use signalling channel – user3666197 May 21 '20 at 08:26
  • 1
    @user3666197, ah, you're right. If one can subscribe to multiple topics, then one of those topics can be for all (X)SUB nodes to receive all messages. UUIDs/GUIDs sound like a good way of ensuring there's no identity clash (i.e. '3' becomes ''. As for lost nodes, whether that's a problem the OP will experience is uncertain; but perhaps regular resubscription by the client XSUB nodes could be used as a way of saying "I'm still here!". – bazza May 21 '20 at 09:10
  • 1
    Pleasure to hear you pieces of wisdom. As always, Salute, Sir! – user3666197 May 21 '20 at 10:16