> > 1. Distributed shared database. (kinda like the radius concept?)
> >
> That doesn't solve all the problems, and speed is still an issue.
Really? Since the bumper runs externally, there is d*mn little overhead
added to the radius server.
> > > What
> > > about when the PM reboots?
> >
> > 2. delete from table utmp where host = 'crashed host'
> > (already running at my site). Smart bumper program also knows
> > how to handle this.
> >
> How did you detect the crash reliably?
The radius server detects it by looking for that magic string the PM
sends when it reboots.
> >
> > 3. Good point. I have implemented a 'loadup' that rebuilds the
> > database by querying the running NAS's. I could add this to the /etc/rc
> > of each radius server, but I won't bother just yet. Since my radius
> > servers have each both been up over 100 days now, I don't think it's a
> > huge issue.
> >
> That must be a lot of fun when the users are trying to get back in while
> this occurs.
Since no current logins are ever killed, it's a non-issue. No one is ever
blocked from logging in. Duplicate sessions are detected and the oldest
one is killed.
> > > What
> > > about network outages or blocks?
> >
> > 4. Smart bumper program runs external to the radius server. If the network is
> > blocked, the user's not going anywhere anyway (can't log in). In any
> > case, it doesn't have to be "perfect". It can be a little loose, as
> > long as it never kills the current login session. Perfection is not
> > required, just pretty good detection and deterrance.
> >
> It can be a little loose at your site by your decision. Livingston can't
> make that decision for everyone.
It's only a little 'loose' in that a user may be able to steal a few
duplicate minutes. I (and I suspect most others) can live with that. If
you don't like it, let's see your solution instead.
> It would do nasty things to their quality
> reputation. They may not have every feature you want, but the ones they
> do have work.
Really. Quality? Ok, let me tell you about quality. The next time my main
ISDN pm stays up for more than a week, will be the first time. And yes, we
are on beta 4.
> > 5. Ought to scale well. Since it's a shared network database. How many
> > of these 'huge' users do you have anyway? The largest providers in the
> > northwest (7 - 10K users) have 'only' 45 PM's. (500 - 1000 lines).
> > An mSQL query in a database of 1000 is still a sub-second response.
> > Sorting and checking for dups takes about 5 seconds (on a slow box).
> > That's good enough for me. When/if i get to 100 NAS's, I'll probably
> > rewrite mSQL to be faster, or change the database backend altogether.
> Ha! Perhaps you should look at a larger picture. Livingstons are widely
> in use by large NATIONAL providers. Many of them have >=2000 PortMasters.
Sure, define many. 10, 100, 1000? Now compare that to the total number of
PM users. I bet it's not a huge fraction. Of the 17-20,000 ISPS, how many
have 1000 or more lines? Next asinine assumption please.
> Also several international sites have large numbers of PMs. It's not likely
> that your above concept will scale to that level.
Why not? As a professional software developer, I have been responsible for
distributed databases spread across 80 sites and 4 continents, updated in
real time. The problem is by no means insurmountable with proper
application of even simple tools.
> Now add in the idea
> of something on the order of a 50,000 user or more table of users, and
> you're starting to really expand the amount of data your shoving around
> the network.
A query into a database of 50,000 is not much slower than a query into a
database of 50, if done properly. And remember, we're only concerned
about the number of users logged in, not the total number of users.
The bumper program can run right on the database server(s). The big
queries don't have to pass over the network. Currently, one extra network
message may (or may not) be generated for each accounting record.
> The problem with a distributed shared database of this
> magnitude is synchronization.
Yup. Real developers know how to handle it. Whiners and wannabees bitch
about how hard it is.
> RADIUS authentication data can be done
> this way, because it doesn't really matter if the data is 10-15 minutes
> old. Not so for the multiple login issue.
> > I come to Livingston for reliable equipment, not business advice. I'll
> > decide how to run my business, thank you.
> Funny, your note is in response to a thread about solving the multiple-login
> problem. This is a viable solution. It may not be the solution you want,
> but it is viable.
No, it's frivolous business advice, given freely, and worth every penny.
As is your solution (just what is your solution?).
> > The features have taken about 6 hours of my time so far. And yes, I am
> > a professional software developer (one of my many hats).
> So? You've got a solution that:
> 1. Works in your specific environment.
And is easily modified to cover most. mSQL is source code and
just as portable as radiusd. In fact, my next step may be to
eliminate the 'users' file altogether in favor of an mSQL database,
so I can easily do remote administration of the user properties,
currently a time-consuming and tedious task, due to an extremely
short sighted design, IMHO.
mSQL is also a good candidate for replacing the Unix password
database on the server. A keyed query into a database of 1,000,000
records is quite fast.
> 2. Won't really scale beyond a small-medium size ISP.
If a medium sized ISP is 10,000 users, I can live with that.
That's 1000 simultaneous logins (or so) and easily handled.
If it's 10,000 simultaneous logins, then mSQL goes out the window
and Oracle (or sybase, or Informix) comes in, and it's still
easily handled, albeit on faster hardware.
I'll bet I could devise a solution that would cover 1,000,000
users (simultaneous), but it would take still more money.
I doubt that radius in it's current form would even get close to
handling a database that size, so I'd have to hack it as well,
(oops, merit already did it for me).
> 3. Has holes in it.
Please, point them out. I'll fix them. That's the whole point
of discussion, isn't it?
The difference is, I consider an effort, any effort, better than
useless debate about whether or not it will work. Excuses are
easy.
Cordially,
-----------------------------------------------------------------------------
Joe Portman - Alternate Access Inc. Affordable, Reliable Internet
baron@aa.net Seattle: (206) 443-3408 Seattle: (206) 777-7777
Tacoma: (206) 927-6010 Federal Way: (206) 838-8457
Bellevue: (206) 455-8414 Olympia: (360) 458-7279
Enumclaw: (206) 862-9423 Black Diamond : (206) 288-8809
To setup your account: set modem to 8-n-1, login as "new"
For questions or support, call our voice line (206) 728-9585.
-----------------------------------------------------------------------------