(RADIATOR) radius proxy and (non-) concurrency

Hugh Irvine hugh at open.com.au
Fri Feb 11 08:19:16 CST 2005


Hello Tariq -

Radiator does not use a fixed size state table - and the problem with 
threading is the lack of "production-quality" threading support in 
Perl.

regards

Hugh


On 11 Feb 2005, at 16:56, Tariq Rashid wrote:

>
> thanks Mike for the quick and useful reply.
>
> just to go one step further, what are the relative merits of a threaded
> proxying server with a limited pool of threads, and an asynchronous 
> event
> driven server with a (fixed size) state table for currenrlt pending 
> proxied
> radius requests.
>
> i've heard arguments for and against each method.
>
> tariq
>
>
>
> -----Original Message-----
> From: Mike McCauley [mailto:mikem at open.com.au]
> Sent: 11 February 2005 12:23
> To: Tariq Rashid
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) radius proxy and (non-) concurrency
>
>
> Hello Tariq,
>
> On Friday 11 February 2005 21:58, Tariq Rashid wrote:
>> 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 - Radiator is single-threaded. A such, if it is 
>> used as
>> a proxy, will it havw to wait for a reply from a proxied request 
>> before it
>> can proxy a second and subsequent requests?
>
> Radiator is single threaded, but it event driven. It proxies each 
> request as
>
> soon as it is  received and returns the replies as and when they are
> received. It never blocks waiting for a reply to a proxied request: 
> its the
> asynchronous arrival of a request on a socket that triggers activity 
> within
> the server.
>
>>
>> For example:
>> 	* Radiator-Porxy proxy server instance forwards radius requests to
>> Radius-A and Radius-B,
>> 	  depending on domain.
>>
>> 	* A request arrives at Radiator-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 Radiator-Proxy.
>>
>> 	* Since Radiator-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?
> No.
>
>> 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.
>
> Hope that helps.
>
> Cheers.
>
>>
>> Tariq
>>
>> --
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>
> -- 
> Mike McCauley                               mikem at open.com.au
> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> 9 Bulbul Place Currumbin Waters QLD 4223 Australia   
> http://www.open.com.au
> Phone +61 7 5598-7474                       Fax   +61 7 5598-7070
>
> 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 etc on Unix, Windows, MacOS etc.
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive 
(www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list