[Multipart nttrans replies 3/3] Take 4: multi-part nttrans
replies
Sam Liddicott
sam at liddicott.com
Sat Jul 5 07:15:10 GMT 2008
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.
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 <sam at liddicott.com>
Sent: 05 July 2008 07:40
To: Stefan (metze) Metzmacher <metze at samba.org>
Cc: samba-technical <samba-technical at lists.samba.org>
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 <metze at samba.org>
Sent: 04 July 2008 20:10
To: Sam Liddicott <sam at liddicott.com>
Cc: samba-technical <samba-technical at lists.samba.org>
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/samba/wip.git;a=shortlog;h=v4-0-recv-helper
metze
More information about the samba-technical
mailing list