No subject


Wed Oct 20 02:45:58 MDT 2010


adjusted based upon the various factors.  I described some of those in an
earlier e'mail and pointed to a KB article for more information.

In any case, the timeout is 45 seconds +/- some fudge factors.

HOWEVER, as the doc explains the list of outstanding requests is scanned
every 30 seconds.  That adds a bit of variability to the mix.

The soonest that a request would be discovered as "timed out", would be at
the approximately 45 second mark.  If the request times out just after the
scan has completed, then add another 30 seconds to the time it takes to
discover that the response is overdue.

I don't know how much the fudge factors can adjust that initial 45-second
value, but if the initial value can be reduced by 15 seconds that would
certainly account for the 30-60 second range that you are seeing.

I have no idea why you would have had one instance in which the socket was
shut down in less than 30 seconds.  Sounds like a fluke to me.

Chris -)-----

Jeff Layton wrote:
> On Wed, 01 Dec 2010 16:08:32 -0600
> "Christopher R. Hertel" <crh at samba.org> wrote:
> 
> [...]
> 
>> Probably needs two tests.  One to see what happens if the (single)
>> connection is lost, and another to see what happens if a single operation
>> takes a very, very long time to complete (as you describe).
>>
> 
> I did an experiment with this on win2k8. I first doctored an smbd to
> discard write requests. When I try to copy a file to this host (via
> copy.exe), the server usually waits a little while (the time seems to
> vary between 30-60s or so), sends a single echo request and then
> reconnects the socket if it still doesn't get a write reply in about
> 30s. copy.exe then says "The specified network name is no longer
> available." Heh.
> 
> That said, the behavior seems to be really inconsistent. In at least
> one case, no echo was sent and the socket was shut down <30s after the
> write request was sent.
> 
> The timeout before sending an echo also seems to vary quite a bit. My
> suspicion is that that indicates that the client has the echo ping on a
> separate timer, and just selectively sends it whenever the timer pops
> based on certain criteria.
> 

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


More information about the cifs-protocol mailing list