Here I'll say you want I'm talking about about searching when I'm connected to an Ultrapeer. It says a Host count of 5, ok. I searched for 'christmas' in the 'audio' category and looked at the Input of my connection and it maxed out at 37KB/s. I received 1350 unique results and I have a screenshot here.

http://24.37.161.8/12-10-01-10.23pm.jpg

Wheres its today's date at 10:23 PM my time.



I have another one where I was connected to ~27 trillion files, 6222 hosts, and ~64TB of data.


http://24.37.161.8/11-13-01-1.43am.jpg

Nov 13, 2001 at 1:43 AM.

I think there are several things being missed here:

1. You want to drop all other connections when you find an UltraPeer ... if you're not *also* an UltraPeer. Meaning, if I'm a modem user, I only want to find my one sugar-daddy UltraPeer. But, if I'm a symmetric DSL (or T1!) user, I should probably become an UltraPeer to the modem users ... and I shouldn't drop them all if I find another UltraPeer, should I?

2. Servents should qualify for UltraPeer-ness until they've been on-line for some preset time, e.g. at least 2 hours. Otherwise, you're going to have a lot of ****ed-off modem users searching for a new UltraPeer.

3. I would like to see an additional feature where each UltraPeer informs it's "clients" of every other UltraPeer it has found. The clients (eg. modem users) would only use this info if they lost the connection to the original UltraPeer. If they have been informed of more than one UltraPeer, they would randomly pick one to reconnect to -- thus spreading the client load across the remaining UltraPeers.

- Tony in San Diego

oops! I left out a couple things on Point no. 2 above:
- I meant to say "shouldn't qualify until"
- I also wanted to point out that only stable long-term connections should become UltraPeers.

Anti-Bearshare-

I managed to replicate the problem you were having with getting disconnected from the UltraPeer after searching for something really popular. I'm about to add it to our bugs database, and we're going to work on it.

We think it's not actually directly related to supernodes -- there has always been logic in there to disconnect from a node that one node is sending a lot of messages to when that node is not sending any messages back the other way. This logic just doesn't make as much sense with UltraPeers around.

Thanks very much for your careful observations in noticing this problem.

how does a leaf behaves when connecting to an ultrapeer ? does it just send its file list over so the ultrapeer can 'pretend" to own all those files ?

Just read the post where I was describing Adam's explaination on how Ultrapeers work earlier on this thread.

Just as an addition, it actually handles these messages very intelligently, using essentially a "Bloom filter" to very efficiently communicate not all of the file names that a client has, but merely a very small representation of all of those file names that both the client and the UltraPeer understand. So, the UltraPeer never really knows what files the client has, just an efficient representation of those files.

I still think there is a miscommunication taking place:
If I understood one of the early posters (on this thread), their experience was that their copy of Limewire 1.9beta would become an UltraPeer and THEN drop all other connections (e.g. modem users) when it discovered another UltraPeer.

This was my 1st point yesterday.

Since you didn't address this, can we assume that this is not what is supposed to happen, and that I either misunderstood that previous post, or that they were reporting a bug?
- Tony

Tony-

I think there's a bit of confusion between the label on the lower left of the connections tab that reads either "UltraPeer" or "Client" in brackets and what you are actually acting as. The label at the lower left simply indicates whether or not we have measured that you are capable of becoming and UltraPeer. Whether or not you are actually acting as an UltraPeer is determined by whether or not you have connections where the protocol is listed as "leaf."

The earlier posts did not explicitly state that the user was really an UltraPeer and then disconnected all cllient connections when it found another UltraPeer. This would be very surpising, and is something we have definitely coded against. Rather, it is very possilbe, and even a frequent occurence, for a node to be UltraPeer-capable (but not actually acting as an UltraPeer), and to disconnect all other connections when it encounters another UltraPeer.

If any of the earlier posters thinks that this is not the case, please let me know. Also, if anyone else sees the behavior that Tony descibed, please let us know. From my reading of the earlier posts, however, this was not the case.

Thanks.

Something is still wrong with the current Ultrapeer implementation.

1. When you were connected to an ultrapeer and lost the connection, you are left without any connections. This happens to me every 15 minutes or so.

2. I know the horizon of an Ultrapeer is not accurately measurable for now, but in fact I get much fewer results when I am connected as Leaf.

3. Technical question: Why don't you insert additional tiers into the network. Wouldn't it be better to have level-1 ... level-N peers instead of just Ultrapeer or Leaf status. I mean the idea sould work even better with more than 2 levels.