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

[Andrew Fenn]

Ah yes! I see what you mean. That makes a lot more sense, my mistake.

On Sat, May 15, 2010 at 1:08 PM, Lee Salzman <lsalzman1 at cox.net> wrote:
> You misunderstood me. :)
>
> I mean a *counter* overflow... as in increment an unsigned int that's
> already at max, and rolls back over to 0.
>
> Lee
>
> Andrew Fenn wrote:
>>>
>>> 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
>