Welcome to xMule: A P2P Client derived from eMule BerliOS Developer LogoSourceForge.net Logo


Links
- Visit the Forums!
- SF.net Project Page
- xMule Screenshots

Modules
· Home
· Content
· Downloads
· Recommend Us
· Search
· Statistics
· Top
· Topics
· Your Account

Who's Online
There are currently, 2 guest(s) and 0 member(s) that are online.

You are Anonymous user. You can register for free by clicking here

 
The comments are owned by the poster. We aren't responsible for their content.

No Comments Allowed for Anonymous, please register

Re: xMule 1.8.3 Released (Score: 1)
by HopeSeekr on Sunday, July 11 @ 09:53:10 CDT
(User Info )
First of all, there is no *one* group that is totally to blame.

Secondly, xMule in the past would upload to any one, even if they had bad packets for *advanced* features, as long as they conformed to standard ed2k protocol. This is sane and prevented xMule from being a leech even if/when the protocol was extended...Historically this has been proven true.

Third, eMule 0.4x code does not upload to clients that have bad packets for *advanced *optional* features, even tho these features are EXTENSIONS of the ed2k protocol and don't in and of themselves prevent the upload from occurring. At the same time, eMules will blindly continue downloading from the same clients they refuse to upload to, instead of stopping both the moment one fails, as xMule does.

Fourth, eMule modified the core ed2k protocol, did not tell xMule of these changes, gave the changes to aMule, banned clients that do not support the new changes correctly (because we were not aware of all their minutae due to nondisclosure!!) and then caused a fuss when I asked for the information.

Simply put, if you are going to extend the protocol *at*least* one of three things, hopefully all, must be adopted:
* You must tell *all* known ed2k client devs (via email listserv preferably) about the new changes *before* you release the client, to allow the developers to make their clients compatible for your release.
* You must make the handling of the extensions very robust, so as not to -- say -- simply leech from clients that do not adequately support them. We all make mistakes :-)
* You must notify INDIVIDUAL clients that an error occurred, and not just report it to your user's own log as eMule and xMule currently do...so that no one will have to guess why a client seems to be not working with another.

These are commonsensical enough. Things are done this way already in other opensource network systems.

Since ed2k is a varied net with many clients and eMule is the by far the biggest player, the reason *none* of the above have been implemented by them represents a general unwillingness to cooperate with other projects on a universally standard un-biased manner, which being such a huge percentage of ed2k necessarily implies for the contiguity of the network.


| Parent


PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL.
PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.07 Seconds