rpc-lite

[Amin Azez]

I'm calling what I'm doing rpc-lite, which is using the NDR functions to
construct SMB packets at the smb-op level.

it involves abusing some nrd code which may utimatly involves some very
small but wide-reaching changes to make the use of smbcli_request (and
->output) more inter-changable with the use of ndr_push.

rpc-lite will have the top level ndr_push for an rpc (e.g.
ndr_push_proxy_Read) be able to push onto an established "struct
smbcli_request*" (and it's member: struct request_buffer *out)

struct ndr_push is functionally similar to struct smbcli_request (
combined with its out member)

request_buffer->ptr serves the same function as ndr_push->offset

The NDR is resized using ndr.c/ndr_push_expand(ndr_request, increment)
The request_buffer is grown using:
smbcli_req_grow_allocation(smbcli_request, newsize)

The abusing method would be to have a new ndr_push_init_smbcli_ctx()
method which set up:

ndr_push->data = req->out.buffer;
and ndr_push->offset = PTRDIFF(req->out.data,req->out.buffer);
and ndr_push->alloc_size = req->out.allocated;

so that pushing would occur on the data portion of the smbcli_request.

Thus, when ndr_push_expand is called, the talloc_realloc is safe as it
occurs on an original talloc'd buffer.

After the push is compete, the smbcli_request could be mended fixed up thus:
if (ndr->data != req->out.buffer) {
    /* re-alloc occured */
    req->out.allocated = ndr->alloc_size;

    /* update the pointers into the packet */
    req->out.data = ndr->data + PTR_DIFF(req->out.data, req->out.buffer);
    req->out.ptr  = ndr->data + PTR_DIFF(req->out.ptr,  req->out.buffer);
    req->out.vwv  = ndr->data + PTR_DIFF(req->out.vwv,  req->out.buffer);
    req->out.hdr  = ndr->data + PTR_DIFF(req->out.hdr,  req->out.buffer);

    req->out.buffer = ndr->data;
}

Now this is a total abuse of ndr expectations, but I think that it is
safe, and will avoid the need to copy buffers.
Maybe all we need to do is change expectations?

This is the angle I am working on right now, I welcome any comments.

Sam

* Amin Azez wrote, On 17/01/08 10:21:
> * 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.
>>   
> Trans2 does so much copying when sending too... I think the most
> efficient thing to do is to steal a new top level operation like I did
> in the first place, but just use NDR to produce the whole packet.
>
> If the NDR packer will work nicely with smbcli_request_setup() and
> struct request_buffer (and that doesn't seem too hard) then it can
> start packing on the end of the smb header. It will be harder to do
> that for trans2 because of all it's requirements, but maybe I can work
> up to that.
>
> So... lets see how that goes.
>
> Sam