On 03/25/2011 04:27 PM, Alan Buxey wrote: > just wondering what the impact on a RADIATOR server is for RADSEC clients > that are running in persistant TCP connection mode (as they seem to do by > default)... > how many of them can I operate in such a fashion against RADIATOR (4.7 with > patches) > or should they not be run in this mode?
I would say this mode is preferred compared to establishing TLS sessions per request. Especially when requests are part of EAP session establishment for various TLS tunnelling protocols. > will it starve the resources of the RADIATOR for other tasks or will the > server > just spawn more children from the thread (hence my question about numbers). It will not spawn automatically, but you could try server farm if you think the number of clients should be split among Radiator servers. > dont want to find things go rapidly melty/wrong/shunoky when I reach > some mahical figure one afternoon...... Well, I do not know if anyone has hit RadSec imposed limit yet. Usually the problems seem to come from LDAP, SQL or some other processing or from AuthByPolicies which run through many AuthBys for each request. If the server is doing just proxying, then RadSec might be the limiting factor at some point, but for authenticating server, the limiting factor could also be the authentication backend. It would be interesting to hear about number of clients and authentication events if you plan to add a large number of clients. Yours, Heikki -- Heikki Vatiainen <h...@open.com.au> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
