-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Distributed Hash Table for discovery instead of central server #5
Comments
Yep. However, there are still one or more central servers ("root nodes") in that setup. I agree though; we could probably piggyback on the BitTorrent DHT:s. |
Have a look at ToxProject's DHT implementation as well - they seem to have figured out the private connection thing... |
Changing this to "won't fix" because I'm not convinced of the advantages. |
The lack of reliance on a centralised server is surely a massive advantage - what if the server goes down? |
@naught101 You still need a central server, or root node, how else does a client just starting up join the DHT? Edit: in any case, while this is an obvious advantage for something like BitTorrent where you have hundreds or thousands of nodes, it's not clear to me that that applies here. A given cluster is composed of a handful of nodes. Dependence on a third party lookup server can be avoided by either giving some node a static address that can be configured on the others, or setting up a discovery server of your own somewhere trusted. If it was a real worry, syncthing could trivially be extended to handle multiple discovery servers returned by DNS. |
I think any node should be able to use multiple discovery servers and act as discovery server if configured to do so, and discovery servers should know about each other, this way there will be multiple discovery servers, helping speed up the network and keeping it working if one of them goes down. I don't think it's important at the moment though |
@calmh you're right, it is necessary (I'm not very familiar with the system, I'm probably speaking out of turn, really), but my understanding is that with DHT the server would be under much less stress, as it is basically just acting as a starting point for the client to bootstrap themselves into the network, and after that, it doesn't need any contact with the client. I guess the server stores less info, which is potentially a good thing for privacy. As fazo96 says, it's probably something that could be implemented later. |
@naught101 Yep, for sure the load is distributed. Currently, the load is negligible but this may be a relevant point in the future. Privacy wise I think the situation is about the same - the exposed info should be considered public, since anyone can query both the central server and the hypothetical DHT. Anyway, I'm not discounting this feature, just pushing it until it becomes obviously necessary. |
Regarding this (old) issue, I think @calmh has a solid point about "until it's needed." I too would like increased decentralization, but it may well be premature, and the discovery server and relay pool server are themselves open source, which helps prevent "lock-in." It also turns out there are beautifully presented usage statistics at https://data.syncthing.net/. Question: do the data start then, or is that just the viewable window? (I think it's all the data based on my reading of the code, but...) (0.10.0 release notes don't seem to mention adding the usage tracker.) Also - I think it would be useful to see some reporting of the load on the various servers; then if us geeks see the load going up too much over time, we can get cracking on implementing DHT! |
Quick ping to mention that the central server is down at the moment, would a DHT have prevented downtime? |
Discovery is not down. We have 3 redundandt servers in 3 continents. |
My mistake, sorry. |
I'm not sure how to implement it, or if it even makes sense, but I'm under the impression that this is what BitTorrent Sync does.
The text was updated successfully, but these errors were encountered: