[Feature Request] every node can play as a STUN/TURN server for higher bandwidth
xialvjun opened this issue · comments
Now the data in the yggdrasil network is send across many nodes. A <-> D may be A <-> B <-> C <-> D in the real network. This makes yggdrasil self healing, but also lower bandwidth.
What if B or C act as a STUN/TURN server?
After A <-> B <-> C <-> D connection is created:
A: hey, D, have you enabled public_real_network_address?
D: yes. xxxxxxxxxx is my real_network_address, what's your's?
A: it's yyyyyyyyyyy.
Then A <-> D connection is created, but in user space, they are the same connection. App will get higher bandwidth.
Of course, if it find A <-> D is broken (by whatever reasons, like censorship), yggdrasil can auto changed to A <-> B <-> D (if B has enabled public_real_network_address) or A <-> C <-> D (C has enabled it) or A <-> B <-> C <-> D.
Enable public_real_network_address will run the risk of widely exposed your IP.
This may be the same feature request.
Simple answer of why we don't do this is because the whole purpose of Yggdrasil is to figure out how to efficiently route with the links we have been given.
If we add mechanisms to facilitate new peerings automatically then we are changing the scope of the project significantly and we are no longer testing the same thing anymore.
Yggdrasil is an overlay over the internet because it is convenient for experimenting at scale, not because that's how the project really should continue long-term. We care about the peering topology only, we are not aware of topology under that by design.
But if without this, after yggdrasil been more popular, no community public peers can afford that big network traffic.
We could have static peers and dynamic/temporary peers. Temporary peers will be removed after the last APP connection is disconnected. This shouldn't affect nodes connecting to each other. Or even we can let connection must be made by static peers, then the other traffic can use temporary peers. Maybe I'm too naive.😔
If you want a p2p latency for yggdrasil connections, you may be interested in yggdrasil-jumper. It is a simple standalone application that transparently implements dynamic peering over the internet, roughly as you describe, with no modification needed to the yggdrasil router.
Yggdrasil is a routing protocol with fixed peerings. It's not a general protocol for end-to-end connectivity. You have some substantial misunderstanding about this project. There are other projects aimed at e2e connectivity with no peering constraints.
Simple answer of why we don't do this is because the whole purpose of Yggdrasil is to figure out how to efficiently route with the links we have been given
So, is it only a research project and no one expects it will be a mature project?
If we add mechanisms to facilitate new peerings automatically then we are changing the scope of the project significantly
I think there are enough users that already don't understand the scope of the project. And even more potential users find this project looking for a silver bullet that should solve their problems (but it isn't)
There are other projects aimed at e2e connectivity with no peering constraints
I don't know any mature or even just really working project that you can "just use" (except the very new yggdrasil-jumper, I'll look at it; I didn't even know this feature was possible outside of Yggdrasil itself)
Yggdrasil is a routing protocol with fixed peerings. It's not a general protocol for end-to-end connectivity. You have some substantial misunderstanding about this project
When you hear about Yggdrasil for the first time, it looks like a tool, a very cool silver bullet that can solve a bunch of different problems. But when you are looking closer, it turns out that every aspect of the project is not so simple, and you get disappointed with every attempt to solve your own issue with the tool
It allows you p2p connections, but with a little different meaning of p2p than in other similar projects. It looks like a VPN, but it isn't. It lets you connect to another device, but it's unsafe by default, and you have to manage the security aspects (like firewalls; not a task for a regular user)
I can't insist on it, but, maybe, it's better to be closer to user expectations? At least, shouldn't we mention yggdrasil-jumper in the Yggdrasil documentation? I don't know how it's possible to find it, even intentionally ¯_(ツ)_/¯
An overlay network with assumption of globally reachable internet would have a drastically different topology. The entire purpose, the algorithm being tested is based on the assumption that only a few peers are directly accessible. So, he's testing the algorithm under this particular assumption. Traffic gets relayed by peers, which gets the protocol tested. If traffic just reaches the peer directly every time you initiate a connection, there is no testing any more. It becomes a DHT at that time.
At some point it will be made into an actual product, or some people make another protocol and use its algo.
There will be no choice of peers if/when ygg replaces the internet
China, Iran, and Russia won't allow it. It's lucky enough TLS became widespread before China decided to up their firewall. They outright banned ECH.
An overlay network with assumption of globally reachable internet would have a drastically different topology. The entire purpose, the algorithm being tested is based on the assumption that only a few peers are directly accessible. So, he's testing the algorithm under this particular assumption
@planetoryd, but can we think of it as an optional optimization layer (based on underlying protocol(s)) for Yggdrasil? We can continue to test Yggdrasil without the optimization, but keep an (experimental) option for end users
In any case, it might be better if each Yggdrasil peer could natively act as a STUN server (it already acts similar to TURN) at the protocol level to get rid of third-party stun servers from the yggdrasil-jumper configuration. It's great that we can implement this already, but wouldn't it be better if yggdrasil-jumper could rely only on Yggdrasil and not third-parties to implement this feature?
I would like to remind community members that Yggdrasil is not intended to solve your problems.
DNS is not the goal of Yggdrasil.
Firewall is not the goal of Yggdrasil.
Tunneling in the form of CKR is not the goal of Yggdrasil
Breaking through NAT is not the goal of Yggdrasil
Bypassing blockages and sanctions are not the goal of Yggdrasil
STUN server is not Yggdrasil's goal
Stop flooding, please.
Closing for reasons discussed earlier.