Protocol Enhancements - Howto? Which opcodes to use?
#21
Posted 18 May 2006 - 07:03 AM
I think, as long as we send a nick we can also send our mod string.
The improvement to be done is to sent our mod string only to mods that displays it and not to the official clinet. We can do it in the following way, we sends it on the first connection and if the hello answer we recives does not contain a mod string we will not send it to the client in the future anymore.
Numeric mod identification is to time intensive, and if a new mod appears all modders must update thair mods, to show the proper mod string, and conflicts between ID's will also be a problem.
To solve the problems we can use a extern universal (readable by all mods), mods.dat file that associate the names to the id's.
For the protocol extensions, i don't think that using common bit maps is a good idea, the comfilct potential is to high.
David
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
#22
Posted 18 May 2006 - 09:09 AM
Quote
that's the way Xtreme does (Code and idea from morph)
#23
Posted 18 May 2006 - 06:25 PM
Take an allround mod for example with
- ICS
- EDT
- L2H
- SCT
...
EVERY feature will use a separate tag and an integer!! Just to send "1" for "I support it"!!
#24
Posted 18 May 2006 - 11:20 PM
David is right: As long as we send nicknames we can send a mod name, too. Please, no integer for that. I'm too lazy to permanently update a map of mod integers and I guess I'm not alone. Also, no one needs the bureaucracy of a central managed database or something like that. Who should be the "management department" and what about modders who don't care about a registry database? A periodic updated .dat file costs traffic, too. It would be a farce.
Just my 2 Cents...
Edit: My 1,5 year overall statistics says, I had a traffic of about 150 Gigabytes and an overhead of about 5 Gigabytes. That's a 3% overhead, I can perfectly live with it. How much we could save with your proposals? Not more than a quarter percent, I guess.
This post has been edited by BuG: 18 May 2006 - 11:54 PM
#25
Posted 18 May 2006 - 11:58 PM
BuG, on May 18 2006, 04:20 PM, said:
Math is delicious!
MmMm! Mauna Loa Milk Chocolate Toffee Macadamias are little drops of Heaven ^_^
Si vis pacem, para bellum DIE SPAMMERS DIE!
#26
Posted 19 May 2006 - 08:44 AM
#27
Posted 19 May 2006 - 08:51 AM
BTW - there are currently enough tags left for use. It's not so exigent.
This post has been edited by BuG: 19 May 2006 - 08:54 AM
#28
Posted 19 May 2006 - 09:00 AM
About compatibility: how 'bout that:
- send the NEW tag(s) only
- if old tags are received then send the old tags in the reply
This would reduce the cost for 4 features from (4*1)+(4*8) bytes = 36bytes down to 1+8 bytes (1 for the opcode and 8 for the int) that's a 75% gain.
This post has been edited by tHeWiZaRdOfDoS: 19 May 2006 - 11:04 AM
#29
Posted 19 May 2006 - 09:13 AM
Ok, it's the same thing with the tags at the moment and as we know that's not really best. So some kind of managing the tag or the tags would be necessary.
#30
Posted 19 May 2006 - 09:17 AM
Right now it's the same bureaucracy (should be bureaucrazy - what an awful word to type!) as one must inform himself about the whole banning scenario plus the used tags list... it's NOWHERE to be found (maybe the wiki would prove useful... I guess when I've collected the info I'll type it down there)
#31
Posted 19 May 2006 - 09:36 AM
tHeWiZaRdOfDoS, on May 19 2006, 11:17 AM, said:
Right now it's the same bureaucracy (should be bureaucrazy - what an awful word to type!) as one must inform himself about the whole banning scenario plus the used tags list... it's NOWHERE to be found (maybe the wiki would prove useful... I guess when I've collected the info I'll type it down there)
I created a stub for you....
http://www.fileshari...col_Information
Please keep a neutral point of view there.
Trouble connecting to a server? Use kad and /or refresh your server list
Strange search results? Check for fake servers! Or download morph, enable obfuscated server required, and far less fake server seen.
Looking for morphXT translators. If you want to translate the morph strings please come here (you only need to be able to write, no coding required. ) Covered now: cn,pt(br),it,es_t,fr.,pl Update needed:de,nl
-Morph FAQ [English wiki]--Het grote emule topic deel 13 [Nederlands]
if you want to send a message i will tell you to open op a topic in the forum. Other forum lurkers might be helped as well.
#32
Posted 19 May 2006 - 10:03 AM
#33
Posted 19 May 2006 - 10:32 AM
Quote
hm.. my ints have only a size of 4 Bytes
#34
Posted 19 May 2006 - 11:34 AM
Maybe a dev could check the thread and propose a "mod_feature_tag" or something so we could stay compatible and won't disturb official clients...
EDIT: argh...
Maybe that's right... however just tell me what to do in my case... I want to create a new feature and HAVE to tell others that I support it...
I could re-use the existing flags but then I'd loose the ability to allow others to view my shared files
#35
Posted 19 May 2006 - 11:35 AM
To demystify all thing that have been said above.
Overhead created by modstring is a billion less than the overhead created by ip protocol du to not optimized ip fragmentation and a trillion less than silly feature like dropping feature...
If the overhead is realy the main factor for you:
- just stop implementing additionnal feature that use ip protocol
- concentrate your power into an enhanced source exchange (no new opcode needed and great chance to reduce overhead).
And finaly there is realy many other thing to do than implement other extended protocol.
[edit]sorry though you were not going to post.
Well do what ever you want.
But don't expect official dev to provide you any kind of answer.
I think they got enough headache to provide backward compatibility for their feature, so i'm sur they will not support any other kind of extended flag just to support few mod.[/edit]
This post has been edited by SiRoB: 19 May 2006 - 11:41 AM
#36
Posted 19 May 2006 - 11:35 AM
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.
Dark Lord of the Forum
Morph your Mule
Need a little help with your MorphXT? Click here
#37
Posted 19 May 2006 - 08:59 PM
What makes ABOSLUTELY no sense is that people that don't support a feature keep getting tons of tags taht the client can't process. And that's something I see every day on my side. There are features aMule has that your mods doesn't, i.e., but they only get sent to aMule clients, to avoid disturbing the network.
And please don't start the overhead-is-only-a-3% talk, because ANY overhead is lost data for EVERYONE. Tehre are other overhead factors? sure. Does that mean we must ignore the parts we can easily fix? I don't think so.
Minister of Strange Operative Systems and Sarcasm (S.O.S & S) in President Birk's New World Order
#38
Posted 20 May 2006 - 05:55 PM
eMule Antares vs Sundawner 1.1b12 & LCT - little CPU-Tool v1.40
eMule AvS use Clientanalyzer & Antileech
Greats to Wizard for its assistance for some problems
Links:
AvS Mod AvS Website
Howe is Member of Nabu nabu.de
#39
Posted 20 May 2006 - 06:14 PM
[OT INFO]
Not only that David introduced lots of nonsense additional tags without asking a dev, he also introduced a bunch of opcodes which can't be used now... and with which I get spammed regularly, that is, like Kry said, really really bad behaviour!
However it continues! He also "enhanced" ICS to v2 without asking all other modders using that old enkeydev feature! He also misused the ICS opcode for SCT... we can't use the upper bits for something useful anymore now...
That leaves us 2 choices: adapt or send it to trash - really nice...
[/OT INFO]
This is exactly what I want to prevent! No, what I want is to stay compatible if possible and by any means necessary!
However I have to check what Netfinity did to avoid that problem... I hope he's not abusing any tags, too... will update soon!
#40
Posted 20 May 2006 - 06:43 PM
1. Create a new tag, with a string name describing your feature. It's value can be anything, doesn't really matter. An integer version number(1 for first revision, 2 for second, etc) would work pretty well.
2. Add code for sending and receiving said tag in the hello packet. It would be fairly similar to the modID code, with slight exceptions. Doing this should not get you banned. Any mod that bans string-named tags will probably hit the report rule violations immediately.
3. Utilize the protocol with any client sending said tag. That is, if the tag is received, send the messages for the given protocol, and receive them. If the tag was not received, and you receive a message with an opcode matching the protocol, you should ignore it none-the-less and treat it as an unrecognized opcode.
4. Once the feature has matured and tested, and the final protocol is decided, go to the mod forum and query for the availability of single-byte opcodes for both the feature's tag and the protocol opcodes. That is, offer numbers, and modders will say if they collide with their own features. Once you find a free opcode, replace the tag names and opcodes in your feature as appropriate, and release it.
SlugFiller rule #1: Unsolicited PMs is the second most efficient method to piss me off.
SlugFiller rule #2: The first most efficient method is unsolicited eMails.
SlugFiller rule #3: If it started in a thread, it should end in the same thread.
SlugFiller rule #4: There is absolutely no reason to perform the same discussion twice in parallel, especially if one side is done via PM.
SlugFiller rule #5: Does it say "Group: Moderators" under my name? No? Then stop telling me about who you want to ban! I really don't care! Go bother a moderator.
SlugFiller rule #6: I can understand English, Hebrew, and a bit of Japanese(standard) and Chinese(mandarin), but if you speak to me in anything but English, do expect to be utterly ignored, at best.