Lets assume that every node on the network have connected to four other nodes. Then, if you rise the TTL by one, your message will reach four time more nodes. If enough clients use too high TTL values, the network will be crippling because of too high traffic.

The more UPs you're connected to, the more queries and query replies you send to the network. If all users would be connected to least 50 UPs, the network would be crippling again because of too high traffic. It simply doesn't make sense to let people use too many UPs at once.

Imagine you have 1000 clients connected to 100 ultrapeers each, let's further assume each ultrapeer is capable of holding 100 connections. - That means the overall ratio of ultrapeers to leaf nodes is 1:1, in which case you could as well stick to the classic gnutella scheme without any ultrapeers.

Yikes, thought you knew that one :o

The higher the TTL, the more clients it will reach, the more traffic it will generate, the more people will be complaning - usually in that order :p

Nevertheless, you can set the TTL to 255, but it won't get passed most modern Gnutella clients at around hop 6 or 7. The early version of NullSoft's Gnutella (0.54 i believe) had a bug in it, which it didn't lower the TTL. Messages just kept going on, causing the network to get really messed up.

Yes
 

Tshdos, Kaapeli, and Taliban pretty much summed it up for me.

Like I said though, it's not the default setting that are hurting the network... It's the possiblilities...

Shareaza’s configurability is based on my philosophy that giving users as much control as possible is beneficial to everyone, and definitely the way to go on a “free” network like Gnutella.

The danger I see in “closed” systems such as FastTrack is that the parameters are determined by the organisation supporting it, and serve their goals rather than yours. For example, its not unusual for P2P clients to disrespect the user’s wishes in terms of the maximum number of uploads they are willing to serve, just to reduce the chances other users will get a busy signal. Making downloads more reliable is definitely a good cause, but that’s not the way to do it. Download queuing, source meshes, etc – those are much better solutions, and that’s the way the Gnutella network is innovating.

Yes, a malicious or perhaps selfish user could change Shareaza’s settings in a non-productive way if they so desire. But the great thing about Gnutella is that every node is autonomous, and performs an independent policing role. If someone sets Shareaza’s default TTL too high, the vast majority of good servents (including Shareaza) will drop it on the next hop. If you set a download retry delay too short, the host will disregard your requests. But by allowing users to change these types of settings, Shareaza lets everyone optimise their own performance – now, and in the future as the Gnutella network evolves. You’re not stuck with some settings that were forced on you “for your own good”.

I think on a free network like Gnutella it’s important to empower the people who are the network. Sure, some people might try to abuse this power, but that’s why servents take on a policing role too.

I haven't tried your client, but I use gtk-gnutella, and its authors have the exact same philosophy as you have.

All the things you described as being configurable in your client, I can configure in gtk-gnutella.

I can even define the maximum size of messages to accept and relay, but this is not a GUI settings, and must be done manually in the config file. I use it to limit queries to 128 bytes, in effect dropping all those verbose XML queries from LW.

Commenting!

-- Peer

You mean you are blocking the xml query replies, - LimeWire's xml queries usually don't reach that size.

I'm glad you feel that way, so you will be GPLing Shareazas source code soon I expect?
With open source your client will live forever and will get the benefit of a whole community of developers that will contribute more features and source code to it.
Users will be further empowered because they can easily change things they want to without waiting months for the change. Security will be assured when new anon protocols arrive through peer review of your code.
Another GPL client on Gnutella would be wonderful!
Yes, yes, yes!

He was talking about the protocol being open. FastTrack is a closed protocol (proprietary), owned by one company, licensed to other companies (like Kazaa).

Re: Re: EQHD
 

Thanks abaris :)