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

[Stefan (metze) Metzmacher]

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.

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.

nttrans req  ->
             <- nttrans interim resp
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..

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20080708/e0456096/signature.bin