The 1.3 edition sounds excellent, Lee - it already includes three
wanna-haves for me. =)
I've tried catching up on range coders using a Wikipedia article, but
I have to admit that the inner workings are entirely unclear to me. :(
So I'll go with some questions I think I can handle the answers of:
1. What's the minimum size for a packet for this kind of compression
to become effective?
2. What kind of data is best compressed with it?
3. Is there a size penalty for attempting to compress data that can't
be compressed?
4. Do I understand it correctly that the hosts must be set for
compression on both ends of a connection for this to work correctly?
Or are compressed packets somehow flagged so Enet 1.3 can recognize
and decompress them when coming in?
5. Wouldn't it have been more convenient to decide compression per
packet (in which case packets *would* need to be flagged, of course) ?
I expect there is little sense in compressing very small packets
especially because there may be overhead in terms of size and
processing...
Thanks!
Martin
Quoting Lee Salzman <[email protected]>:
On packet sizes under ENet's default MTU (1400), the range coder beat
gzip almost all the time, and was faster to boot. Of significant note
is that I made the range coder table-less, i.e. it requires no
initializing of any tables at all before compressing a packet, and
never does any allocations at all and operates within a small fixed
amount of memory. I wanted to avoid any setup/teardown time per packet
that would have detracted from performance.
Lee
Philip Bennefall wrote:
Hi Lee,
Thank you very much for all the time and effort you are putting
into this library. I am about to integrate it into a game scripting
engine, and these new features will really come in handy. I'll be
testing it over the next few days, and will report any bugs or
issues that I find. I do have a quick question though. How does the
built-in ENet compressor compare to using an external library such
as zlib, both in terms of compression speed and ratios?
Kind regards,
Philip Bennefall
----- Original Message ----- From: "Lee Salzman" <[email protected]>
To: "Discussion of the ENet library" <[email protected]>
Sent: Thursday, May 20, 2010 11:56 PM
Subject: [ENet-discuss] 1.2.2 and 1.3.0 *PRE*-release
So, I was playing around with packet compression for Sauerbraten
using an adaptive range compressor. It turned out that did not
work out so well on Sauerbraten's data, because I had already so
tightly quantized it that the gains were small. But since the
packet compressor was still good on other data besides
Sauerbraten's and was of higher quality than other similar
performing range compressors I could find, I decided to keep it in
ENet.
This also gave me a chance to break the protocol and introduce
some various things, thus there will be a dual release of 1.2.2,
which does not contain any protocol or API changes, and 1.3.0,
which contains the packet compression changes amongst others. In
1.3.0 I also changed how session disambiguation works, to the
effect that I cut down on packet header size (by 4 bytes) unless
the user enables checksums. Since I was free to break the API a
bit, I did the specify channel limit on host creation thing, and
also added a connect data field to connect events since someone
wanted that a while ago. Also noteworthy is that even in 1.2.2,
packet checksums can be enabled by setting a callback, no longer
breaking binary compatibility of the longer amongst same-numbered
builds, which should make it easier on those Linux distributions
that distribute it as a shared library.
So now I think the feature set is mostly complete, and I would
like people to test the pre-release packages to make sure there
are no issues with them, after which I will do a real release if
everything is okay.
1.2.2 pre-release: http://lee.fov120.com/enet-1.2.2-not-released.tar.gz
1.3.0 pre-release: http://lee.fov120.com/enet-1.3.0-not-released.tar.gz
Note that CVS currently only contains the 1.2.2 changes. The 1.3.0
pre-release was taken from my private Sauerbraten tree, and will
only be stuffed into CVS when I am ready for the final release.
Proposed ChangeLogs:
ENet 1.3.0 (May 20, 2010):
* enet_host_create() now requires the channel limit to be specified as
a parameter
* enet_host_connect() now accepts a data parameter which is supplied
to the receiving receiving host in the event data field for a connect event
* added an adaptive order-1 range coder as a built-in compressor option
which can be set with enet_host_compress_with_range_coder()
* added support for packet compression configurable with a callback
* improved session number handling to not rely on the packet checksum
field, saving 4 bytes per packet unless the checksum option is used
* removed the dependence on the rand callback for session number handling
Caveats: This version is not protocol compatible with the 1.2 series or
earlier. The enet_host_connect and enet_host_create API functions require
supplying additional parameters.
ENet 1.2.2 (May 20, 2010):
* checksum functionality is now enabled by setting a checksum callback
inside ENetHost instead of being a configure script option
* added totalSentData, totalSentPackets, totalReceivedData, and
totalReceivedPackets counters inside ENetHost for getting usage
statistics
* added enet_host_channel_limit() for limiting the maximum number of
channels allowed by connected peers
* now uses dispatch queues for event dispatch rather than potentially
unscalable array walking
* added no_memory callback that is called when a malloc attempt fails,
such that if no_memory returns rather than aborts (the default behavior),
then the error is propagated to the return value of the API calls
* now uses packed attribute for protocol structures on platforms with
strange alignment rules
* improved autoconf build system contributed by Nathan Brink allowing
for easier building as a shared library
Caveats: If you were using the compile-time option that enabled checksums,
make sure to set the checksum callback inside ENetHost to enet_crc32 to
regain the old behavior. The ENetCallbacks structure has added new fields,
so make sure to clear the structure to zero before use if
using enet_initialize_with_callbacks().
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
