Jeff Layton wrote: > 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). The reasoning behind the VC=0 behavior does not apply to any contemporary transport, so there is no reason to enforce that behavior. > 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. That's overkill, I think. The transport, as you mention below, will take care of dropped connections in due time. > The question is how to check that validity. Unfortunately, the best you > can probably do is rely on TCP keepalives. ...and that's probably the best you want to do. Chris -)----- -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@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
