[ENet-discuss] Prioritisation

[Lee Salzman]

Well, there is some synergy between reliable and unreliable packets. I
use reliable packets to measure the RTT (and its variance) of the connection, 
and send out pings regularly to make sure this information is always
being collected periodically. Abnormal RTTs (either too high or too low)
cause the throttle to move down or up, as appropriate. And the throttle
basically just tells how many packets to drop. I try to send the
unreliable packets out ASAP or drop them, so I basically trade latency
for packet loss. Given what ENet was written for, the latency was the
way more critical issue.

Now, the reliable packets just use a window, which is probably far from
ideal. But on the other hand, it "magically" works with the unreliable
throttling as lots of reliable traffic will cause the RTTs to go up and
the throttle will start dropping more unreliable packets in response.

Now, in an ideal world, ENet would probably not work by "magic" and
would use some sort of uniform rate based approach, although I am not so
sure it would help the unreliable packet situation and would require
either require more info about connection bandwidth or just some new
"voodoo" to automatically determine some ideal rate to send data out at.
In any case a possible start would be to have some good metric of how much
data in total is being sent out over a given time period, and have the
throttle attack that, rather than merely unreliable packets. And I don't
know if I would even want to change how unreliable packets are handled,
so much as making something more flexible than the window scheme for
reliable data. Then you start getting into the land of Quality of
Service --- UGH! A choice between magic or voodoo, hmm? :)

Lee

On Tue, Feb 03, 2004 at 12:47:35PM -0000, Jim Purbrick wrote:
> Hi Lee,
> 
> I was suggesting that you nescecarily change ENet at all, just discussing
> the changes I intend to make and the best way to make them. If I can ask
> your advice on how to move forward and share my findings with you then you
> can maybe decide if it's the way you want to take ENet later.
> 
> The first step is to get all packets sent using rate based flow control.
> Could you describe how the current rate based scheme works for unreliable
> data. Do you send as much unreliable data as you can each service and then
> bin the rest? To you allow unreliable data to build up if the rate is too
> low to send it all? How does the trottling and probability drop stuff work?
> Does the sending rate go down, or the drop rate go up with conjestion?
> 
> Cheers,
> 
> Jim.
> 
> > -----Original Message-----
> > From: Lee Salzman [mailto:lsalzman at telerama.com]
> > Sent: 03 February 2004 05:21
> > To: Discussion of the ENet library
> > Subject: Re: [ENet-discuss] Prioritisation
> > 
> > 
> > Well, something like that would require a bit rewrite of how 
> > all packets
> > are handled, so needs to really wait for a 1.1 release.
> > 
> > For now I just want to get a 1.0 out the door some time this 
> > century so
> > people have a stable library to use. :)
> > 
> > This is something to consistently harp on me about after 1.0, though.
> > 
> > Lee
> > 
> > On Mon, Feb 02, 2004 at 02:58:14PM -0000, Jim Purbrick wrote:
> > > I imagine something like the retransmission scheme used for 
> > all packet
> > > sending. Given a target data rate and the size of the next 
> > packet, you
> > > calculate when the next packet should be sent and store it 
> > as the next
> > > transmission timeout, which you check on each service call 
> > and send the
> > > packet when it's due.
> > > 
> > > Without prioritisation the packets are sent on a FIFO 
> > basis, prioritisation
> > > can be used to re-order the outgoing queue.
> > > 
> > > The only difference between reliable and unreliable packets 
> > is that reliable
> > > packets are remembered and retransmitted, unreliable are 
> > sent once then
> > > forgotten about. 
> > > 
> > 
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss