A new machine ? Nice stuff - I bet it's a screamer! ;-)

>128 Inuyasha episodes are available via different p2p networks, AFAIK, - but you won't be able to find & download many of them with Gnutella.

Actually, both Kazaa and gtk_gnutella find hundreds of the files, and usually hundreds of sources for each of them. I recently grabbed the most recent IY episode using gnutella, had no problems finding it, and got over 50K/sec download average speed. Kazaa lite can hit 170K/sec if I can find the right sources, but that's rare. Most people seem to be in the 1 to 10K/sec range.

>That's why the limit is at ~150 results.
>LimeWire's lack of automatic research is intended. Finding additional sources via keyword search is very inefficient that's what the download mesh is for. Once your download has started, you will be informed about other sources for this particular file automatically.

Kazaa works in a similar fashion. Regardless of the number of sources that turn up in a search, it only passes the 20 best bets to the search process, which then opens up 200 slots for each file, to be filled in as they are discovered, or as needed when sources shut down, or become disconnected.

What the large result list can do is offer you a better choice of the initial 20 sources for a file, and it also gives the user a feel of what is out there, so that they know what to expect. If they let the search run for a 1/2hour, and only find 5 sources, they are not likely to be able to download it. If they find 100 or more, chances are good they can get the file.

I find that typically only 1 out of 10 to 20 sources is really going to give you a connection right at that moment. The others disappear, time out, put you in a queue, or whatever. Even limewire does this. Files marked with 4 stars often stall right away, even with 6 to 10 sources. Some refuse the connection, some are too busy (or say so), some place you in a queue, but never get freed up because these files are large and can take 1 to 2 hours to de-queue, even with a fast connection.

By the way, if limewire is a gnutella client, why does it only connect to limewire peers? Is this intentional to force the restrictions of limewire onto every source that can be accessed?
While gnutella says there are hundreds of copies of the files out there, I can't find them with limewire, because it restricts the TTL needed to get to those sources.

>All those additional query packets would have to be routed throughout the network not only causing huge redundancies but also overloading the ultrapeers that have to route queries.

>We had that a while ago and it sucked. Too many queries were overloading the network so instead of finding more sources you were actually finding less because queries had to be dropped before reaching very far.

THere must be a happy medium that will work better than what we have. While you say that Kazaa and gnutella can't really provide good performance, I'm getting 50K/sec downloads with gtk-gnutella, and peaks of 170K/sec on Kazaa when I can find a source that has a fat pipe.

Yet the fastest I've seen on limewire yet is about 11K/sec, and it's using the same hardware to reach the net. It's also on the fastest machine i have, a dual processor system running Solaris 8, with lots of memory and Ultra-160 SCSI disks. So it's not I/O bound. All the machines are attached to the same local net through a switch. And I only run 1 p2p app at a time.

Perhaps it's my ISP, though. They have a screwed up routing scheme that makes my data travel 6 hops to Maryland, before it reaches a boarder router to the backbone. I don't know where limewire limits, but if it's at 6 or 7 or so, I'm not even reaching the backbone before I'm out of TTLs.

If that's the case, you need to make the TTL adjustable within some small limit, so that I have a chance to reach other local nets. Adjustments from 5 to 15 would surely do the trick.

But I do wish you could have been a little more open with the number of results, and how they are handled. You don't have to pass all the results to the download, just pass alone the ones that seem like the best bets for a connection, limiting whereever you limit now. But give them more choices. Since you do open the slots up once they are queued, they may find enough active connections to get better thruput.

I guess all the virii and trojans out there have made people get firewalls (which they should have, don't get me wrong). But if the slow feeds are because they don't know how to enable forwarding, it's really sad. I've heard that over and over, and seen it in the FAQs, yet it's so simple to do with almost any firewall, hardware or software. A few click to pass the port through, and it's done.

But I guess it's either that, or there are a lot of 1200 baud modems still out there! Ick! (I'd like a T1, but wouldn't we all?)

I guess I still disagree with most of the designs out there. The problem for me is the design really has to work in the real world, where ISP's do crazy routing, people misconfigure their firewalls and proxies, and servers are setup to be overloaded to the point of being unusable. I don't know the details of what Kazaa-lite has done beyond what I've said, and I'm still reading through the source code of gtk-gnutella, and have a long way to go.

But I am able to find the files I want using their programs, and reach download speeds that don't make me wait for 12 to 24 hours for a file. To me, that's working, no matter what they are doing to their network. It may be inefficient, but it works. And they will only get better as they learn how to tune their net for better performance.

I'm hoping that LimeWire will too, and change some of their limits to work better for people like me who search for large filesets, and download files that average 200MB each. I suspec that for 4mb *.mp3 files, Limewire is plenty fast, and it's media player even works on Solaris, which is amazing.

Nice Job! for whoever wrote the player. Now if they would include a video player that handles AVI files, I'd be overjoyed.

And, oh yeah (can't resist it), the player needs a volume control. I know programming the Solaris audio mixer is difficult, and badly documented, but have them contact Mike Reilly at Sun, and he will show them how <mikeri@sun.west.com>.

Or at worst case, put in a mute button. We need a way to lower the volume when the phone rings ;-)

I do like LimeWire, it looks nice, and works pretty damn well for the curren beta. I'm impressed by the statistics pages, but do wish that 'write to disk' of the data was enabled, even it it has to be comma delimited formats, or a graphic snapshot in the local native format. But those are whole different topics, and belong in their own thread.

So if you want to follow up, how do we get LimeWire to work better in the trenches, when compared to the other apps I mentioned. While the design probably is more 'correct' than those other apps, they deliver, while I'm still waiting in LimeWire.

Regards,
--Rockkeys

ps: Please don't take this as anything but constructive criticism. I am not trying to shoot the product down, but instead find a way to improve it. I'm reporting what I see, and while my opininons on how to fix it may be in a cocked hat, the performance observations are real - details on demand.

I'm quite interested in helping if I can - I spent over 12 hours porting and building gtk-gnutella on Solaris 8 using the Sun compilers instead of gcc/g++, because I have to keep a commercial development environment here. Since that app required about 8 third-party support libs to also be ported, built and tested, from source, it took quite a while, even though I am a porting engineer. So I have a committment to this. I'm sorry to say I'm a C/C++ programmer, not Java, so I can't help in that area. But I can test, and provide feedback, which is what I'm trying to do.

Comments are welcome, and I do have some time available each week to put in on test and evaluation.

-R