On Tue, 25 Jan 2000, Brian wrote:
It is spiffy, but it's doesn't periodically check with the hub to see who's logged on (at least it doesn't in my version, I am running one rev back). Only when it's about to deny someone a login because they are exceeding their max session count does it go out and look to see if the other sessions are still up. Since radiator is single threaded, I'd think this could really cause a problem if the check is slow or hangs.
Aaron,
Are you using Radiators session database to limit your concurrent sessions of your users? does it work well?
No, but I've looked at it. Mostly been concerned about the potential for blocking, and the fact that I run a separate acct and auth instances. I _think_ gdbm is single writer, multiple reader safe (and I'm almost sure the other dbm's aren't), so it might work. The main problem that I see is that by hard blocking mulitple access it allows people to effectively multiplex one account across several users, something I'm not keen on encouraging. What I do now is run a program that checks for multiple connections every 5 mins, then I write people a nasty gram when I catch them. My _dream_ solution is to modify radiator (or write a separate program) that simply hangs up any other connections but allows the last person to call in to log on. People would get very tired of getting bumped off-line when their buddy calls in with their password. Then of course they call back in, bump the buddy off line, who then calls back in, etc... -- Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.