[ENet-discuss] Bandwidth Monitoring?

[fuzzy]

I think the 86 seconds it would take you to add to YOUR very specific 
packet handling code is not worth adding a whole bunch of irrelevant 
data to the wrapper itself.

Take for example profiling your networking, Some questions you might ask :
     How much data are chat message taking up in my game?
     How much data is spent keeping players in sync (versus say, how 
much is sent administering players)?
     How much data is spent on player joining, just player joining (ie 
all players lag when someone joins).

NONE of this can be answered by ENet, and never should be.
"Simple statistics" mean nothing, and if you want a total byte count 
just increment a single variable.


On 2010/10/21 04:21 PM, Nicholas J Ingrassellino wrote:
> On the one hand I understand-- and love-- the idea of the minimalistic 
> approach. Sure, it was designed for games, but if you want a lobby, or 
> compression, or encryption, you have to implement it yourself. These 
> are all high-level functions that keep ENet light on its feet and 
> would be better implemented if trailered for a specific game. 
> Bandwidth tracking, however, I feel would be best if part of the ENet 
> API. If for no other reason than ENet can let us know about overhead 
> in addition to the raw data being sent. Hell, it already reports latency.
>
> ------------------------------------------------------------------------
>
> Nicholas J Ingrassellino
> LifebloodNetworks.com <http://www.lifebloodnetworks.com/> || 
> nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>
>
> "The idea that I can be presented with a problem, set out to logically 
> solve it with the tools at hand, and wind up with a program that could 
> not be legally used because someone else followed the same logical 
> steps some years ago and filed for a patent on it is horrifying."
> - John Carmack on software patents
>
>
> On 10/21/2010 09:43 AM, Beau Albiston wrote:
>>
>> It would be nice to have some statistics functions.  I would be most 
>> interested in things like bytes/sec sent/received at the socket, for 
>> instance.
>>
>> -Beau
>>
>> *From:*enet-discuss-bounces at cubik.org 
>> [mailto:enet-discuss-bounces at cubik.org] *On Behalf Of *Nicholas J 
>> Ingrassellino
>> *Sent:* Thursday, October 21, 2010 8:16 AM
>> *To:* Discussion of the ENet library
>> *Subject:* Re: [ENet-discuss] Bandwidth Monitoring?
>>
>> Ooohhh, I misunderstood their purpose. Is there a variable somewhere 
>> that will tell me how much data is going back and forth at any given 
>> time or do I need to do that myself?
>>
>> ------------------------------------------------------------------------
>>
>> *Nicholas J Ingrassellino
>> LifebloodNetworks.com <http://www.lifebloodnetworks.com/>* || 
>> nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>
>>
>> "/The idea that I can be presented with a problem, set out to 
>> logically solve it with the tools at hand, and wind up with a program 
>> that could not be legally used because someone else followed the same 
>> logical steps some years ago and filed for a patent on it is 
>> horrifying./"
>> - *John Carmack* on software patents
>>
>>
>> On 10/20/2010 10:19 PM, Lee Salzman wrote:
>>
>> They're never updated and merely hold the values you pass in when you 
>> create the host.
>>
>> Lee
>>
>> On 10/19/2010 10:13 AM, Nicholas J Ingrassellino wrote:
>>
>> Is there something special I have to do to get 
>> /_ENetPeer.incomingBandwidth/ and /_ENetPeer.outgoingBandwidth/ 
>> working? I am using both reliable and unreliable packets but these 
>> values are always zero. For example, if I do /std::cout << 
>> event.peer->incomingBandwidth;/ inside my main loop I get 
>> bumpkis.//Also, how often are they updated?
>>
>> ------------------------------------------------------------------------
>>
>> *Nicholas J Ingrassellino
>> LifebloodNetworks.com <http://www.lifebloodnetworks.com/>* || 
>> nick at lifebloodnetworks.com <mailto:nick at lifebloodnetworks.com>
>>
>> "/The idea that I can be presented with a problem, set out to 
>> logically solve it with the tools at hand, and wind up with a program 
>> that could not be legally used because someone else followed the same 
>> logical steps some years ago and filed for a patent on it is 
>> horrifying./"
>> - *John Carmack* on software patents
>>
>>
>>
>>   
>>   
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org  <mailto:ENet-discuss at cubik.org>
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>    
>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>    
>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20101021/e776d86f/attachment-0001.html>