freedce (was: Re: DCE/RPC NamedPipe Transport emulation)

[Luke Kenneth Casson Leighton]

On Mon, Sep 03, 2001 at 10:27:06AM +0100, Wez Furlong wrote:

> OK, so I'm not talking about NamedPipes specifically,
> just about freedce where my comments are relevant
> to some of the things that luke has said...
 
ack.  subject-line change time :)

> That said, I tend to favour using freedce because:
> (in no particular order)
> a) I'm biased
> b) It means that it is being used for something real,
>    which gives me another reason to contribute to it.
> c) It will save you a lot of coding effort in dealing
>    with RPC, and that is (after all) the reason that
>    DCE/RPC was invented.
> 
> On 03/09/01, "Luke Kenneth Casson Leighton" <lkcl at samba-tng.org> wrote:
> > 1) freedce - the OSF rpcd.
> [...]
> > basically, the rpcd application - as outlined by ep.idl,
> > is incredibly simple.  it's an implementation of:
> [...]
> > this provides the dynamic contact point management.
> > it's a berkeley db implementation, it's used internally
> > as well as on-wire.
> 
> It's not actually berkeley db; it's a custom db implementation
> that has it's interface published as IDL (local only, IIRC).

that's cool [thanks for correction]

> > advantages / disadvantages - afaict.
> > 1) freedce.
> > adding new transports is trivial, given that wez
> > structured the code such that transports are now
> > dynamic loading modules (he moved a series of
> > existing functions behind a dso loader - that was
> > it!).
> 
> It could do with a little bit of tidying up, but yes -
> thanks to the forethought in the original freedce
> codebase, this was easy.  One thing that would be nice
> would be to delay loading the modules until they were
> needed (currently all modules are loaded at library init).
> I'm not sure if this would work, since the libraries need
> to know which transports are available before they can
> use them (duh!), but for client apps this should speed
> things up (I'm thinking of COM applications, which probably
> won't use the network).
  
well, then... uh... how about...
performing the moduleload in the first server-side
fnction call, or is it possible to detect server/client?
this has to be done, i know, for memory decisions
in marshall/unmarshall.

and performing individual load, otherwise, on-demand?

or is that too much to do right now?

> > developing new client / server apps is trivial.
> > the addition of a namedpipe transport module
> > makes NamedPipe capability availably *instantly*
> > to *existing* applications, with a kill -HUP
> > or a service restart.
> 
> It would have to be a service restart with the current
> implementation.

ack.

> > server application-wise: freedce is a threaded
> > architecture.  here, we're hit by limitations
> > on the threading library (it's the old POSIX
> > draft 4 model!) which we're investigating doing
> > an APR version of, to get full platform-independence,
> > even on NT and OS/2, but that's a _big_ project
> > to do properly.
> 
> I don't think making it work with APR would be too bad.
> Here's one method; using the dcethreads code, replace
> the linuxthreads pthread calls with the corresponding
> APR calls. Recompile and cross your fingers :)
> Then we can merge the dcethreads in freedce and get
> rid of those draft 4 calls.
 
:)

> > but, threads offer a speed advantage: you can 'prep'
> > ten threads (the default) which never die, they just
> > are put to sleep and wake up on receipt of packets.
> 
> The number of initial threads is something I plan to
> look into; again, taking COM as an example, we probably
> won't need so many threads, so I will see if there is
> a way to reduce this number for some apps.
 
apache has a config option - max processes
and min processes.

> > given that TNG is slated for replacement with
> > freedce services, it doesn't bother me that it's
> > a 5-10ms response time, at best [compared to a 1-4ms
> > response time from NT of the same calls, last
> > time i checked].  so... irrelevant.
> 
> Are you saying that TNG is slower than NT, or that
> freedce is slower than NT? (or should I say,
> "less reponsive"?)

at a guess:

freedce equal or on-par performance to NT (1ms)

TNG appx order of magnitude slower (10ms instead of 1ms)

> > advantages regarding licensing of the three
> > remaining methods:
> 
> > 1) freedce.  freedce is released under an OSF/1
> > BSD-style license.
> 
> Just to clarify; the draft 4 threads library (dcethreads)
> is GPL, but freedce itself is OSF/1 BSD-style.

thanks!