[openbeosnetteam] Re: general or PPP ideas

> >> > I would like to use userland user-DB-add-ons because it puts less
> >> > code into
> >> > the kernel.
> >>
> >> You could have a kernel-level protocol module talk to some generalized
> >> password database.
> >
> >This is what I wanted to do, but this module would have to be developed
and
> >it would reside inside the kernel.
> >
> >The DB module asks the userland DB process through a port. The userland
DB
> >process loads DB add-ons. I will define some add-on API so everyone who
> >wants to implement his own DB add-on does not have to write a kernel
module,
> >but only a new userland DB add-on. The DB process loads the add-ons and
> >creates a thread for each authentication request.
> >How does the authenticator get the result? Can it just read the thread's
> >message queue? The userland add-on would get a thread_id and write the
> >result to it.
> >All requests would be distributed through threads and all authentications
> >would work simultaneously.
> >
> >I hope this was understandable. :)
> >
> 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.

> >> > 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.

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

Other related posts: