[Multipart nttrans replies 3/3] Take 4: multi-part nttrans replies

[Sam Liddicott]

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 :-(