dce/rpc "client" api

[Mayers, Philip J]

Hmm. It depends on what you consider "the RPC library". I was under the
impression we're talking about PDU creation (marshalling and unmarshalling)
and the associated infrastructure. Since you're only supporting one type of
transport (SMB) a lot of the infrastructure isn't needed (like an endpoint
mapper) but it's still a (mini) RPC runtime library, isn't it?

Is the auto-generated RPC code on the cards any time soon? If not, then
you're using hand-coded RPC marshalling, with no transition overhead to a
new system, in which case it's a mini-RPC runtime, with no transparent
network layer/encryption/endpoint mapping/etc. You've got this kind of
process:


network transport (TCP/SMBtrans) -> RPC PDU (fragmentation) assembly ->
encryption/authentication -> marshalling/unmarshalling -> opcode/function
mapping -> function call

This hypothetical mini-runtime implements steps 2 (and 3??). Samba's SMB
implementation implements step 1. Code in the RPC service .so's would
recieve whole PDUs, so sites at step 4 (or 3, depending on where encryption
lies).

Note, to be absolutely clear - I'm not proclaiming either one or other other
way of doing things. It depends on your priorities. As far as I can see,
Samba is going for a NT domain client, so the existing type of codebase is a
low-overhead way of doing things - debug the data-type marshalling routines,
put the TNG implementation behind them - cook for 2 minutes. Bing! done...

Alternatively, if the effort to move to IDL/compiled marshalling code were
ever made, I think it would adviseable to structure the code in a way which
allows the RPC runtime to be replaced with a more generic library.
Unfortunately, that makes in-process running of the various RPC services
difficult, which I think is Luke's point. The RPC services would have to sit
at step 5/6 boundary.

So, to summarise (correct me if I'm wrong)

1) DCE/RPC has (mostly) a transport-independent structure for it's PDUs.
Luke favours the creation of a generic, transport-independent library for
marshalling, unmarshalling, endpoint-mapping, authentication/encryption, and
all the services associated with the RPC runtime under Win32

2) Jeremy, Andrew (and optionally others), for *Samba*, favour
implementation of per-data type marshalling functions, using the service
implementation code from TNG. This would allow them to marshall to/from SMB,
and pass full RPC PDU's to/from dynamically-loaded modules, which actually
*implement* the services.

The problem is that option 1) requires the RPC runtime to do lots of stuff
which Samba would do in option 2. So codebase 1 and 2 might now work well
together, given the favoured RPC implementation in samba.

======================

Would it be possible to write an RPC library with optional hooks in it. That
way, Samba could (in the future, after 3.x has stabilised, if the developers
want to) use that library/IDL-compiler, and hook in at the points between
1/2 and 3/4 (or 2/3). Other services, like our hypothetical "Exchange"
server, could let the RPC runtime handle the network stream level and
optionally everything right up to calling the implementation functions.

If the developers wanted to, in the fullness of time, Samba could be
extended to use more of the library, although step 1 is probably always
better off in SMBD.


======================

Disclaimer: This is what *I thought* we were talking about. I could be
talking out of my ear, so could someone correct me?

A gnarly problem indeed...

Regards,
Phil

+----------------------------------+
| Phil Mayers, Network Support     |
| Centre for Computing Services    |
| Imperial College                 |
+----------------------------------+ 

-----Original Message-----
From: Gerald Carter [mailto:gcarter at valinux.com]
Sent: 21 August 2000 17:32
To: Mayers, Philip J
Cc: 'samba-technical at samba.org'
Subject: Re: dce/rpc "client" api


"Mayers, Philip J" wrote:
> 
> The real shame of it is that two DCE/RPC libraries 
> might end up being available. If you're using an 
> IDL compiler, which calls the library to marshall/unmarshall, 
> then the non-Samba library is going to make sense, and
> the auto-generated codebases (samba and not-samba) are
> going to diverge. That could be costly in the future.

I don't think we are talking about implementing a dce/rpc
over SMB library in Samba.  Just supporting the necessary 
services that clients require to do our job.








Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com  VA Linux Systems    gcarter at valinux.com
       http://www.samba.org       SAMBA Team           jerry at samba.org
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )