dce/rpc PDUs [was Re: dce/rpc "client" api]
Luke Kenneth Casson Leighton
lkcl at samba.org
Wed Aug 23 08:29:32 GMT 2000
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
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.
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?
More information about the samba-technical