dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On Mon, 21 Aug 2000 jeremy at valinux.com wrote:

> On Tue, Aug 22, 2000 at 01:52:51PM +1000, Luke Kenneth Casson Leighton wrote:
> > > >daemon idea until Andrew pointed out to me the problems with
> > > >is (scalability, reliability etc.)
> > 
> > [double-take].  scalability???  what???  how can scalability be relevant?
> > 
> > talk of scalability and reliability is, if you don't mind me saying so, a
> > load of rubbish, compared to just using a file descriptor for all data
> > transfer.
> 
> Scalability - using one daemon process for *all* dce/rpc
> code is *NOT* scalable.

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

we know that this is patently not the case, therefore using one daemon
process is equally not the case.


jeremy, may i remind you of the conversation that we had about.... mmm...
three months ago, where i finally realised what you considered the
implementation of the daemon architecture to be.

if i recall, you thought that the implementation was similar to nmbd.
namely, that there is only one daemon process and that it does not fork.

this being the case, of _course_ it's not scalable!!!!!!

having realised immediately that this would not be scalable after a few
seconds thought, i decided to copy the same system used in smbd, nay, in
fact i took smbd/process.c and cut and paste it to unrecognisable
smithereens.

in other words, immediately after an accept() there follows a fork(). just
like in smbd.

the consequences are that, apart from on VMS [discussions on this are in
the samba-ntdom or samba-technical archives, dated approximately nov 99 -
jan 2000] this is fully scalable.  for each DCE/RPC connection, there is
one DCE/RPC daemon.

john has to solve the [expensiveness of the] VMS fork() issue for smbd
anyway, so he would have to employ the same solution under the daemon
architecture, too.