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 ...

+ Reply to Thread
Results 1 to 2 of 2

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

  1. 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


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


+ Reply to Thread