TTL Issues

With the sudden influx of members to gnutella that was bound to happen, this is the time to take action. We have all seen the gnutellanet slow to a crawl. I encourage programmers of clients to make the default TTL values 5. I encourage current users to set their Originating and Forwarding TTL values to 4 or 5. This will reduce network traffic severalfold, and especially with more users, will make little or no difference in the number of hosts received. Plus, it will improve the efficiency of the network, speed search results, etc. and avoid those slow sundays. Please encourage people to do this. PLEASE! feel free to reply to <arodland@ptdprolog.net>

[Picker]

my thoughts on this are to make it impossible to set TTL higher then 5 (?) through a setting via the program. however setting higher via manual edits should still be allowed.

I hadn't thought of that, but it would be a good idea to make it extremely hard to set a high TTL (I think 5 would make a fine limiting value), although I'm sure that people would write clients that attempt to set it higher, so the "Max TTL" value should be set to 5 as well, so that the "good" clients can stop the "bad" clients as soon as possible, before the network is flooded. Of course, some developers might object to the limitation of freedom, but the performance of the net for everyone is (I think) more important than the freedom of any particular greedy user.

arodland, isn't the converse true? The more users of gnutella there are, the more non-sharing users there are in your gnutellanet horizon? This means that you need a larger horizon and bigger TTL.

Ignoring the other issues that make parts of my statement above "false", when there are more users, the existing uploaders are swamped with requests. So, you need a bigger list of search results in order to find the few uploaders that still have bandwidth for you to download from.

The default of gnutellanet clients is to NOT share files so most people find that to be their most convenient setting and leave it that way. Perhaps there can be some other ways to encourage the sharing setting to be enabled somehow.

First, if you had read a little more carefully, a combination of
1) less redundant replies and
2) more clients means more routes and ___therefore more hosts within a certain ___radius,

means little or no difference in the number of hosts received if the TTL is lowered.

Second, an algoritm that searches the users' directories(folders if you prefer) for certain file types (perhaps .mp3, you know that plenty of people use gnutella for it), and adding them automatically would be pretty invasive, but if that is what is needed, then perhaps on install, it could be an option to "Scan your computer for files to share". Even this is a little borderline, but so has the whole discussion ;/

This is sort of a double edged sword thing, so let me put my few cents in.
matter.
They should just allow the TTL as it is, and let some keep it high, and some put it low, in my opinion, because 5 hops is nothing. I live in CA, and most places anywhere past arizona are more than 5 routers away from me. Sure, I probably don't need files from 2000 miles away, but what if it's the only way I can get that song I *really* want? If you notice on the list of connections, most people sharing lots of files set their TTL high anyway.
The amount of reflected packets and packets that loop forever, etc. can't be worth the expense of finding faraway files, especially since the amount of subnets the packets can get lost in is so many that it can't really hurt the "network" that much, can it? (Feel free to share your insights if I'm wrong)

Oh, I just thought of this.
Ok, so the problem is lots of Gnutella users slowing down the "network".
Well, I don't think that's from the TTL at all. I don't know how Gnutella/Gnotella queries the master server, or how the server finds the IP of any clients, but if it uses any sort of broadcasting (like NetBios) or it has to update the LMHOSTS list frequently (with WINS) or even if they found some way to dynamically do DNS and it has to update the HOSTS file a lot, all of those cause a lot more slowdown than packets running free with high TTL.
A server that has to constantly find where every client is, assign it an IP address, assign that IP to a MAC address, and store that for however long is going to be severely impacted by many people trying to connect to it at the same time, especially if the address resolutions are kept for very long or are dynamically reassigned.
When the source code comes out we'll see.

Go read the protocol specs on gnutella.wego.com and perhaps you might get more of a clue as to what is really going on, instead of placing both feet in your mouth at once.

Ok, well, I read it. Huh.
Forget what I said before, everyone makes mistakes. But you can flame me more, I deserve it.
So my suggestion now is to find some other way to identify all the clients without having to PING so many damned times.
I'm trying to think of a way to do that without having a list on every client, because that would destroy anonymity.
I still don't think the TTL is really the problem though, because if each client only pings a few other clients, then the packets that fly around loose are still separated on many different subnets.
Anyway, my bad, should read more first.