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

[Gerald Carter]

Luke Kenneth Casson Leighton wrote:
> 
> there are potentially two levels of PDU assembly.
> 
> level 1)
> 
> take the DCE/RPC function-arguments, marshall them 
> into a contiguous data stream which may be larger 
> than 0x1630-0x10 bytes, and split them down
> into 0x1630-0x10 byte segments, add a 0x10 byte 
> header at the front and call each one a PDU 
> (protocol data unit).
> 
> send them.  receive them.
> 
> strip out the headers.  concatenate the data.  you 
> have the modified-DCE/RPC function arguments.  
> unmarshall them.

This is at the dce/rpc level

> level 2)
> 
> take each PDU (of which there may be several).  
> take any transport, and use it to send each [independent 
> PDU].  the transport *MAY*, at its own discretion, fragment 
> the PDU.  the transport *MUST* reassemble any
> arbitrary fragments back into a contiguous stream.
> 
> 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.
If the dce/rpc data (parameters) had been fragmented
at the dce/rpc layer, then the transport layer should be
ignorant of this.  Gotcha.  Yes, of course.  Just didn't
understand what you were saying.






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 )