lsarpcd

[Andrew Tridgell]

> i cut/paste smbd as the basis for the daemon-starter, therefore in exactly
> the same way that smbd self-spawns for incoming SMB connections, the
> individual msrpc daemons self-spawn for incoming MSRPC connections, and
> terminate in the same way.

Luke,

I don't think we've yet seen a reason from you on why this stuff
should be in separate daemons, and we certainly haven't seen a reason
why it should be fork-per-request.

The only good reasons for this whole change so far have been:

- to allow you to develop separately, because we find it hard to
  co-exist in the same code tree (our development methodologies are so
  different) 
- to allow msrpc to run over different transports.

the above two reason suggests a single msrpc daemon that is long lived
and handles all rpc requests. 

> the amount of time that an average MSRPC daemon is up and servicing
> requests is of the order of... let's take a look at a netmon trace...
> srvsvcd will be up for 9ms to service a NetrShareEnum.  lsarpcd will be up
> for 16ms to service an LSaOpenPolicy / LookupSidss / LsaClose sequence.

I don't see anyone suggesting we have a separate process for strcpy(),
why do we have a separate process for this stuff???

the caller has to block waiting for the reply, the reply is guaranteed
not to block, it is short lived, it doesn't require a separate
security context and it doesn't need any special environment. That all
screams "library call". Why the hell fork a process? That just makes
the whole thing hugely more complex!

> >  Could not one daemon autospawn the required NT daemons on demand?
> 
> i don't see why not, however this would be best done in a startup script,
> don't you think?

I want to know why these daemons are *required* first.