Re: (RADIATOR) AuthRADIUS (non)forking problem
>From what I have seen with my own (meager) experiments with Perl threading, it appears to behave radically different on different OSes, presumably because every OS treats threading differently. This may be the reason for the non-production-quality aspect. Chris > From: Hugh Irvine <[EMAIL PROTECTED]> > Organization: Open System Consultants > Reply-To: [EMAIL PROTECTED] > Date: Thu, 28 Feb 2002 11:17:15 +1100 > To: Damir Dzeko <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: (RADIATOR) AuthRADIUS (non)forking problem > > > Hello Damir - > > Mike and I have discussed this issue at length over a long period of time, > and indeed the topic has also been discussed on the mailing list several > times as well. > > Basically, it is our intention to extend Radiator to use multi-threading so > that each request runs in a separate thread, which we feel is the best > approach for dealing with all these sorts of problems (not just with AuthBy > RADIUS clauses). > > The only reason that this has not been done yet is due to the fact that > although there is experimental support for multi-threading in Perl now, it is > specifically stated that it is not to be considered "production-quality" code. > > This being the case, we have opted to wait until there is a solid > multi-threading release of Perl first before spending more time on it. > > regards > > Hugh > > > On Wed, 27 Feb 2002 19:55, Damir Dzeko wrote: >> Hugh Irvine <[EMAIL PROTECTED]> writes: >>> Hello Damir - >>> >>> As always, many thanks for your very valuable contributions. >>> >>> Mike will apply the fixes for the next release. >> >> My coleagues & I are discussing an interesting idea. Would it >> be possible to handle slow AuthRADIUS proxy requests in a single >> process (forked out of main radiusd)? >> >> That process would have a communication line with main radius >> daemon through some socket (or whatever) and handle all slow >> requests in one big select loop (instead of forking an extra >> process to do the job for less then a few packets). That would >> make more efficient use of system resources. >> >> -d > > -- > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. > - > Nets: internetwork inventory and management - graphical, extensible, > flexible with hardware, software, platform and database independence. > === > Archive at http://www.open.com.au/archives/radiator/ > Announcements on [EMAIL PROTECTED] > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthRADIUS (non)forking problem
Hello Damir - Mike and I have discussed this issue at length over a long period of time, and indeed the topic has also been discussed on the mailing list several times as well. Basically, it is our intention to extend Radiator to use multi-threading so that each request runs in a separate thread, which we feel is the best approach for dealing with all these sorts of problems (not just with AuthBy RADIUS clauses). The only reason that this has not been done yet is due to the fact that although there is experimental support for multi-threading in Perl now, it is specifically stated that it is not to be considered "production-quality" code. This being the case, we have opted to wait until there is a solid multi-threading release of Perl first before spending more time on it. regards Hugh On Wed, 27 Feb 2002 19:55, Damir Dzeko wrote: > Hugh Irvine <[EMAIL PROTECTED]> writes: > > Hello Damir - > > > > As always, many thanks for your very valuable contributions. > > > > Mike will apply the fixes for the next release. > > My coleagues & I are discussing an interesting idea. Would it > be possible to handle slow AuthRADIUS proxy requests in a single > process (forked out of main radiusd)? > > That process would have a communication line with main radius > daemon through some socket (or whatever) and handle all slow > requests in one big select loop (instead of forking an extra > process to do the job for less then a few packets). That would > make more efficient use of system resources. > > -d -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthRADIUS (non)forking problem
Hugh Irvine <[EMAIL PROTECTED]> writes: > Hello Damir - > > As always, many thanks for your very valuable contributions. > > Mike will apply the fixes for the next release. My coleagues & I are discussing an interesting idea. Would it be possible to handle slow AuthRADIUS proxy requests in a single process (forked out of main radiusd)? That process would have a communication line with main radius daemon through some socket (or whatever) and handle all slow requests in one big select loop (instead of forking an extra process to do the job for less then a few packets). That would make more efficient use of system resources. -d === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthRADIUS (non)forking problem
Hello Damir -
As always, many thanks for your very valuable contributions.
Mike will apply the fixes for the next release.
regards
Hugh
On Wed, 27 Feb 2002 00:06, Damir Dzeko wrote:
> Hello,
>
> Using Radiator with AuthRADIUS module to handle requests for GRIC
> authentication I noticed strange problems. Although in my
> configuration was specified that handler for that type of request
> should fork, no forking occured.
>
> That caused our radiusd to block forever(!). That could be because
> some bug exists in Select.pm (in process_timeouts function perhaps?).
>
> Useful information could be that I'm using AuthRADIUS with "Synchronous"
> flag set.
>
> I traced bug to AuthRADIUS::handle_request function which overrides
> default handle_request function defined in its superclass AuthGeneric.
>
> Other Auth* modules which do not redefine handle_request worked fine
> with 'Fork' option set, but this one never forked.
>
> Because of that I added the same piece of code found in
> AuthGeneric::handle_request into AuthRADIUS::handle_request
>
> # Now we might fork before processing the request
> # Should only do this for "slow" authentication methods
> return ($main::IGNORE, 'forked')
> if $self->{Fork} && !$self->handlerFork;
>
> I hope you will include that in new release of Radiator.
>
> Also, it would be of great help if someone could correct the
> bug that caused my radiusd to wait forever (almost for one
> hour) in this loop:
>
> while (! defined $p->{RadiusResult})
> {
> ...
>
> &Radius::Select::process_timeouts();
> }
> return ($p->{RadiusResult});
>
> During that period users of ISP that I work for could not
> connect to our dial-up service and that is certainly something
> that should happen never again.
>
> -d
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on [EMAIL PROTECTED]
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) AuthRADIUS (non)forking problem
Hello,
Using Radiator with AuthRADIUS module to handle requests for GRIC
authentication I noticed strange problems. Although in my
configuration was specified that handler for that type of request
should fork, no forking occured.
That caused our radiusd to block forever(!). That could be because
some bug exists in Select.pm (in process_timeouts function perhaps?).
Useful information could be that I'm using AuthRADIUS with "Synchronous"
flag set.
I traced bug to AuthRADIUS::handle_request function which overrides
default handle_request function defined in its superclass AuthGeneric.
Other Auth* modules which do not redefine handle_request worked fine
with 'Fork' option set, but this one never forked.
Because of that I added the same piece of code found in
AuthGeneric::handle_request into AuthRADIUS::handle_request
# Now we might fork before processing the request
# Should only do this for "slow" authentication methods
return ($main::IGNORE, 'forked')
if $self->{Fork} && !$self->handlerFork;
I hope you will include that in new release of Radiator.
Also, it would be of great help if someone could correct the
bug that caused my radiusd to wait forever (almost for one
hour) in this loop:
while (! defined $p->{RadiusResult})
{
...
&Radius::Select::process_timeouts();
}
return ($p->{RadiusResult});
During that period users of ISP that I work for could not
connect to our dial-up service and that is certainly something
that should happen never again.
-d
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
