New feature in v3.1.x

[Alan DeKok]

  I've just committed a new feature to the v3.1.x branch.  It's called "queue_priority" for the thread pool.

  The idea is to allow the administrator to control how the server behaves in overload conditions.  When a back-end database goes down, or 10K users log in at once, the server can't process packets as fast as they come in.  This is "overload".

  The usual method of dealing with overload is to put the extra packets into a queue for later processing.  But the question is, how should the queue be organized?  In v3.0 and earlier, the queue had fixed behaviour.  In v3.1.x, it is configurable.

  The 3 options are:

time

       order packets by when they are received
	Note that replies from a home server
	are ordered by when the *original*
	packet came in, so they are prioritized.

default

        Order by listener type
	  proxy > auth > acct > detail > coa
	Packets from the same listener are
	ordered by "time".

eap

        Order by ongoing EAP sessions.
	EAP authentication takes multiple
	rounds.  This priority ensures
	that EAP sessions which are "further along"
	in the authentication process are
	handled with a higher priority.
	Packets with the same eap priority
	are ordered by "default"

  The "default" order is pretty much what was in 3.0 and earlier.

  If anyone has suggestions for additional prioritization methods, I'd be interested in hearing them.

  Alan DeKok.