triple allocation of large buffers.
azez at ufomechanic.net
Thu Jan 17 10:00:30 GMT 2008
* 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.
More information about the samba-technical