Official eMule-Board: Protocol Enhancements - Howto? - Official eMule-Board

Jump to content


  • (20 Pages)
  • +
  • 1
  • 2
  • 3
  • Last »

Protocol Enhancements - Howto? Which opcodes to use?

#1 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Post icon  Posted 12 May 2006 - 10:07 AM

As some ppl are interested in my feature request here I started to code it...

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
0

#2 User is offline   bscabral 

  • "Dream" member
  • PipPipPipPipPipPip
  • Group: Members
  • Posts: 339
  • Joined: 25-December 02

Posted 12 May 2006 - 01:04 PM

I think that NeoMule already find a way to do it, maybe you should check NEomule code to see what they do
IPB Image
IPB Image
0

#3 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 12 May 2006 - 05:16 PM

Yes I know that they found a way but that doesn't answer my question.... as said I could use a nametag or some unused opcode but I will most likely end up being banned and I want to avoid that right from the beginning...
0

#4 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 12 May 2006 - 10:18 PM

I already propsed that some eons ago.
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.
The problem is not the client, it's the user
0

#5 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 13 May 2006 - 09:43 AM

Hmmm in this case I think we should keep this topic on top to gather more opinions and/or feedback... it's just not funny to not being able to implement something because you have to fear getting banned/punished...

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

#6 User is offline   Avi-3k 

  • hebMule [retired] dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1127
  • Joined: 25-June 03

Posted 13 May 2006 - 08:29 PM

hi all

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
retired developer of hebMule and eMule Skinner...
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).
0

#7 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 13 May 2006 - 10:12 PM

This thread isn't a feature request .. this is one of Wizards flamewar.
"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.
0

#8 User is offline   PacoBell 

  • Professional Lurker ¬_¬ (so kyoot!)
  • PipPipPipPipPipPipPip
  • Group: Moderator
  • Posts: 7296
  • Joined: 04-February 03

Posted 13 May 2006 - 10:13 PM

Avi-3k, on May 13 2006, 01:29 PM, said:

such a system will
highly reduce bandwidth, and make is easier to detect bad opcodes.
View Post
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? :huh:
Sed quis custodiet ipsos custodes
Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!

#9 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 13 May 2006 - 11:19 PM

Substituting the mod string with a 32 bit identifier cannot really be seen as a way to "highly reduce bandwidth".

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.
The problem is not the client, it's the user
0

#10 User is offline   birk 

  • Room To Let
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5524
  • Joined: 23-May 03

Posted 14 May 2006 - 01:22 AM

Trying to find the best smilie here but I have come up short. Without knowing the internals here it sounds like you are trying to start a flame here xman and no one else. To me this sounds like a legitimate question.
0

#11 User is offline   Avi-3k 

  • hebMule [retired] dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1127
  • Joined: 25-June 03

Posted 14 May 2006 - 07:50 AM

@Paco
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
retired developer of hebMule and eMule Skinner...
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).
0

#12 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 14 May 2006 - 08:34 AM

@Avi-3k
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.
0

#13 User is offline   tHeWiZaRdOfDoS 

  • Man, what a bunch of jokers...
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5630
  • Joined: 28-December 02

Posted 14 May 2006 - 08:53 AM

Xman you got it totally wrong (again).
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

0

#14 User is offline   Avi-3k 

  • hebMule [retired] dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1127
  • Joined: 25-June 03

Posted 14 May 2006 - 01:29 PM

@Xman
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

retired developer of hebMule and eMule Skinner...
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).
0

#15 User is offline   Devil Doll 

  • feature request writer
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2570
  • Joined: 19-February 04

Posted 14 May 2006 - 03:40 PM

tHeWiZaRdOfDoS, on May 12 2006, 11:07 AM, said:

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.
Sounds perfectly reasonable to me, although I consider the bandwidth saving rather marginal.
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.
0

#16 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 14 May 2006 - 03:41 PM

the SNAFU-taglist hasn't changed o much during the last 2 years.. maybe it's still the same.

@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" ?
0

#17 User is offline   Devil Doll 

  • feature request writer
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 2570
  • Joined: 19-February 04

Posted 14 May 2006 - 03:45 PM

Xman1, on May 14 2006, 04:41 PM, said:

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" ?
If these encoded IDs were to be requested from and accepted by the developers then eMule might contain a module doing the translation into printable display strings. Version numbers might have to be encoded in some lossless way (which means global rules for mod version numbering, of course).
0

#18 User is offline   kabouterflop 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 67
  • Joined: 11-April 04

Posted 15 May 2006 - 04:41 AM

Xman1, on May 14 2006, 05:41 PM, said:

But if I send e.g. 1234 as mod-ident, how does the other client knows, "oh it's a Xtreme-mod" ?

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

#19 User is offline   Xman1 

  • Xtreme Modder
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1955
  • Joined: 21-June 03

Posted 15 May 2006 - 07:15 AM

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

#20 User is offline   netfinity 

  • Master of WARP
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1658
  • Joined: 23-April 04

Posted 15 May 2006 - 04:35 PM

I've made some posts about this before.

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
eMule v0.50a [NetF WARP v0.3a]
- 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!)
0

  • Member Options

  • (20 Pages)
  • +
  • 1
  • 2
  • 3
  • Last »

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