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

Tom Jebo tomjebo at microsoft.com
Thu Sep 29 14:31:52 MDT 2011


Thanks for your question about CIFS behavior.  One of the Open Specification team will contact you shortly to assist. 

Best regards,
Tom Jebo
Escalation Engineer
Microsoft Open Specifications

-----Original Message-----
From: Steve French [mailto:smfrench at gmail.com] 
Sent: Thursday, September 29, 2011 2:36 PM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: [Pfif] Maximum Simultaneous Request for CIFS behavior clarification

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



More information about the cifs-protocol mailing list