Packet Compression
Hi
Can you guys point me out some compression algorithm that would be usefull for packet compression ?
All algorithms that i have found, need an header, and in consequence my packet becames bigger than smaller.
Thanks,
Bruno
June 16, 2002 09:33 PM
Per-packet compression is generally only useful for very large packets. What you can do is run some statistics over the messages you send and record from the most common to the least common, all the bytes that you send. Then you can make a table that is kept on both sides of the connection for a huffman coding (do you know what huffman coding is?). This way you don''t need to add anything extra to your headers, except maybe a 1-bit or 1-byte flag to say wether the message is compressed or not. You won''t get maximum compression on each packet, but you should, on average, end up with smaller packet sizes. Some packets may end up larger compressed however. If this is the case, you simply send the packet non-compressed. So in this way, you have a worst case that all packets are sent uncompressed (and therefore with no change in size). Best case, all packets can be compressed to a simple stream of 1-bits for each byte
.
It''s actually interesting to note that compressing in this way will actually decrease considerably the time it takes to compress a packet, because you don''t have to do the work of creating a new encoding table for each packet (ie. going through the packet and counting the occurences of each byte etc.)
An expansion on this idea is having seperate tables for seperate message types. For instance, you may have one decompression table for chat messages, and a different decompression table for...ummm....movement update messages.
As a final thought, you could have many (say 255) tables on each end. When sending, you do a full count of byte occurences (count how many times each byte appears in the message) and then choose the table that is closest (you could possibly use a hash string table to decide this) and then in your header, you have a 1-byte compression field which can be 0 for no compression, or 1-255 which denotes a compression table to use.
Hope that helps a bit.
PS. if you do a bitwise encoding don''t forget to pack out the end of the message somehow...it should be ok to remember the count of bytes (length of the message) and then only decoding this many bit-strings, and discard any leftover bits.
![](tongue.gif)
It''s actually interesting to note that compressing in this way will actually decrease considerably the time it takes to compress a packet, because you don''t have to do the work of creating a new encoding table for each packet (ie. going through the packet and counting the occurences of each byte etc.)
An expansion on this idea is having seperate tables for seperate message types. For instance, you may have one decompression table for chat messages, and a different decompression table for...ummm....movement update messages.
As a final thought, you could have many (say 255) tables on each end. When sending, you do a full count of byte occurences (count how many times each byte appears in the message) and then choose the table that is closest (you could possibly use a hash string table to decide this) and then in your header, you have a 1-byte compression field which can be 0 for no compression, or 1-255 which denotes a compression table to use.
Hope that helps a bit.
PS. if you do a bitwise encoding don''t forget to pack out the end of the message somehow...it should be ok to remember the count of bytes (length of the message) and then only decoding this many bit-strings, and discard any leftover bits.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement