patch: multi-part nttrans replies

Sam Liddicott sam at liddicott.com
Mon Jun 30 14:20:36 GMT 2008


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 merge them
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.git?a=commit;h=6334f3c7de921f896cc0c4d4919ced07465f2a56

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


More information about the samba-technical mailing list