SMSG_COMPRESSED_MOVES

[xex]

Буду благодарен если кто-нибудь выложит любую информация по этому опкоду. Для 3.3.5. Хочется пожамкать трафик

[zergtmn]

packet.Unpack();

while(packet.remain())
{
    byte length;
    Opcode opcode;
    packet >> length;
    packet >> opcode;

    Packet pkt(opcode, packet.GetDirection());
    pkt.SetContents(packet.ptr(), length - 2);

    m_buffer << "Opcode: " << opcode << '\n';

    ProcessPacket(pkt, false);

    packet.skip(length - 2);
}

[xex]

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

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