Hi,

        Ive been playing around with the SessionDatabase and MaxSession features 
and i have a couple of questions:
        
        . Is the SessionDatabase DBM recomended if you have to serve lots of 
sessions? I had the problem that the server ate up all the cpu (and started 
to ignore requests) once i enabled the MaxSession option on a DBM with 
about 1500 entries, and serving about 15 requests/sec
        
        . Is currently any way to make queries to SessionDatabase Internal ? (to 
know if a user is currently logged in, etc)

        . Using SessionDatabase SQL with mysql i get the following error if an 
adminstrator telnets into a USR nas:

        Wed Feb  2 14:11:34 2000: ERR: do failed for 'insert into RADONLINE 
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, 
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values ('!root', 
'200.42.xx.xxx', , '!rootxxxx', 949511494, '', 'Virtual', 
'Administrative-User')': You have an error in your SQL syntax near ' 
'!rootxxxxx', 949511494, '', 'Virtual', 'Administrative-User')' at line 1

        . Also i get SQL errors when the server gets 'noisy' requests (with ' 
chars in the user-name attribute). I have Rewrite rules to get the invalid 
characters filtered out from the username, but they dont have effect on 
SessionDatabase as the session is verified before the Rewrite rules 
tranform the username. We also use the Rewrite rules to get the username 
'normalised'  (user xxx should be equivalent to [EMAIL PROTECTED]). How can 
i get the session verification to be done after the username rewriting rules?


  Also I whished to hear some comments from people currently using the 
concurrence control features of radiator. How do you have it configured? do 
you use the NasType option? do you use dbm or SQL or internal? Im 
particulary worried about using NasTypes at the client entries, as any 
query to the nas will block radiator up.

Ive been thinking about making a small perl script to make 'asyncronical' 
verification of the session at the nas. Suppose radiator receives an auth 
request for an user that has too many sessions, then at first refuse the 
request but at the same time sends a message (through named pipes, socks, 
or simplier but uglier through the logfile) to the verification process to 
get the sessions checked by it. If the user is not logged in anymore the 
verification program will delete up the entry in the session database, so 
the next time the user tries to log in it will be accepted. I hope im not 
rambling; please send your comments, if you think its worth the trouble, etc

Regards
Alejandro Dau




===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to