On Fri, Dec 03, 2010 at 01:50:11PM -0500, Jeff Layton 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.
Probably all this timeout stuff varies too much with different application behaviours. I have the same discussion right now with the opposite direction: How can a server reliably tell that a client died hard? The question here is: When can we reliably throw away share mode entries? A colleague just measured a W2k8 timeout of 5 minutes in this case, but is this dependable? I suspect we have to develop our own policies for this. Volker _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
