You cannot compress random data (statistically, one small example may work).

Huffman encoding is not recommended for game packets. They are small enough not to benefit from packing, and if you do use compression, i'd suggest a better algorithm and implementation, such as the zlib.

Quote:Original post by Basiror
lol all data is random pf

The AP's reference to the term "random data" appears to have gone right over your head. With any background in compression you would have know the APs point ahead of time. You might also have known that individual huffman compression (generation of seperate trees) for each packet is not only a waste of CPU time, but of network bandwidth as well. Look into adaptive huffman compression, which is the prefered form of huffman when transmitting seperate but sequenced units over a network. However as the AP stated, your approach is next to useless unless you intend this for compressing user text messages (in which case adaptive is still the best approach). Unless you are doing an absolute horrible job of choosing the data you send, the data is just too random (uniformly distributed between 0x00 and 0xFF) for huffman to do any good, due to the size overhead involved.

The presence of a lot of zeros means your packets are very badly constructed. This should be fixed at the packet construction phase, not by a general purpose compressor. The most likely cause is that you are using huge data types for small pieces of data (like using a 32bit integer to store a number from 1 to 10). When contructing packets you should really look at taking advantage of all space in the packet (using bit fields to place more then one piece of information in a single byte, i.e. 1 byte to store 8 bools, rather then 8 bytes) before trying general compression.

Also, 3-4KB/s is way way way too much. That will not be playable on dialup (~1KB/s upload), and even light broadband connections will sputter (there are many "light" broadband services, which offer "broadband" for about the price of dialup, usually it is 128kps up, 32kps down). What kind of game is it that you need to send 300-450 bytes per packet. My guess is that all your problems are in the design of your games network structure. You are doing something we call "premature optimization". Because of this you are optimizing the wrong part of your code, while leaving the real performance bottleneck alone. Real network games do not send that much data. That's why packet compression does little to nothing to help them, because the packets are too small (going with plain huffman, the huffman header would make the packet bigger then the original one)