Does anyone know, or is there documentation describing Windows timeout values for Read and Write via SMB?

[Richard Sharpe]

On Sun, Dec 2, 2012 at 1:25 PM, Christopher R. Hertel <crh at samba.org> wrote:
> On 12/02/2012 10:27 AM, Volker Lendecke wrote:
>> On Sun, Dec 02, 2012 at 07:11:24AM -0800, Richard Sharpe wrote:
>>> On Sat, Dec 1, 2012 at 9:54 PM, Christopher R. Hertel <crh at samba.org> wrote:
>>>> On 12/01/2012 11:30 PM, Jeremy Allison wrote:
>>>>> On Sat, Dec 01, 2012 at 01:56:57PM -0800, Richard Sharpe wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> Is there any documentation or any experience on how many SMBecho's
>>>>>> Windows is prepared to receive before it declares a READ or WRITE has
>>>>>> failed?
>>>>>
>>>>> Isn't it a timing thing rather than a "number of echos" thing ?
>>>>
>>>> Richard:  Are you talking about Windows clients sending SMBechos to see if
>>>> the server is alive or the server receiving and responding to SMBechos while
>>>> still processing other operations?
>>>
>>> Well, yes.
>>>
>>> More specifically, I am interested in knowing:
>>>
>>> 1. How much patience does Windows have? Ie. what are the timeout values?
>>>
>>> 2. Where are they defined in the registry?
>>
>> We have done quite a bit of research here, but have not
>> found a definite answer. The problem is that you don't only
>> want to look at the Windows redirector, it is also
>> applications that might run into timeouts at a higher level.
>> Talks on the SDC floor track gave a timeout value of 25
>> seconds as the maximum for any request. It might also be
>> possible that you find timeouts in the SMB3 CA share
>> requirements in the SMB3 and FSA documents.
>
> It is somewhat frustrating to me that I no longer have access to the Windows
> source code.  I remember that the Win9x code had one set of behaviors and
> that the NT client code had a slightly different set of behaviors.
>
> ...and Volker is correct that applications may have their own timeouts on
> operations.
>
> Here is my vague memory of the workings of the Win9x client (and the correct
> version of all of this should be in [MS-CIFS] in some form or other, though
> probably not in a way that spells it out succinctly):
>
> * The client has an internal command queue for outstanding commands.
> * The client's command queue enforces the one-outstanding-command-per
>   PID+MID rule.
> * Each outstanding command is given a timestamp, indicating the time
>   at which it was sent.
> * Periodically (and I know I put the timing into [MS-CIFS] somewhere),
>   the client will scan the list looking for operations that have exceeded
>   a timeout value.  Those operations are canceled.  From the client's
>   perspective, they have failed.
> * There is a separate timer that is used to determine whether or not the
>   connection has failed.  Connection failures are not the same as
>   operation failures.
>
> That's my memory, and the clues should be scattered throughout [MS-CIFS] but
> will take some digging to tease out.  In order to meet the regulatory
> requirements, we had to break things down into discrete behaviors and
> describe each behavior in reference to the overall state machine.  Ugh.

>From MS-CIFS:

<189> 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.
------------------------

Other documentation claims that the number is 32 seconds. I have seen
48 second, I think, on the wire. Will have to check that last number.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)