[ENet-discuss] Prioritisation

Lee Salzman lsalzman at telerama.com
Mon Feb 2 06:24:13 PST 2004


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?


More information about the ENet-discuss mailing list