Hi, Jeff, We created the case 112030174895568 to track this issue.
Chris, thank you for your reply. We researched this issue a few months ago with Steve. The outcome of our analysis can be found at https://lists.samba.org/archive/cifs-protocol/2011-October/002207.html. Please let me know if this resolves your issue. If not, I would be happy to research this further for you. Bryan -----Original Message----- From: Christopher R. Hertel [mailto:[email protected]] Sent: Thursday, March 01, 2012 11:56 AM To: Jeff Layton Cc: Interoperability Documentation Help; [email protected]; [email protected] Subject: Re: [cifs-protocol] clarification of MaxMpx value in MS-CIFS On 03/01/2012 11:19 AM, Jeff Layton wrote: > Dearest Dochelp... > > We in the Linux CIFS client community are attempting to clean up our > code to make it better respect the MaxMpxCount value that the server > advertises in the NEGOTIATE request. > > MS-CIFS currently says this: > >> MaxMpxCount (2 bytes): The maximum number of outstanding SMB >> operations that the server supports. This value includes existing >> OpLocks, the NT_TRANSACT_NOTIFY_CHANGE subcommand, and any other >> commands that are pending on the server. > > It is rumored however that servers are not supposed to count certain > command types against this limit. For instance, SMB echoes and > blocking locks. My questions are: > > 1/ what do windows servers do in this regard? Do they count all > outstanding requests against the maxmpx value, or are certain commands > exempted? Section 3.3.5.33, which covers the server's handling of an echo request, does not list the echo as exempt. It does, however, indicate how a cancel request would be handled. As I recall (the truth is in the code), you cannot cancel a request that is *not* in the PendingRequestTable. That would suggest that SMB_COM_ECHO is not exempt from MaxMpxCount. ...but it would be good to check. My memory is that SMB_COM_ECHO may be handled separately since it can be executed without a SessionSetup or TreeConnect. The thing is, an SMB_COM_ECHO must follow (at minimum) a NegotiateProtocol, which would provide the server's MaxMpxCount. ...so, SMB_COM_ECHO *may* be counted against the MaxMpxCount. > 2/ do windows clients ever send more than MaxMpxCount requests at a > time? For instance, suppose I have a MaxMpxCount of 50 and I spawn 100 > threads that attempt to acquire blocking locks. What happens at that > point? Will the client end up using all of the slots for blocking > locks in such a way that nothing else can get through? Or does it > allow you to exceed that value somehow? > > Thanks for the info! There is code specific to this in both Windows 98SE and NT4 Server (and all subsequent clients). I do not recall what the code says. A shame, as that's where the answer lies. Note to DocHelp: The client code will go through and cancel outstanding requests that have timed out. That code is rarely exercised, I'd guess. I just recall that it's there. Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- [email protected] OnLineBook -- http://ubiqx.org/cifs/ -)----- [email protected] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
