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

[Jeremy Allison]

Luke Kenneth Casson Leighton wrote:
> 
> 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.

The current HEAD code is able to ignore all this stuff.
Writes are coalesced - whatever method they come in via,
into PDU chuncks, which are then stripped, de-sign/sealed
if neccessary, then the data is appended to a linear buffer.

Once the full RPC length (multi-pdu or not) is received
then it's handed down to the implementation layer.

This is very clean and simple and is working well in HEAD.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------