No subject
Wed Oct 20 02:45:58 MDT 2010
t 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:smfrench at gmail.com]
Sent: Friday, December 03, 2010 3:12 PM
To: Volker.Lendecke at sernet.de
Cc: Jeff Layton; MSSolve Case Email; Christopher R. Hertel; cifs-protocol at s=
amba.org; Edgar Olougouna; pfif at tridgell.net
Subject: Re: [Pfif] [cifs-protocol] [REG: 110120160951867] Requesting clari=
fication of CIFS client timeout behavior
On Fri, Dec 3, 2010 at 2:21 PM, Volker Lendecke <Volker.Lendecke at sernet.de<=
mailto:Volker.Lendecke at 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 operati=
on
> > 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
--_000_C3D5BF8228FEF54BABF69D7E1088B85F568D34AFTK5EX14MBXC117r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
p.Default, li.Default, div.Default
{mso-style-name:Default;
margin:0in;
margin-bottom:.0001pt;
text-autospace:none;
font-size:12.0pt;
font-family:"Verdana","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">MS-CIFS<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">3.3 Server Detai=
ls</span></b><span style=3D"font-size:11.0pt;font-family:"Calibri"=
;,"sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class=3D"Default"><b><span style=3D"font-size:10.0pt">3.3.2.2 Idle Conne=
ction Timer
</span></b><span style=3D"font-size:10.0pt"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt">This optional timer =
controls the amount of time that a session can be idle before the server di=
sconnects the session. An idle session is one on which no open handles exis=
t (no open files, directories, search
contexts, etc.), and no operations have been issued within an implementati=
on-specific period of time. <209><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt"><209> Section =
3.3.2.2: The default idle timer time-out value for Windows NT 4.0 is 15 min=
utes. See [KB297684] for more information on Windows NT idle timer settings=
.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Regards,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Edgar<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"=
;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> Steve Fr=
ench [mailto:smfrench at gmail.com]
<br>
<b>Sent:</b> Friday, December 03, 2010 3:12 PM<br>
<b>To:</b> Volker.Lendecke at sernet.de<br>
<b>Cc:</b> Jeff Layton; MSSolve Case Email; Christopher R. Hertel; cifs-pro=
tocol at samba.org; Edgar Olougouna; pfif at tridgell.net<br>
<b>Subject:</b> Re: [Pfif] [cifs-protocol] [REG: 110120160951867] Requestin=
g clarification of CIFS client timeout behavior<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class=3D"MsoNormal">On Fri, Dec 3, 2010 at 2:21 PM, Volker Lendecke <=
<a href=3D"mailto:Volker.Lendecke at sernet.de">Volker.Lendecke at sernet.de</a>&=
gt; wrote:<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">On Fri, Dec 03, 2010 =
at 01:50:11PM -0500, Jeff Layton wrote:<br>
> > Probably needs two tests. One to see what happens if the (s=
ingle)<br>
> > connection is lost, and another to see what happens if a single o=
peration<br>
> > takes a very, very long time to complete (as you describe).<br>
> ><br>
><br>
> I did an experiment with this on win2k8. I first doctored an smbd to<b=
r>
> discard write requests. When I try to copy a file to this host (via<br=
>
> copy.exe), the server usually waits a little while (the time seems to<=
br>
> vary between 30-60s or so), sends a single echo request and then<br>
> reconnects the socket if it still doesn't get a write reply in about<b=
r>
> 30s. copy.exe then says "The specified network name is no longer<=
br>
> available." Heh.<br>
><br>
> That said, the behavior seems to be really inconsistent. In at least<b=
r>
> one case, no echo was sent and the socket was shut down <30s after =
the<br>
> write request was sent.<br>
><br>
> The timeout before sending an echo also seems to vary quite a bit. My<=
br>
> suspicion is that that indicates that the client has the echo ping on =
a<br>
> separate timer, and just selectively sends it whenever the timer pops<=
br>
> based on certain criteria.<o:p></o:p></p>
</div>
<p class=3D"MsoNormal">Probably all this timeout stuff varies too much with=
<br>
different application behaviours. I have the same discussion<br>
right now with the opposite direction: How can a server<br>
reliably tell that a client died hard? The question here is:<br>
When can we reliably throw away share mode entries? A<br>
colleague just measured a W2k8 timeout of 5 minutes in this<br>
case, but is this dependable? I suspect we have to develop<br>
our own policies for this.<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><br>
A loosely related question is whether POSIX forbids<br>
EIO or EHOSTDOWN on some syscalls. If such were<br>
specified in the standard, at least for those syscalls posix <br>
clients can never time out (or must timeout and either <br>
cancel/resubmit and/or reconnect transparently)<br>
Currently write beyond end of file (and operations on<br>
offline files) are the only known special cases where timeout would<br>
be inappropriate, but we may find other syscalls where it<br>
would be inappropriate for a client to return to the user.<br>
<br>
For Windows (Windows behavior may be slightly different<br>
than POSIX but still important for implementers to understand)<br>
it would be helpful to know which operations<br>
are allowed to return errors to the user (if the host<br>
hangs or goes down) and which must retry forever.<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><br>
<br>
-- <br>
Thanks,<br>
<br>
Steve<o:p></o:p></p>
</div>
</body>
</html>
--_000_C3D5BF8228FEF54BABF69D7E1088B85F568D34AFTK5EX14MBXC117r_--
More information about the cifs-protocol
mailing list