Surely the only approach that could work is to select a performant relay at the point that data needs to be transferred (especially since most devices are connected to a relay they won’t use, and most of the others won’t be transferring data most of the time).
The obvious approach which comes to mind is, when data needs to be transferred, the devices open up connections to a handful of promising-looking relays, and blocks are pulled through all of them simultaneously. The ones which have less bandwidth naturally end up transferring less of the data. The least performant relays can be dropped to reduce the load on them.
Of course, that’s probably also the most technically challenging solution, and therefore the least likely to be completed…
Another idea is to let devices “rate” the relay they’re using: when transferring data through a relay, they tell a central point (the relaypoolsrv) what speed they’re getting. Other devices can consult this at the point that they start transferring data, allowing them to first hop to a higher-rated relay.
Of course this is open to abuse. Another option is to let the relay tell the relaypoolsrv what speeds its devices are getting in practice, but that’s open to a different kind of abuse. Maybe a combination of both…
EDIT: Although, thinking further, if devices monitor the performance they’re getting out of a relay, and move away from it if it’s significantly worse than advertised, then that limits the damage that someone can do by advertising themselves as a relay with unlimited capacity.
I remember a discussion somewhere else about allowing devices to announce alternate addresses for themselves (and others) over a normal connection between two devices (in addition to the discovery servers). That seems related to allowing devices to quickly announce a change in relay to each other.
But the device we need to talk to needs to already be connected to them and waiting, and per definition they cannot accept incoming connections - otherwise we wouldn’t be using relays.
Devices that are idling on a relay and waiting for a connection don’t need a performant relay, and neither do devices which are connected through a relay but aren’t actually transferring anything.
So one could use the current algorithm, or something even simpler, to pick a relay to connect to initially. It might be slow: that doesn’t matter.
It’s only at the point where two devices become connected over a relay, and one devices to transfer data to (or from) the other, that they look at the current state of the relay network and pick (a) good relay(s) to switch to, if necessary. One would probably have to tell the other the address of the new relay(s) directly, using their existing connection.
(To be clear, I personally don’t have any complaints with the existing relay network, and I’m not asking anyone to implement anything. This is just thinking and brain-dumping for the fun of it).
Hello, I just set up 2 relay from our company server in singapore. In just 4 hours, the data flow is huge and stay there. Is that maybe there’s no relay server in asia so that cause the problem? I just asking, and I’m new here.
I planning set up more relay if the company money isn’t that tight. Thanks.
Quite likely. Asia is somewhat underrepresented relay wise, and Singapore is well connected. I wouldn’t be surprised if you’re also picking up traffic from Oceania.
Anyway, I also have another question. Why the traffic data should move between a relay server, not direct from IP A to IP B like torrent do? Or I’m missing the point in the process? I just don’t get it, I think the relay server only to make client know and agree on spesific port to be used lik torrent does. Thanks.
I Think it start to be out of topic about this thread. Last hunch. Then how torrent work behind firewall? I’m quite curios about it. I mean if the port say like un occupied port, and they report to server, using port that’s not used, that means it will work right? Let’s say above 20000 until 65001 such ?
I am sure you can find plenty of information on the internet how torrents work.
Torrents use stateless protocols based on UDP which can punch through NATs, syncthing uses TCP.
On top of UPnP, there are multiple techniques to directly connect two systems behind NAT directly. One often used in https://en.wikipedia.org/wiki/TCP_hole_punching that uses the “relay server” just for setting up the connection, but the actual traffic doesn’t hit the Relay Server