Protocol Improvement - Multitask Upload Slots!
 

*** NOTE: this proposal is also available @ http://users.ev1.net/~eweb/ ***

Chunk-Based Downloads - A Very Good Thing!

One of the biggest problems I -- and from what I can tell by my friends' experience, most users -- have with gnutella is that when you go to download a file the remote servent is busy. I have a possible solution to this problem outlined here:

1. Make sure that query responses contain not only the file-size, but also checksums calculated using two different algorithms. This should help servents recognize the same file with different names more readily, thus allowing servents to download file chunks from multiple servents simultaneously.

2. Provide a chunk-based upload slot - in other words, on this download slot, allow no more than, say, 2KB to be uploaded before disconnecting the client (note - this number is totally arbitrary!)

3. Require that servents that get disconnected after they receive their chunk not re-connect for random some time period greater than 0.

4. Require that servents share chunks they have already downloaded, even if they can't provide the whole file.
Allow the servent to specify the file-size and checksums with a query. If this information is required, the servent is required to send back only files matching those criteria.

The combination of the servent being able to download separate 2KB chunks from different servers and the fact that each servent would share chunks already received would create a situation where:

1. Rare but desired files flow through the gnet quickly, because servents would not have to wait for the second servent to get the entire file before being able to download from 2 servents instead of 1.

2. High-bandwidth servents would be able to support more users. Today, when a user tries to download a file from me, I might allow 64KB/s and 2 download slots. Well, if those two are taken by somebody who can only download @ 3KB/s total, then everybody else with big pipes is screwed and has to wait for slow-poke boy to finish downloading the huge file at slow speed. On the other hand, if slow-poke has to disconnect after 2KB, then the fast guys can jump in and each grab a few chunks by the time the slow-poke re-connects.

3. Busy signals do not last as long, because servents connect, grab a few bytes, and disconnect, freeing up the slot for another user. The downside, of course, is that when the servent attempts to reconnect, the slot may be in use by another user. Not a big problem, because the slot will be freed up momentarily when the other user disconnects.

-- Early Ehlinger