darn tootin' Re: rpc-lite

[Amin Azez]

Grrr....

Unless I add an "rpclite" operation to ntvfs_ops I have to stick within
the operation types already defined, which means a trans2 is the only
choice, - but trans2 seems to waste so many bytes on headers that I can
do without, more than I need to transport my actual arguments.

(Is trans2 a pre- dcerpc rpc mechanism?)

Also, although trans2 can assemble multi-packet requests, it seems to
want to send a reply_trans_continue message after each piece in order to
trigger the sending of the next portion - which is hardly good for a
solution designed to optimize high latency networks - but yes I can see
how it stops overstuffing of the tcp window on low-bandwidth networks,
which could result in smb timeouts.

But although that is bad news, it's not as bad as the near 130 byte
overhead dcerpc was giving me (which supposedly can't async over smb
anyway).

So, I've got two angles:

1. investigate trans2 a bit more and see if I can get the benefit
without re-writing the whole of rpc-over-trans2 (which surely is what
dcerpc was anyway)

2. avoid the trans2 overhead and steal a top-level code for proxy
operations, effectively just using the NDR libs to marshal the arguments
(as described in my previous mail, and now working), and suffering no
worse overheads than SMBREADX and friends (i.e. precious little)

I can see that trans2 is the formal "interoperable" way to go, but this
layering of protocols is nuts, doesn't seem handled well (poor for low
latency) and doesn't work right either (nor async for dcerpc over smb)
and wasteful with large overheads.

I'll give 1 a go, but I don't hold out much hope of avoiding 2 and
adding a new operation to ntvfs ops like I did in the first place.

Sam