search

kixelated / moq-rs

Rust library for Media over QUIC
Apache License 2.0
385 stars 56 forks source link

moq-api controlled routing of subscriptions between relays #118

Closed Markcanfly closed 5 months ago

Markcanfly commented 10 months ago

Implement a possiblity for arbitrary routing of subscriptions between relays, controlled by moq-api.

The default behavior stays the same, relays are connected as a full mesh. Meaning if you SUBSCRIBE to a track on a relay, it will directly call out to the origin relay of that track, and SUBSCRIBE to the track there.

If however you supply one or more --next-relay ${RELAY_URL} parameters when starting the relay, the relay will send these next_relay URLs to moq-api as a URL parameter. If moq-api finds the track in its KV store, instead of returning the real origin of the track it will choose from the supplied next_relays, and return that as the origin.

This results in the ability to restrict traffic within nodes to arbitrary topologies. See examples in dev/topologies/star/topo.md and dev/topologies/spine-and-leaf/topo.md

By default the choice of the next relay is random, to serve as a basic load balancing mechanism, but smarter routing patterns can be implemented there.

Markcanfly commented 10 months ago

This is a solution for #108

Markcanfly commented 10 months ago

For now it doesn't have the stateful routing, this is more of a skeleton for that, but it's still suitable for a simple tree-like structure. I won't have time to work on figuring out an actual application-layer routing for this in the next 2 months, so if anyone wants to use this as a base, please do.

kixelated commented 9 months ago

For now it doesn't have the stateful routing, this is more of a skeleton for that, but it's still suitable for a simple tree-like structure. I won't have time to work on figuring out an actual application-layer routing for this in the next 2 months, so if anyone wants to use this as a base, please do.

Yeah of course. Thanks for putting this together!

I think the play is PUT relay/<name> on startup and keep refreshing that entry while the relay is alive. It would contain the paths to other relays via --next-relay. You could then make a simple path-finding algorithm to figure out how to go from one relay to another.

But I don't think we can run this code until then. Rolling the dice on which non-equal route to take is just going to make the experience worse.