<div class="gmail_quote">2010/12/20 Lee Salzman <span dir="ltr"><<a href="mailto:lsalzman@gmail.com">lsalzman@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">







<div text="#c0c0c0" bgcolor="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
 throttle % * window size = throttled window size<br>
<br>
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.<br>
<br>
Problem solved in one damned line of code. Oh, how blind I was. :(
-> :)<br></div></blockquote><div>So where did you put that damned one line of code? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#c0c0c0" bgcolor="#000000">


<br>
Thoughts?<br>
<br>
Lee<br>
<br>
<br>
<br>
</div>

<br>_______________________________________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div>Kabil Akpınar</div><br>