> > > > 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.
>
Assuming the magic string go there, which doesn't reliably happen.
> > >
> > > 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.
>
Again, not an acceptable solution for all environments.
> > > > 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.
>
I don't have the problem, so I consider the solution irrelevant. However,
I do know from watching this list that many of the people don't want a bumper,
they want a way to deny new sessions.
> > 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.
>
BETA, read my lips BETA. BETA is supposed to be broken. That's why they
call it BETA. If you can tell me about an experience like that with a
released version of ComOS, (other than the early 2's, which even Livingston
admits had some nasty problems which they resolved quickly and re-released),
I'll be pretty surprised.
> > > 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.
>
Of the 100,000's of PortMasters sold each year, how many go to
these ISP's. See, it's not a question just of how many different companies.
It's a question of what represents the majority of the UNITS SOLD.
Of the ~20,000 ISPs, probably about 2000 are >500 PortMasters. Probably
around 10 are greater than 3000 PM's. However, that small fraction of
ISP's probably represents something like 75% of Livingston's units shipped.
Guaranteed _ALL_ of them think OSPF is more important than this.
> > 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.
>
Again, the bumper might scale, but many sites consider bumping an unacceptable
practice. I, for one, would not appreciate it if I got bumped in the middle
of a big download just 'cause I made a mistake and hit the wrong one of
the many services I can dial into on my other computer. Example:
John Doe has 2 computers. He has accounts with 3 online services
(Plodigy, America on Hold, and Compu$erve)
Also has accounts with 2 local ISP's.
Connects and is downloading latest version of 20MB package from
somewhere.
Lets it run for 3 or 4 hours.
Later decides to use other computer to do some surfing. Accidentally
selects wrong icon and connects (again) to your service
instead of other local ISP.
OOPS!!!
There goes that download, just as he was getting past half
way, you nuke it so he can surf. How considerate.
> > 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.
>
Yes and no. Also, some ISP's can have as many as 100,000 people logged
in simultaneously, and the database can be more like 1,000,000 records.
> 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.
>
Again, your solution assumes a bumper. I didn't catch this in my original
reply.
If I had, I would have pointed out the inadequacies.
> > 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.
>
OK, develop a solution that scales, allows us to deny the login in real
time, and doesn't break when a PM reboots and the accounting magic cookie
doesn't get through. Then, you can post it to the list and Livingston can
adopt it. Otherwise, stop whining about how easy 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?).
>
My solution is to avoid dialup. My only interest in this whole discussion
is to see that Livingston doesn't piss away valuable engineering time solving
this non-problem instead of the real priorities.
> > > 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.
>
Platform portability isn't the only issue. You handle it based on one
set of policies and your way of treating your users is downright hostile
and rude IMHO. Bumping off the established session in favor of the new
session is just plain bad. The new session should be denied.
> > 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.
>
But a large part of Livingston's customer base can't.
> 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.
>
But now you need multiple versions of the daemon(s) and testing becomes
more of an effort. Don't forget the overhead of SQAing all the possible
combinations.
> I'll bet I could devise a solution that would cover 1,000,000
> users (simultaneous), but it would take still more money.
>
Yep. And more combinations of hardware/software and more testing and more
engineering time, and all of a suddent it's starting to look alot less
trivial to implement.
> 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?
>
1. New session gets established.
2. Old session gets bumped.
3. Doesn't allow for different policies towards users.
> The difference is, I consider an effort, any effort, better than
> useless debate about whether or not it will work. Excuses are
> easy.
>
I consider the effort being spent on more important problems better than
any effort being spent on this one. That's why I keep making excuses
for this one. Sure, this problem _CAN_ be solved. However, solving it
right is:
1. Non-trivial
2. Not the highest priority
> 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.
> -----------------------------------------------------------------------------
>
>
Owen