×

Das ist ein archivierter Beitrag. Du wirst hier nicht abstimmen oder kommentieren können.

Alle 17 Kommentare

[–]MorphisCreator 5 Punkte6 Punkte  (4 Kinder)

I wrote the most advanced eMule client in java a while back, OmniP2p. Unfortunately I then got distracted by my career (combined with that my design was very complex and got to the point that OmniP2p had some bugs I couldn't figure out with my knowledge at the time).

Anyways, the ONLY problem I saw with eMule design was that the credits are not global. That was it. Meaning, that if I only have Beethoven shared for ages and go to download a Solfald track, I will more likely than not have no priority on their queue. This is because my credits are mostly with Beethoven fans, somewhat with classical fans in general, and less correlated perhaps with Solfald fans.

OmniP2p was designed from the beginning as a multi-protocol p2p client. I started with eMule with the intent to implement BitTorrent next. I finished eMule minus some bugs as mentioned - just before getting pulled into a high stress job. I kept thinking about it, Etc. I soon came to the realization that BitTorrent is flawed in its design. The OP is exactly correct!

After temporarily giving up on OmniP2p, I instead spent my time trying to fix the protocol -- instead of omnip2p itself; meaning, I put my p2p thinking into solving the global credit problem. Then Bitcoin happened. Now that the replacement for the only flawed component of eMule was out, I then pretty soon took a look at my old OmniP2p code again. It wasn't long until I chose to abandon it, and decided to go with a pure DHT design this time! This is the result: http://redmine.morph.is/redmine/projects/morphis (reddit: /r/morphis).

[–]ZapperDJ[S] 1 Punkt2 Punkte  (3 Kinder)

Oh, I forgot about the credits system. It is totally useless. Nowadays it is more a bug than a feature, as it slows down the network and contributes to endless queues. I don't think that replacing it with a bitcoin-like system is a good idea, as most of the users tend to change their UserID on the network, mainly because they don't know that they should keep their config files across reinstallations of the client. I think BitTorrent made a smart decision by chosing not to implement a credit system. Unfortunately, as the official eMule is the most used client, and it uses the credit system, making a new client without the credit system enabled won't make a difference as long as it is using the same network. What would I do if I was a developer? I would create a new client that used a new network based on the strenghts of the ed2k and torrent protocols. Then I would make it compatible with ed2k links and other types of links as DirectConnect TTH magnet links. That way it would ease the transition from other clients and networks. I wouldn't go making a multinetwork client as they usually become overcomplicated and with too much options that confuse the user. The idea is to make a client that is very simple to use and is as lightweight as possible. Chosing Java may not be the lightest option, but it has the advantage of easily covering the multiplatform issue, but I would recommend using natively compiled java packages so that the user doesn't need to install the JRE. JDownloader is a good example of this. Anyway you could always make a generic JAR package available to cover those operating systems with no native build available

[–]MorphisCreator 0 Punkte1 Punkt  (2 Kinder)

You make very good points. Regarding the credit system, I disagree that there is a fatal issue using a Bitcoin like system (assuming micro-transactions become available), since your credits can be backed up by printing out a QR code that is your private key even just once in the beginning (no need to repeat as balance changes). Then if you ever nuke your computer, you can easily recover everything with the QR code. You are correct at least in that having the system rely on credits does present the problem you raised (but implied is fatal), and thus at least some solution is needed for that problem, and thus some extra bit of work on the part of the user is likely needed in this case like the QR code example (if they want to be safe).

Therefore, it is true then because of what you say that potentially using a global credit system is -- while a great solution -- not the best possible one. I do see this potential fact and thus have looked and even see an alternative potential design. Here is the thing: While the alternative potential design might work, the global credit system WILL work. The global credit system is more complicated though, so in actuality, (and then this is good news from your stand point in regards to the credit system), the potentially workable alternative is much simpler and thus I am trying that first on the way!

Regarding how to do the next gen P2P File Share, here is what I believe and have done. First off, BitTorrent is a highly flawed design. However, it did bring one piece of genius that more than made up for the flaws: economic game theory. It brought this in the form of its direct tit-for-tit method of ensuring cooperation in a swarm. Such was very easy to implement in their flawed federated design. The tit-for-tat method is one used in many areas of P2P development. It worked really well for swarms. I am implementing a custom Kademlia that additionally uses tit-for-tat for calculating routing decisions. This solves many Sybil type issues with a P2P network. This is nothing new, Freenet is where I got the idea. I do see the likelihood that this feature I am implementing to the Kademlia layer will ultimately have the emergent property of acting as a relative credit system that ends up fulfilling the role of the edonkey one (which is incentivization) to the point that no global one (like Bitcoin) willl /need/ to be integrated for file sharing (although I will still be doing so for higher level purposes - Ie. economy to replace our current ones).

It is already usable. It is 100% python, very simple to run. An unzip and one click to run package for Windows.

Send me a Dmail: samzu1ctt7kscitkrt5jft91gtw5c (Dmail is free, encrypted, authenticated, email replacement that is pushed to the network.)

It already works fine for file sharing. There is no search yet, but TRUST ME, that is as planned as Dmail was.

Oh yes, and I plan to make MORPHiS support edonkey as well as bittorrent links in the near future.

Basically, MORPHiS is a high-performance attack (RIAA, government, Etc.) proof p2p distributed database. It is designed to enable things like a new github/facebook/twitter/slack/Etc. to be written in javascript or such and implemented using MORPHiS as its database and 'server' to run on. I had this idea long before even Bitcoin, so others doing similar things just described are late comers. The difference is that mine not just going to replace github, facebook, and slack, but it is also designed purposely (as originally) to be the successor and evolution of eMule! Thus it will always be the best file sharing client possible! It can already do file sharing quite fast, just no search yet. Check it out: https://morph.is

[–]ZapperDJ[S] 1 Punkt2 Punkte  (1 Kind)

Well I have taken a brief look at Morphis (not yet downloaded and tested) and it seems to me more like a Freenet alternative or even similar to RetroShare, because its approach is not only filesharing, but also distributed websites, forums, messaging, etc. This is not what I am looking for (too many features, and I already disliked the integrated IRC client on eMule). Let's say that I prefer the Unix philosophy of doing only one thing and doing it right, but nevertheless Morphis seems like an interesting project as well as RetroShare, and I will keep an eye on it and test it in the near future. Even if it ends up being not suitable for me, I like to see new projects with interesting approaches and see how they develop :-)

[–]MorphisCreator 0 Punkte1 Punkt  (0 Kinder)

Thanks for taking a look! I understand what you are saying. Here is how I thought to formulate then the answer that is what I'm doing: I propose that the best filesharing app possible is only possible in a system that has at least some social networking element in it; you yourself don't even have to use the social part - think searches, search data is generated by social interaction and scraped by systems algorithms, you get the benefits of a searchengine like UI on top of that data to find the results of the files you want! :)

EDIT: Another way to word it is this: You would not have much difficulty in obtaining a highly reliable answer to the question where is the nearest 7/11 in real life because you could ask around and be pointed to more and more reliable answers until it is pretty sure. The algorithm can do that for you in the filesharing system.

[–]vato76 2 Punkte3 Punkte  (1 Kind)

i still use emule 24/7. to me there is no easier way to share my collection. cant find anything i want though.

[–]ZapperDJ[S] 1 Punkt2 Punkte  (0 Kinder)

That's what I was saying, ease of sharing encourages more peers to share their files, but the protocol is inefficient, so you get low speeds, huge download queues and subpar search results. On top of that, last available version is ancient and development seems stalled

[–]interfect 1 Punkt2 Punkte  (1 Kind)

There's RetroShare, which has built-in search, hashes files individually, and lets you link to files by hash. It's also (supposed to be) friend-to-friend: you connect your node explicitly with peers you trust (or, more commonly, random people you met online who you don't distrust), and everybody forwards messages for everybody else so only your friends are (in theory) able to identify you.

[–]ZapperDJ[S] 2 Punkte3 Punkte  (0 Kinder)

Tryed it sometime ago, and found it fully bloated with useless features as channels, forums, etc. On the other hand, having to mess with certificates in order to add friends and start using the network is not what i would call easy to use. Furthermore, the F2F paradigm is quite the contrary to an open network such as ed2k

[–]rtechie1 1 Punkt2 Punkte  (5 Kinder)

There isn't one. The purely decentralized model of eMule and gnutella and similar systems has proven to perform poorly compared to the bittorrent/tracker model, for searches in particular. You can almost completely avoid trackers with DHT and magnet links, the tracker pages just "advertise" the torrent.

If you want alternatives, the main one with significant traffic is Freenet. Freenet is really slow and mostly CP (because everyone else is using torrents).

Retroshare, which is more for private sharing, has already been mentioned.

[–]ZapperDJ[S] 1 Punkt2 Punkte  (4 Kinder)

How does it perform poorly? Not having the ability to search (like bittorrent) is not an improvement over a poorly implemented search function (as supposedly eMule has)

[–]rtechie1 0 Punkte1 Punkt  (3 Kinder)

eMule's search function was slow enough to the point that you'd "miss" the vast majority of content due to indexes timing out. The short version is that distributed search doesn't work, you need a central index like a torrent tracker.

[–]ZapperDJ[S] 0 Punkte1 Punkt  (2 Kinder)

Well, maybe the approach of "asking every peer for what you are searching" doesn't work and times out, but other methods exist, like selecting the best peers and making them act as mini-indexes. I think Kazaa had this approach, with nodes and supernodes

[–]rtechie1 0 Punkte1 Punkt  (1 Kind)

Kazaa's model is also a proven failure because what counts as a "supernode" is limited by latency.

[–]ZapperDJ[S] 0 Punkte1 Punkt  (0 Kinder)

I'm not saying that Kazaa's implementation is good, I was talking about the idea of supernodes which I think is the way to go, but with a different implementation

[–]operatornormal 0 Punkte1 Punkt  (0 Kinder)

There is classified ads for linux and windows. While it is specifically not designed for leeching big files, you could use that to distribute your torrent or magnet links. In practice it is a messaging app for public and private messages and since v0.91 also includes voip feature. The useful thing in this context is functional free-text search over (subset of) nodes in the network. http://katiska.org/classified-ads/ for more details.

[–]MeneerKrabs 0 Punkte1 Punkt  (0 Kinder)

There is the Bittorrent client with decentralized search, called Tribler; https://www.tribler.org/