docs/mldonkey-design.tex

   1 \documentclass{article}
   2
   3 \author{b8\_bavard}
   4 \title{Some MLdonkey design choices}
   5
   6 \begin{document}
   7
   8 \section{No credit-system}
   9
  10 We have decided not to add a credit-system to MLdonkey for some reasons:
  11
  12  \begin{description}
  13
  14  \item[Unclear interests:] the interests of a credit system are unclear. The
  15 credit-system is supposed to incitate users to upload. However, most users
  16 already upload a lot. No-uploads patches for binary clients exist, and it is
  17 easy to modify open-sources clients to prevent upload. However, very few
  18 clients use these kinds of tricks, and anyway, there are enough good
  19 uploaders in the network to cope with a few no-uploaders.
  20
  21  \item[Cheating:] whereas the credit-system is supposed to prevent
  22 no-uploaders, it introduces some problems that did not exist before:
  23 formerly, cheaters could only do queue-jumping (now, they get banned by emule
  24 and mldonkey clients) and no-upload. With the credit system, it is now
  25 possible to cheat in other ways: you can try to get credits by uploading
  26 random data to interesting peers (the data is checked for corruption only
  27 after a long while), you can fake other clients hashes (either to make them
  28 lose their queue position, or to get their credits), etc...
  29
  30  \item[Popular files trend:] if you want credits to be able to download a
  31 lot, you have to share popular files. This trend causes a loss of value:
  32 interesting files, but not popular, are disappearing from the network,
  33 because they are no interests to upload them.
  34
  35  \item[Windows community:] most clients are using windows, and are downloading
  36 windows apps. Thus, if you don't share windows apps, you will lose a lot of
  37 credits compared to these users. In particular, unix users don't benefit from
  38 these credits, which are only moving inside the emule community.
  39
  40 \end{description}
  41
  42 \section{No long upload-queue}
  43
  44  The long upload queue sorts the clients requesting to enter the upload
  45 queue in a fifo order. This means that the oldest clients are always in the
  46 top of the queue (ie they have a lot of upload slots in other clients, even
  47 if they cannot use them at full speed), whereas new clients (for example
  48 newbies) have to wait for days to see their downloads start. Clearly,
  49 to get as many users as possible, it is important for newbies that they
  50 immediatly download something from the network, even if it is not a lot.
  51 Long upload-queues are good for long term users, those who are the most used
  52 to waiting long for files...
  53
  54 \section{Banning system}
  55
  56 Until now, a client is banned by MLdonkey in two cases:
  57
  58 \begin{description}
  59
  60  \item[Queue-jumping:] if a client requests a file more often than other
  61 clients, it has a better probability to enter the upload queue (when the
  62 upload queue is short, which is the case in edonkey and mldonkey). To prevent
  63 such a behavior, mldonkey bans such users, when 3 queue-jumping attempts are
  64 detected in one hour. A queue-jumping attempt is the fact of asking a given file less than 9 minutes after the previous query for this file.
  65
  66  \item[Long upload-queue:] mldonkey does not use long-upload queues,
  67 meaning that all clients are equal when they request to enter its upload
  68 queue. On the contrary, long upload-queue clients are unfair: they benefit
  69 from the probabilistic queue of mldonkey, while preventing it from uploading.
  70 As a consequence, these clients are banned if they announce that your rank is
  71 greater than 1000, so that they won't upload until you get a better position
  72 in their unfair queue.
  73
  74 \end{description}
  75
  76 \section{Multiple servers connections}
  77
  78 MLdonkey allows several connections to servers, which are classified in different connections:
  79 \begin{description}
  80
  81  \item[Master servers:] master servers are servers to which mldonkey sends
  82 its list of shared files. MLdonkey never connects to a master server for less
  83 than two minutes. Being connected to several servers allows to propagate
  84 shared files faster, and to find sources for rare files more easily.
  85
  86  \item[Walker servers:] UDP queries are bad for servers, since it is very
  87 hard to limit them. A client downloading 60 files will send 60 UDP packets to
  88 each alive server in its list. Some servers have even decided not to reply to
  89 UDP packets to prevent this. MLdonkey uses a walking mechanism instead: it
  90 connects every 6 hours to all the servers in its server list, and then ask
  91 for the 20 first files to download. This looks better since (1) the server
  92 controls how many users can be connected, so the connection will only be
  93 accepted if the server has free slots (2) the file queries will only be sent
  94 if the server has accepted the connection. Note that the connection is
  95 light-weigth: the list of shared files is not sent, contrarily to what
  96 happens with the bot, or with clients connecting and disconnecting from
  97 servers.
  98
  99 \end{description}
 100
 101 \section{The 'nu' command}
 102
 103 \section{MLdonkey self upload slot bypassing}
 104
 105 \section{Emule upload-slots limitation}
 106
 107  MLdonkey limits the number of slots used by emule clients to 1/3 of the
 108 slots, because the emule client is a bad uploader (it downloads much more
 109 than it uploads), compared to other clients. Consequently, it is always
 110 better to upload to an edonkey or mldonkey client, since the data uploaded
 111 will be better shared afterwards. This limitation however does not limit the
 112 bandwidth (they can use 100% of the maximal bandwidth with only 33% of the
 113 slots) that can be used by emule clients.
 114
 115 \end{document}