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