DCE/RPC NamedPipe Transport emulation

[Wez Furlong]

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...

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).

> 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).
 
> 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.

> 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.

> 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"?)

> 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.

--Wez.