tridge at linuxcare.com
Mon Dec 13 22:52:15 GMT 1999
> 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.
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
- 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.
More information about the samba-technical