Graeme Hinchliffe <[EMAIL PROTECTED]> wrote: > > It uses a pool of SQL connections, and doesn't use a "connection per > > request". > > If I have the number of SQL connections say set to 10, then when I > launch a large number of RADIUS requests the log files say that > there isn't enough SQL connections and it seems to then reject the > connection. So I get a few accepts and hundreds of rejects.
Yes... because the SQL queries are taking too long. It's simple math. The server gets 100 requests in a second, and if the SQL queries take 1/10 of a second each, it will take 10 seconds to respond to all of the requests. At which point, some will have timed out, and the NAS will have sent even more. Fix your SQL database to be faster, or run it on a faster machine. > > The NAS boxes can have more than 256 RADIUS packets outstanding. > > How is this achieved? I thought that the RADIUS protocol only > permitted 256 sessions, (well per connection)? There is no "connection" between NAS and RADIUS server. Read the RFC's for descriptions of how more than 256 requests from one NAS are allowed. > if I have less than 256 it rejects a lot of the requests. Because your SQL database is slow. Adding more SQL sockets means that even more requests can *appear* to be handled. It doesn't solve the underlying problem. > > The server should stop accepting new > > packets if doesn't have the resources to process them. This will go > > in before 0.9. Sory, I meant 1.0. > Any idea of timescale for this? Before 1.0. > Also how will it be done? Properly. > hanging back on responces to slow the sender down? That won't make any difference. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
