patch #7308
[mldonkey.git] / docs / mldonkey-design.tex
blobd1c1f5a1d146f0b2998084d8f7c26e13607f6641
1 \documentclass{article}
3 \author{b8\_bavard}
4 \title{Some MLdonkey design choices}
6 \begin{document}
8 \section{No credit-system}
10 We have decided not to add a credit-system to MLdonkey for some reasons:
12 \begin{description}
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.
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...
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.
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.
40 \end{description}
42 \section{No long upload-queue}
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...
54 \section{Banning system}
56 Until now, a client is banned by MLdonkey in two cases:
58 \begin{description}
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.
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.
74 \end{description}
76 \section{Multiple servers connections}
78 MLdonkey allows several connections to servers, which are classified in different connections:
79 \begin{description}
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.
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.
99 \end{description}
101 \section{The 'nu' command}
103 \section{MLdonkey self upload slot bypassing}
105 \section{Emule upload-slots limitation}
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.
115 \end{document}