i agree with Raphael that noone seems to listen to anyone else. there are so many misunderstandings in this thread that you will hardly ever come to a conclusion. the best thing a moderator could do was to close this thread. but mr. unregistered would take that as just another proove of how corporate greed ignores freedom of speech. so perhaps some of these misunderstandings can be made clear.

First of, all there ARE misunderstandings on the Ultrapeer concept (from now on, i will use the term "old client" for a client that does not implement the ultrapeer/QRP proposal), which is in part due to LimeWire's terminology. I will try to explain some basics, i hope that Adam will correct me if i am wrong about something.

1) from the ultrapeer point of view, an "old client" is an ultrapeer node without leaves. it is NOT a leaf node without an ultrapeer. Indeed, an old client can never ever become a leaf node because leaf nodes have to use the QRP (Query Routing Proposal). QRP reduces bandwidth usage to ~10%. that means, if leaf nodes use QRP, ultrapeers can handle 10 times as many leaves, which indeed scales the visible horizon by a factor of 10. it would be ineffective as hell if "old clients" would be accepted as leaf connections. at the moment, Lime is the only servent that implements Ultrapeer/QRP proposal, that means that only Limes can become leaf nodes and only Limes can become Ultrapeers.

2) An Ultrapeer, however, can maintain as much connections to old clients as it wants, because an old client is, once again, nothing but an ultrapeer without leaves. about statistics, in a perfectly structured network, the whole network would consist of ultrapeers only, and every ultrapeer would shield up to 500 leaves, thereby multiplying the visible horizon by 500 (yes, that means that the users get 500 times more search results!). but gnutella will never be perfectly structured, as there are a lot of old 0.4/0.6 clients out there and as these clients cannot become leaves, they reduce the effect of ultrapeer scaling just as an ultrapeer would if it didn't accept leaves.

3) the critical issue about ultrapeer clustering is therefore the following: How many ultrapeer connections should go to other ultrapeers, and how many ultrapeer connections should go to old clients? in other words, what should be the ratio of Ultrapeer vs. Old connections? Adam has pointed out that a Lime Ultrapeer will maintain at least two connections to old clients no matter what. An Ultrapeer generally has about 6 Ultrapeer connections and, at the moment, 80 Leave connections. so at least one third of a Lime Ultrapeer's connections go to older clients. And at this point, i do agree with moak: One Third seems to be a bit low for that ratio. IMHO the ratio should be One Half. A clustering ratio of One Half would give an old client and a new client exactly the same possibility of connecting to an ultrapeer.

4) about how clustering might be selfish and how clustering might be beneficial: a clustering ratio of one half treats newer and older clients equally and seems to be a fair strategy to me.
a lower ratio would mean that newer clients can profit much more from ultrapeers than older clients can, as they are preferred over the others. for the end user, this means that Lime users get more search results than other users (others would also if they implemented Ultrapeers).
however, older clients would never get less results than they would without ultrapeers, it is just that a ratio below 0.5 helps the users of newer clients more than it helps the users of older clients. this is what Lime is doing, as their ratio is 0.33. Our marxist friend, Mr. Unregistered, calls that selfish, greedy and unethical. I disagree. Limewire put a lot of work (marxist key word) into developing and implementing ultrapeers, and now their users are the first to profit from it. as soon as other clients implement it, they are going to profit just as much as Lime does. This sounds fair to me. Furthermore, older client's searches ARE improved by ultrapeers, as the ratio is far from zero. it is just that newer one's searches are improved two times as much (0.66 vs. 0.33).

5) Last, i'd like to mention that Gnucleus does not have an ultrapeer system at the moment. Swabby announced that Gnucleus 1.7 will have one, but 1.7 has not been released, not even a beta version. So Lime is actually the only ultrapeer-supporting client for the time being.

Adam, I count on you correcting me if i got anything wrong, it has been some time since i read the ultrapeer and qrp proposals. note also that all this applies to LimeWire only and in no way to the clustering of Bearshare, which is a totally different story.