Editing Mod Multi Packet
From EMule Wiki
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 15: | Line 15: | ||
The TCP packet is sent imminently after the normal eMule Multi Packet, the answer is sent when the mod multi packet is received. | 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 have the | + | 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 but as an answer on the "File Reask Ping Acknowledge". |
The Extended 4 way file reask ping looks like following: | The Extended 4 way file reask ping looks like following: | ||
Line 29: | Line 29: | ||
Note: Support for the "Extended 4 way file reask ping" have to be announced separately in the Mod info tag FILE_STATUS_EXTENSIONS | Note: Support for the "Extended 4 way file reask ping" have to be announced separately in the Mod info tag FILE_STATUS_EXTENSIONS | ||
+ | |||
+ | The UDP multi Packet(Answer) have the following format: | ||
+ | <pre> | ||
+ | Entries till data end: | ||
+ | [uint8 1] // Sub Opcode | ||
+ | [uint16 2] len // entry length | ||
+ | [data] // content | ||
+ | Next Entry: | ||
+ | ... | ||
+ | </pre> | ||
= Mod Multi Packet Applications = | = Mod Multi Packet Applications = | ||
− | == ICS == | + | == ICS v1/v2 == |
− | ICS | + | 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 ICS informations should be accepted in every Multi Packet because all 4 variants should use the same parsing function. | ||
Line 43: | Line 53: | ||
</pre> | </pre> | ||
− | The | + | === 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 in a 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 | + | === 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 == | == SCT == | ||
Line 55: | Line 64: | ||
The mod multi packet entry for SCT have the following format: | The mod multi packet entry for SCT have the following format: | ||
<pre> | <pre> | ||
− | |||
− | |||
[uint8 1] count // Map Count | [uint8 1] count // Map Count | ||
if count == 0xff [uint16 2] long count // just in case | if count == 0xff [uint16 2] long count // just in case | ||
// block maps for selected parts | // block maps for selected parts | ||
[uint16 2] part // part number | [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 | // next map | ||
</pre> | </pre> | ||
Line 67: | Line 76: | ||
Please note that no more than 15 Maps should be sent at once due to the overhead, a recommended limit is min(15,max(5,PartCount/10)). | Please note that no more than 15 Maps should be sent at once due to the overhead, a recommended limit is min(15,max(5,PartCount/10)). | ||
The Maps are sent progressive, only when all have been sent they are resent from the begin and only on TCP, on UDP no resent is done after all maps are out. | The Maps are sent progressive, only when all have been sent they are resent from the begin and only on TCP, on UDP no resent is done after all maps are out. | ||
− | |||
− | |||
− | |||
= Appendix = | = Appendix = | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== OpCodes == | == OpCodes == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | *OP_MODMULTIPACKET 0x11 | |
+ | *OP_MODMULTIPACKETANSWER 0x12 | ||
+ | *ET_INCOMPLETEPARTS 0x3D | ||
+ | *OP_SUBCHUNKMAPS 0x8F |