Official eMule-Board: New Emule Compatible Client In The Making - Official eMule-Board

Jump to content


  • (3 Pages)
  • +
  • 1
  • 2
  • 3

New Emule Compatible Client In The Making

#1 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 14 May 2020 - 11:22 AM

Hello community,

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?
3

#2 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4723
  • Joined: 13-May 07

Posted 14 May 2020 - 11:52 AM

http://www.emule-pro...general.cgi?l=1

Quote

What is eMule?
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.

0

#3 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 14 May 2020 - 12:02 PM

That was good for 2002, but nobody is developing eMule in 2020 anymore - or is there any development? (Which isnt a mod outside of the core developers)
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

0

#4 User is offline   mul3usr 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 14-May 20

Posted 14 May 2020 - 07:46 PM

A new modern client? It would be amazing!! :thumbup:
I hope senior developers will also support it
0

#5 User is offline   Campo 

  • Member
  • PipPip
  • Group: Members
  • Posts: 47
  • Joined: 18-June 19

Posted 14 May 2020 - 09:50 PM

Iam very interested in this. Read your other post yesterday.

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.
0

#6 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 15 May 2020 - 09:42 AM

View Postmul3usr, on 14 May 2020 - 07:46 PM, said:

A new modern client? It would be amazing!! :thumbup:
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).
0

#7 User is offline   Some Support 

  • Last eMule
  • PipPipPipPipPipPipPip
  • Group: Yes
  • Posts: 3649
  • Joined: 27-June 03

Posted 15 May 2020 - 03:14 PM

View PostmegaT, on 14 May 2020 - 12:22 PM, said:

Hello community,

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

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).

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

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.

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

Another point would be interesting features demanded, if you could have them - what would that be?

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

Honestly would be interested if *any* of the original emule developers are still caring for?

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 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 15 May 2020 - 03:36 PM

Hi

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

0

#9 User is offline   Some Support 

  • Last eMule
  • PipPipPipPipPipPipPip
  • Group: Yes
  • Posts: 3649
  • Joined: 27-June 03

Posted 15 May 2020 - 04:31 PM

View PostmegaT, on 15 May 2020 - 04:36 PM, said:

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).


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 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 15 May 2020 - 04:33 PM

Quote

It was not really a "thing" back then neither.

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.
0

#11 User is offline   fox88 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 4723
  • Joined: 13-May 07

Posted 15 May 2020 - 05:02 PM

A curious fact about MFC, which was kind of "dead before it was born" :)

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.
0

#12 User is offline   Mobandi 

  • Member
  • PipPip
  • Group: Members
  • Posts: 17
  • Joined: 08-May 05

Posted 16 May 2020 - 04:33 PM

Hello megaT,
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:

I stand with Some Support, let eMule fade into obscurity, fork the client or restart from scrap.
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

0

#13 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 16 May 2020 - 04:58 PM

Hi Mobandi

Ya your describing the exact situation.

Quote

I always wanted a linux headless client different than aMule, and nobody does that

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.
0

#14 User is offline   TreviSyn 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 10
  • Joined: 11-February 03

Posted 16 June 2020 - 04:33 PM

Good job ^^ :thumbup: :worthy:
0

#15 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1468
  • Joined: 23-April 04

Posted 26 June 2020 - 10:52 AM

View PostmegaT, on 14 May 2020 - 12:22 PM, said:

Hello community,

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

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
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.
0

#16 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 26 June 2020 - 02:08 PM

View PostDavidXanatos, on 26 June 2020 - 10:52 AM, said:

View PostmegaT, on 14 May 2020 - 12:22 PM, said:

Hello community,

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.
0

#17 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1468
  • Joined: 23-April 04

Posted 26 June 2020 - 02:29 PM

View PostmegaT, on 26 June 2020 - 03:08 PM, said:

Is yours fully compatible with eMule?
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

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
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.
0

#18 User is offline   Enig123 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 519
  • Joined: 22-November 04

Posted 08 July 2020 - 07:28 PM

You might want to look at Hydronode, which had the same goal until the author Madcat abandoned it without no one to take over.

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.
0

#19 User is offline   megaT 

  • Member
  • PipPip
  • Group: Members
  • Posts: 38
  • Joined: 09-May 20

Posted 10 July 2020 - 04:33 PM

Hi
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

What I mean is, writing a wonderful headless ed2k app is a tough job.

It is absolutly, its more work than I expected.. :lol:
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)
0

#20 User is offline   Campo 

  • Member
  • PipPip
  • Group: Members
  • Posts: 47
  • Joined: 18-June 19

Posted 10 July 2020 - 05:01 PM

P2P is still a big field, but in case of BitTorrent, a lot of clients arent allowed on some trackers. So the ed2k/torrent combo clients are out by default. Shareaza for example is banned often too and on top for releaser/longtimesharer not a good option.

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...
0

  • Member Options

  • (3 Pages)
  • +
  • 1
  • 2
  • 3

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users