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

[Christopher R. Hertel]

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.

Chris -)-----

-- 
"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