[Mldonkey-users] observations (was Re: Emule for Linux)

[nospam]

Well, lmule works quite well - at least the bandwidth stuff is like in
windows emule. Sources searching etc works like under windows, apart from
this it's quite unflexible for a unix app - which comes from the direct 
port of windows emule to wxwin-gtk.

I noticed quite some differences concerning source management there,
let's try to explain what I understand from the sourcecode, maybe it's
helpful for mldonkey developers to solve the bandwidth control and/or
sources problem.

I did some research about delays, thresholds etc. Note that emule processes
one file after another with sources searching, so it can take quite some
minutes if you got some files in the queue for finding sources - which
limites bandwidth efficiently.

This is taken from emule 0.27a, but it was the same in 0.26d, which is
used for lmule.

#define CONNECTION_TIMEOUT    40000 // set his lower if you want less connection
s at once, set it higher if you have enough sockets (edonkey has its own timout 
too, so a very high value won't effect this)

this is our client_timeout, which defaults to 120 in mldonkey (quite too high,
30-40 isn't too low I think)

#define MAX_CLIENTCONNECTIONTRY  2

(not configurable in mldonkey) - client is thrown away after 2 unsuccessful
retries.

#define UDPSERVERREASKTIME    1300000  // ***

If new sources are needed, the server is asked in this interval for
sources - that means only every 1300s the local(!) server is queried
for new sources.
New sources are only asked if current sources < max_sources_per_file*0.9

Only if current sources < max_sources_per_file*0.75 other servers are
queried with UDP for new sources (!). Maybe this is implemented to reduce
load because of emule client-to-client source exchange.

#define SOURCECLIENTREASK     600000

interval for asking a client for sources (UDP)

#define  MIN_REQUESTTIME         590000
(min_reask_delay)

#define  FILEREASKTIME        1300000  // **
This is used for reasking a chunk on clients. 

One interesting part,
- not needed parts sources:
  this time is 2*FILEREASKTIME.

- not needed parts sources are purged if over 0.8 * max_sources_per_file
  every 40s

- state remotely queued
  UDPReaskForDownload is called after FILEREASKTIME-20000 = 1280s, this
  should be our max_reask_delay then.
  Note there's no connected inited, but only a small, not bandwidth-harmful
  UDP packet sent.

- lowid sources are purged if over 0.8 * max_sources_per_file every 30s

- queue full sources are purged if over 0.8 * max_sources_per_file every 60s,
  UDPReaskForDownload is called after FILEREASKTIME-20000 = 1280s
  (same like queued sources)

- a maximum of 28 sources at once is sent between client_to_client
  source exchange

- if I understand correctly, always a bunch of 100 sources is processed
  in one file, then switched to another (asking clients, removing sources)

This list is far from complete, but it's quite interesting.
You can take a look yourself at emule sourcecode, esp. PartFile.cpp,
DownloadQueue.cpp and opcodes.h

yours,
nospam