New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build relay functionality into syncthing itself #4182
Comments
|
This doesn't make sense as it does not solve the bootstrapping problem of device A having to know where this relay that it can use to connect to device B or this discovery server that can help me find address of device B is if the discovery server and the relay actually runs on B. |
|
Even if it doesn't solve the bootstrap issue, it can still reduce load on the global discovery servers and relays (and improve efficiency). As an example, say you have 3 devices set to sync with each other, A, B, and C, and B has an internet routable address which A and C are configured to connect to directly. In the current setup, an external relay is required for A and C to talk, and they have to use a separate discovery server to find that connection. If Syncthing itself were to optionally operate as a relay between other trusted nodes though and advertise this functionality when nodes connect, then that setup would actually be able to run completely self contained beyond bootstrap (B would just relay for A and C), and in fact depending on how connections are ordered, it may not even need to talk to a global discovery server at all. Additionally, assuming that B has more bandwidth that it can dedicate to the links, it would probably sync data between A and C faster than using an external relay. |
|
@Ferroin That is 100% certain that node B in my case could relay much-much faster than anything I could get trough a public relay. In addition to that @AudriusButkevicius, node B has a domain name (and a static IP), A and C know for certain how to connect to B. But let's assume even if the IP was dynamic and there's no domain name assigned to the node, this feature would still allow faster relaying after being discovered. |
|
Though it would be even nicer if node B could provide private discovery and private relaying all built into one client. Though that's not exactly what I had in mind creating the issue (original issue was meant only to integrate relaying). |
|
The discovery part is #3474. |
|
What you described can already be done, yet it's a bit more advanced use case of what the average Joe might care about, hence I think it's acceptable for users to have to put some effort to get the relay up and running as well as configuring the clients. |
|
To be honest, providing relay functionality internally wouldn't be a bad idea if it just worked, so reopening. We'd probably start comparing to skype in terms of connectivity abilities at that point, as you could imagine relaying across multiple nodes to get connected. |
|
We already do this, we just relay file data instead of connections. It's unclear to me what the gain would be.
|
|
Thats actually a good point, as it gives you a false assumption of things being faster. It's probably slower. |
|
You could imagine a folder that is shared only between A and C with messages relayed via B because they all share some other folder. |
|
@AudriusButkevicius That's actually exactly what I would want this functionality for. In my case, node A is my laptop, node C is my phone, and node B is a Linode instance. I only share one folder between all three systems (in particular, a folder I use for Dropbox-like functionality), but I share quite a few folders between the laptop and phone that aren't shared to the Linode instance (because of both space and security considerations). It would be really nice if I didn't have to set up my own relay server on the Linode instance together with a private discovery server (because there is a monthly bandwidth cap which would mean I'd have to limit it to less than most of the public relays if it was public) just to improve sync efficiency between the phone and laptop when they're not on the same network. |
|
You don't need discovery to use relay. Just enter the relay address as your listen address and as an address of the remote devices. |
Would it be possible to add a configuration flag to make standard syncthing client act like a relay and discovery server for just those devices that are trusted by that syncthing client?
This would make it tremendously easier to run Syncthing on a server, to make it act like a high bandwidth high up-time relay and file host, without having to manually add relay server (and a new discovery server separately) to each node in the network.
The text was updated successfully, but these errors were encountered: