Gnutella Forums - Making Ultrapeer Better

OK, I put a lot of time into playing with Ultrapeer on my client and (no surprise here) I've figured out that it doesn't work that well. There are a variety of problems with the current implementation. The good news, I believe, is that the concept is sound, the current implementation just isn't quite there. Currently you have the following:

1) True ultrapeers (not that many of them). These people have big pipes (T1+) and are stable clients. They end up connected to other ultrapeers, to leaves, and to older Gnutella clients. When you are an ultrapeer you can recognize these people by the hundreds of connections they're running.

2) Wannabe ultrapeers (probably quite a few). These people have good connections (cable/DSL) and want to simulate their old gnutella network connections, so they force ultrapeer in their .props file. Unfortunately, a DSL connection can't sustain enough ultrapeer connections to become valuable parts of the network. Instead, they end up with a couple of ultrapeer connections at best, likely with people like themselves who haven't got good connections to the rest of the network. In addition, they get overwhelmed with older gnutella connections, and have to disable uploading to be a valuable ultrapeer.

3) Leaves. Mostly, these people just get screwed. They have no way to see if they have a good ultrapeer or a wannabe ultrapeer. They can't do anything except drop connections until they get one that reports several hosts (an ultrapeer that is connected to several other ultrapeers).

4) Other Gnutella clients (including old Limewire clients). These guys link up to ultrapeers and hammer their bandwidth. This is OK for the true ultrapeers, but it really keeps the wannabe ultrapeers from being as productive as they could/should.

There is a simple solution to the problem, and it lies in configurability. What is needed is 2 levels of ultrapeer, one for the true ultrapeers, and one for the DSL/Cable users. Who cares what you call them. Maybe:

1) Ultrapeer
2) Junior Ultrapeer
3) Leaf

Here's how it works:

1) Ultrapeers don't change, except that they're required to maintain a minimum of 5 ultrapeer connections and a minimum of 5 standard gnutella connections. Maximum number of each is configurable. If they can't maintain this, they should be demoted to Junior Ultrapeers.
3) Leaves don't change, except that they are allowed to maintain 2 ultrapeer connections, and that the first promotion is to a Junior Ultrapeer, not an Ultrapeer, then only T1+'s are promoted from Junior Ultrapeer to Ultrapeer.

2) Junior Ultrapeers should be allowed to select the number of Ultrapeer connections they maintain (minimum 3) AND the number of standard Gnutella connections they maintain (minimum 0). They should also be allowed to maintain unlimited leaf connections.

This would create a 3 tier network, possibly not as efficient as an ideal 2 tier network, but you're NEVER going to get an ideal 2 tier network, and you're just really making Limewire unusable to a lot of people. There were several times when I was forcing myself to be an ultrapeer that I couldn't successfully connect with more than one other ultrapeer. The leaves that were connecting to me were getting screwed. I finally stopped trying.

The good thing is that implementing Junior Ultrapeers would be simple, and would require no changes in the protocol. The only difference between a Junior and normal Ultrapeer is the client configuration: how many connections of each type it's trying to maintain.

Colin