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

Jay Sprenkle jsprenkle at gmail.com
Mon Dec 20 09:15:31 PST 2010


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> 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> 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.orghttp://lists.cubik.org/mailman/listinfo/enet-discuss
>
>
>
> _______________________________________________
> ENet-discuss mailing list
> 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20101220/96ffb778/attachment-0001.html>


More information about the ENet-discuss mailing list