how to broadcast to all connected clients?

[sritchie]

Socket.io allows broadcast to every client, or to every client except the sender. I'm using Sente to broadcast race results in realtime to every connected browser - this feels difficult in the current API.

I think what I want is socket.io style channels in addition to the per user channels. I can fake this by using the "uid" as a channel ID for now. Just wanted to gather thoughts.

[sritchie]

Similar to this socket featureset, I guess?
https://github.com/LearnBoost/socket.io/wiki/How-do-I-send-a-response-to-all-clients-except-sender%3F

[sritchie]

I'm also happy to work on this one, depending on how you feel on this extended channel or topic functionality.

[seancorfield]

I'd be interested in this functionality too.

[ptaoussanis]

Oh, just posted to the Google group. Will copy, let's keep the discussion going here instead:

---

I'll be honest I'm a little hesitant to add any kind of room/subscription facilities to Sente itself...

My thinking currently goes:

• Far as I can tell (?), this is always easy to do application-side.
• Doing it application-side gives a lot more flexibility. For example, what if you've got multiple servers and want a distributed/db-backed subscription index?
• For general hygiene I prefer keeping state (like subscriptions) separate from the comms mechanism itself. Keeping subscription info in Sente makes it tricky to get to if you want to do something unexpected with it. When you control the shape+location of the relevant data/atom(s), you're free to use it and bash on it however you like.

Instead, I'd propose to just expose a set of currently-connected uids. You can then intersect that set against any subscription/channel logic you may have.

Having said all that, I'm not sure what Socket.IO's rationale was when they chose to bundle subscription semantics into the core API so I might well be missing something...

Does that make sense? What do you think? Is your concern more that maintaining your own subscription data will be a nuisance, or that it's difficult to do? Am definitely open to ideas I may not have thought of.

@seancorfield Would be happy to get your thoughts too Sean!

[ptaoussanis]

Have added a quick commit to the dev branch that returns a :connected-uids set for the server-side make-channel-socket!.

There's a couple ways it could be implemented - need to do some benching. Won't take long, just swamped atm - will try find time in the next day or two.

[ptaoussanis]

Okay, just pushed v0.10.0 which exposes an atom that tracks connected user-ids. You can deref it to get a snapshot, or watch it to get changes as they happen. Changelog: https://github.com/ptaoussanis/sente/releases.

Also updated the example broadcaster to show how to use it, but it's pretty straight-forward.

Closing this issue for now, but feel free to reopen if either of you have any additional thoughts.

Cheers! :-)

[sritchie]

Totally agree that this should be built outside of the core library. I think that that atom is enough to build out the rest.

For broadcasting to multiple folks, do you recommend just doseqing through calls to ch-send!, or is there some bulk send operation I could add that would make this more efficient?
—
Sent from Mailbox for iPhone

On Wed, Apr 16, 2014 at 3:20 AM, Peter Taoussanis
notifications@github.com wrote:

Oh, just posted to the Google group. Will copy, let's keep the discussion going here instead:

I'll be honest I'm a little hesitant to add any kind of room/subscription facilities to Sente itself...
My thinking currently goes:

• Far as I can tell (?), this is always very easy to do application-side.
• Doing it application-side gives a lot more flexibility. For example, what if you've got multiple servers and want a distributed/db-backed subscription index?

• For general hygiene I prefer keeping state (like subscriptions) separate from the comms mechanism itself. Keeping subscription info in Sente makes it tricky to get to if you want to do something unexpected with it. When you control the shape+location of the relevant data/atom(s), you're free to use it and bash on it however you like.
  Instead, I'd propose to just expose a set of currently-connected uids. You can then intersect that set against any subscription/channel logic you may have.
  Having said all that, I'm not sure what Socket.IO's rationale was when they chose to bundle subscription semantics into the core API so I might well be missing something...
  Does that make sense? What do you think? Is your concern more that maintaining your own subscription data will be a nuisance, or that it's difficult to do? Am definitely open to ideas I may not have thought of.
  @seancorfield Would be happy to get your thoughts too Sean!

  Reply to this email directly or view it on GitHub:
  how to broadcast to all connected clients? #23 (comment)

[ptaoussanis]

For broadcasting to multiple folks, do you recommend just doseqing through calls to ch-send!, or is there some bulk send operation I could add that would make this more efficient?

I think a doseq should be fine - the send call is async. For large broadcasts, I'll sometimes actually induce a pause between sends. I'll define a window - say 100ms - and distribute sends evenly over that window to keep the server load smooth rather than spikey.

Does that make sense?

[ptaoussanis]

Oh, I should add - if you try send to a disconnected client, it's just a noop. So no need to worry about a connected-uids deref/snapshot going stale.

[sritchie]

Hey Peter,

Sorry for my silence, I've been on the road traveling back out to Cali. Thanks for all your advice. I'll ping back if I run into any trouble. Sente's the solid foundation I needed to get working on this stuff.

[ptaoussanis]

Hey Sam, no problem - just shout if there's something I can assist with. Cheers! :-)