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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected] <mailto:[email protected]>
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
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
