2010/12/20 Lee Salzman <[email protected]> > ENet has had a packet throttling mechanism since the beginning that > allowed the amount of unreliable packets sent over the link to scale up or > down depending on a % representing the current quality of the connection. > Only % of the queued unreliable packets would get sent through, the rest it > would actually discard. Since the packets are unreliable, it is perfectly > legal to drop them, and advantageous to do so when it helps reduce network > congestion. This % floated up or down depending on whether reliable packets > or periodic pings (which are just null reliable packets) took above or below > average amount of time to get acknowledged. Keep that in mind. > > But I could never figure out a similar simple scheme for reliable packets. > I always thought I needed good bandwidth capacity estimates of the > connection so that I could know how much reliable data to send on any given > call to enet_host_service. Then some silly scheme about measuring the > average time between enet_host_service calls so I would know how much more > data budget to allocate to reliable data to send again, since I reasoned you > need to know the rate at which data was getting sent to fit in within the > estimated budget. And that brought up questions like, over what timescales > do you measure the rate and the budget, and how do you fit that into the > programmer interface of ENet which is based on a polling enet_host_service > call? And then the mechanism wouldn't cooperate with the unreliable packet > throttling very well since it is a different metric, unless I changed the > metric for unreliable packets too which would require a crapload of > empirical testing to tune right again... I was not looking forward to any > such thing, so for years the throttle has remained as it is, rather than me > risk that. > > Now, there is a reliable data window size in ENet that affords some static > flow control. The window size is constant so does not float up or down in > response to connection quality at all. There were some provisions in the > code to assign a fixed window size based on the user provided bandwidth > numbers, which I don't think anyone (even me) seriously uses at this point. > But this also creates nasty antagonism if you send a lot of reliable data > that overwhelms the link: suddenly ENet sees your ping times skyrocketing, > so the throttle slows unreliable traffic down to almost nothing but keeps > flooding the connection with reliable data, so just kinda sucks. But that > games I was using it for were based on unreliable traffic with only limited > reliable traffic, so it never really mattered except occasionally. Also keep > that in mind. > > Then I was just for one reason or another reading an article on some TCP > mechanism, and there was a sentence in it that struck me like a brick in the > head: the window size in TCP floated up or down in response to congestion. > See where this is going? Ouch, the answer was staring me right in the face > the whole time: > > throttle % * window size = throttled window size > > The feedback would be more or less perfect: if the throttled window size > was still too large to prevent congestion, ping times would end up > increasing, and throttle % will just keep going down until the effective > window size is low enough to stabilize the connection again. If ping times > improve, the throttle opens up again. And the throttle % should already be > well tuned with no need to mess with it. The window was the only mechanism I > ever needed to handle flow control, I just needed to link it to the > throttle. > > Problem solved in one damned line of code. Oh, how blind I was. :( -> :) > So where did you put that damned one line of code?
> > Thoughts? > > Lee > > > > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > > -- Kabil Akpınar
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
