haha.. one step at a time.. need to think about how to scale the “lots of subscriber” case.. in a distributed way

yeah @incalculable-waitress-45352 should have thoughts and maybe some code he can share. he did some of this with his sfu

if you have roles (e.g. you know someone is subscriber only) you can just put them on any box (+ build box to box streaming)

it does get very complex

when we break a box size i’ll let you know 😉

yeah, so the idea i had was basically -- think of publishing and subscribing as 2 different units. then, you have a bridge/replicate node in between. subscribe --> bridge/replicate <--> publisher i.e: publisher A, publishes video to instance A subscribe 1, trying to subscribe to publisher A, instead of going to instance A directly, it can connect to an intermediate node which then find the origin for publisher A and subscribe from it. in my implementation i've tried kind of a p2p model where any instances can subscribe to any instances without clear lines of responsibility, but it turned into a clusterfuck very quickly LOL. so it might be easier if you make them as a separate instance with clear responsibility -- have the intermediate node only pulling videos for origin. from scalability standpoint, i'd imagine something like: subscriber nodes in the edges, which communicate to the immediate nodes in the region, which communicate to the origin. with this strategy you should be able to scale exponentially.

it's definitely easier to think about it when you pull apart publishing / subscribing imo

lmk if that make any sense if not i can draw up a diagram might illustrate it better

Sounds like having colocated relay nodes that a subscriber connects to

“Relay nodes” was the way I understood it, like daisy chaining the streams

What if a subscriber then becomes a publisher?

Is the idea that relays get set up for every publisher in a room?

hmm I think you'd have to join the RTC node (where room is hosted on)

easier to think about it as a second category.. relay nodes. I'm still wondering if it's simpler to have this second category of nodes feed off of a single track (that's a combination of all of the tracks from the room)

yeah it's basically relay nodes.

there might be 50 tracks in the room from various clients.. seems complicated to send that through

back when i was working on mine, i don't really have the concept of room because i feel like it's a wrong way to look at it. my design was focusing on clients should be able to specify which stream / tracks they want to subscribe / publish. and the design will do the hard work of routing and figuring out

it's slightly different than the requirement of room, but thinking about now, probably not as much -- lul

what makes you think it's complicated to send that through?

it's more complicated than sending one stream 🙂

ah gotcha

i.e. ideally relay nodes don't have to worry about participants joining/leaving/etc

but that the stream is tied to the lifecycle of the room

that makes it much easier to scale

yeah i think there's only 1 way to get true brodcast + real time - make subscriber only allowed to fan out. You can publish to the same box (or room) but the the concept of a room is just a grouping id. There's a lot more complexity as you go down this path but fan out for subscribers only is probably the shortcut to "infinite scale"

so thinking about it.. I think the relayer idea would work pretty well.. versus trying to condense into one stream..

the relayer would be a separate cluster that can scale independently.. to keep the core RTC servers as focused as possible

yeah relayers basically have added latency (1 extra hop), ideally people on the call aren't on it.

I'd put publishers / subscribers on any box, this way you can scale up by just increasing node and not having pools of things, also you'll probably always have inbound bandwith available

you could make it so that publishing for a room happens on 1 server but there isnt' much of an advantage to put relayers on their own box