patch: multi-part nttrans replies - Samba

This is a discussion on patch: multi-part nttrans replies - Samba ; Those who have an interest in async mutli-part nttrans replied, or extending smbcli_request or modifiying smbcli_transport_finish_recv will want to review this patch. I'm told a similar helper may also be needed for trans2 and trans. Stylewise, the helper function smb_raw_nttrans_recv_helper ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: patch: multi-part nttrans replies

  1. patch: multi-part nttrans replies

    Those who have an interest in async mutli-part nttrans replied, or
    extending smbcli_request or modifiying smbcli_transport_finish_recv will
    want to review this patch.

    I'm told a similar helper may also be needed for trans2 and trans.

    Stylewise, the helper function smb_raw_nttrans_recv_helper in the patch
    is similar to smb_raw_nttrans_recv because I was hoping to mergethem
    to a single function which could validate and/or convert to the
    smb_nttrans struct (depending whether or not smb_nttrans *parm was
    passed), thus keeping the sanity and decoding logic all in one place;
    however the fact that one adds to helper->part and one consumes from
    helper->part could make the additional complexity of merging them
    overcome the benefit.

    Patch at:
    http://repo.or.cz/w/Samba/vfs_proxy....9ced07465f2a56

    Async multipart nttrans responses could not be received because
    the synchronous call to wait on additional parts could not be
    called from an asynchronous callback handler.

    It would have been bad form to sync-wait in an async handler anyway.

    smbcli_request has been modified to allow the smbcli function that
    sends the request to register a callback and some data.

    Before calling the application specific callback,
    smbcli_transport_finish_recv() will try this library-specific
    callback helper.

    The library specific helper must set req->state
    back to SMBCLI_REQUEST_RECV if there are more parts to be received
    before the response is complete and can be presented to the
    application. The library helper does not need to re-add
    the smbcli_request to the transport pending list.

    The library helper will need to save req->in each time it is
    called so that the corresponding receive function can loop
    round each copy of ->in to get each response part.

    The helper is called even if there is no async callback
    registered by the application (req->state is kept at
    SMBCLI_REQUEST_RECV until enough parts are read) so
    there is no need to call smbcli_request_receive_more(), instead do:

    req->in=helper->part->in;
    smb_setup_bufinfo(req);
    DLIST_REMOVE(helper->part, helper->part);

    in the helper, which sets up the next fragment in req
    as if it had just been received.

    Sam


  2. Re: patch: multi-part nttrans replies

    I've re-worked yesterdays patch, I think this more a smoother piece of work.

    
    http://repo.or.cz/w/Samba/vfs_proxy....7a0215aefd1086

    It preserves the old request_more model for better encapsulationand
    uses the same function to check completeness as to unpack into smb_nttrans

    I'm not sure if DLIST_FIND from my dlinklist.h was put into mainline:
    http://repo.or.cz/w/Samba/vfs_proxy....v4-0-vfs-proxy

    This patch allows smb_raw_nttrans_recv to handle multi-part responses
    even when used asynchronously from a callback.

    smbcli_request has:
    1. a new member async_cli_helper which can contain an smbclient
    library specific helper callback, and some private data.
    2. a new in_parts member, which is a list of the smb_request_buffer's
    of responses to a request

    smbcli_transport_finish_recv() will append receive buffers to
    req->in_parts, if there is a helper callback, and then consult the
    helper callback to decide if all response parts have arrived (or
    if enough parts have arrived in the case of an error).

    smbcli_request_receive_more() has been modified to read the
    extra response parts from req->in_parts where these exist
    in order to preserve the semantics for *_recv handlers.

    smb_raw_nttrans_recv and smb_raw_nttrans_recv_helper are now merely
    thin wrappers for smb_raw_nttrans_recv_parts which has been refactored
    from smb_raw_nttrans_recv, and uses the same logic to either merely check
    or actually process the reponse parts into the smb_nttrans struct.

    This means that in order to support multi-part responses only a small
    change is required to the *_recv function, and that at the option of
    the author it could either store state so it can process just the new
    response part, or process all the parts in order each time.

    Once all parts are gathered, the state may need to be reset so that
    the parts can be properly processed.



+ Reply to Thread