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