On Wed, 01 Dec 2010 13:46:21 -0600 "Christopher R. Hertel" <[email protected]> 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 <[email protected]> _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
