Re: [Mldonkey-users] Re: can t connect to server

[Pierre Etchemaite]

Le Mon, 25 Nov 2002 10:29:49 +0100, Sven Hartge <address@hidden>
a écrit :

>> md4_speedup.patch: patch #634, uses a larger (128Kb), static i/o
>> buffer for file md4 computations
> In what scale is this speedup to be expected?

10% on my box, for chunk validation itself, so it's noticeable, but not
amazing, it should be i/o bound anyway. 
I also recommend lowering compute_md4_delay.

>> get_chunks_in_random_order.patch: patch #665. Try to get the chunks
>> of files in a random order. Better for file propagation.
> What is mldonkeys current strategy? Get the first chunk? Get the chunk
> with the fewest sources?

Get the last chunk, then the other chunks from the beginning to the
end. If the source is the only "known" source for some chunk(s), the
priority is given to one of those chunks, randomly choosen. In real
life, that last case seldom triggers.

The new algorithm sets a chunk order when the download starts. It will
try to get the last chunk, then the first chunk, then the others at
random. 

For those who wonder, prioritizing first and last chunks is useful for
previewing. It's very easy to modify the way chunks are prioritized,
to download several chunks at the beginning of the file before getting
others at random, for example.

>> hide_chunks_being_uploaded.patch: patch #668. Hide chunks already
>> being downloaded to other uploaders. Better for file propagation. 
> So, if a file has 5 chunks, and 4 people already downloading 1 different
> chunk, then mldonkey would report only 1 chunk as available to the net,
> right?

Correct, and if all the chunks are being uploaded, you cannot upload
from the first source. The first "batch" of uploads can complete
faster, and when a chunk is transferred, it now has two available
sources: the first source, and the peer that just received it.
And so on.

>> fifo_new_sources.patch: patch #700. Check that sources received
>> (from servers or from other peers) aren't already known, queue them
>> in a FIFO, and dequeue them when no other client connections are
>> scheduled. 
> This is an attempt to resolve those bandwidth problem, correct?

It's an attempt at not chocking on very popular files. The official
client puts sources addresses received by UDP (from servers or by
source propagation) in front of the scheduling queue. If you receive
lots of them, you can spend your time trying new sources, maybe
slowing down the scheduling of working sources to the point they don't
work anymore, etc.

Also, the reasking timers of received sources are resetted, even if
the source was in fact already known by you. In that case, the
min_reask_delay parameters is not followed for that source, and that
can "upset" eMule clients. That patch doesn't touch reasking timers,
sources received by UDP are handled the same as sources received by
TCP, so the bugfix is in fact a *simplification* of the algorithms.

> Let's hope mldonkey (the coder) returns fast, so official developement
> can start again.

Same thing :)

Whenever possible, I try to fix things in the simplest correct way,
and to follow the current "programming style" of mldonkey, so I
believe most of those patches will be accepted by mldonkey when he
gets back.

BTW, are other people working on patches, not yet published on
Savannah website ?