Gnutella and eDonkey Networks SUCK!!!

[MkII]

Sorry, deliberately put that there to get your attention…

Ok to start off, what I’m finding is that the Gnutella and eDonkey Network’s can get allot of sources fast but you cannot seem to download from anyone. The obvious reason is that allot of former K++ users or maybe users in general are mostly ‘tight-fisted-file-sharers’ (RIAA?).

I’ve tested all mainstream and allot of none mainstream Windows based Gnutella and eDonkey clients and every one of them (including spyware-spamware clients) have the option to reduce your upload speed to nothing.

In order to make this a success in its entirety uploading should stay ‘permanently ‘on. Of ‘course you should have a restriction on how fast you want to upload but it should be no less than ‘6 kilobytes’ (not bits) a sec (just an approximation). For connections that upload slower than 6K a sec will have to upgrade or put up with it. I’ve also thought that having a credits system is a bad idea for the potential reason that computers always screw up, there for you could loose all your points (frustrating)!

A small feature like this would make these networks allot more popular than the Sharman network, as you would be able to actually get a good download speed and fast. I do like the fact that users can dynamically download bits of the uncompleted download from other users on various clients it has allot of potential!!!

BTW, I think developers from competing clients could get together to discuss ways of beating Sharman, especially - mute-net.sourceforge.net - this one would get the RIAA and the MPAA off our backs for a long time.


Note: This message has been sent to forums where it would reach out to developers and file sharing enthusiasts on net. Feel free to express any further ‘CONSTRUCTIVE’ opinions.. :type:

[vernarial]

Hey MKII, welcome, and very good post. I agree that people need to allow a certain amount of bandwidth for uploading. But the reason why you can get alot of sources for a file, and not get a download started is because of the queue. I'm not sure about the credit system, but here is some documentation on it. Credit system (http://www.emule-project.net/faq/)
It sounds to me like people who do upload can move up in the queue line faster than those who don't. The key to getting any decent downloads with eDonkey is to stay connected for long period of time, so you can work your way up in the queue. Currently I've gone over to Shareaza. It allows you to connect to a few different clients at once(including Gnutella 1 and 2, eDonkey, and bit torrent). I like their idea of trying to join the different factions of the file sharing community.

[MkII]

I use Shareaza (http://www.shareaza.com/) as well, I love all the features except the points I described.

Would be good if all compeating developers chose a date to get together and find a way to beat FastTrack. Mute definitely have the right idea of knocking off the RIAA and MPAA... :hammered:

[lordpake]

Also emule-clients have a built in ul:dl-limit, 1:3 I think so you most certainly need to upload stuff before your client starts to work properly. IMHO this is good, does minimize the number of leeches found in the network :) ed2k is about being connected for days and weeks ( queue system ) and most of the time uploading more than downloading...

My current cumulative ul:dl ratio is at the moment 5.14:1 but then again I have 1Mb/512kb line...never actually dl'ed with full bandwidth ;)

I use eMule to take full benefit of the credit system, since Shareaza to me knowledge does not store client data as emule.

[Project-Buckfast]

I like emule but I find it very "un user-friendly". If they had a P2P application such as kazaalite K++ I would use it more often, unfortunatly they dont so I only use it when I cant find what im lookin for on kazaa K++

Is it possible to mess around with the code of kazaalite K++ and make it use different P2P networks???? I think not, but it would be a good thing!! :hammered:

[Fister]

In the words of the illustrius Lion7718

Bit Torrant :hammered: Bit Torrant :hammered: Bit Torrant :hammered: