>From the server side, per MS-CIFS, I think the idle connection timer is what >you are looking for. If you have further clarification questions, I would be >happy to open a case and assist on this.
MS-CIFS 3.3 Server Details 3.3.2.2 Idle Connection Timer This optional timer controls the amount of time that a session can be idle before the server disconnects the session. An idle session is one on which no open handles exist (no open files, directories, search contexts, etc.), and no operations have been issued within an implementation-specific period of time. <209> <209> Section 3.3.2.2: The default idle timer time-out value for Windows NT 4.0 is 15 minutes. See [KB297684] for more information on Windows NT idle timer settings. Regards, Edgar From: Steve French [mailto:smfre...@gmail.com] Sent: Friday, December 03, 2010 3:12 PM To: volker.lende...@sernet.de Cc: Jeff Layton; MSSolve Case Email; Christopher R. Hertel; cifs-proto...@samba.org; Edgar Olougouna; p...@tridgell.net Subject: Re: [Pfif] [cifs-protocol] [REG: 110120160951867] Requesting clarification of CIFS client timeout behavior On Fri, Dec 3, 2010 at 2:21 PM, Volker Lendecke <volker.lende...@sernet.de<mailto:volker.lende...@sernet.de>> wrote: 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. A loosely related question is whether POSIX forbids EIO or EHOSTDOWN on some syscalls. If such were specified in the standard, at least for those syscalls posix clients can never time out (or must timeout and either cancel/resubmit and/or reconnect transparently) Currently write beyond end of file (and operations on offline files) are the only known special cases where timeout would be inappropriate, but we may find other syscalls where it would be inappropriate for a client to return to the user. For Windows (Windows behavior may be slightly different than POSIX but still important for implementers to understand) it would be helpful to know which operations are allowed to return errors to the user (if the host hangs or goes down) and which must retry forever. -- Thanks, Steve
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol