Re: [Mldonkey-users] Investigation: No download for some, full downloads for the other

[MLdonkey]

As I said un a previous mail, I think we have to reconsider how
sources are handled from scratch. What made mldonkey download very
fast "in the old ages" was the fact that it was always looking for new
sources and testing them. 

Of course, this behavior has drawbacks, in particular, the fact that
it uses a lot of CPU, bandwidth and memory. So, what we have to do is to
find a way to aggressively search for sources, and then, store them
without using too much memory, and test them without using too much
bandwidth... 

Formerly, sources were stored in each file structure. After discussion
of my previous mail with Simon, we think we could get rid of this
organization, and store all sources in different globals sets
depending on their "quality" (ie the result of the last connection):

- connected clients: the clients that we are trying to connect, or
  that we are still connected with. Those clients would be the only sources
  displayed for the files as "sources" in the GUI, and they would use
  big data structures compared to other sources.

- good sources: these sources were connected and have at least one
   chunk we don't have.
- untested sources (what I formerly called emerging-sources)
- concurrent sources: these sources were connected and have some
   chunks of the file that we already have.
- old sources: these sources were connected a long time ago, but did
   not reply to our last connection request.
- other sources: these sources have never been connected, but have
   been sent to us as sources, so we can keep them for some time.

The connected clients set would be limited by a
"max_connected_clients" global value. 
When a client would disconnect, it would be stored in one of the
different sources set (fifo in fact), depending on the result of the
connection. Then, another source would be taken from the sources set
(probably in the order I've displayed them), and connected, depending
on the option "max_clients_per_second".

1) What do you think of this approach ?
2) Do you know the approaches used in eMule, eDonkey or Overnet ?

Note that we could implement three sets of sets of sources, ie one for
high priority files, one for normal files, and one for low priority files.

Any comments ?

- MLDonkey