I had a dream in which I searched the Gnutella Network for a file with LimeWire and I got a number of Groups as results. Having selected a group containing lots of files and a good number of four star downloads, the tab changed and I was on the Phex download window. All the elements of the Smart Download Group, as they all have the same file size, were automatically added as Download Candidates. No I woke up and I am able to see the great progress to both LimeWire and Phex that was revealed in my dream:

LimeWire's Smart Downloads behave poorly, due to the fact that LimeWire is unable to search for *new* sources to resume a download that has once been started. Most often downloads fail because the uploading user has disconnected from the Gnutella Network. As most users are not permanently connected to the Internet and as most ISPs assign dynamical IPs, the user's IP address is likely to have changed when he rejoins the Gnutella Network and therefore a partial download will almost never be resumed when trying to connect to old download sources only.
Phex offers a much better feature: It handles a dynamic 'Download Candidate' List for each download. When the list elements are out of date, the Gnutella Net is automatically researched for the file using the original search term. Each result that exactly matches the filesize is added to the list of Download Candidates. The search term can even be edited by users and Candidates can manually be added to and removed from the list. Phex also searches for new Candidates silently in the background. This way one is able to get new usable IPs instead of unusable out-of-date IPs.

However, when you start a search you generally get lots of results that have slightly different file sizes. Although three kilobytes more or less are completely meaningless when audio or video quality is concerned, it makes it impossible for these files to interact as Download Candidates for each other. The problem is that Phex offers no way to determine how many Candidates are likely to be found for each file that is returned in the search results.
The Solution to this problem are LimeWire Smart Download groups that have been reconfigured to group files by size rather than by name (grouping by filename is ineffective for Smart Downloading anyway). When you get two groups of which one contains 20 elements and one contains 5 elements, when you download both groups (using the Phex Candidate way), stop them after you have the half of both files, and research for new Candidates even months later, you are likely to find about 20 new Candidates for the first file and about 5 new Candidates for the second file again, because the average number of available mirrors is likely to remain constant regardless of your unique network horizon. So you have a way to determine the number of available Candidates before you start a download.

Combining these two features with the LimeWire four star rating system would solve all downloading and resuming problems the Gnutella Network is currently suffering from. You would know the quality of a download before you start it, you would know how many mirrors there are on the Network (and this number is likely to remain constant even over longer periods of time), and you would be able to search for new IPs when the old ones are out of date (which is a matter of days and even hours). The only remaining problem would be to improve the download speed. And even this could be done quite easily:
Handling a dynamic Download Candidate List for each file is not only a great way to resume files. It would also make the implementation of 'segmented downloading' very easy. Imagine you have an ISDN internet connection that allows you to download 8 kilobytes per second. Now imagine you have two Download Candidates: one offers a rate of two kilobytes per second and the other one offers a rate of three kilobytes per second. Downloading the first half of the file from the first source and the second half from the second source at the same time would give you a combined speed of five kilobytes per second and thus would almost double your download speed. This mechanism is used in download managers like GetRight and is likely to grant you your full internet connection speed for each download if you have enough available Download Candidates in your List.

As we all dream of better Gnutella Network performance I hope that these technics will be combined in a future client, Phex or LimeWire or any other one, of course preferrably written in Pure Java to also grant the Gnutella Community true Platform Independance. It would make life so much easier for everybody.

really nice dream you had there i am waiting for someone to program such a client - preferably open-source and platform-independent. unfortunately i am not enough a coder to contribute to this in the meaning of writing code but i am sure that's where we are going to. just that it might be that we (should) switch to an anonymous network as gnutella is traceable and will get into problems over time. there are several projects underway ... so let's have several cups of tea and see where we land

Segmented downloading is an excellent idea! I also think that there should be a way for a gnutella servant to keep a list of file requests. This way uploads can be finished first-in-first-out instead of a mad frenzy of file requests. When a file is done uploading the servant checks the queue for the next request. If that person is available then start the upload, else next request. I think this will make gnutella more predictable.

Segmented downloads will not function!!
You know it! The download slots are limited, so the Gnutella network will be more slowly if you introduce segmented downloading!! It came to me in a dream and I forgot it in another dream (Futurama) CU Abaris

Du bist ein Schuft, Jens. Du hast mir meinen Traum gestohlen.