threading and proxying
We're considering using a front-end radius server instance as a proxy - which will proxy depending on the user's domain name. The question I have is to do with concurrency. As I understand it - if I use a single-threaded radius proxy server - it will it have to wait for a reply from a proxied request before it can proxy a second and subsequent requests? For example: * Radius-Proxy proxy server instance forwards radius requests to Radius-A and Radius-B, depending on domain. * A request arrives at Radius-Proxy and is determined to go to Radius-A. It is sent. However Radius-A (or its backend) don't reply quickly - taking 5 seconds or more. * A second request arrives at Radius-Proxy. * Since Radius-Proxy is single threaded it cannot forward the second request. It must wait for the reply from Radius-A or a timeout. Is this correct? If it is, it would make sense to have a threaded radius proxy server as the forwarding proxy - perhaps with 3000 threads configured. It would then take 3000 delayed resoponses to fill exhaust the 3000 threads. Comments / corrections welcome. Tariq - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: threading and proxying
Tariq Rashid [EMAIL PROTECTED] wrote: As I understand it - if I use a single-threaded radius proxy server - it will it have to wait for a reply from a proxied request before it can proxy a second and subsequent requests? No. The server proxies the request, and then stops processing it. The request is still in the request queue (src/main/request_list.c), so that when the reply comes from the home server, it's associated with the original request. See src/main/radiusd.c, packet_ok(), request_ok() and proxy_ok(). Is this correct? If it is, it would make sense to have a threaded radius proxy server as the forwarding proxy - perhaps with 3000 threads configured. It would then take 3000 delayed resoponses to fill exhaust the 3000 threads. Having 3000 threads waiting up to 30 seconds for a response from a home server is a way to kill your system. FreeRADIUS doesn't do that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: threading and proxying
Is this correct? If it is, it would make sense to have a threaded radius proxy server as the forwarding proxy - perhaps with 3000 threads configured. It would then take 3000 delayed resoponses to fill exhaust the 3000 threads. Having 3000 threads waiting up to 30 seconds for a response from a home server is a way to kill your system. FreeRADIUS doesn't do that. how do you mean? do mean that large number of active threads will kill my system? i dont see what is wrong with, say, 200 threads for proxying. That way, if there are 50 bad requests which cause the home servers not to reply, the other 150 from the thread pool can continue to handle requests. hote that we intend to proxy to DIFFERENT sets of radius servers under the control of different entities - and this is why we need to be cautious about non-returning home servers. this is why a sequential proxy service is not a good idea. is it possible to have say 50 threads in 5 pools? the 5 pools corresponding to 5 different home radius servers. t - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: threading and proxying
Tariq Rashid [EMAIL PROTECTED] wrote: how do you mean? do mean that large number of active threads will kill my system? A large number of active threads which are doing nothing other than blocking for 30 seconds is a waste of resources. i dont see what is wrong with, say, 200 threads for proxying. It's a bad design. See my previous response. That way, if there are 50 bad requests which cause the home servers not to reply, the other 150 from the thread pool can continue to handle requests. It's not needed. See my previous response. hote that we intend to proxy to DIFFERENT sets of radius servers under the control of different entities - and this is why we need to be cautious about non-returning home servers. this is why a sequential proxy service is not a good idea. Which is why the server is not designed that way. is it possible to have say 50 threads in 5 pools? the 5 pools corresponding to 5 different home radius servers. It's not needed. It's a bad design. The threads on the server are unrelated to clients, databases, or to home RADIUS servers. Tying threads to any one of those objects would be a bad design, and would cause problems. The threads on the server are visible only to the server core. They're not visible to modules, databases, or anything else. The purpose of the threads is to allow the server to parallelize internal operations. The threads do not block for ANYTHING except to serialize access to server modules (rlm_*). Please go READ src/main/radiusd.c, the code there explains how proxying is handled. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
