[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-devel
Subject:    Re: Module for Access Request - wait for some things - Accept/Reject
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2009-04-13 15:59:07
Message-ID: 49E3614B.3000504 () deployingradius ! com
[Download RAW message or body]

John Bourke wrote:
> I need to implement a extension which makes Access Request decisions in
> batch.  I need to queue up a bunch of requests, analyse them, and decide
> which are Accepted or Rejected.  This is for a resource allocation problem,
> not an authentication problem.  I want to batch 2-3 seconds of requests
> which could be up to 150 requests, (I need to handle some exceptional peak
> loads).

  That is very difficult to do in the current design of the server.

  And if your back-end system can't handle a steady stream of requests,
it's likely time to get a better back-end system.  Really.

> "Similarly, the module infrastructure is NOT intended to allow servers,
> applications, timed events, or anything other than handling incoming RADIUS
> packets."
> 
> So the best way is to push this problem off to another application via some
> clean, non blocking, interface.

  Yes.

> But.
> 
> How may outstanding Access Requests can I have waiting on the
> module/external to complete ?  I guess this is a question about Free Radius
> internal threading, queueing or blocking/non blocking.

  Lots.  I would suggest *proxying* the requests to another RADIUS
server that you write yourself.  It can queue up the requests, and then
respond in one big batch.

> Does the Free Radius/Module architecture allow large numbers of outstanding
> Access Requests, and if so, are they queued, or do they exist in 100's of
> independent blocking threads, or is there some other mechanism ?

  If you block in a module, then it *will* use many threads.  If you
proxy the requests, it won't.

  I wouldn't recommend doing this, to be honest.  It's going to be
expensive, fragile, and completely non-standard.  I would suggest
instead fixing the back end system.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
[prev in list] [next in list] [prev in thread] [next in thread]