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.