<br><br>
<div class="gmail_quote">On Sat, Dec 4, 2010 at 5:44 AM, Jeff Layton <span dir="ltr"><<a href="mailto:jlayton@samba.org">jlayton@samba.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Sat, 4 Dec 2010 09:13:21 +0100<br>Volker Lendecke <Volker.Lendecke@SerNet.DE> wrote:<br><br>> On Fri, Dec 03, 2010 at 09:54:13PM -0600, Christopher R. Hertel wrote:<br>> > That may seem to be in the "who cares" category, since those old transports<br>
> > are essentially dead (much more dead than NBT, or even NBF). Unfortunately,<br>> > the code to handle the old transports is still there in Windows, so there<br>> > are behaviors -- things like the timeouts you're talking about and the weird<br>
> > VC=0 shutdown behvior -- that exist because of these old disused transports.<br>><br>> VC=0, how does Windows treat this facing NAT (masquerading)<br>> networks? I've done tests in the past where Windows killed<br>
> valid connections from behind a NAT box when a new client<br>> came in.<br>><br>> Volker<br><br></div>It seems like the best way to deal with this on the server side with<br>direct hosted TCP would be to treat VC=0 like any other VC number<br>
(MS-CIFS says that this is allowed).<br><br>Ideally any new connection event from a host however should make the<br>server check the validity of any other connection from the same host.<br>That way you could release resources held by dead connections in case<br>
the new one is a reconnect and needs to reclaim state.<br><br>The question is how to check that validity. Unfortunately, the best you<br>can probably do is rely on TCP keepalives.<br><font color="#888888"><br>--<br>Jeff Layton <<a href="mailto:jlayton@samba.org">jlayton@samba.org</a>><br>
</font>
<div>
<div></div>
<div class="h5">--<br>To unsubscribe from this list: send the line "unsubscribe linux-cifs" in<br>the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
</div></div></blockquote></div>
<div> </div>
<div> </div>
<div>Is SMB Echo command the only way to determine whether to reconnect or not?</div>
<div>The assumption here is SMB server is unresponsive. </div>
<div>There could be other circumstances on the server box (or even client box) that are</div>
<div>slowing down the SMB server responses such as slow network, slow network stack,</div>
<div>memory pressure etc.</div>
<div>So server could be fine all along and yet client would ask for reconnection!</div>
<div> </div>
<div> </div>