On Thu, 9 Dec 2010 20:29:56 +0000 Edgar Olougouna <[email protected]> wrote:
> Jeff, > > If the server does not respond to outstanding requests, the expected behavior > is that the Windows client sends out an echo request. > > Can you consistently reproduce the scenario whereby the client does not send > the echo request? We would be interested to investigate this, if needed. > No, I've seen it happen a few times, but I can't reproduce it with any regularity. If however, the client is going to close down the connection regardless, the echo seems sort of pointless anyway. So, I don't see any need to investigate it. > We will update the Windows behavior note to reflect the fact that the client > closes the connection regardless of the echo probe response if there is no > response to the outstanding commands that "have exceeded" the > Client.SessionTimeoutValue. This update describes the behavior you observed > in your testing. > > Let me clarify a bit further. Like Chris mentioned, there are two key > factors, i.e. session timeout value and 30 seconds scanning interval for > outstanding requests. > > Per MS-CIFS Section 3.2.3, the Client.SessionTimeoutValue is set based on > system policy. The "default" session timeout value is 45 seconds in Windows > NT, and 60 seconds in Windows 2000 and onward. Per KB102067, > Client.SessionTimeoutValue could vary depending upon the client's policy. > The scanning for outstanding commands occurs every 30 seconds (request > expiration timer event). As a result this incurs a lag on the time the client > effectively closes the connection. > > For example, let's assume that at the scanning interval, an outstanding > command is due to expire in 8 seconds. The scavenger will not close the > connection at this time; it will be closed at the next scanning cycle. This > will result in: > Client.SessionTimeoutValue (45 seconds default for NT, 60 sec default for > Windows 2000 and beyond) - due seconds at the scavenger timer event (8 > seconds) + next scavenger time (30 seconds). > If it is the default 60 seconds session timeout, then the connection will be > effectively closed at 82 seconds. > > This is the provisional update to MS-CIFS: > > Current behavior note: > > <WBN> 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.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. > > Provisional Windows behavior note: > > <WBN> 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. Regardless of > receiving the SMB_COM_ECHO response, the client closes the connection if > there is no response to the outstanding commands that have exceeded the > Client.SessionTimeoutValue. > Sounds like a reasonable correction. I will note however that I didn't actually test Win98 or NT. It's rather difficult to find working media for them nowadays since they're not available on MSDN (hint, hint). This capture was done with a win2k8 client. I'll have to take your word for it that they behave in the same way. -- Jeff Layton <[email protected]> _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
