[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 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 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