Where are GTK-G's settings stored?

Lord of the Rings · #1 (**permalink**) February 6th, 2012

Can anybody of the GTK-Gnutella crew tell me where the program's settings are stored on each platform (Linux, Windows & Mac.)

I use Mac. I have checked user preferences, user application support, documents, caches, even the program's resources and after changing a setting within the program, I was unable to find any change to any mentioned folder or any file or folder shooting to the top of those mentioned folders when set to Date Modified view. Or are GTK's settings hidden files? (Even setting all files to visible did not seem to show any of gtk's settings.)

NVM found it. Tricky. Hidden folder.

Wow over 5,000 hosts is a lot for GTK-G. to check through. I presume GTK-G. surveys the network and updates the list like other clients do by adding and removing hosts? Or is this a preset list with each release of GTK-G.?
Does GTK-G. remove hosts after a certain number of failures of finding?

ram · #2 (**permalink**) February 8th, 2012

Quote:

Originally Posted by Lord of the Rings

Wow over 5,000 hosts is a lot for GTK-G. to check through. I presume GTK-G. surveys the network and updates the list like other clients do by adding and removing hosts? Or is this a preset list with each release of GTK-G.?
Does GTK-G. remove hosts after a certain number of failures of finding?

There is no pre-set list of hosts distributed.

I assume the 5,000 hosts you're referring to are the cached hosts in your ~/.gtk-gnutella/ultras or other similar cache? In that case, let me reassure you: these are not systematically checked, they're just a pool for reconnecting to the network without having to contact a UDP Host Cache. That list is constantly refreshed.

But gtk-gnutella is not solely relying on this list of collected Gnutella hosts to bootstrap its connection: it also uses its saved DHT routing table, relying on the fact that all the peers listed there are necessarily modern servents (basically only LimeWires and gtk-gnutella hosts) which are, by definition, supporting UDP. Therefore, it uses them as a source of extra UHCs to probe for faster connecting... Since this probing requires only a single UDP Ping, this is extremely efficient, and the saved DHT nodes are usually stable enough (since they made it to the routing table).

The aim is to never rely on the central UHCs once a first connection to the network has been achieved. But in any case, random contacting of the cached hosts stops as soon as we get the desired amount of Gnutella connections.