dce/rpc "client" api

[Peter Samuelson]

  [Jerry Carter]
> > You're now trying to equate KLOC with number of clients.  Those are
> > different things.

[Luke Leighton]
> ?
> 
> what is KLOC?

Source code size.  I think the acronym is "thousands of lines of code".
And I think Jerry's wrong.  Your quote was:

> > > by the same token, using one smbd process for *all* smbd 
> > > code is equally not scalable.

and I think Jerry took this to mean "using one smbd binary for all
dce/rpc interaction" whereas what you meant was "*if* we had a no-fork
architecture for smbd (i.e. one-process) it would not be scalable".

> for this particular reason, dce/rpc is generally inefficient, however
> that is actually the fault of the developers writing the client-app
> and sometimes the fault of the client dce/rpc transport
> implementation.

If it's really an issue -- might I suggest the pool-of-processes (aka
"prefork") architecture used in many web servers?  Web servers had to
solve the short-lived-connection problem long ago.  Here's what Apache
1.x does (2.x has a threaded mode so I don't know as much about it):
Basically you start up a number (the parameter `minspareservers') of
child servers and these children sit around until needed.  When you get
a connection in, rather than fork, you just hand it off to an idle
child.  If the number of idle children falls below the
`minspareservers' parameter you start forking more; if it rises above
the `maxspareservers' parameter, you start having children die off.
Apache also defines a maximum number of connections each child is
allowed to handle before it dies; this is to mitigate memory leaks (the
Apache group says it's for memleaks in system libraries but it would
also be useful if the Apache codebase has any).

Yes it's somewhat complex, involving a shared memory segment (the
"scoreboard") for the master to keep track of what all the children are
up to ... but much of the implementation can probably be stolen from
Apache.  I don't know if the number-of-forks issue is really worth it
for msrpc, though.  The old Unix culture of "fork() is massively
expensive and use should be minimized at all costs" is not always true
on modern Unices; Linux in particular has a fairly cheap fork().

Peter