Ability to not compress a packet

[jack9267]

I noticed enet has a flag for if a packet is compressed. I have a packet that is already compressed and optimised as much as it can be so I don't want it compressed. Can you possibly implement a packet flag to avoid compressing it?

ENet's protocol already handles a flag for if a packet is compressed when sent so this should be quite easy to do.

[bjorn]

The default behavior of ENet is not to compress packets. So if you don't want compression, just don't call enet_host_compress_with_range_coder (which would set the default range coder) and don't call enet_host_compress with a custom ENetCompressor.

The ENET_PROTOCOL_HEADER_FLAG_COMPRESSED is only used on the receiving end, to check whether it will need to decompress the incoming packet. The flag will never be set, if the sender didn't set a compressor.

[jack9267]

I wanted to write a better explanation.

Basically ENet checks the flag ENET_PROTOCOL_HEADER_FLAG_COMPRESSED to know if it needs to decompress the packet. So this means the compressor needs to be registered always (otherwise it can't decompress packets with old clients if I suddenly stopped using the compressor). But you can simply not compress packets at all by faking the compressor and making the compress function simply return 0 (this is a bit hacky but means it can at least still decompress packets from older clients).

In the ideal world we could hint to enet and have an extra packet flag like ENET_PACKET_FLAG_NO_COMPRESS or some other name that would be read before the compress function is actually invoked to simply just not compress it (same logic if calling compress yields a larger size). This is only an efficiency improvement as if you are sending data already compressed it would tell enet not to bother trying to compress it in the first place. Obviously in the current state it would try compressing it, then realise it's likely larger and then skip compression anyway but thats a waste of CPU time trying to compress the large data only to throw that away realising it got larger anyway when I could have told enet that in the start!

My only other option is to make a dummy compressor that doesn't support compressing but allows decompression and manually compress the packets myself but it's far less hacky if enet could just support a packet flag to ignore compression and other people may benefit from this.

[lsalzman]

This is complicated by the fact that compression does not operate on user packets, but rather on overall protocol packets, which may contain multiple packets and commands of various origins.

It is unclear whether that would require any single no-compress packet blocking compression of the entire packet, or some such scheme.

[jack9267]

This is complicated by the fact that compression does not operate on user packets, but rather on overall protocol packets, which may contain multiple packets and commands of various origins.

It is unclear whether that would require any single no-compress packet blocking compression of the entire packet, or some such scheme.

Oh the compression basically operates on chunks sent out I guess where user packets could be split up other combined packets anything until the MTU I guess?

Maybe my best option for compatibility is just disabling compression entirely but keeping the decompression working (for old servers/clients that still has the compression enabled) and I simply manually compress the data if needed before hand.