dce/rpc PDUs [was Re: dce/rpc "client" api]

[Luke Kenneth Casson Leighton]

On Mon, 21 Aug 2000, Gerald Carter wrote:

> > strip out the headers.  concatenate the data.  you 
> > have the modified-DCE/RPC function arguments.  
> > unmarshall them.
> 
> This is at the dce/rpc level

yes.
 
> > different reassembly rules, which i split with cli_connect.c.
> > cli_connect.c handles individual PDUs.
> 
> ok...now you comment about the mess makes sense.
> Basically you were saying that the transport layer need
> only worry about dealing with complete PDUs and 
> fragment/reassembly the data as it was passed down the stack.

for the ncalrpc implementation, individual-PDU reassembly is... automatic
and integral with the way that write() and read() work.

for the ncacn_tcp implementation, ditto.

for ncacn_np, the SMB transport _really_, _really_ gets in the way of
this individual PDU reassembly, as what SMBs are used are not only
dependent upon the size of the PDU, but on the client's maximum SMBtrans,
SMBreadX and SMBwriteX buffer sizes, on whether the first and/or last bits
are set in the PDU header, and _also_ on what is negotiated during the
Bind / Bind-Ack sequence: it is possible for NT5 to negotiate - somehow -
to _not_ use SMBtrans but only to use SMBreadX and SMBwriteX, which
incidentally allows for the "cancellation" of outstanding DCE/RPC
requests, at the cost of doubling the round-trip time on every DCE/RPC
function call.

> If the dce/rpc data (parameters) had been fragmented
> at the dce/rpc layer, then the transport layer should be
> ignorant of this.

correct.