Hello Carles -
On Tue, 12 Sep 2000, Carles Xavier Munyoz Bald� wrote:
> Hugh Irvine wrote:
> > You can certainly try the "Fork" parameter if you wish, but keep in mind that
> > it will duplicate the entire Perl+Radiator process for each packet that is
> > processed by the AuthBy in question. We would be interested in the results of
> > your experiments.
>
> Hello again,
> I have tried the fork parameter with the configuration:
> <AuthBy DBFILE>
> Fork
> Filename %D/userdb
> </AuthBy>
>
> But this doesn't solve the problems.
> I have seen that after the Radiator has created its child process, it
> uses the waitid system call and waits for its child to finish its
> execution:
> waitid(P_PID, 17340, 0xEFFFF8E8, WEXITED|WTRAPPED|WNOHANG)
>
> This has the same effect than make the radius packet processing
> sequential.
> If the child process has problems to comunicate with the NAS (using
> SNMP) or with the data base engine, Radiator will wait until it timeouts
> and finish its execution, to continue processing the next radius
> packets.
> This wait, this time of inactivity, (may be lot of seconds) is the
> important problem I have reported you in another e-mail.
>
As I mentioned previously, this is way that Radiator operates currently. If you
are having too many problems communicating with your NAS equipment, all I can
suggest is that you not use the NasType parameter so you don't query them.
Alternatively you might try the NasType of "Ping" which has a one second
timeout, but there are other potential problems with Ping as well.
> I'm using Alteon devices to redirect the UDP radius traffic to varios
> radius hosts, but this is not the solution. The problem is still here
> with the redirectors configuration.
>
> For example, imagin that I have my configuration with one Alteon and two
> radius hosts. One of the NAS fails.
> If one Access-Request arrives to host radius 1 and makes that Radiator
> use SNMP to query the failed NAS, this will make that the Radiator
> server in host 1 doesn't process any more radius packet during 6 seconds
> (the time required by the snmpget program to timeout).
> The NAS will timeout (5 seconds) and retransmit the Access-Request. This
> Access-Request will be send by the Alteon to the radius host 2 (radius
> host 1 is not responding to the Alteon test) and the Radiator server in
> this host will use SNMP to query the failed NAS.
> At this moment, my radius system is blocked and will not process any
> more radius packets during some seconds.
> If there are lot of SNMP queries over the failed NAS, the radius system
> may be stoped during various seconds, making that NAS generates
> retransmisions.
>
> This problem may appear too if there are comunications problems with the
> sessions data base engine, or this engine responds slow to the Radiator
> SQL queries.
>
Yes, we understand the problem and we know that multi-threading is the answer.
> Do you have any idea about when will the multi-thread perl and Radiator
> avaible ?
> I really trust the Radiator radius server. It has gone very very fine
> since now, but this perfomance and software design problem is making me
> think in look for another radius server, because I see that Radiator
> doesn't match my High Avaibility requeriments at 100%.
>
Unfortuantely, multi-threading support in Perl is still "Experimental - Not for
Production Systems", so at the moment we have to wait.
> One personal question... Why decided you to program it in Perl and not
> in C ?
> With C the generated code will be more optimized and the wait problem
> will have a very easy solution (multi-thread or fork).
>
Radiator was written in Perl for ease of development and ease of deployment on
multiple platforms.
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
