MLdonkey
MLDonkey - the Open Source eDonkey client
Features:
- 100% Open Source, GPL license
- runs on Linux, Unix, Solaris, MacOSX, MorphOS and Windows
- The p2p core can run on a resource limited headless computer, with remote GUI clients accessing it over the network.
- The core is built to run as daemon for days, weeks, ever...
- Several different GUIs available, some of them developed separately.
- Multi-user support: the same core can queue and process downloads for several different users who can't see what the others are downloading.
- Several different file-sharing networks supported:
- ED2K (and Kademlia and Overnet)
- BitTorrent
- DC++
- (FastTrack, SoulSeek, Gnutella and G2 need work)
- The core can download the same file from several different networks simultaneously.
- Scriptable command-line interface available. It's possible to control all aspects of mldonkey from the CLI.
- Written in ObjectiveCaml, with some parts written in C and some in Assembly.
Background
MLDonkey has been developed since January 2002 [1] and has been hosted by Savannah, a development site for free software that is not part of the GNU Project, since Feb. 19, 2002. It was started by Fabrice Le Fessant and Simon Patarin who work at INRIA to prove the capabilities of the OCaml language. Quoting http://hal.archives-ouvertes.fr/inria-00071789/en/ :
- A lot of designers of functional languages have one dream: finding a killer application, outside of the world of symbolic programming ( compilers, theorem provers, DSLs ), that would make their language spread in the open-source community. One year ago, we tackled this problem, and decided to use Objective-Caml to program a network application in the emerging world of peer-to-peer systems. The result of our work, MLdonkey, has superseded our hopes: it is currently the most popular peer-to-peer file-sharing client on the well-known freshmeat.net site, with about 10,000 daily users. Moreover, MLdonkey is the only client able to connect to several peer-to-peer networks, to download and share files. It works as a daemon, running unattended on the computer, and can be controlled remotely using three different kind of interfaces. In this paper, we present the lessons we learnt from its design and implementation.
MLDonkey was originally intended as a pure eDonkey2000 clone, running on Unix and Linux, a sector that the original client never served well. Since the release of version 2, there has also been development to access other networks, most notably the eDonkey2000 offspring Overnet, BitTorrent, Kademlia and DirectConnect.
The history of MLDonkey has been lined with controversy, mostly based on the fact that the original Overnet client has always been proprietary, in terms of source code as well as transfer protocol. This has forced the MLDonkey developers to reverse engineer the basic mechanisms, but they didn't stop at that. In many cases, new functionality has been introduced, sometimes great and sometimes questionable.
The first controversy was regarding servers. MLDonkey introduced a method to connect to several servers simultaneously, thereby increasing search efficiency greatly. This was at a time when servers were relatively small, and already strained (mainly by bots). Too many users, too few servers, new solutions needed.
Later on, certain pretentious server admins became more and more interested in the numbers of users assigned to their servers, rather than in the efficiency of the network. This meant that a client connecting to more than one server was a threat to their internal "high score" competition of served users.
Complaints started to come in from eDonkey users about MLDonkey being too efficient, i.e. utilizing an unfair amount of network resources. This probably has to do with the extreme reluctance of the developers of eDonkey2000 to improve their product, which led to larger and larger servers, instead of following the approach MLDonkey stood for: increasing the connectivity of the network as a whole. But, then again, making the eDonkey2000 network too efficient would probably not be in line with the plans to develop the Overnet, which is indeed a high connectivity serverless network.
MLDonkey also featured a way to exchange file sources between clients, thereby making the servers less important, of course another threat to the pride of the server admins. Soon, a strange alliance was formed by the developer of the popular Lugdunum server and MetaMachine, the eDonkey2000 development company. This resulted in a long series of attempts to ban MLDonkey, bans which were easily worked around, and due to the nature of open source projects, also easy to deploy among users.
It is important to note that, being an open source project, the MLDonkey team have always offered their solutions to the original developers, as well as the rest of the community. This courtesy has never been returned, even though numerous pleas have been forwarded; MetaMachine insists on keeping their code and protocols proprietary.
Later on, as MetaMachine turned all their efforts into creating the aMule was developed from xMule source code and most of their developers, which is listed on eMule homepage as the eMule for linux right now. With Overnet, another eDonkey client emerged: eMule. This was the result of popular demand from users to provide (a) nice graphics and (b) balanced of upload and download. It runs only on Windows. An eMule port to linux was created lMule, available on Sourceforge, which later was forked to xMule, and then aMule came the total surrender of the term "file sharing" per se, in favor of ultra liberal demands to convert the network to a file trading model, using a currency of credits, complicated queue systems, and internal preference. The credit system in eMule is no longer mandatory as of release 0.28a. eMule's biggest deficiency is that it cannot be used with a remote GUI, making it impractical for use on a server machine. However the last eMule and aMule versions have implemented a web-interface making it possible to remotely control basic search/download/preferences functions. aMule has also implemented a GUI/Core separation but the standalone remote GUI is quite in initial stage of development and implements basic functions. At the moment MLdonkey is the only one providing deep remote control of the core thanks to the web-interface and various GUIs.
...
Late development is that the official client now seems to adapt MLDonkey's concept of also connecting to the Overnet. Although MetaMachine has been labeling MLDonkey a_rogue client over this, it chooses to call their own offspring_hybrid vigor. My paranoid explanation of this is that the growth rate of the Overnet does not please MetaMachine, nor does it honor its business idea, so in the meanwhile they are trying to seduce ed2k/eMule users to try it out.
Nowadays, MLDonkey still has a bad reputation among clients since it used to be aggressive back in the early days. MLDonkey is still the only client supporting MacOSX users and the only native client for MorphOS
Some MLDonkey design choices are quite different from eMule's, and are often misunderstood.