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

[Andrew Fenn]

> 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.

What about people that aren't using these new features, isn't that
going to trip them up?

Perhaps it would be better to just contain data since the last time
you have called enet_host_service because I wouldn't want other users
of the lib to suddenly have buffer overflows in their code after
upgrading.

On Sat, May 15, 2010 at 6:53 AM, Lee Salzman <lsalzman1 at cox.net> wrote:
> 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
>>>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>