Revision as of 22:20, 19 July 2007

Mod Multi Packet Specifications

The mod multi packet is designed as a default container for file Reask related data’s, like ICS or SCT. It can be sent over TCP as well as over UDP. It is in the new mod prot optionality but it is strongly recommended to use it to save overhead and have a larger opcode pool available.

The TCP multi Packet(Answer) have the following format:

[hash128 16]               // FileHash
Entries till data end:
[uint8 1]                  // Sub Opcode
[uint16 2] len             // entry length
[data]                     // content
Next Entry:
...

The TCP packet is sent imminently after the normal eMule Multi Packet, the answer is sent when the mod multi packet is received.

The UDP packet is similar but it does not have the file hash on the top, because it is not sent together with the file reask ping bus as an answer on the "File Reask Ping Acknowledge".

The Extended 4 way file reask ping looks like following:

A                 B
FR_PING    --->                   // this step may be done over a Kad buddy !!!
          <---    FR_PING_ACK
MOD_MP     --->
          <---    MOD_MP_ANS

This way was chosen because it allows sending the Mod Multi Packet also to Low ID clients without using the Kad Buddy.

The UDP multi Packet(Answer) have the following format:

Entries till data end:
[uint8 1]                  // Sub Opcode
[uint16 2] len             // entry length
[data]                     // content
Next Entry:
...

Mod Multi Packet Applications

ICS v1/v2

ICS Extends the regular chunk status with the status of incomplete chunks, it sends a separated status bit field listing chunks that are incomplete but not empty. This is use full for Intelligent Chunk Selection as well as for release related features (v2).

The ICS informations should be accepted in every Multi Packet because all 4 variants should use the same parsing function.

The mod multi packet entry for ICS and other Part based status informations shell have the following format:

[uint16 2] count          //PartCount
[bitField count/8]        // bit encoded status informations

Protocol v1

The v1 version sends the informations only in file request answers over TCP, it don't sent them over UDP and it also don't sends them to the source on a file request.

Protocol v2 (Neo)

The Neo v2 extension enables sending of the status informations over UDP and in file request. The purpose of sending the data in file request is to allow the releasing clients have a better overview witch parts are needed as well as don't apply part hiding for a particular client on parts that he have incomplete.

SCT

The Sub Chunk Transfer feature is mainly only a block status exchange it is sent in file reask answers associated, mod multi packets, not in file requests associated ones, but it can be handled in booth.

The mod multi packet entry for SCT have the following format:

[uint16 2] count        // Map Count
// block maps for selected parts
[uint16 2] part		// part number
[bitField56 7]          // [bits 1-53] block status
                        // [bits 54-55] reserved
                        // [bits 56] determines if the map contains verified blocks
// next map

Appendix

OpCodes

• OP_MODMULTIPACKET 0x11
• OP_MODMULTIPACKETANSWER 0x12
• ET_INCOMPLETEPARTS 0x3D