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

Jeremy Allison jeremy at valinux.com
Tue Aug 22 20:56:11 GMT 2000

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.


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

More information about the samba-technical mailing list