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

Lee Salzman lsalzman1 at cox.net
Fri May 14 16:53:28 PDT 2010


Okay, this is what I added, which should hopefully suit your needs:

typedef struct _ENetHost
{
    ... usual stuff here ...
   enet_uint32        totalSentData;               /**< total data sent, 
user should reset to 0 as needed to prevent overflow */
   enet_uint32        totalSentPackets;            /**< total UDP 
packets sent, user should reset to 0 as needed to prevent overflow */
   enet_uint32        totalReceivedData;           /**< total data 
received, user should reset to 0 as needed to prevent overflow */
   enet_uint32        totalReceivedPackets;        /**< total UDP 
packets received, user should reset to 0 as needed to prevent overflow */
} ENetHost;

The semantics of these is that they are set to 0 on enet_host_create() 
but just increment thereafter. It is the user's responsibility to
reset them to 0 periodically to prevent them for overflowing. Suggested 
usage pattern would be like:

myCounter += host -> totalSentData;
host -> totalSentData = 0;

Also note the total*Packets statistics are in terms of raw UDP packets, 
i.e. the aggregates of various ENet commands, so are a better
indicator of the actual network performance than what you were using 
before, which was only user packets. Each increment represents
a single enet_socket_send or enet_socket_receive call under the hood. 
The total*Data versions reflect the actual size of the buffers sent
or received via the enet_socket_* calls too.

Lee


Andrew Fenn wrote:
> In that case is there a solution or can we see this possibly being
> made easier via the API down the line?
>
> On Fri, May 14, 2010 at 9:52 PM, Lee Salzman <lsalzman1 at cox.net> wrote:
>   
>> Keep in mind that reusing those internal ENet statistics is not going to be
>> very safe at all, except for the roundTripTime stat. Those *Bandwidth vars
>> don't measure totals and are just limits supplied by the user. And because
>> of the whole dispatch queue change I made, lastServicedPeer no longer
>> exists. :)
>>
>> Lee
>>
>> Andrew Fenn wrote:
>>     
>>>> 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
>>>       



More information about the ENet-discuss mailing list