[ENet-discuss] Packet throttling: it's the little things...

[Lee Salzman]

If you look inside enet_host_bandwidth_throttle(), that is where it 
diddles throttles to achieve various bandwidth targets depending on what 
it knows of the limits on both ends of the connection. Pretty much any 
effect you want so long as it can be expressed in terms of nudging the 
throttle around can be done there.


On 12/20/2010 07:15 PM, Jay Sprenkle wrote:
> I misunderstood. The documentation lead me to believe it was a global 
> function:
>
> void 	enet_host_bandwidth_limit 
> <http://enet.bespin.org/group__host.html#g83c5fa02a3ba6ab829856302e54929fe> 
> (ENetHost <http://enet.bespin.org/struct__ENetHost.html> *host, 
> enet_uint32 incomingBandwidth, enet_uint32 outgoingBandwidth)
> 	Adjusts the bandwidth limits of a host.
>
>
> It adjusts the bandwidth limit of the host (I.E. all peers). So in 
> reality it's really on a per peer basis, but can't be effectively 
> controlled at that level because of the design of the network stack?
>
> That would imply I need to "de-congest the link" by pushing the 
> connection throttling to the operating system network stack. Iptables 
> has rate limiting so I can perhaps I can get iptables to do the 
> throttling.
>
> Thanks
>
>
> On Mon, Dec 20, 2010 at 1:59 AM, Lee Salzman <lsalzman at gmail.com 
> <mailto:lsalzman at gmail.com>> wrote:
>
>     Throttling in ENet has always been done on a per connection basis.
>     :) The congestion metric is based on the length of a round trip
>     time between a host and a given peer, and the RTT metrics and
>     throttle values are stored in the peers themselves.
>
>     The issue is more one of quality of service: one connection
>     hogging bandwidth can cause the throttles of all other connections
>     to go down because  the link overall is congested.
>
>     Lee
>
>
>     On 12/20/2010 05:38 PM, Jay Sprenkle wrote:
>>
>>     On Sun, Dec 19, 2010 at 6:49 PM, Lee Salzman <lsalzman at gmail.com
>>     <mailto:lsalzman at gmail.com>> wrote:
>>
>>
>>
>>         Problem solved in one damned line of code. Oh, how blind I
>>         was. :( -> :)
>>
>>         Thoughts?
>>
>>
>>     Thanks for putting in the time to make enet better :)  I'll patch
>>     my code.
>>
>>     I realize it's a much larger change than one line but I'd really
>>     like to see throttling adjustable on a per connection basis. That
>>     would provide a better mechanism to react to denial of service
>>     attacks. I could at least attempt to throttle back the offending
>>     connection with less affect on other connections.
>>
>>     It may be a better solution to handle this in the network
>>     firewall code instead of enet. If anyone has any feedback on this
>>     I'd love to receive it.
>>
>>
>>
>>     ---
>>     "The great thing about Object Oriented code is that it can make
>>     small, simple problems look like large, complex ones."
>>
>>
>>     _______________________________________________
>>     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 <mailto:ENet-discuss at cubik.org>
>     http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
>
> -- 
> ---
> "The great thing about Object Oriented code is that it can make small, 
> simple problems look like large, complex ones."
>
>
> _______________________________________________
> 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/20101220/40383cd9/attachment.html>