Protocol Enhancements - Howto? Which opcodes to use?
#1
Posted 12 May 2006 - 10:07 AM
Now I'm almost done but lacking one thing:
How can I tell the other client that I am supporting this feature? I have to send an opcode in the hello but here's my problem:
Which opcode can I use WITHOUT getting banned as leecher/ghostmod/whatever?
Yeah that's a direct question to NeoMule/Xtreme/Morph: Would you please provide a "white list" of opcodes to use? I've not the time to check all these fancy antileecher-measurements in detail... and I don't want to run into bans/punishments like happend with NeoMules "Encryption" or the SCT of netfinity.
I know I *could* send a nametag but that would fall under "default" tag and might be banned then too and besides I don't want to waste such a lot of overhead for a simple bit!
BTW: a proposal: let's introduce a "mod-feature-tag" (like the misc-feature-tags) to combine all the information about what features (ICS/EDT/L2H/...whatever) our mod supports... would save overhead and it would provide a better overview.
Cheers,
WiZ
#2
Posted 12 May 2006 - 01:04 PM
#3
Posted 12 May 2006 - 05:16 PM
#4
Posted 12 May 2006 - 10:18 PM
None agreed in having an official list of assigned identifier one for each mod.
The idea was having a single global tag followed by the mod identifier (16 bit at least), a size byte and a payload free to be used as any modder would wish.
Maybe the search function could help you more than I can now.
#5
Posted 13 May 2006 - 09:43 AM
On the other hand I could simply use a random SNAFU tag (at least this list is available) and then ban all SNAFU supporting mods on sight... not the best solution imho...
#6
Posted 13 May 2006 - 08:29 PM
i think we should also start a system which would gather mods
from this forum (valid mods which were checked by the devs
or other respected modders of the community)
and make them compatible with each other and save bandwidth:
instead of sending a mod *string* we'll use a 32bit identifier
which will include mod name, version and maybe some bit flags
that can be used by certain mods. such a system will
highly reduce bandwidth, and make is easier to detect bad opcodes.
btw, for such systems to work, we'll need the co-operation of
all modders and probably the devs so everything will be kept
compatible for future use and changes...
Regards,
Avi3k
hebMule site and topic.
hebMule2 unique features: AntiLeech, AntiVirus, Fake Check, ServerFilter, WebSearches, Export Searches, Relative Priority, ModID and much much more...
eMule Skinner is an application to create/edit skins for eMule,
it's multilingual, supports mods, easy-to-use design, integrates to hebMule & Windows and lots more...
code fixes/improvements: #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 (to check/verify: #12, #13).
#7
Posted 13 May 2006 - 10:12 PM
"morph, Neo and Xtreme baning innocent clients, ban them, only allow my analyzer" is the thing I read between lines.
Nobody else than Wizard knows better which tags are on the blacklist. And these tags are there for years now and available in many mods. Everybody can look inside.
@Avi-3k
we don't need an other system. Most bad mods don't send a modstring.. why they should use any new identification-system ?
nothing more to say here.
#8
Posted 13 May 2006 - 10:13 PM
Avi-3k, on May 13 2006, 01:29 PM, said:
And how will you react to private mods (like mine, for example) who don't follow your good ol' boys club standards? Are you going to ban me for being different?Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!
#9
Posted 13 May 2006 - 11:19 PM
Opcodes have been "abused" to communicate the other clients what are the protocol "ehancements" that are available. The propoal here is to avoid using arbitary opcodes but use mod-related bitfields instead. So you don't have to choose a bunch of opcodes hoping other mods are not doing the same. You just need a single identifier (16 or 32 bit) and then you are free to communicate other client what you are able to to. If they can't understand you, then you are not in their supported mod/features list. However opcode mismatch is finally avoided this way.
#10
Posted 14 May 2006 - 01:22 AM
#11
Posted 14 May 2006 - 07:50 AM
it's not about banning every mod not associated with
the community or private mods, it's about better detection
of bad mods, leechers and GPL violators.
if your mod is ok, then it won't be banned...
@Xman, Ciccio, other modders
first, consider the fact that both of your mods send a rather long
modstring which causes high bandwidth (general for strings):
1 byte opcode + 2/4 byte string length + n/n*2 string length
it's a total waste especially when connected to lots of clients.
we can easily reduce this to ~4 bytes if we have a such system.
second, i/others know for a while now that we need protocol standards.
such standards will make it easier to introduce new features,
reduce bandwidth for current features and etc...
btw, you don't have to agree with me, though i think birk is right in a way.
i'd rather open a new topic about it so my idea will be more clear
and disconnect myself from this thread...
Avi3k
hebMule site and topic.
hebMule2 unique features: AntiLeech, AntiVirus, Fake Check, ServerFilter, WebSearches, Export Searches, Relative Priority, ModID and much much more...
eMule Skinner is an application to create/edit skins for eMule,
it's multilingual, supports mods, easy-to-use design, integrates to hebMule & Windows and lots more...
code fixes/improvements: #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 (to check/verify: #12, #13).
#12
Posted 14 May 2006 - 08:34 AM
we don't save much overhead and we don't detect one single leecher with a new system. Why ? Easy:
Using a Bitfield means: we send a cheap "unit" which tells the other clients what features we support... e.g. ICS, Webcache.
But how does the other client knows my modname ? I must send my modstring in any way. No matter what way I go, the string is always the same length.
Detecting leecher is also impossible with a new system why ?
Many leechers don't send any additionally Info like modstring or webcache-tags. If you introduce a new system, they don't use it and still claim to be vanilla emule.
#13
Posted 14 May 2006 - 08:53 AM
I know SNAFU though I don't agree with it however you and others "extended" it to other "known" bad opcodes that's why I asked...
Besides I like the idea of that system... you don't need to send "Xtreme v.blabla" as a string but rather an uint32 with
16 bites = mod-ident
16 bits = mod-version
(should be sufficient) and an additional uint32 for the mod-features (these should be uniformed, too, to allow others to properly detect what you're supporting)
Up2now it's a complete overkill to send one opcode for every feature PLUS it somehow scrambles the protocol as the devs might have decided to use one of them in the future... it would have been better to use nametags to avoid that but it would be even better to implement a common system so nobody has to complain about something like that again...
EDIT: stupid bits/bytes!
This post has been edited by tHeWiZaRdOfDoS: 14 May 2006 - 04:02 PM
#14
Posted 14 May 2006 - 01:29 PM
you didn't get where i'm going with it, the idea is
the same as client detection, only for mods
(by using a mod-id we can create the modstring)
this will save bandwidth, e.g: your current version "Xtreme 5.1.1"
sends 12 chars but with my system it will only send 4 bytes tops.
it will also make it easier to create standards for protocol changes.
also, i didn't say it will ban all leechers, only that it will help...
Edit: i don't know if you've notices but i'm not as active as
i was, the only reason i'm replying is that i think this is an
important matter that all modders here should discuss.
@all
btw, just to make sure everybody knows,
i'm not on anyones side in these stupid flamewars.
this is an important issue and i hope you'll all leave
your differences aside so the communy will benefit
from the changes that might happen from the discussions...
Regards,
Avi3k
This post has been edited by Avi-3k: 14 May 2006 - 01:33 PM
hebMule site and topic.
hebMule2 unique features: AntiLeech, AntiVirus, Fake Check, ServerFilter, WebSearches, Export Searches, Relative Priority, ModID and much much more...
eMule Skinner is an application to create/edit skins for eMule,
it's multilingual, supports mods, easy-to-use design, integrates to hebMule & Windows and lots more...
code fixes/improvements: #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11 (to check/verify: #12, #13).
#15
Posted 14 May 2006 - 03:40 PM
tHeWiZaRdOfDoS, on May 12 2006, 11:07 AM, said:
The organisational problem might be that someone would have to do the bookkeeping, i. e. permanently keep some documentation up to date so that any arbitrary modder would be able to implement a new feature flag using the next available bit of this bitstring without reasonable danger of colliding with some other modder doing the same at the same time. Seems to require some organisational "transaction mechanism" as well as some procedure as when to accept a new feature flag and when to reject it (by this documentation maintainer who has to be available semi-permanently as not to delay/block mod development by hanging requests); modders whose flag request was rejected would then have to use fancy opcodes or whatever as they have to do now.
Maybe you should ask the modders in question which flags they would request for their current releases, and form a starting list of flags (to find out the current degree of compatibility amongst them). Adding some statistics mechanism about the relative bandwidth savings quota by this protocol change would be easy to implement by tHeWiZaRdOfDoS, I guess (and can be implemented already even without the actual change being implemented anywhere, although Wizard's mod would then probably report the effect on outgoing traffic only) - and we would then be able to see whether the savings were infact significant or not.
Unresolved bugs in MorphXT (as of v8.13): Sorting search results by "Known" column, Sorting "Files" page by "Transferred Data" column
#16
Posted 14 May 2006 - 03:41 PM
@Avi3k
of course, sending a uint32 is cheaper than the modstring. But if I send e.g. 1234 as mod-ident, how does the other client knows, "oh it's a Xtreme-mod" ?
#17
Posted 14 May 2006 - 03:45 PM
Xman1, on May 14 2006, 04:41 PM, said:
Unresolved bugs in MorphXT (as of v8.13): Sorting search results by "Known" column, Sorting "Files" page by "Transferred Data" column
#18
Posted 15 May 2006 - 04:41 AM
Xman1, on May 14 2006, 05:41 PM, said:
IMHO using mod strings amounts to solving the wrong problem in the wrong place. It shouldn't matter what mod you are using, but what protocol extensions your mod supports. The only solution to this is some form of protocol management. The authority for this could be the EPB (eMule Protocol Board ).
#19
Posted 15 May 2006 - 07:15 AM
I thought I get this answer.
And know the inversion of the argument:
if we need the modstring only for protocol extensions, why do we send it, if we don't use any additionally extension ? (e.g. Xtreme doesn't use any extension).
The modstring was never introduced to work with / show any protocol extensions.. it's simple purpose is to show the other clients the name of the mod.
#20
Posted 15 May 2006 - 04:35 PM
Check this post and this!
One way to handle string based MOD tags without making to much unnecessary overhead is to put extra tags within a new OP_MODINFO opcode that will only be sent if the OP_HELLO contained a MOD string. That way we want send any odd tags to official clients.
/netfinity
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)