[cifs-protocol] [Pfif] Maximum Simultaneous Request for CIFS behavior clarification

[Steve French]

Resending with correct title.

On Thu, Sep 29, 2011 at 1:09 PM, Steve French <smfrench at gmail.com> wrote:
> I would like clarification on the how the maximum number of cifs
> simultaneous requests are enforced, and for which cifs operations they
> apply to.  In part this is to avoid triggering a serious problem in
> Windows 7 and Windows Vista (when they are run as a server) when
> exceeding this limit on simultaneous requests.
>
> What I have observed in my testing:
> - Although Windows 7 and Vista allows more than 10 simultaneous SMB
> write requests (and Windows 2008 allows more than 50 simultaneous
> write requests), Windows 7 and Windows Vista appear to have problems
> when 20 or 30 are in flight at one time.
> - Windows does not enforce a limit on SMB Negotiate Protocol
> - Windows seems to ignore checks on maximum simultaneous requests on
> certain handle based operations (SMB writeX in particular) until after
> the file is closed (the writes don't get an error, but the next
> QueryPathInfo after the file is closed gets an error).
>
> I need to understand on which requests (besides SMB Negotiate) I
> should ignore MaxMpxCount.  In particular, SMB Echo, seems like an
> obvious choice to ALWAYS allow to be sent by the client, since SMB
> Echo is sent to make sure the server is alive (when for example the
> limit on simultaneous requests has been reached due to slow opens, or
> writes past end of file) and to prevent timeout.   If a client is
> restricted from sending SMB Echo then there is no reasonably reliable
> mechanism available to determine whether the server is dead or just
> hung temporarily processing slow requests.
>
> MS-CIFS is not clear on which commands MaxMpxCount is enforced.
>
> I would like to ignore MaxMpxCount on (sending one of) SMBEcho (where
> you could cause data integrity issues if you limited the ability to
> check server state up/down) and SMBNegotiate (where it is obviously
> not set yet) and SMBOplockBreak responses (since you can't guarantee
> the order that these are received/sent from the server relative to
> other frames which are being processed, and can cause the server
> session to drop if you don't allow the client to send these) to the
> server since there is no reasonable mechanism to limit these without
> risking problems with prematurely taking down a slow session (perhaps
> opens of offline files for example).
>
> It looks like the safest way to handle this is for the client to limit
> pending requests to the MaxMpxCount, with the exception of the three
> SMB types listed above.
>
> In previous versions of MS-CIFS there were mentions of different
> processes, and uids on the negotiated tcp session and their relation
> to the MaxMpxCount - and I would also like to verify whether the
> limits are considered relative to some combination of the negotiated
> tcp session and uid and/or pid as earlier discussions implied (or file
> handle, as our testing hinted at).
>
>
>
>
>
> --
> Thanks,
>
> Steve
>



-- 
Thanks,

Steve