Daniel Grace wrote: > In watching the downloads progress [the screen where you can see the > chunks download -- not sure what that would be called]
It's the [detailed download] progress bar.
> the download doesn't seem very random at all.
Well, we can only download ranges that are available. If it tends be
heavily contiguous then
- I'm missing something (i.e., it's intended for reasons I don't know) OR
- it's a bug in Gtk-Gnutella OR
- other clients do not randomize chunks (maybe to enable streaming)
I also suspect that the download mesh isn't utilized and updated as
it should - in all Gnutella clients, not just Gtk-Gnutella. If properly
implemented it should be almost as good as the Bittorrent approach.
There a definitely some issues in Gtk-Gnutella that harm its
download performance:
1. Missing support for Tigertree hashes (TTH)
2. Bad sources (uploading damaged data, intented or not) are not removed
due to (1).
3. Gtk-Gnutella accepts arbitrary sized chunks as long as it's free
I think arbitrary small chunks (unless the gap is really that small)
shouldn't be accepted as it causes a lot overhead, wasted time and
increases the amount of chunks to handle[1] and tiny gaps that have to
be resumed later. If there are a lot of tiny gaps scattered over a
file there'll be a massive HTTP protocol overhead to fill them.
[1] This might even allow a minor(?) DoS. It would probably be
better to use a tree instead of a list to handle the chunks but
memory is limited as well, of course, so there must be an upper
limit of chunks. That probably means, as soon as we approach the
limit we must stop creating new chunks and only fill existing
gaps.
If you have some time to work on Gnutella, I'd rather encourage
you to try getting TTH support to fly.
> Now, the compromise. Things would be much better for me, without
> actually hurting the download pool if the following two rules were
> followed:
> 1) New rules only kick in when there is a gap followed by a "large"
> (yet to be defined) chunk that is finished
> 2) Everything but the fastest chunk historically ignores the chunks,
> the fastest source will go back to get the chunk
> That way the slower sources will still grab random chunks and preserve
> the randomness of the pool. Would that be acceptable?
At the moment, I suppose doing it vice-versa would be more effective
i.e., use the fast sources for random chunks. Another thing that
would speed thing up is pipelining.
--
Christian
pgpi7ma6lmHke.pgp
Description: PGP signature
