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

[MLdonkey]

>  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...

Right. I'm also on cable, I can understand that :)

>  Yes, I've found the "fine" comment in the source :)

Comments should never be written while debugging code :)

>  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.

Yes, this message does exist, and should clearly be used and
understood by mldonkey. This fix was mainly an emergency fix, not a
good one. If Emule clients use this message, it could explain while
the upload from Emule clients is also so low. But at least, download
from mldonkey clients now works. 

There was a problem of asynchrony that prevented us from keeping it:
BlocQuery requests were not accepted when the client_bucket=0, while
mldonkey believes they were and keeps waiting for them. Since the
CloseSlot is received too late, a lot of these messages are lost until
a new JoinSlot is issued by mldonkey.

Anyway, there is still a problem there. Anybody can download from
mldonkey if it directly sends BlocQuery requests without JoinSlot
ones. So the client_bucket verification should in fact be replaced by
a client_join_slot verification, to be sure that the client has been
accepted in the queue before it sends requests for files.

>  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.

As said before, it was an emergency fix, and we were a bit upset to
discover this problem. Another problem is that the development of
mldonkey was stucked for two months, and a lot of users were asking
for fast integration of your patch, so that it was done
without real discussion. Anyway, what happened is not that bad, only 1
or 2 patches among 30 have been removed.

>  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 ?)

Maybe another solution would be to test if an emule uploaded is
interesting for us (ie it has chunks we want), and then give him a
push to enter our upload queue. This would be a more "interested" approach
than the credit system.

>  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...

Right. A place for another option :) We should probably work again on
the source propagation mechanism, that clearly doesnot scale
properly. Using a protocol compatible with emule would also be
great. I don't know what to do with new sources. Indeed, these sources
are "fresh", compared to the ones in the list we already have. Maybe a
good approach would be to keep them, but in a compressed format (not a
client type) to reduce memory usage, and then, use them on demand. The
problem of the new_clients_list is that it does not indicate for which
file the (ip,port) is interesting.

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

I don't think there are so many things removed, probably 1 or 2
patches (credit system and quantum) among 30... In fact, now, I think
that only the quantum patch was responsible for the problem. 

>  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)

Yes, it could be a good thing. mldonkey, as edonkey, can still be
attacked by queue-jumping (clients asking very often for files to
increase their probability to enter the queue). With an upload queue,
it would not be possible anymore. The main problem is to know how to
manage the queue so that, when a slot is available in the queue, it
does not have to wait for the first client in the upload queue to
reconnect (if it reconnect ever). 

Regards,

- MLDonkey