[cifs-protocol] [REG:112030174895568] clarification of MaxMpx value in MS-CIFS
bburgin at microsoft.com
Thu Mar 1 14:28:36 MST 2012
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.
From: Christopher R. Hertel [mailto:crh at samba.org]
Sent: Thursday, March 01, 2012 11:56 AM
To: Jeff Layton
Cc: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
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
Section 18.104.22.168, 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.
"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/ -)----- crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh at ubiqx.org
More information about the cifs-protocol