> This is so easy to prove that I'll let that as an exercise to Moak.

PS: Funny comment.

I thougt superpeers are designed to help also normal clients, e.g. to shield the weakest members (modem users). Thx Raphael, but I let you do your own homeworks and proof your clustering theories together with Vinnie and Limewire.

Actually I wonder about your flappy comment, Raphael. It is such easy to proof that clustering away of superpeers is not something you want to improve the network. Not all clients can act as superpeer (not enough bandwith, CPU or old OS), so not all Limewire users can act as superpeers, so you always get a mix of superpeer and normal clients. What do you wanna cluster, superpeers away from normal client? That makes no sense. As a matter of fact you will always have a mixture of superpeers and normal clients... exactly what was the idea behind superpeers, to balance and reduce load and traffic. So why or whom do you cluster? An exercise to Raphael.

That Limewire superpeer concept needs a clustering away from non Limewire clients to be reliable is one of the best rumours I heard in this propaganda circus, ridiculous. As I told before, maybe the Limewire proposal is not reliable enough and needs to be improved. All so far heared estimation are based on a Limewire _special_ superpeer concept and partly away from reality (e.g. a 500 times higher horizon without involving non-LW clients). The LW's proposal is unecesarry complex and inefficeint, there is no real need of clustering with a different concept (imagine a simple clip2 reflector but with improved eDonkey superpeer features and exchange of file databases). Perhaps in future you will find alternative concepts, without your self created clustering needs and without forcing others to do it like the commercial vendors do. In the past I was willing to work out solutions, but the high society GDF is not even intersted in listening and learning. The "Gnutella development community" was a very disapointing experience with less technical innovations the last months.

So, LW and BS are still valuable partners for you, good to know.

> I see no technical need to do a clustering of superpeers

It's common sense

> I thougt superpeers are designed to help also normal clients
> e.g. to shield the weakest members (modem users).

That is only one benefit of Ultrapeers, but you can do much more with Ultrapeer technology. Not only can you shield modem users from heavy traffic, but by clustering Ultrapeers together, you can increase the search horizon of all Ultrapeers and the clients connected to them.

This will make the end users happier, as they will more likely be able to find the file they want in their larger horizon. Isn't that important to you Moak? That the users of gnutella clients are satisfied with the results the receive?

*Note: Adam Fisk already posted a picture illustrating how Ultrapeer clustering achieves a higher horizon.

it's technical nonsens:
* not all clients can act as superpeers, you will have a mixture.
* give some statistics how high is the percentage of superpeer against nomal clients (leaves).
* you'll have a higher percentage of normal clients, this normal clients can also be any non-Limewire client

Clustering of only Limewire clients brings less or no advantage, is unfair against others.

Note: Yes, he showed a picture about our beloved superpeers (did you see the mixed topolgy of superpeers and normal clients), but the pictures shows not how clustering of Limewire clients will improve anything. My conclusion, I only waste my time fighting against Limewire propaganda. So long, Moak

> Not all clients can act as superpeer (not enough bandwith, CPU
> <snip>

If a client is incapable of acting as an Ultrapeer, it can either continue to operate as a regular peer or connect to an Ultrapeer as a Leaf client.

> so not all Limewire users can act as superpeers

This is why (in LimeWire) you can disable Ultrapeer functionality, and the user will become a shielded leaf node.

> so you get a mix of superpeer and normal clients.

Can you give me technical reasons why this is a bad thing?

> What do you wanna cluster, superpeers away from normal
> client?

I see... Ultrapeers are not completely seperating themselves from regular peers. AIUI, Ultrapeers are fully capable of connecting with regular peers.

> exactly what was the idea behind superpeers, to balance and
> reduce load and traffic.

Ultrapeers shield low bandwidth users from high amounts of traffic. When Ultrapeers are clustered together, the possible search horizon is increased.

I agree with Rapheal Manfredi (sorry if I spelled that wrong) that Moak, and users of both sides are not listening to eachother.

> * not all clients can act as superpeers, you will have a mixture.

Yes, not all clients will be unable to act as Ultrapeers. That's why a user can choose to be a shielded leaf node if they don't have the resources to act as an Ultrapeer.

> * give some statistics how high is the percentage of superpeer
> against nomal clients (leaves).

Honestly, I don't have those statistics. I don't see how those statistics would be beneficial to your arguement anyway.

> * you'll have a higher percentage of normal clients, this normal
> clients can also be any non-Limewire client

IF A CLIENT IS INCAPABLE AS ACTING AS AN ULTRAPEER, THE CLIENT CAN BECOME A SHIELDED LEAF NODE. Shielded leaf nodes connect to Ultrapeers and therefore benefit by having larger search horizons and lower bandwidth utilisation.

> Clustering of only Limewire clients brings less or no advantage,
> is unfair against others.

LimeWire clients are clustered together right now because LimeWire is the only client that supports ultrapeers! Geez, it's not like LimeWire is intentionally blocking other clients or anything.

> but the pictures shows not how clustering of Limewire clients
> will improve anything.

If you can't understand this simple concept, then there is seriously no reason to continue this discussion.

OK Adam, you have to be playing with me, your IQ is way too high to not get this.
Sleep on it, go party (must be nice to have big bucks to party with) come back and read the threads again, and think seriously about how your packets travel through non LimeWire clients, how they provide LimeWire users with files, and how that improves your user's experience so they keep using your product and keep viewing your SPAM (ads, shopping site, whatever pay for clients will offer).

Adam, a lot of developers didn't agree with XML, mostly the "small" ones you love to ignore. A lot of them threw their hands up and gave up. You just did what ever your corporate attitude wanted to do, and what was in the corporations best interest. You and Vinnie lost a lot of support by ignoring the small developers, making sure they couldn't keep up.
You unfairly use the network to make $$$ that allows you to advance far beyond developers who are doing this for free. You need your own network.
This is the problem with greed, and it needs to get off Gnutella.
We all know you and BearShare will eventually create your own network, as soon as you use all the resources on Gnutella to build a decent user base.
With the new software you won't be able to do that, we now have a way to fight against you using our resources for your corporate profit.
Now your only choice is to try to make your own private network and hope you don't go bankrupt doing it. It's pretty hard to make a profit without us, isn't it?

Moak, Gnucleus has superpeers now, we don't need LimeWire or superpeers to "scale", never really did, Morpheus jumping on proved that. The code is there, it's open source so anyone can apply it to their client. It's free, and you don't need big inve$tors and a lot of fluff staff members to get it working. Plus it doesn't "cluster" and even if it did, at least you know the clustering isn't to make a third party a buck.

RAM, thanks for all your hard work on a truly free and open source client. You have a good "political" position there.
I see the writing on the wall if we let these corporations keep sucking our resources and had to do something about it before it got worse, Vinnie was just the last straw. Gtk-gnutella has already been modified for this so you don't have to worry about it.

We could always swing the other way, everyone start making pay for clients, with adware, popups and spam so there is no other choice but to put up with the corporate garbage, and a few of us will get rich!
That is the corporate plan after all, isn't it?

Block'em all!

O BTW, Moak, you need to read up on the Ultrapeer proposal. I have a feeling you don't understand that there are 3 modes that clients can run in if they have ultrapeer support.

This is what I've taken out of the LimeWire source code, which is unlike the source of other clients, open for everyone. (I'm not a programmer, so correct me if I'm wrong).

If all LimeWire clients are clustered together, it's easier for the leaf nodes to find new Ultrapeers in case a connection breaks. LimeWire Ultrapeers do not forward all pings to their leaves, but only pings that were marked as coming from an ultrapeer. When the Ultrapeers are grouped, it's logical, that each leaf node will receive many more ultrapeer pings.

In order for LimeWire leaf nodes to stay connected, it is better if the Ultrapeers are grouped, so the leaf nodes won't have to connect to normal hosts which would result in increased traffic for the leaf nodes.

Oh btw Unregistered, the Limewire's superpeer concept is unnecesarry complicated in my eyes (so is the 3 step handshake). Anything else you want to badmouth about my technical background? *yawn*

> Superpeers and normal clients (leaves) will be mixed, so there
> is no need to cluster away clients.

Yes, there is a need. That need is to reduce bandwidth utilisation and increase the search horizon for shielded leaf nodes.

> Please don't flood or badmouth my technical knowledge

O, you don't like criticism? That's just too bad. You obviously lack technical knowledge of Ultrapeers and I have proven that.