mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] 2.02-20 working great!


From: MLdonkey
Subject: Re: [Mldonkey-users] 2.02-20 working great!
Date: Wed, 26 Feb 2003 12:06:15 +0100

>  2.02-20 is working great here, nice speed!
>  
>  Some people report heavy memory usage, IMHO this is one of the few things
>  that should be looked into before releasing to 2.03...

I think we have to things to do before 2.03:

* understand how to behave with full-chunks upload: what should we do
  when the slot is closed by the client ? Do we currently support that
  ? It looks like we lose everything for min_reask_delay... It is
  clearly the biggest problem we have currently for downloads. I'll
  try to setup a small network with emule and mldonkey to see what
  exactly happens.

* fix memory behavior (both core and gui)

>  Also, I'm releasing new patchsets, with dynamic upload slots allocation and
>  more:
>  
>  
> http://download.berlios.de/pub/mldonkey/pango/patches-against-CVS2.02-20/pango-CVS2.02-20-20030226a.tar.gz
>  
>  Changelog:
>  http://download.berlios.de/pub/mldonkey/pango/Changelog

I've just downloaded them, and see that the full-chunks upload is back :) 
I have two problems with that:
1) does mldonkey support that ? the reason why it was removed a few
  months ago was that mldonkey was not able to continue a download when
  the CloseSlot was sent by another mldonkey client. before applying
  such a patch, we must be sure that downloads between mldonkey
  clients are ok.
2) does edonkey support that ? Emule probably supports that, but I'm
  not sure that the official client supports it. Indeed, it clearly 
  changes the semantics of the protocol: before, the AvailableSlot
  meant "you can download whatever you want", while now, it would mean
  "you can download no more that one chunk". We should clearly be
  careful with such changes, as I respect the work of jed (which seems
  not to be the case of emule devs).

  This means that we must either prove that edonkey is not affected
  (put mldonkey, edonkey and a server on your localhost, and try to
  download a big file with edonkey to check), or use another method
  (we could for example simply disconnect after the chunk, and allow
  the client to reconnect and reask  the file without being banned, or
  immediatly reconnect to him if we are a LowID).

- MLDonkey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]