On Sat, 4 Dec 2010 09:13:21 +0100 Volker Lendecke <Volker.Lendecke@xxxxxxxxx> wrote: > On Fri, Dec 03, 2010 at 09:54:13PM -0600, Christopher R. Hertel wrote: > > That may seem to be in the "who cares" category, since those old transports > > are essentially dead (much more dead than NBT, or even NBF). Unfortunately, > > the code to handle the old transports is still there in Windows, so there > > are behaviors -- things like the timeouts you're talking about and the weird > > VC=0 shutdown behvior -- that exist because of these old disused transports. > > VC=0, how does Windows treat this facing NAT (masquerading) > networks? I've done tests in the past where Windows killed > valid connections from behind a NAT box when a new client > came in. > > Volker It seems like the best way to deal with this on the server side with direct hosted TCP would be to treat VC=0 like any other VC number (MS-CIFS says that this is allowed). Ideally any new connection event from a host however should make the server check the validity of any other connection from the same host. That way you could release resources held by dead connections in case the new one is a reconnect and needs to reclaim state. The question is how to check that validity. Unfortunately, the best you can probably do is rely on TCP keepalives. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
