[cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior
Jeff Layton
jlayton at samba.org
Wed Dec 1 13:19:33 MST 2010
On Wed, 01 Dec 2010 13:46:21 -0600
"Christopher R. Hertel" <crh at samba.org> wrote:
> Jeff,
>
> I am chiming in because my team and I spent a lot of time digging through
> the code that generated the Windows Behavior Note that you are referencing.
> I probably wrote that one myself.
>
> There is more information in [MS-CIFS] that should be referenced. The
> particular 30-second timer you are asking about is part of Windows, not part
> of the actual protocol. That's why it is listed as a WBN--it's really not
> needed for CIFS interoperability. It's just something weird that Windows does.
>
> In addition to that timer, however, there's another timer that *is* part of
> the protocol:
>
> - See section 3.2.2.1 and the associated WBN.
> There is a "Request Expiration Timer". The "Request Expiration Timer"
> is used by the NT client to determine whether or not the request
> should be canceled using an SMB_COM_NT_CANCEL. Note that the
> SMB_COM_NT_CANCEL command was introduced in the NT LM 0.12 dialect
> and is not part of earlier dialects.
>
> - In section 3.2.3, the "Request Expiration Timer" is identified within
> the state machine as "Client.SessionTimeoutValue". There is a
> WBN that points to a KB article with further information on the use
> of the SessionTimeoutValue. Read the entire KB article because there
> are caveats at the end of that article.
>
> - In section 3.2.6.1 there is a further explanation of the behavior of
> the Client.SessionTimeoutValue. This is the section which references
> the WBN about which you are asking.
>
> So, as I read the docs, here's what happens:
>
> - Every 30 seconds, the Windows client scans the list of outstanding
> commands to see if any of those commands have exceeded the
> Client.SessionTimeoutValue. The default starting point for
> Client.SessionTimeoutValue is 45 seconds but that number is modified
> as described in the KB article.
>
> + Some commands, such as NT_Trans/NT_Transact_Notify_Change are exempt.
>
> + Other commands (mostly transactions) have their own timeout value.
> If that timeout value is set to "infinite", then the outstanding
> request is exempt. Otherwise the timeout value is added to the
> Client.SessionTimeoutValue to ensure that sufficient time for a
> response is provided.
>
> - If the Client.SessionTimeoutValue (+/- all adjustments) has been exceeded,
> then the connection is closed. The suggested behavior is that an
> SMB_COM_NT_CANCEL should be sent, but that's not what Windows actually
> does. The idea of sending an SMB_COM_NT_CANCEL comes from a variety of
> historical sources. The Core Protocol probably specified that an
> SMB_COM_PROCESS_EXIT should be sent, and I believe that some of the
> older Microsoft documentation that I read also stated that
> SMB_COM_NT_CANCEL should be sent.
>
> ...and that is probably why the client sends an SMB_COM_ECHO. The original
> intent was probably:
>
> "Send the echo, if you get no response then the connection is dead so
> just close it, if you do get a response, then send the cancel command
> and keep going."
>
> ...but it wasn't actually implemented that way.
>
> My memory fails me at this point. I don't remember the exact interaction
> between the echo, echo response (or lack thereof) and the closing of the SMB
> session. It may be that the Windows clients only close the connection if
> the echo fails, but if that's the case then I don't know what happens with
> the outstanding commands.
>
> For the folks at Microsoft:
>
> - WARNING: Very old versions of CIFS could multiplex a *single SMB
> session* over multiple physical connections. It is
> possible that this Echo code was used to test *the
> connection* rather than *the SMB session*. Closing
> a single physical connection would not close the
> SMB session. Note that the WBN that Jeff references
> uses the term "connection".
>
>
> - Finding and understanding the code that actually performs the
> periodic check will be difficult. It is somewhat obscure
> particularly on the Windows98 client. That's my memory, anyway.
> It has been a long time since I had a look at that code.
>
> - The Windows98 client code and the Windows NT client code is
> *different*. You need to check both and look for different
> behaviors.
>
> - As you know, if there were changes made, those changes should be
> documented in [MS-SMB] rather than [MS-CIFS].
>
> Chris -)-----
>
Thanks Chris,
Yes, this is probably stretching the definition of protocol
clarification, but I figured it wouldn't hurt to ask... :)
--
Jeff Layton <jlayton at samba.org>
More information about the cifs-protocol
mailing list