Official eMule-Board: Adding Custom Tags! - Official eMule-Board

Jump to content


Page 1 of 1

Adding Custom Tags! Where are they best put?

#1 User is offline   netfinity 

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

Posted 22 December 2004 - 08:24 PM

I have noticed that Mods add the Mod string and ICS tags in both OP_HELLO and OP_EMULEINFO. To me it seems a bit overkill to send these tags twice.

My question is, where is the best place for such extra tags?

This may sound like an Mod question, but I consider it a general eMule development question as it also is valid for any extensions that may be done in future official eMule 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

#2 User is offline   bluecow 

  • The Merciful
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1772
  • Joined: 27-December 02

Posted 22 December 2004 - 09:41 PM

I appreciate your attitude very much to ask before doing anything related to this and I would wish the modders would have done also..

But, the true answer is: The best place is "nowhere"; meaning that no tags should be added at all. 90% of the tags which were added by mods are useless, a waste of bandwidth, redundant, inefficient and quite annoying. Modders tend to introduce a new INT32 tag for sending a single bit sometimes, not to mention the sending of string tags which is even worse.

If you though think that you need to add a new tag which is worth to be sent to each client (when sent with OP_HELLO) and which is worth the additional bandwidth which would be wasted in nearly 100% of all OP_HELLO packets, then use an ID near CT_MOD_VERSION. This value area is already messed up by modders, so it doesnt matter that much. However, do not use any values in the range CT_EMULE_RESERVED1 - CT_EMULE_RESERVED13. Future eMule version will use those tags. Generally you have to expect that future eMule versions will use any tag value, but in practice this won't happen. We will try to walk the value range 'downwards' from 0xFF.

Whether a tag should be sent with OP_HELLO or with some other packet depends on the tag itself and the context in which the related information is to be used by sending and/or receiving client.

As a general rule: Think twice before adding any new tag. And when you have thought twice and are still convinced that it is worth to add it, think a 3rd time about it. Do NOT use any string tags (waste of bandwidth), try to use INT32 tags and also try to use one INT32 tag for several features (like CT_EMULE_MISCOPTIONS1).

The most important things are:
*) Do not disturb any other clients.
*) Do not break the protocol in any way.
*) Try to avoid any waste of bandwidth.
0

#3 User is offline   netfinity 

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

Posted 22 December 2004 - 11:08 PM

@bluecow
Thanks for your fast and thoroughly answer.

The reason I ask is...

1. I wanted to know if there is any reason why Mod strings are sent in OP_HELLO message.
I thought of removing it from there as it feels like unnecessary overhead to send the same info everytime we reconnect to a client. It feels like redundant information. I once tried to remove enkeyDev's ICS tag from OP_HELLO, but that didn't work out well.
2. I want to relax the protocol so that unsolicated OP_FILESTATUS messages can be sent.
Reason for this is that I have made it possible in my client to keep track of part maps, file names, comments and AICH hashes for multiple files at once, so that when doing A4AF swaps this doesn't have to be asked again. In order to make it more efficient I want to let the uploader decide when to send a part map to the downloading client. Eg. to send the part map when a new part has become available, under the condition that the client is already connected.
3. I want, in the future, to add an extra opcode that allows sending sub-part maps.
Reason for this is that when there is very few sources and very many downloaders, it can take weeks to download a single part. If a part could be splitted up in 180k chunks, as with the AICH hashing system, those chunks could be shared much earlier by sending a small set of sub-part maps for a few incomplete parts. This feature is supposed only to be used in NNP situations and when the number of useful sources are very low.

My thought is that it best place to send tags, if needed, is in the OP_EMULEINFO packet as it is only sent once per session as far as I know. In extent we could check for a Mod string tag first before sending any extra tags in response.

/netfinity

This post has been edited by netfinity: 22 December 2004 - 11:09 PM

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

#4 User is offline   x4u 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 52
  • Joined: 30-September 02

Posted 24 December 2004 - 12:14 PM

Wouldn't it make sense to send CT_MOD_VERSION only within OP_HELLO but to put all mod related extra tags into OP_EMULEINFO if and only if you know by CT_MOD_VERSION that the other client can understand the extra tags at all?
0

  • Member Options

Page 1 of 1

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