[cifs-protocol] [REG:112030174895568] clarification of MaxMpx value in MS-CIFS

[Bryan Burgin]

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: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 
> 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/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org