[ENet-discuss] Prioritisation

[Jim Purbrick]

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. 

> -----Original Message-----
> From: Lee Salzman [mailto:lsalzman at telerama.com]
> Sent: 02 February 2004 14:24
> To: Discussion of the ENet library
> Subject: Re: [ENet-discuss] Prioritisation
> 
> 
> Any sort of prioritization is going to work easiest at the level of
> channels, not packets. Channels are sorta there to support 
> features like
> that.
> 
> In any case, I'm not really sure how to make reliable data go out at a
> rate in the same sense as unreliable. I can't just drop reliable
> packets, as that's going to cause some nasty lag. What did you have in
> mind?
> 
> Lee
> 
> On Mon, Feb 02, 2004 at 11:22:25AM -0000, Jim Purbrick wrote:
> > The next (last?) big change I want to make to my version of 
> ENet is to add
> > support for prioritisation of packets. Real-time data, like 
> movement, will
> > be sent at a higher priority to non-realtime data, like 
> chat. In order to do
> > this I need to modify ENet so that when sending it just 
> requests packets one
> > at a time from a scheduler, which will be using an 
> algorithm like Weighted
> > Fair Queuing to determine the next packet to send. Currently ENet's
> > scheduling seems to send reliable data based on sliding 
> window space, then
> > unreliable data using a rate based scheme. What's the 
> reasoning behind this
> > hybrid approach? It seems the best way to integrate 
> prioritisation would be
> > to switch to a purely rate based approach where packets are 
> sent at the
> > current sending rate. Does this approach sound feasible? 
> The rate would be
> > adjusted based on conjestion and packet loss, with packets 
> lost due to the
> > receivers processing rate just being folded in to sender 
> based flow control.
> > As well as being more amenable to priority, it seems a rate 
> based ENet would
> > also be simpler and it would be easier to reason about TCP 
> friendliness. Any
> > thoughts?
>