dce/rpc "client" api

[Gerald Carter]

Luke Kenneth Casson Leighton wrote:
> 
> the semantics [and i have just updated the comments] 
> are that cli_connect.c must receive / send full PDUs.
>
> it is therefore the responsibility of the caller 
> to ensure that data has a full PDU in it, and the 
> responsibility of the cli_nca*.c api-instances to
> return a full PDU in rdata.

This is good.

> then, the callers of cli_connect.c do not need to 
> _worry_ about PDU reassembly.  otherwise, you end up 
> in a right mess.

Please explain.  You're already having to assemble the 
PDU to pass to the cli_connect routines.  I agree
that the caller should only deal with full PDUs.
I don't see why it is ok for the caller to assemble 
the PDU but not reassemble on the way back.  Not 
disagreeing with you.  Just don't understand your comment.

> e.g the current implementation of cli_ncacn_np.c 
> [and all versions of samba's client-side DCE/RPC code] 
> uses an *incredibly* inefficient algorithm:
> 
> - write request PDU
> 
> - read 16 bytes.  decode this as a PDU header, including 
> length of response.
> 
> - read remainder of response PDU (exactly length bytes).

So we believe the PDU header?  Hmmm...I see why 
this is bad.  But could you enlighten me on how
you locate the end of the PDU without trusting 
the header information.  

> _however_, if it were to be made more efficient (use 
> SMBtrans) it would be a simple matter of updating 
> cli_ncacn_np.c and _no other code_.

ok.  I need to read up some to follow you here.  Go 
on and I'll catch up.

> yes... however if you have an architecture 
> where  each client is allocated its own process 
> per socket, sending  half a PDU only disrupts 
> the client itself, and noone and nothing else.

ok.  but I thought you were suggesting a single 
daemon to service all incoming / outgoing dce/rpc 
commands.  So you're suggesting a smbd model 
instead then.

> this principle is already employed in smbd, and i do 
> likewise with the TNG domain architecture.

I need to read up on the TNG daemons and setup more
I think.  If I understand correctly at the moment,
you have one set of RPC daemons which all smbd 
processes communicate with.  The smbd processes
act a proxy for each client connection.  Correct?







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 )