Some of you have mentioned alternatives to LimeWire, such as eDonkey2000 and FastTrak.

Which is best? Where can I find these clients to try out.


I still use LimeWire 1.7c. I am NOT a fan of Ads or Spyware. I like Limewire and would be happy to pay an reasonable amount (PayPal) for an ad-less version.

But I think I need to start checking alternatives to LimeWire.

I just surfed to http://www.taxster.f2s.com. This is a real good site that compares most of the FileSharing programs.

One of his favorites for Applications and Games is Direct Connect, with eDonkey2000 close behind.

Anybody ever try Direct Connect ?

Maybe you picked the wrong forum to elaborate the blessings of DirectConnect.

This is the best site for other programs but this is the Limewire forum after all.

http://www.zeropaid.com/

the link that you have on your website only allows me to download the 1.8b version of limewire and not the limewire 1.9 beta that it is supposed to link to.

Hi,

is the "Sparky"-like Pong caching implemented into this beta version?

Hi Moak. LW 1.9 does not use pong-caching, mainly because we have enough new things in it to keep us busy. :-) Ultrapeers do shield leaf nodes from all pongs except new ultrapeer pongs, unless the leaf explicitly pings the ultrapeer.

Just curious, you said that there is already enough new code for 2.0? What other features will be added?

When will HUGE be implemented?

-gnutellafan

You have pointed out that files are only bundled for a swarm download if they are in the same download group and have the same size, and that they are bundled in download groups only if they have exactly the same filename. however, it turns out that this way of swarming fails way too often and is less more than a disappointment - i'm sorry to tell you, but it's the truth.

I think it is very unlikely to find a lot of files that have exactly the same filename. limewire should rather group downloads into download lists by size only. after all, the files were returned as replies to the same query string, and if the file size is exactly the same, it is very likely that the files are too.

If that is not enough safety you can still implement a rollback interval in order to check if the files are the same (gnucleus does so, i think it uses a 4 kb rollback, but i am not sure).

i think that would by far increase the number of mirrors and the effectiveness of swarming. i find it *very* annoying that i get results of files that have exactly the same size and only differ slightly in the title (for example, some are called band-album-title and others are called band -- title). although it is obvious that these files are equal, limewire does not recognize them as peers.

And of course there should be an option for researching files for an active download, adding the results to the mirror list if they equal the file. this does not mean any kind of aoto-requerying. but when i resume a file that is already 80%, but the hosts in the mirror list are no longer running, i want to search again for sources of that very file instead of restarting at zero.

i think gnucleus has the most stable implementation o f all this (although it does not swarm, it only downloads from one mirror in the list at one time). you should try to get your mirror lists as accurate as those of gnucleus are, this *is* possible and swarming would then be no problem at all. this could all be done easily even without HUGE.

--- awaiting comments

HUGE is clearly the best way to implement this, and this is where the majority of improvements in this area will come from, along with HTTP 1.1.

The file matching does not require exact names -- it uses an approximate matcher to identify files with similar names. I do agree with your point that files of the exact same length for a given query are almost definitely the same file, in which case you could bypass the approximate matching by name all together. We may implement this in our final release.

I disagree that this will signifantly increase the number of swarmable files, however, as it is quite rare that identical files have names that are so different that the approximate matcher does not group them together.

We will likely implement the researching for more hosts for a given download feature at some point.

The best easiest and most robust way of getting more hosts is to build a download mesh -- this is really the ideal, and it is not that hard. We will be doing this fairly soon.

Thanks for the suggestions -- the file length one in particular we may just go ahead and implement.