Re: [Mldonkey-users] Re: Using full upload again !

[Pierre Etchemaite]

Le Fri, 20 Dec 2002 00:44:13 +0100, MLdonkey <address@hidden> a écrit
:

> Since some people care a lot about upload bandwidth, and some other
> don't care, it should probably be adjustable by a new option...

Thanks for that.

An additionnal filerequests uses 22 bytes, but you don't need to add the
size of the tcp header, since you need one no matter how many filerequests
you send (well, unless your list is so big that it requires several packets
to transmit, ~70 requests for the standard 1500 bytes MTU, I suppose it's
not very common).

So we find roughly the same totals; But 2.5kb/s is not neglectible for many
of us, ADSL and cable users! That's 200Mb by the end of day...

> [it] was
> reverted when we discovered that mldonkey clients couldn't properly
> download from each other (for another reason in fact).

Yes, I've found the "fine" comment in the source :)
Oh well, shit happens. I remember a mldonkey version that couldn't download
from full sources :)

BTW, I found the existence of that message in a reverse-engineered draft
specs, so I guess this message also exists "in the wild". Fixing its
handling was a good thing either way.


Beside that, I don't mind seeing some patches removed (like the
upload_quantum patch, ugly hack), but for many changes, I'd like them to be
discussed, for example in this mailing list, instead of seeing them doing
the added-removed mumbo. The point of most of them is either in the
changelog, or was described on demand in this list already.

I do not like the credit system either, but implementing something that
would fake it was a try to unlock some "eMule safes". (Maybe it is not
necessary after all, because of the "infinite upload queue", all you have to
do is patiently wait for your turn ?)

Sometimes, when a good list of sources already settled, discarding received
list of 1000 (!) sources addresses, 4 times my max_sources_per_file,
appeared to be the best thing to do (short of being able to stop their
sending in the first place, but that seldom happened, so it's not so
critical. BTW, eMule uses sources propagation on demand). Or maybe we should
stop getting addresses out of the new_clients_list until we're in need of
new sources again? I feared that the memory usage could go ballistic...


Etc, I didn't have the time yet to check all what was removed from that new
version...


On a different subject, do you think it's worth implementing an upload queue
in mldonkey ? Many features could then be implemented (like fairness among
files, for example)

Best regards,
Pierre.