[openbeosnetteam] Re: general or PPP ideas
- From: "vladimir reikine" <vreikine@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 04 May 2003 15:44:46 -0400
>> I think it's too complicated. I like the idea the SeOS is using - create a
>kernel module that would overload open() call. By replacing open() call you
>don't create API dependancy and it's easier to port other applications. SeOS
>module would also grab information about current user from process tables
>and pass it to userland DB process that will do authentication and whatever
>you need to do.
>
>I have not understood you here. Could you please explain it more detailed,
>please?
>There is no open() call in modules (like the authentication module), only in
>drivers.
Well, SeOS is doing it for different reason - it suppose to make Unix or
Windows more secure. So they replaced standard system open() call with their
own.
So whatever userland application tries to open it has to go through
authentication module of SeOS. Don't get fooled by the name 'SeOS' - it's not
an OS it's just a secure subsystem for Unix and Windows. Replacement of
existing security schema with more secure. And it's commercial product. I think
other commercial security products are using the same idea. My point was leave
the authentication to userland application (as I think you planned) and don't
even create special hooks for it in your module - standard open() call is
enough.
>> >> > But this removes the possibility to make a PPP connection inside
>> >> > the kernel. And it adds dependency on a userland application or
>> >> > complicated
>> >> > userland API. I would prefer to make it very easy. If the
>> >> > authenticator asks
>> >> > the userland DB it must block until each user is authenticated.
>> >>
>> >> Why? It could be asynchronous.
>> >
>> >Is my idea similiar to what you thought of when you wrote "asynchronous"?
>>
>> I thought that PPP portion in the kernel would only create /dev/net/ppp
>device (or something like that) and userland app would just open() it - this
>would be similar to using other devices. And what's wrong with blocking
>/locking ? It's authentication thread - it runs only once before connection
>is established. The rest of communications is not affected. Are you
>expecting to have high volume of PPP connection requests ?
>
>
>If anybody wants to use our PPP implementation and has 1000 requests/second
>it is useful if the authentication is done simultaneously. Do you think that
>under those circumstances someone would use a professional $10000
>application for this instead of our PPP implementation?
>Is blocking okay for 100 requests/second? This might be normal for a big
>university that cannot afford $10000 for a professional PPP software. I do
>not want that they use Linux or Free-/OpenBSD instead of OBOS just because
>it can process more connections per second.
>
Are you talking about PPP daemon that accepts connections from modem pool ? It
means at least 1000 modem lines or to be more realistic 10,000 modem lines.
I guess you know that there are hardware PPP implementations - old DEC terminal
server we throw away 10 years ago was capable of this. And they are not that
expensive - don't try to compete with hardware implementations.
>Oh, having 1000 requests at the same time means having 1000 threads at the
>same time. I heard that our limit is 1600 threads or so. Or was it the Zeta
>limit? Or is this completely wrong? I just remembered the number 1600 in the
>context of a kernel limitation.
>This might become a problem, so blocking is useful at some point anyway.
>
>Waldemar
>
I think the simpler you make it the faster it will be.
>
____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005
Other related posts:
