(RADIATOR) radius proxy and (non-) concurrency

[Tariq Rashid]

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.