New Emule Compatible Client In The Making
#1
Posted 14 May 2020 - 11:22 AM
Im currently developing a new eMule compatible client (not a mod).
In fact its a complete reimplementation/rewrite, not a mod - not based on that very old code base.
There are numerous reasons for this, Im doing this now for lil' bit more than half an year.
I tried to closely study the eMule codebase, but didnt want to inspired by it - just for the sake of
staying compatible and implementing the existing features.
Personally Im more used to aMule, as Im a Linux and BSD user - to me aMule isnt a very good port.
Today it suffers from quite the same problems as the original codebase.
I hardly doubt that eMule runs well on any modern OS (Win8.1, Win10 etc.) with a good/proper bandwidth connection (VDSL, Fiber etc.)
Im not going to argue the fact that torrent has superseeded the original p2p software since many years now,
however I still personally like using ed2k/emule for smaller files - being able to search something is great thing.
As far as I understand the codebase it was originally written and based on MFC, well MFC is now dead for good 2 decades I guess -
while its true that Microsoft keeps compatibility around for ages, its not running well as things change under the hood.
I guess sooner or later that old C++ libraries will vanish for good (just as win32 will in the end).
On the Linux side we have similar issues, aMule is horrible crashing ocassionly (especially on FreeBSD) and based on wxWidgets
which was a neat idea back then but has long being superseeded - (almost) nobody is using that toolkit anymore.
Plus as it is a port you carry a huge pack of unnecessary things, in the end it wasnt platform independent written in the first place.
I cant comment on Mac OS because I never used it long... Im not a Mac guy (nor a Mac developer).
My client was originally supposed to be a multi-protocol client (not necessarily torrent client, there are so many good torrent apps available),
however since I was targeting emule/ed2k from the beginning - it took a long time and till today that is the only thing I can do.
I'll do a Linux version for sure, I guess also a Windows version - and I will only target x64 (no old 32bit stuff).
(If I ever do ARM... *huh* I dont know)
Would be nice to know who wants to see a good/proper running eMule compatible client which is *not* a mod but a new thing.
Im also looking for testers, so people who can let it run - share a couple of files, keep reporting back etc.
Im not debating in what people are sharing or anything about piracy, what you guys sharing is up to you - not me.
Also what I would require sooner or later are people who translate, I wont push all things in google translator.
Another point would be interesting features demanded, if you could have them - what would that be?
#2
Posted 14 May 2020 - 11:52 AM
Quote
At dawn of May 13th 2002 a guy called Merkur was dissatisfied with the original eDonkey2000 client and was convinced he could do better. So he did. He gathered other developers around him, and eMule Project was born. Their aim was to put the client back on track where eDonkey had been famous before, adding tons of new features and a nice GUI.
#3
Posted 14 May 2020 - 12:02 PM
Those things repeat themselfs, sure... Im not saying that eMule was bad in the year 2002 or in the year 2010 - Im didnt say this.
Yet today we've even better technologies for development in 2020.
Btw. if I refer to eMule I also did refering to the extended protocol,
there are quite some clients out there which are aiming to be eMule compatible.
This post has been edited by megaT: 14 May 2020 - 12:04 PM
#4
Posted 14 May 2020 - 07:46 PM
I hope senior developers will also support it
#5
Posted 14 May 2020 - 09:50 PM
As far as its going with emule, the newest mod for me is morph with the 12.7 version in emule 50. The version 51 from fox88 hasnt get a mod as i know.
For Torrent, iam using BiglyBT and was using BitTyrant before, because they have a better upload behaviour (in my opinion^^) and a lot of options. Thats the reason, why iam using morph.
I think a modern morph would be great. If that is combined with the features from like BiglyBT for BitTorrent, so that 1 program is enough, would be cool.
It is very important, that your project isnt cast in the leecher/bad client section, is accepted for private torrent tracker and dont get banned or collect bad points from emule/mods... That would be a "must have" for me.
#6
Posted 15 May 2020 - 09:42 AM
mul3usr, on 14 May 2020 - 07:46 PM, said:
I hope senior developers will also support it
Honestly would be interested if *any* of the original emule developers are still caring for?
Or has really everyone just moved to bittorrent?
As I understand there are only ocassionly some mods built by some people (not original developers),
but you wont get very far with mods.
You really need to redo the whole thing, keyword: confirmability, replicability.
The old codebase wont build well with newer / today's tools.
Guess there were already a couple of topics how to build is with VS19 or whatever - aint gonna happen so easily.
I'd have no problem if one of the original developers would like to join in,
if not I'd also like to know the reason why (apart from simply not having the time).
#7
Posted 15 May 2020 - 03:14 PM
megaT, on 14 May 2020 - 12:22 PM, said:
Im currently developing a new eMule compatible client (not a mod).
In fact its a complete reimplementation/rewrite, not a mod - not based on that very old code base.
There are numerous reasons for this, Im doing this now for lil' bit more than half an year.
Good luck It's certainly an interesting project and topic with a lot to learn - which is after all the reason eMule started to exist a few decades ago. Although as you no doubt have found out already, rewriting a project is often more daunting than it seems in the beginning.
Quote
while its true that Microsoft keeps compatibility around for ages, its not running well as things change under the hood.
I guess sooner or later that old C++ libraries will vanish for good (just as win32 will in the end).
Yes MFC is very dead. It was already in its final moments when eMule was born. Although I'm quite sure it will be supported forever by Microsoft. Maybe not as development option for modern Visual Studio releases, but it will run on Windows 11, 12 etc. To be fair, I'm not sure if there is any desktop UI framework right now which isn't kinda seen obsolete by MS, given that UWP kinda didn't work out, WPF somewhat deprectated and WinForms pretty close to MFC when it comes to age.
Quote
Im also looking for testers, so people who can let it run - share a couple of files, keep reporting back etc.
I'm pretty sure there is always interest and demand in good software, even though the "gold rush" days of filesharing apps are a bit in the past.
Quote
Get Kademlia ready for Ipv6 It's an interesting challenge, one which eMule didn't finish anymore. Of course there are mods which supprot Ipv6, but keeping DHT safe against tampering and poisoning without a limited ressource needs some new concepts.
Quote
All the original developers care deeply for the Mule But none of them is actively working on it since quite a while. And I don't think that is likely to change.
#8
Posted 15 May 2020 - 03:36 PM
Thanks for the reply, yeah there is a lot to understand in it -
but Im still beating around it sooo.. I guess I can get it done.
Just really a lot of work.
Most often its about reading the source and understanding how its supposed to work
(without getting into the details, how it is implemented).
For the UI I go with Qt5 because that's the only toolkit I know which is reasonable,
works nicely with any other C++ stuff.
But essentially this is a Standard C++17 deal, without Qt except for the UI area.
One of the things I wanted to have in the beginning modularity, very good speration from the emule logic
and the UI or whatever.
For a good portion that is the case in eMule too, but not everywhere - I think you cant really seperate the UI from the logic.
Qt5 works well in Linux, on BSD and in the end on Windows too - any other tookit hasn't made the pace.
And Im not going in the .NET/managed area - not for the complete thing.
Yeah its not really about goldrush for me, its not even about "file leeching" - Im coming more out of the privacy/data communication area.
And I think that is still the area which will stay more relevant and even become more relevant, despite the majority of the people turning a blind eye on it - they will regret it.
In fact in my client, KAD isnt even implemented - not a single line (yet).
As mentioned Im in an early alpha phase, downloading/uploading, searching, basic portions of the UI work (which wont mature until BETA1)
backend storage (sqlite), priority, blacklisting (basics), the whole protocol parsing...
I've strictly seperated the client/server and client/client communication, the portion Im working on right now is filling the missing pieces regarding AICH.
Im on a good road to alpha2 now, once that is reached I'll starting KAD implementation.
Yeah I'll keep it sane, Im not here to damage the net, in fact for all the testing I've done so far these were mostly only with a different amule client (which I also ran) and ocassionaly a couple of test transfers with foreign peers and small files.
Edit:
Another thing which should be improved is the credits/auth features - it uses RSA keys.. but with a length which is beyond good and evil.
256bit is not really a *thing* today any longer, it seems that the protocol here is quite restricted - talking about OP_PUBLICKEY.
With a static length of 256bytes you cant really fill the whole out including all the ASN.1 wrapped around stuff.
Afaik a sane key length such as 2048bits simply didnt fit here anymore (I've tried this).
So either one does change the restriction here or simply drops RSA for good and goes to ECDHA (which would be better anyways).
This post has been edited by megaT: 15 May 2020 - 03:51 PM
#9
Posted 15 May 2020 - 04:31 PM
megaT, on 15 May 2020 - 04:36 PM, said:
Another thing which should be improved is the credits/auth features - it uses RSA keys.. but with a length which is beyond good and evil.
256bit is not really a *thing* today any longer, it seems that the protocol here is quite restricted - talking about OP_PUBLICKEY.
With a static length of 256bytes you cant really fill the whole out including all the ASN.1 wrapped around stuff.
Afaik a sane key length such as 2048bits simply didnt fit here anymore (I've tried this).
So either one does change the restriction here or simply drops RSA for good and goes to ECDHA (which would be better anyways).
It was not really a "thing" back then neither. But the eMule Protocol was always built in a way to avoid overhead as much as possible and this key is sent to every new contact (so enough that a KB more or less matters - or mattered back then, bandwidth is different today too after all). It isn't used for security critical operations but to avoid "drive by credit stealing". As such a few hours of security was good enough back then, today it's probably more like minutes or seconds though.
#10
Posted 15 May 2020 - 04:33 PM
Quote
Yeah but as I understand it, it is there to identify clients later on... so the issue remains
that one can impersonate other clients.
So maybe a nice detail to improve.
#11
Posted 15 May 2020 - 05:02 PM
The full list of versions could be seen in Wikipedia, and the latest one is:
Visual C++ 16.5.0 14.25.28508.3 March 16, 2020
True, it is not haute couture in the modern programming.
#12
Posted 16 May 2020 - 04:33 PM
nice to know that there's still somebody developing clients.
I don't know (or I don't get?) at which stage you are in, but you might want to consider the following:
https://forum.emule-...7&#entry1092017
I'll quote myself:
Mobandi, on 06 February 2016 - 10:40 AM, said:
My opinion is that the first thing to do is to develop a cross-platform/multi-architecture shared library for ed2k, somebody started doing something like that on github but I think he abandoned the project ( hxxps://github.com/qmule/libed2k last serious commit is from 1 year ago ).
After that, develop clients that rely on that library, this way the users can have all the options in the world: headless client for linux servers, pretty GUI client for win10, shitty GUI client for win95, etc.etc.
I always wanted a linux headless client different than aMule, and nobody does that
If you were to make something like that, I would love to help by testing your software.
This post has been edited by Mobandi: 16 May 2020 - 04:35 PM
#13
Posted 16 May 2020 - 04:58 PM
Ya your describing the exact situation.
Quote
Was exacly my kind of thoughts as well, for along time now actually.
So that is what Im doing, exacly all ed2k stuff is in its own module and its designed in the way that it can be completly seperate from the UI.
I did describe my progress in my earlier post.
#15
Posted 26 June 2020 - 10:52 AM
megaT, on 14 May 2020 - 12:22 PM, said:
Im currently developing a new eMule compatible client (not a mod).
Been there done that,
the user interest was next to non existent.In case you want to take a look on a working ed2k implementation in Qt my NeoLoader is on github
It can also download torrents and has an own novel network with onion routing and anonymity.
This post has been edited by DavidXanatos: 26 June 2020 - 10:57 AM
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
#16
Posted 26 June 2020 - 02:08 PM
DavidXanatos, on 26 June 2020 - 10:52 AM, said:
megaT, on 14 May 2020 - 12:22 PM, said:
Im currently developing a new eMule compatible client (not a mod).
Been there done that,
the user interest was next to non existent.In case you want to take a look on a working ed2k implementation in Qt my NeoLoader is on github
It can also download torrents and has an own novel network with onion routing and anonymity.
Well, very good.
Nah I dont expect much user interest, I merley do this for myself -
many people did that before I think, of course most of these projects end up dead/unsupported.
Which is sad.
I didnt find anything which suits my needs really... its either a codebase issue, a quality issue or a functionality issue.
Need a headless client and it must have a well designed (also well documented) interface.
Is yours fully compatible with eMule?
Did you extend it with IPv6?
If you like to share some details, I'd like to keep compatible to (other) clients.
Not planning on doing my own network though, there so many networks already.
#17
Posted 26 June 2020 - 02:29 PM
megaT, on 26 June 2020 - 03:08 PM, said:
Did you extend it with IPv6?
Yes its fully eMule compatible,
Yes it has IPv6 support and also NAT-Traversal.
It can operate in fully headless mode with a Web UI, or with a Qt UI connected using pipes or sockets.
The code is very Qt centric using all the nice container objects and the signal/slot paradigm but its written very cleanly IMHO.take a look to NeoLoader\FileTransfer\ed2kMule\MuleClient.cpp
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
#18
Posted 08 July 2020 - 07:28 PM
That project has good documentation etc., and was using then state of the art c++ codes for development.
What I mean is, writing a wonderful headless ed2k app is a tough job. When your project is mature enough, probably you'll get help this time, at least I am willing to contribute some of the good parts of my mod.
#19
Posted 10 July 2020 - 04:33 PM
Yeah I know Hydranode, in fact I stumbled over it.... It seems to be abandoned now for years.
The code isnt modern enough, I personally use completly different aproaches - so I wont take any code from there, but I read quite some documentation.
Quote
It is absolutly, its more work than I expected..
But Im happy with my progress so far, I've a fulltime job and thats mainly the reason why progress is slow - I will not release any code prematurly.
I also dont like forks... at least not from half baked things, other than that we'll see.
What I would like probably is, if there is interest and people know C++ (I mean know it, not just wrote a couple of hello worlds) then I'd be interested in teaming up.
I still wonder (as I've already wrote elsewhere) what about the other more modern eMule compatible clients that are existing already?
They dont get the job done, what's wrong with them? (if there is still interest in p2p)
#20
Posted 10 July 2020 - 05:01 PM
I tried a lot torrent and ed2k clients for my systems at home. For my servers i used mldonkey or torrentflux. But mldonkey has a lot of problems and is showing bad behaviour quite often or if misconfigured.
As far as it goes with emule mods, iam using morph at the moment and this for a long time now...