RE: [Multipart nttrans replies 3/3] Take 4: multi-part nttransreplies - Samba
This is a discussion on RE: [Multipart nttrans replies 3/3] Take 4: multi-part nttransreplies - Samba ; I remember why I didn't want to actually receive the response in the handler.
For most requests, the receive buffer (in the smb_* struct) is pre-allocated by the caller, and for vfs_cifs and vfs_proxy they are pre-allocated in the partially ...
-
RE: [Multipart nttrans replies 3/3] Take 4: multi-part nttransreplies
I remember why I didn't want to actually receive the response in the handler.
For most requests, the receive buffer (in the smb_* struct) is pre-allocated by the caller, and for vfs_cifs and vfs_proxy they are pre-allocated in the partially constructed response packet, and so memcpy and stuff can be avoided, so effectively io->out.data is an input argument.
Thus it is not generally possible or worthwhile to receive the response unless the callers io struct is available.
But I did not check to see if that was specifically true for the cases thatneed multi-part responses, and it seems not to be the case but I'l check when I have a screen resolution of more than 320x240.
This helper mechanism is simplified to naturally suit operations that don'tpre-allocate a data buffer for the response.
There may not be other types that also need a helper, but it ought to be commented I think.
Sam
-----Original Message-----
From: Sam Liddicott
Sent: 05 July 2008 07:40
To: Stefan (metze) Metzmacher
Cc: samba-technical
Subject: RE: [Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies
You beat me.
I did think of actually receiving the response in the helper, just not for very long.
I also missed clearing the req->in after each part.
Thanks for looking over that and for the better job of it.
Sam
-----Original Message-----
From: Stefan (metze) Metzmacher
Sent: 04 July 2008 20:10
To: Sam Liddicott
Cc: samba-technical
Subject: Re: [Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies
Sam Liddicott schrieb:
> This patch allows smb_raw_nttrans_recv to handle multi-part responses
> even when used asynchronously from a callback.
I'll commit a different approach to fix this problem,
it'll change much less of the core code and has less potential
to bugs in the recv helpers.
here's the branch:
http://gitweb.samba.org/?p=metze/sam...-0-recv-helper
metze
-
Re: [Multipart nttrans replies 3/3] Take 4: multi-part nttransreplies
Stefan (metze) Metzmacher wrote:
> Hi Sam,
>
>
>> I remember why I didn't want to actually receive the response in the handler.
>>
>> For most requests, the receive buffer (in the smb_* struct) is pre-allocated by the caller, and for vfs_cifs and vfs_proxy they are pre-allocated in the partially constructed response packet, and so memcpy and stuff can be avoided, so effectively io->out.data is an input argument.
>>
>> Thus it is not generally possible or worthwhile to receive the response unless the callers io struct is available.
>>
>> But I did not check to see if that was specifically true for the cases that need multi-part responses, and it seems not to be the case but I'l check when I have a screen resolution of more than 320x240.
>>
>> This helper mechanism is simplified to naturally suit operations that don't pre-allocate a data buffer for the response.
>>
>
> It should be easy to let the *trans*_recv_helper functions to handle
> preallocated buffers.
>
How? They won't have the smb_* struct to unpack to, only the *_receive
has that.
> The trans[2] and nttrans client and server should now be in sync and
> support multi fragmented async requests and replies.
>
> (There still some alignment bugs, but they were there before too).
>
> Now you can transfer buffers larger than 64k with a nttrans
> and it's using just 2 round trips.
>
Thats brilliant.
> nttrans req ->
> <- nttrans interim resp
>
I didn't know it worked like that for large requests
> nttranss req ->
> nttranss req ->
> nttranss req ->
> nttranss req ->
> <- nttrans resp
> <- nttrans resp
> <- nttrans resp
> <- nttrans resp
>
> Where each packet fits into the max buffer size.
>
> Please let me know how it works for you..
>
I will. I saw the patches this afternoon, I think you did a very
thorough job; not like my timid patches.
thanks
Sam
p.s. still no tool in the post :-(
