Closed Markcanfly closed 5 months ago
This is a solution for #108
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.
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.
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 suppliednext_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.