\documentclass{article} \author{b8\_bavard} \title{Some MLdonkey design choices} \begin{document} \section{No credit-system} We have decided not to add a credit-system to MLdonkey for some reasons: \begin{description} \item[Unclear interests:] the interests of a credit system are unclear. The credit-system is supposed to incitate users to upload. However, most users already upload a lot. No-uploads patches for binary clients exist, and it is easy to modify open-sources clients to prevent upload. However, very few clients use these kinds of tricks, and anyway, there are enough good uploaders in the network to cope with a few no-uploaders. \item[Cheating:] whereas the credit-system is supposed to prevent no-uploaders, it introduces some problems that did not exist before: formerly, cheaters could only do queue-jumping (now, they get banned by emule and mldonkey clients) and no-upload. With the credit system, it is now possible to cheat in other ways: you can try to get credits by uploading random data to interesting peers (the data is checked for corruption only after a long while), you can fake other clients hashes (either to make them lose their queue position, or to get their credits), etc... \item[Popular files trend:] if you want credits to be able to download a lot, you have to share popular files. This trend causes a loss of value: interesting files, but not popular, are disappearing from the network, because they are no interests to upload them. \item[Windows community:] most clients are using windows, and are downloading windows apps. Thus, if you don't share windows apps, you will lose a lot of credits compared to these users. In particular, unix users don't benefit from these credits, which are only moving inside the emule community. \end{description} \section{No long upload-queue} The long upload queue sorts the clients requesting to enter the upload queue in a fifo order. This means that the oldest clients are always in the top of the queue (ie they have a lot of upload slots in other clients, even if they cannot use them at full speed), whereas new clients (for example newbies) have to wait for days to see their downloads start. Clearly, to get as many users as possible, it is important for newbies that they immediatly download something from the network, even if it is not a lot. Long upload-queues are good for long term users, those who are the most used to waiting long for files... \section{Banning system} Until now, a client is banned by MLdonkey in two cases: \begin{description} \item[Queue-jumping:] if a client requests a file more often than other clients, it has a better probability to enter the upload queue (when the upload queue is short, which is the case in edonkey and mldonkey). To prevent such a behavior, mldonkey bans such users, when 3 queue-jumping attempts are 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. \item[Long upload-queue:] mldonkey does not use long-upload queues, meaning that all clients are equal when they request to enter its upload queue. On the contrary, long upload-queue clients are unfair: they benefit from the probabilistic queue of mldonkey, while preventing it from uploading. As a consequence, these clients are banned if they announce that your rank is greater than 1000, so that they won't upload until you get a better position in their unfair queue. \end{description} \section{Multiple servers connections} MLdonkey allows several connections to servers, which are classified in different connections: \begin{description} \item[Master servers:] master servers are servers to which mldonkey sends its list of shared files. MLdonkey never connects to a master server for less than two minutes. Being connected to several servers allows to propagate shared files faster, and to find sources for rare files more easily. \item[Walker servers:] UDP queries are bad for servers, since it is very hard to limit them. A client downloading 60 files will send 60 UDP packets to each alive server in its list. Some servers have even decided not to reply to UDP packets to prevent this. MLdonkey uses a walking mechanism instead: it connects every 6 hours to all the servers in its server list, and then ask for the 20 first files to download. This looks better since (1) the server controls how many users can be connected, so the connection will only be accepted if the server has free slots (2) the file queries will only be sent if the server has accepted the connection. Note that the connection is light-weigth: the list of shared files is not sent, contrarily to what happens with the bot, or with clients connecting and disconnecting from servers. \end{description} \section{The 'nu' command} \section{MLdonkey self upload slot bypassing} \section{Emule upload-slots limitation} MLdonkey limits the number of slots used by emule clients to 1/3 of the slots, because the emule client is a bad uploader (it downloads much more than it uploads), compared to other clients. Consequently, it is always better to upload to an edonkey or mldonkey client, since the data uploaded will be better shared afterwards. This limitation however does not limit the bandwidth (they can use 100% of the maximal bandwidth with only 33% of the slots) that can be used by emule clients. \end{document}