-
Notifications
You must be signed in to change notification settings - Fork 11
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
"Discovering" of GDS-Instances #24
Comments
Some kind of tracker system similar to BitTorrent would be great. Discoverability does require a central register machine, but like BitTorrent, the actual server being used can be pluggable, you can use multiple servers, etc. I don't know a lot about BitTorrent, but perhaps the entire discovery part of BitTorrent can be completely reused? |
But Bittorrent is closed source, isn't it? |
The bittorrent protocol is open: http://www.bittorrent.org/beps/bep_0003.html I'm not sure about the license of the protocol, though. |
It's very important to decentralize this discovery process as well. |
@vis7mac Yes, that was my idea, maybe I didn't point it out clearly. |
@augustl The Protocol document is public domain... |
@vis7mac @lukasepple great idea! But whats with obsolete URL's. Do obsolete URL's disappear automatically from the lists? Do GDS has to care about this issue, anyway? ...don't know how this works in case of DNS. |
@DerZyklop DNS has a TTL (time to live) time for each record, for example 3600 for "an hour" or 60 for "a minute". This might be an issue for GDS, because it would take quite a lot network traffic and computing power, although we could use it in an amazing way: uptime monitoring. A possible problem: The alternative email address would get a lot of mails for each downtime if every server sent a mail. So all GDSs have to communicate to
A requirement for this is that every single GDS with a "discovery and uptime" server knows of all the other ones. |
@vis7mac Wow, that sounds like an awesome idea! "Discovery and Uptime" would be a really nice app if we manage to take care of the mail spam problem. But that should be possible ... |
I guess the first server noticing this would select a random new one standing at a different position. But this does still not resolve the spam problem. |
Oh, hey: I just got an amazing idea how to solve this:
If another GDS with "discovery and uptime" now finds out that Rolf is down, it sends that information to another "discovery and uptime" server. This would generate a lot of traffic if there are many GDSs (the mentoring servers would get a lot of requests by kind of every "discovery and uptime" server). I will write more about this idea in the concept markdown later on. |
So I actually wrote something structured about it. And it became a novel. :P |
Please stop closing issues!! We need this discussions. This is still a concept and even if ideas sound great this is about writing them down first then thinking about implementations then building them and then reevaluate if they work together and if they help the general concept. This is not about playing: "ok I think I solved this" and closing stuff within a couple hours. |
Aye! You're right. |
Yep, that's totally right. |
Absolutely!! Those discussions should always lead to additions or edits of the concept. |
I'm doing that in the moment for the current issues by linking to them in the Markdown. |
That's perfect!! |
Additional to @vis7mac "3 mentoring servers"-system – an idea to avoid multiple notifications to the Admin: Isn't it possible that the 3 "mentoring" servers of Rolf make oneself known to each other? So if one of them gets a order to send a notification to the Rolf-Admin, it might also ask the others, if someone has already notified the Rolf-Admin. And afterwards, the "mentoring" server might inform the others that a Notification was send. |
That's a pretty nice idea! I will add that to the Markdown ASAP. |
For some Apps it's useful to know as many GDs Instances as possible, for example for a decentraliced search etc.
Therefore we may add something like a "Known GDS-Instances"-API which is managed and extended by each GDS. When it gets to know a new isntance it also extends its own list of GDS-Instances using the list of the new GDS-Instace.
The text was updated successfully, but these errors were encountered: