These are chat archives for fanout/pushpin

Nov 2016
Devin Fee
Nov 28 2016 17:55 UTC
@jkarneges you were correct about {"action": "close"}. I noticed that pygripcontrol's WebSocketMessageFormat doesn't support changing the key of the message body, so I just created another subclass:
class WebSocketControlMessageFormat(Format):

    def __init__(self, control):
        self.control = control

    def name(self):
        return 'ws-message'

    def export(self):
        return {'action': self.control}
Devin Fee
Nov 28 2016 18:20 UTC

Is there a way to query the clients who are subscribed to a channel? For example, chat rooms often list who's present. I'm currently imagining implementing this:

  • a Redis SET of sessions keyed to the channel name (e.g. 'chan1': {'sess1', 'sess2', 'sess4'}), and
  • a Redis SET of channels keyed to a session id (e.g. 'sess1': {'chan1', 'chan2'})

I'd need to perform the necessary Redis operations to build the sets on open, and the Redis operations to delete the session SET and pop from the channels' SET.

However, I'm doing a lot of work to manage state that Pushpin is already aware of, introducing another service (Redis), and attempting to maintain consistency – which is never a simple task.

Justin Karneges
Nov 28 2016 18:38 UTC
@dfee you can monitor subscriptions using the stats socket or sub socket (both zmq based)
you can't exactly query for past subscriptions though, so you'll probably still want to store the results in a separate db like Redis. I consider this preferable to the idea of querying Pushpin, since in a high scale situation you might have lots of Pushpin instances and probably don't want to be issuing queries to all of them
there's a program called that you can try out
python tcp://localhost:5562
Devin Fee
Nov 28 2016 18:43 UTC
Ok – your description of the challenge querying a multi-node Pushpin network for subscriptions is helpful in justifying not supporting querying.
Justin Karneges
Nov 28 2016 18:50 UTC
pushpin will tell you when at least one subscription exists for a channel, so you don't have to deal with individual sessions. if 100 clients subscribe to the same channel you'll get one subscribe event when the first client arrives. if they all unsubscribe, you won't get an unsubscribe event until the last one is gone
the stats socket emits events when subscriptions come and go, but it doesn't send past subscriptions and it's also not reliable (so if your listening worker ever dies, you'll need to timeout any subscriptions you haven't heard from in awhile)
the SUB socket is a bit fancier. all past subscriptions are sent upon connect, and the zmq client library on the listening side will simulate unsubscribe events if the listener ever disconnects. so it's very easy to achieve a consistent in-memory channel set, which you could also copy over to redis