[ENet-discuss] ENet 1.2.2 work-in-progress

[Andrew Fenn]

> That out of the way, are there any not too difficult things people would
> like to see in 1.2.2?

- I use the cmake build system for our project. It'd be great if ENET
included a FindENET.cmake script or better yet just completely change
over from autotools.

I've attached the ENET scripts I use to statically link it into our project.

- I'm currently trying to figure out how to get the following data from ENET:
     - Total data received / sent
     - Data received / sent since the last flush
     - Total packets received / sent

I'm not so sure those things are features but I'm sure i'm not the
only one that's confused over how to get that data. So if you could
correct me on the following..

lHost->lastServicedPeer->roundTripTime - I use this for ping time
however it always says 5ms even when I kill the server.
lHost->incomingBandwidth/1000 - Data in KiB received (always shows the
same number even when killing the server)
lHost->outgoingBandwidth/1000 - Data in KiB sent (always shows the
same number even when killing the server)
lHost->lastServicedPeer->packetsSent - Get's the packets sent since
the last flush


On Fri, May 14, 2010 at 9:28 AM, Lee Salzman <lsalzman1 at cox.net> wrote:
> Just so we're clear: this is NOT a release announcement. Didn't want to get
> your hopes up. :)
>
> But recently I added some features to ENet CVS that people were bugging me
> about, so I thought I'd just tell you all what they were if you were in need
> of them.  Or maybe you just want to test them out and make sure they're
> stable (which they should be as far as I could test so far).
>
> 1. I fixed some places in the event dispatch where it was walking over all
> the channels to find appropriates packets to hand off to the user, such that
> is basically no longer does evil stuff like this. In other words: there is
> no longer any performance penalty for using high numbers of channels, per
> se, although it still needs to allocate memory for each channel, for each
> client, when you first create the host. But the dispatching costs of using
> them are gone.
>
> 2. I added a no_memory callback that allows you to override ENet's standard
> out-of-memory behavior, which was simply to call abort. Someone simply
> wanted the API functions to simply return errors in this case, and I revised
> some internals so that you can safely make a null no_memory handler and get
> that behavior. The default is just to call abort, which keeps ENet behaving
> as it always did, unless you decide to supply that callback.
>
> 3. I used the packed attribute on some sensitive protocol structures that
> were causing some protocol incompatibilities on platforms like ARM+GCC,
> which appeared to use much different alignment rules than what x86 and
> friends were.
>
> 4. Nathan Brinks contributed a less crufty autoconf build system.
>
> That out of the way, are there any not too difficult things people would
> like to see in 1.2.2?
>
> Lee
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enetcmake.zip
Type: application/zip
Size: 7909 bytes
Desc: not available
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20100514/248b735c/attachment-0001.zip>