These are chat archives for fanout/pushpin

26th
Nov 2016
Devin Fee
@dfee
Nov 26 2016 03:52

@jkarneges after playing w/ pushpin I have a better idea for how it works. However, I'm a bit puzzled as to how I'd attack this problem:

  • each client (browser window) has an open ws
  • clients are authenticated via sessions
  • ergo, a session can have multiple clients (A web browser can have multiple open windows, all connected)

So, if the session is to expire (a trivial case would be a client logging out) with a POST to /logout, how might I close all the open websockets for the session?

Without Pushpin, I need to keep track of sessions and WS connections (in a database) – but I think there'd be a real gain for my software if I can keep this stateless. For instance, if I subscribed all the session's clients to the channel session:1234, it'd be great to send a CLOSE message to that channel with then gets broadcast to all subscribers of that session channel. Is something like this possible?

Devin Fee
@dfee
Nov 26 2016 04:11
Maybe it's simpler if I ask this: how can I close all WS connections that are subscribed to a particular channel?
Devin Fee
@dfee
Nov 26 2016 04:38
Or, we can abstract the question one level further: how can I send control messages for clients subscribed to a particular channel?
Devin Fee
@dfee
Nov 26 2016 06:11

I referenced some messages dating back to May 25 :point_up: May 25, 2016 11:14 AM and discovered I'm not the first to have this challenge.

An alternate implementation could be (and, I'd love to hear your considerations) to subscribe a client to channels: [session:{id}, user:{id}, and resource:{id} x N resources]. Whenever a user needs to subscribe to a new resource, I could send a channel "user:{id}" a message with body "RECONNECT" (if using SSE) or "REDISCOVER" (if using WS) and reset the client's subscriptions now that I can send control messages again. The same thing would apply when a session is unauthenticated – effectively dropping the "user:{id}" channel.