I have run many different p2p packages in both Windows and UNIX, and I still use only Kazaa-Lite (on windows) or gtk_gnutella (on UNIX), because these are the only programs that seem to handle searching properly.

I want to be able to find 200 to 500 sources for a program, knowing that only 5 or 10 of these sources might actually be able to provide a good download thruput. My systems are capable of download speeds of 200K/sec or more, and only these two programs have been able to provide the sources that can support those speeds.

Finding 20 or 30 files on a search, of which only 2 or 3 have multiple sources is rediculous, since many of the common sources on p2p networks are misconfigured, or have routing problems that result in thruputs of a couple of hundred characters per second.

If I wanted to download an Anime video file, which might be 200MB in size, at those speeds it would take almost 12 days to obtain one file. And this is what I typically see out there.

We need a search feature that can repeatedly search again and again, until the user either decides to stop, or it reaches some maximum (but a very large maximum). The large maximum is needed because some file groupings really do have hundreds of files associated with them. For example, the Anime video series Inu Yasha has 125 episodes, and there are multiple versions, both dubbed and undubbed out there. The only search term you can count on is the title, because of the way users list their shared files.

Limiting a search return to 20 or even 50 files would prevent the user from ever finding the complete set of files.

Note that on both Kazaa and gtk-Gnutella, it's often needed to let the search run for more than an hour to turn up some of the episodes. While this may reflect a bad protocol design, it's the real world effect of how these programs and users work in concert. And while an immediate search will sometimes turn up 5 to 15 sources for the most popular files, letting the search run for a long time often results in 200 or more sources for the files.

Yet even with 200 sources, I often am unable to find a machine that has an open download slot, has the file shared, and has a reasonable thruput. I usually sit and watch the download flip through source after source, only to see them time out, or be rejected. Once in a rare while, I see someone allow me to queue on their machine, but with these size files, waiting for an unused slot can take hours.

So with 100 sources or more, I see an aggregate download average speed of 10 to 20K per second. And I find that acceptable, although it's nowhere near the speed capabilities of the machine. Once in a very rare while, I find a fast source that I can connect to, and see a download reach 200K per second. That's the way it should work, but there is so much wrong with the common protocols, that it seems that it's really the rare exception to the rule.

Further, sources come and go with time, and the approach used to build the aggregate needs to select the fastest available sources which actually will grant a connection at that moment when a slot opens in the aggregate. Kazaa-Lite seems to handle this fairly well, considering the number of sources that say they have the file, but actually refuse the connection for one reason or another.

While I do not often agree with the approach used to build a fast aggragate download queue, and to maintain the highest thruput possible, it's very clear that most of today's programs are unable to reach this goal. Perhaps it's because of legacy code, which people do not want to break. Or for the sake of compatibility, they are unable to make the best use of the available bandwidth.

But it's clear we have a long way to go in reaching a low frustration level in p2p networking.

LimeWire, in specific the beta currently available, has no ability to retry a search automatically, and only seems to allow one additional re-search before clearing the search and starting over.
Yet after leaving the program running for a day, and then searching, I was unable to find more than 27 files in my catagory.
In the same period of time, gtk-gnutella found 2789 files, with literally thousands of sources between them. And Kazaa-lite found almost 200 sources for each of the main files of interest, and in some cases nearer to 300 sources!

Limewire Beta feels like I am only reaching a few machines in mostly a local area. I'm sure that's not the case, and that some sources could easily be on the other side of the world. But that is what it 'feels' like, because of the way it responds.

Unless such a feature would completely break the network protocol, or interfere with the network in some way, it really must have a auto-retry search capability, to compete with the other programs out there.

I suppose if I was looking for more common files, it might not be such a big problem. But these other programs have clearly solved the problem, and LimeWire must also, or be unable to be useful to the general user who is looking for more than just the popular mp3 files of the week.

Please make sure the beta team sees this request.
Thanks,
Rockkeys