Editing Mod protocol

From EMule Wiki
Jump to: navigation, search

Warning: The database has been locked for maintenance, so you will not be able to save your edits right now. You may wish to cut-n-paste the text into a text file and save it for later.

The administrator who locked it offered this explanation: site maintenance

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
= Under construction =
+
=Under construction =
 
THIS IS NOT FINAL.. feel free to edit.  
 
THIS IS NOT FINAL.. feel free to edit.  
  
 
== Introduction ==
 
== Introduction ==
  
The Modprot is needed for more clean protocol extensions by eMule modders....
 
  
The main idea is to set a bit in CT_EMULE_MISCOPTIONS2 in the initial hello packet. If that bit is set and received by an eMule mod that is capable of processing extensions, then that mod will send the options it is capable of in the response and the first client will also send back the protocol extensions it is capable of.
+
Modprot is needed for more clean protocol extensions by eMule modders....
  
'''Important:'''
+
The main idea is to set a bit in CT_EMULE_MISCOPTIONS2 in the initial hello. If that bit is set and receive by e eMule mod that is capable of processing extensions then that mod will send the options it is cabpale of in the response. and the first cleitn will also send back the protocol extensions it is capable of.
  
Clients that are not capable of processing the mod protocol (like official eMule/aMule)  will not set the mod bit in CT_EMULE_MISCOPTIONS2 and will never receive extended protocol information.
+
Important:
  
== Documentation ==
+
Clients that are not capable of processing the mod protocol(like official eMule/amule)  will not set the mod bit in CT_EMULE_MISCOPTIONS2  and will never receive extended protocol information.
  
All mod communication is to be done over the OP_MODPROT/OP_MODPACKEDPROT.
+
== Documentation ==
When a hello(answer) with a set mod bit is received the ConnectionEstablished has to be delayed. Instead of that the mod info packet with the opcode OP_MODINFOPACKET is to be sent.
+
All mod communication is to be done over the OP_MODPROT/OP_MODPACKEDPROT,
ConnectionEstablished will be triggered when the mod info packet is received.
+
When a hello(answer) with a set mod bit is received ConnectionEstablished is to be delayed, and instead the mod info packet with the opcode OP_MODINFO is ti be sent,
 +
ConnectionEstablished is to be triggered when the mod info packet is received.
 
<pre>
 
<pre>
 
A              B
 
A              B
Hello  --->    MB Set (see if ModBit is set)
+
Hello  --->    MB Set (see ModBit is set)
 
MB Set  <---    Hello Answer
 
MB Set  <---    Hello Answer
 
ConEst  <---    MInfo (Mod Info)
 
ConEst  <---    MInfo (Mod Info)
 
MInfo  --->    ConEst (call ConnectionEstablished)
 
MInfo  --->    ConEst (call ConnectionEstablished)
 
</pre>
 
</pre>
The mod info packet has to contain eMuleTags that announce the supported features. The packet is made up this way:
+
The mod info packet have to contain eEmuleTags that announces supported features:
 
<pre>
 
<pre>
 
<uint 32> tag count
 
<uint 32> tag count
Line 32: Line 32:
 
<emule tag n>
 
<emule tag n>
 
</pre>
 
</pre>
It's only allowed to use mod features it their capability was announced by both sides.
+
Only mod features are allowed to use that what was announces by both sides,
After the capability exchange via OP_MODINFOPACKET all remaining opcodes are allowed to be used by clients in any way they want.  
+
after the capability exchange all reminding opcodes > 0x01 (0x01 is mod info packet) are allowed to be used by clients in any way they want.  
 
All further communication is not part of this specification.
 
All further communication is not part of this specification.
  
 
== Protocol ==
 
== Protocol ==
  
=== Sending Hello(answer) packets ===
 
  
Setting the modbit in CT_EMULE_MISCOPTIONS2
+
=== Hello ===
 +
 
 +
Set the modbit ot in in CT_EMULE_MISCOPTIONS2
  
 
in baseclient.cpp,  void CUpDownClient::SendHelloTypePacket(CSafeMemFile* data)
 
in baseclient.cpp,  void CUpDownClient::SendHelloTypePacket(CSafeMemFile* data)
Line 69: Line 70:
 
</pre>
 
</pre>
  
=== Processing hello(answer) packets ===
+
=== Process hello. ===
 
+
Read out the modbit from CT_EMULE_MISCOPTIONS2
+
  
 
baseclient.cpp bool CUpDownClient::ProcessHelloTypePacket(CSafeMemFile* data)
 
baseclient.cpp bool CUpDownClient::ProcessHelloTypePacket(CSafeMemFile* data)
Line 102: Line 101:
 
</pre>
 
</pre>
  
== Sending hello answer and modprot info ==
+
==Send hello answer and modprot info ==
 +
 
  
 
Listensocket.cpp bool CClientReqSocket::ProcessPacket(const BYTE* packet, uint32 size, UINT opcode)
 
Listensocket.cpp bool CClientReqSocket::ProcessPacket(const BYTE* packet, uint32 size, UINT opcode)
Line 118: Line 118:
  
  
Example of SendModInfoPacket:
+
Example of sendmoinfopacket:
  
 
<pre>
 
<pre>
Line 156: Line 156:
 
</pre>
 
</pre>
  
=== Delaying ConnectionEstablished & sending the mod info packet ===
+
=== delay ConnectionEstablished & send mod info packet ===
  
 
listensocket.cpp
 
listensocket.cpp
Line 239: Line 239:
 
</pre>
 
</pre>
  
=== Processing the modinfo packet ===
+
=== process modinfo packet ===
  
 
listensocket.cpp
 
listensocket.cpp
Line 338: Line 338:
 
</pre>
 
</pre>
  
=== Processing mod data example ===  
+
=== proces mod data example ===  
 +
 
  
 
EMSocket.cpp
 
EMSocket.cpp
Line 453: Line 454:
 
</pre>
 
</pre>
  
=== Additional modifications ===  
+
=== additional modifications ===  
 +
 
  
 
Packets.cpp
 
Packets.cpp
Line 483: Line 485:
 
</pre>
 
</pre>
  
== Backward compatibility ==
+
== backward compatibility ==
  
The modstring is still send via hello(answer) packets but '''only''' if the remote client is using a mod and does not support the mod prot extension to maintain backward compatibility. Usage of CT_MOD_VERSION is proposed to move it to the mod protocol. A mod using the modbit MUST identify itself either via CT_MOD_VERSION in the hello(answer) packets or via modstring in the modinfo packet.
+
Modstring is still send and replied in hello packet to maintain backward compatibility. However a opcode for modstring will be defined for those who also want to move it to the mod protocol. A mod using the modbit MUST identify itself. (A mod that uses extensions but refuses to identify itslef CAN be considered a bad mod by some antileecher systems)
'''NOTE:''' a mod that uses extensions but refuses to identify itself will most likely be considered a bad mod by some antileecher systems
+
  
The proposed check to use would be like
+
== OPCODES==
 
<pre>
 
<pre>
void CUpDownClient::SendHelloTypePacket(CSafeMemFile* data)
+
OP_MODPROT 0x57
{
+
OP_MODPACKEDPROT 0x58
...
+
...
+
uint32 tagcount = 6;
+
 
+
if( theApp.clientlist->GetBuddy() && theApp.IsFirewalled() )
+
tagcount += 2;
+
 
+
//>>> MODPROT::Send Modstring to old mods only
+
const bool bSendModString = !SupportsModProt() && (!m_strModVersion.IsEmpty() || !m_pszUsername);
+
if(bSendModString)
+
++tagcount;
+
//<<< MODPROT::Send Modstring to old mods only
+
 
+
data->WriteUInt32(tagcount);
+
...
+
...
+
tagMuleVersion.WriteTagToFile(data);
+
 
+
//>>> MODPROT::Send Modstring to old mods only
+
if(bSendModString)
+
{
+
CTag tagMod(CT_MOD_VERSION, L"My Mod String");
+
tagMod.WriteTagToFile(data);
+
}
+
//<<< MODPROT::Send Modstring to old mods only
+
 
+
uint32 dwIP;
+
uint16 nPort;
+
...
+
...
+
</pre>
+
and similar for the info packet.
+
 
+
 
+
== OPCODE defines ==
+
<pre>
+
OP_MODPROT       0x4D
+
OP_MODPACKEDPROT 0x6D
+
 
OP_MODINFOPACKET 0x01
 
OP_MODINFOPACKET 0x01
 
</pre>
 
</pre>
  
== TAG defines ==
+
== TAGS defines ==
  
Tags used must be reserved in modprot topic at http://forum.emule-project.net/
+
Tags used must be reserved in modprot topic at emule-project.net. Source must be published withing 3 months for claiming a tag.  
Sources must be published within 3 months after claiming a tag.  
+
  
The range 0x01 - 0x1F is completely reserved.
+
A mod can claim only up to 4 tags, BUT with capabilty bit in a tag this should be MORE than enough! If you need more you are dowin something wrong probably. Note that also string tags are available that are not regulated.  
  
Tags in the range from 0x20 - 0x7E are reserved for major features, possible objections can be:
+
only tags in the rage from 0x20 (space) - 0x7e are to be used in this version of modprot.
#Modder uses too many tags (if you need more than 5 tags you are most likely doing something wrong. Note that string tags are also available - those are not regulated)
+
#Utterly useless or unimplementable feature (no other mod will ever use it)
+
#Illegal feature (should be clear)
+
  
The range 0x7F-FF is open and you can claim any free tag you want, only objection can be the usage of too many tags (e.g. someone claims to need a range from 0x80 to 0xAF).
+
TODO: add more detailded cescriptoin of these tags.  
  
 
{| style="font-size: 85%; text-align: Left;Border="1";
 
{| style="font-size: 85%; text-align: Left;Border="1";
Line 557: Line 516:
 
|MISC_PROTOCOL_EXTENSIONS
 
|MISC_PROTOCOL_EXTENSIONS
 
| 'M' 4D  
 
| 'M' 4D  
| used for full mod extensions like ICS, etc..
+
|(etc..)
| basic modprot
+
 
|-
 
|-
|MISC_PROTOCOL_EXTENSIONS2
+
|FILE_STATUS_EXTENSIONS
| 'm' 6D
+
| 'S' 53
| used for full mod extensions 2, reserved for future use
+
|(SCT, ICS, etc..)
| basic modprot
+
 
|-
 
|-
|CT_MOD_VERSION
+
|NEO_PROTOCOL_EXTENSIONS
| 'U' 0x55
+
|'N' 4E
| Modstring
+
|(NatT, NeoXS, etc.. by david xanatos)
| basic modprot
+
 
|-
 
|-
 
|KAD_EMULE_BUDDYID
 
|KAD_EMULE_BUDDYID
 
| '@' 40  
 
| '@' 40  
| [[NatT_protocol|NatT]]
+
|(for NatT by david xanatos)
| David Xanatos
+
 
|-
 
|-
 
|XS_EMULE_BUDDYIP
 
|XS_EMULE_BUDDYIP
 
| 'B' 42  
 
| 'B' 42  
| [[NatT_protocol|NatT]]
+
|(for NatT by david xanatos)
| David Xanatos
+
 
|-
 
|-
 
|XS_EMULE_BUDDYUDP
 
|XS_EMULE_BUDDYUDP
 
| 'b' 62  
 
| 'b' 62  
| [[NatT_protocol|NatT]]
+
|(for NatT by david xanatos)
| David Xanatos
+
 
|-
 
|-
|NEO_PROTOCOL_EXTENSIONS
+
|CT_MOD_VERSION
|'N' 4E
+
| 'U' 0x55
| etc.
+
| Modstring. Modstring MUST be sent either in hello OR Modprotocol (note that sending it in mod protocol is not backward compatible)
| David Xanatos
+
|-
+
|NEO_PROTOCOL_EXTENSIONS2
+
|'n' 6E
+
| reserved for future Neo features
+
| David Xanatos
+
 
|-
 
|-
 +
 
|}
 
|}
 
 
* MISC_PROTOCOL_EXTENSIONS:
 
 
  [bit 1]  // Unsolicited Part Status (idea from netfinity, allows our client ro recieve filestatus at any time)
 
  [bit 2]  // LowID UDP Ping Support (notifyes a fix form xman1 that  allow the remote low ID to use udp reasks)
 
  [bit 3]  // [[Mod_Multi_Packet#ICS|ICSv2]] New Official Version
 
  [bit 4]  // UDP Mod File Status*
 
  [bit 5]  // [[NatT_protocol|NATT]] - [NatTraversal], [[NatT_protocol#XS Callback|XSB]] - [XSBuddy], [[NatT_protocol#Port Reporting|RPT]] - [ReuseTCPPort]
 
  [bit 6]  // [[NatT_protocol#Neo XS|NXS]] - [NeoXS]
 
  [bit 7]  // [[CommentsV2|SF comments v2]]
 
  [bit 8]  // [[Mod_Multi_Packet#SCT|SCT]]
 
  [bit 9]  // [[L2HAC|L2HAC]]
 
 
 
<nowiki>*</nowiki> The UDP Mod File Status bit is not only used for ICS but used in general. It also tells whether Mod Multi Packet with extended mod status should be sent over UDP or not.
 
  
 
== See also ==  
 
== See also ==  
  
 
References to emule protocol...
 
References to emule protocol...
[[category:Mod_protocol_extensions]]
 

Please note that all contributions to EMule Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see EMule Wiki:Copyrights for details). Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)
Personal tools