Ru-MaNGOS - SMSG_COMPRESSED

Спасибо. Т.е. получается как-то так (набросок структуры):

Код:

struct CompessedPacket

{

   byte   lenght; // length of packed data

   uint16 opcode;

// packed data

};



WorldPacket data(SMSG_COMPRESSED_MOVES, 4+compressedSize);

data << uint32(compressedSize); // or uint16?

data.append(compressedData);

SendPacket(&data);

А какие опкоды можно паковать? Информации в инете 0-ль. Теоретически все SMSG_MOVE_XXX.

Вот нашёл только:
{Server} SMSG_COMPRESSED_MOVES (0x2FB) of 65 bytes
Compressed moves packet, original size is 65, inflated size is 94
Bytes requested to be read: 54 bytes.
Got opcode id: MSG_MOVE_TELEPORT (0x00C5)
Bytes requested to be read: 38 bytes.
Got opcode id: MSG_MOVE_FALL_LAND (0x00C9)

Вот у кого реализовано: http://static.tauri.hu/svn.php
"Compressed update data more effective low bandwidth users happy and less traffic"
но svn приватный =(

-----------------------------------------------------
Добавлено. Оказывается гайды тоже паковать можно:
Now that we know why packet parsing is a cool method in itself lets discuss some basics of the way Blizzard segregates their packets. Once you obtain a pointer to the stored decrypted packet location the next thing you need to figure out is:
A) What type of packet are you looking at?
B) How big is the packet you are looking at?

The first 4 bytes of any packet answer these very questions:
First 2 bytes (unsigned short) is the packet Type (maps to the list I posted above)
Next 2 bytes (4 bytes for Client -> Server packets it seems like) is the packet size

Common Blizzard Shortcuts
There are two main shortcuts blizz takes inside their packets... both are based on using bit-masks to aid in compressing some of the information inside the packets.
1) Blizzard often (not always) will bit-mask the GUID of the object the packet is in reference to. GUIDs as you know are 64-bit (8 byte) values. There is a convention that they follow which can help filter down the type of object you are looking it simply based on the 2 highest bytes in a GUID:

Код:

0x4000 -- items and containers

0x0000 -- players

0xF110 -- game objects (mines, herbs, treasures, etc.)

0xF120 -- transport objects 

0xF130 -- units (npcs)

0xF140 -- pets

0xF100 -- dynamic objects (fireballs as per mage spell)

0xF101 -- corpse objects

0x1FC0 -- mobile transports

Now, because of this convention there is a lot of 00 bytes in most GUIDs. For example a player GUID is something like:

Код:

0x0000000000624581 -- as uint64_t

81 45 62 00 00 00 00 00 -- as 8 bytes in packet

For an item it could be something like:

98 95 73 FF 00 00 00 40 -- as 8 bytes in a packet

So blizzard packs the GUIDs removing all 00 as part of the packing algorithm and pre-pends a masking byte. As a result the 8 byte packet GUIDs from above would look like this:

Код:

07 81 45 62 - player

8F 98 95 73 FF 40 - item

The way to understand the masking byte is to think of it in binary:
8F - 1 0 0 0 1 1 1 1 - these represent the 8 bytes in a guid
As your read each byte after the mask you put in the location represented by a "1", as you go right-to-left in the above binary string, if you encounter a "0" in the binary string you just pad in a 0x00 byte into the GUID.

и т.д. Источник (полная статья) http://www.gamedeception.net/threads...iffing-Parsing