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

[Lee Salzman]

They're solely counters for the user, and will never be used by ENet for 
any other purpose than to increment them on sends/receives. So if you 
want to overwrite them with random values at any time or just totally 
ignore them, you can do that, it won't harm ENet. :)

Lee

Nuno Silva wrote:
> Do the counters affect ENet in any negative way should they overflow, 
> or is it okay to not care about that if we're not using the new features?
>
> On Sat, May 15, 2010 at 7:08 AM, Lee Salzman <lsalzman1 at cox.net 
> <mailto: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 <mailto: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 <mailto: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
>
>                                  
>
>