Steve, 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:[email protected]] Sent: Thursday, September 29, 2011 2:36 PM To: Interoperability Documentation Help Cc: [email protected]; [email protected] Subject: [Pfif] Maximum Simultaneous Request for CIFS behavior clarification Resending with correct title. On Thu, Sep 29, 2011 at 1:09 PM, Steve French <[email protected]> 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
