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

[Luke Kenneth Casson Leighton]

On Tue, 22 Aug 2000, Jeremy Allison wrote:

> 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.

it's tricky :)

by "ignore", i assume you mean it strips it out successfully.  i also
assume that you are talking about the server-side impl. not the
client-side.

most of the burden of the logic regarding sending of PDUs efficiently and
successfully over SMB is done at the client-side end.

a successful server-side implementation is therefore less tricky.

a transport-independent server-side implementation is actually a valuable
task itself, as it clearly delineates where the layers are, making the
implementation task that much simpler and cleaner.

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

good.

is it suitable for use for putting a TCP/IP front-end on it?

is it suitable for adding the NETLOGON "Secure Channel" as an encryption
mechanism for netlogond?