Skip to content
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

Closed
ptman opened this issue Jan 2, 2014 · 12 comments
Closed

Distributed Hash Table for discovery instead of central server #5

ptman opened this issue Jan 2, 2014 · 12 comments
Labels
frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion

Comments

@ptman
Copy link

ptman commented Jan 2, 2014

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.

@calmh
Copy link
Member

calmh commented Jan 4, 2014

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.

@naught101
Copy link

Have a look at ToxProject's DHT implementation as well - they seem to have figured out the private connection thing...

@calmh calmh added wontfix and removed far-future labels Apr 22, 2014
@calmh
Copy link
Member

calmh commented Apr 22, 2014

Changing this to "won't fix" because I'm not convinced of the advantages.

@calmh calmh closed this as completed Apr 22, 2014
@naught101
Copy link

The lack of reliance on a centralised server is surely a massive advantage - what if the server goes down?

@calmh
Copy link
Member

calmh commented Apr 24, 2014

@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.

@fazo96
Copy link

fazo96 commented Apr 27, 2014

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

@naught101
Copy link

@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.

@calmh
Copy link
Member

calmh commented Apr 28, 2014

@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.

@GeoMaciolek
Copy link

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!

@PrototypeNM1
Copy link
Contributor

Quick ping to mention that the central server is down at the moment, would a DHT have prevented downtime?

@AudriusButkevicius
Copy link
Member

Discovery is not down. We have 3 redundandt servers in 3 continents.

@PrototypeNM1
Copy link
Contributor

My mistake, sorry.

@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Jun 17, 2017
@syncthing syncthing locked and limited conversation to collaborators Jun 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion
Projects
None yet
Development

No branches or pull requests

8 participants