triple allocation of large buffers.

[Amin Azez]

* Stefan (metze) Metzmacher wrote, On 17/01/08 07:37:
> Hi Sam,
>
>   
>> vfs_proxy now uses rpc for passing proxied read requests in order to
>> easily support various compression types, and I'm wondering if this is a
>> bad idea...
>>     
>
> I think using rpc for file access is a bad idea, it makes only sense for
> management stuff.
>
> I think it would be better to use the trans2 (or was it nttrans)
> subcodes, to implement for cifs proxy. Your aim for the whole project is
>  performace, so should really do it at the SMB level.
>
> Note: you can still use ndr encoding for some sub-opcodes content,
> but for read and write you should avoid it.
>   
I'm sincerely glad you said this today...

so if I use trans2 directly, async will work fine, and I'll still have
my tid context.

I'll derive from dcerpc.c/dcerpc_ndr_request_send() to easily get a
DATA_BLOB which can form the payload of my trans2 sub-op.
(Like an rpc-lite where the sub-op-code and tid context replaces the
GUID and bindings)

I'll also add (if missing) support so that the rpc out struct can have
pre-allocated pointers for variable arrays to be unpacked to; sort of
like [in,out] uint8 *x; where the caller provides storage, except for
out-only params. (If its not there already).
> Also note there're known bugs in our dcerpc client code,
> in the handling of broken connections.
>   
which might not affect rcp over smb?
> And the dcerpc server code doesn't support async requests
> via the smb transport (ntvfs/ipc/).
>   
I'm trying to think why, but I'm stumped...

Thanks very much for your advice.

Sam