[cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior

[Jeff Layton]

On Thu, 9 Dec 2010 20:29:56 +0000
Edgar Olougouna <edgaro at microsoft.com> 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 <jlayton at samba.org>