Could put a 32 bit CRC in the advertised file name to avoid
downloading different files of the same length.

i.e.

supernova(GNUCRC-C0A35F7A).avi

or something like that...

Regardless, I think a CRC is important because of the existing
problem with different files of the same length.

It seems to me that every time I download an MP3 with more
than 5 or 6 sites that I get a corrupted version. I suspect it's
because of this problem. I have so far been able to get a good version by limiting LimeWire to one site.

The Gnutella Developer Forum already decided to use SHA-1 hashes. They are going to come in one of the next versions (maybe THE next version) of LimeWire. Bearshare already uses them, as far as I know.

A hash would be just as good... Thanks. Just need something
to identify identical files, that's all!

Do you plan to use these hashes when searching for new
instances of the file that become available as connections
change, instead of looking for the file name, size, etc?

'Cause if you're not, it would probably help reduce bandwith
and CPU use on peers by only sending/matching a few bytes
instead of the whole file name, size, etc, and also increase
the number of instances that could be found because even
files with wildly different names could be matched.

The HUGE (Hash/URN Gnutella Extensions) proposal covers using the SHA1 hash and how it can be used in queries and returned in query hits to identify exact matches of files.

Wouldn't using simple MD5 sums be enough instead of SHA-1 ? MD5 is widely spread and simply available to most engines (including java).

Coz I'd really like to see that this item gets dealt with, just tried to grab some stargate episodes, selected 2x04, it downloaded as 2x17, and I ended up with 2x22 as the result (I wouldn't have minded if it was 2x17 wich I missed as well, but get the picture).

Gnucleus (Daddy Gnutella as I call it) has also implemented some form of file verification, but it seems that limewire is better able to also get the files.

Furthermore there is the issue of upload capping, I think you should get rid of the connections being related to available speed option, and especially the slider for the upload speed, replace it with a textinput field where the user himself can decide how much bandwidth he really wants to assign. I got cable here from @home with rates of 4mbit/128kbit, so even selecting cable would make me unable to assign 4-5 k/sec for uploading (I need some bandwidth left for other things on my network as well)

Then there is another idea I have in mind regarding the download technique used, how about a queueing system with notifiers. Currently the client keeps requesting the file over and over again, multiply this by the amount of clients doing the same and you get a hell of a lot bandwidth usage within the gnutella network for just REQUESTING a file. Instead of that the host should NOTIFY the client attempting to download that he can now commence downloading.

Another thing is the fact how gnutella deals with shared file caching, if a client attempts a fetch, and the host does not have this file (perhaps due to dynamic IP, or deleted...), the host sends back a 404 (File not found, gnutella is HTTP based), but somehow the client on the other side does not deal with the 404 properly, so he keeps requesting the file for days until he gets the picture himself. That puts a hell of a lot traffic on the net if you sum em all.

And how about scripting capabilities like in DirectConnect ? In that way users could for example make scripts that control the behaviour of the client, and perhaps these capabilities would result in you getting some idea's for future versions based on the operation of the script and it's popularity. A nice example for a script would be that if someone wants to download, he could only do resumes from a certain point for example, that host would be a so called ResumeStation then (for ppl with low upstreams that want to enable other users to finish there downloads properly).

While we are at it, perhaps add CPU utilization control to it (does java actually support that ?)

Another pesky issue is the refreshing of the windows, after running it a while the buttons render like if they are filled with garbage data as if limewire has some leaks that need to be stuffed. And when ppl are requesting files at your point and you select a download you want to kill you sometimes need to be very quick because before you can hit the button, the file is no longer selected and the kill wont commence.

In the downloads window I'd like to see the extended info like in gnucleus and morpheus (pretty much the same to me in fact except the slight GUI changes) so you see what you already downloaded and from where. Transactionlogs would also be nice so you could run some offline statistics (perhaps using MRTG or PISG)

Seems like most of these features belong in the gnutella core itself so everyone benefits from it, other things are client related, but I think you got enough headache now after reading it, so here is your coffee and fastfood, now start coding

1) SHA-1 was chosen by the GDF, MD5 was not. SHA-1 is more secure, although a little (like 20%) slower. I don't see any point in changing that now.

2) Gnucleus has AFAIK not implemented hashes or checksums. If you could call any client "Daddy Gnutella" it would be the old Gnutella 0.56 client. Of the clients still being developed, LimeWire is the oldest ;-).

3) There's a reason why LimeWire doesn't allow you to reduce the bandwidth allocated for upstream any further. You can set it in your limewire.props file, however.

4) The implementation of queueing has been queued, see http://www.gnutellaforums.com/showth...&threadid=7199

5) Sending HTTP requests and returning 404s usually doesn't cause much traffic. One of those clients resending requests is Bearshare, but I think, they wanted to change that.

6) I don't quite get the scripting point. Could you give me any further explanation how that should work?

7) You usually can control the CPU utilization of an application at OS - level. Unix systems can allocate a priority for any process for example. I think Windows XP can do that, too. Java does not really support that, and I don't think they will in the forseeable future.

8) The GUI can become slower, if you have minimized the window for a longer time. That's because your OS moves the data of the GUI in different parts of your memory, when it is not accessed for some time. The "kill upload issue" is a fault of Javas Swing object, I think.

9) You could try interpreting the downloads.dat file, that's where the information, which parts of the file already have been written, is saved. You could also edit the source code, I think the changes you want to make would consider the IncompleteFileManager.