[cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior
Christopher R. Hertel
crh at samba.org
Wed Dec 1 12:46:21 MST 2010
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 -)-----
Edgar Olougouna wrote:
> Jeff,
>
> I am researching this and will update you as soon I have news.
>
> Regards,
> Edgar
>
> -----Original Message-----
> From: Sebastian Canevari
> Sent: Wednesday, December 01, 2010 8:54 AM
> To: Jeff Layton; Interoperability Documentation Help
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: [cifs-protocol] Requesting clarification of CIFS client timeout behavior
>
> Thanks for your question Jeff.
>
> Someone from my team will follow up with you shortly.
>
> Regards,
>
> Sebastian
>
> Sebastian Canevari
> Escalation Engineer, US-CSS DSC PROTOCOL TEAM
> 7100 N Hwy 161, Irving, TX - 75039
> "Las Colinas - LC2"
> Tel: +1 469 775 7849
> e-mail: sebastc at microsoft.com
>
>
>
> ________________________________________
> From: cifs-protocol-bounces at cifs.org [cifs-protocol-bounces at cifs.org] on behalf of Jeff Layton [jlayton at samba.org]
> Sent: Tuesday, November 30, 2010 9:24 PM
> To: Interoperability Documentation Help
> Cc: pfif at tridgell.net; cifs-protocol at samba.org
> Subject: [cifs-protocol] Requesting clarification of CIFS client timeout behavior
>
> I have a number of questions regarding Windows behavior with respect to call timeouts. MS-CIFS says this in Appendix A:
>
> <186> Section 3.2.6.1: Windows NT and Windows 98 CIFS clients
> periodically scan for any commands that have not completed. The
> default scanning period is 30 seconds. If there are outstanding
> commands that have exceeded the Client.SessionTimeoutValue, an
> SMB_COM_ECHO (section 2.2.4.36) is sent to determine whether or not
> the connection has been lost. The client closes the connection only
> if there is no response to the echo request.
>
> My questions are as follows:
>
> 1) If the server is responding to the echo requests, does the client
> still eventually return an error to the application or does it wait
> indefinitely for the response?
>
> 2) If it returns an error to the application, does the client send a
> SMB_COM_NT_CANCEL to cancel the outstanding request?
>
> 3) If it waits indefinitely, does it send more than one echo request?
> If so, how frequently are they sent?
>
> 4) Do more recent versions of Windows behave similarly?
>
> --
> Jeff Layton <jlayton at samba.org>
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
--
"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
mailing list