From: "Talpey, Thomas" Subject: Re: [PATCH 3/7] SUNRPC: Allow the client to detect if the TCP connection is closed Date: Fri, 09 Nov 2007 11:53:38 -0500 Message-ID: References: <20071107003834.13713.73536.stgit@heimdal.trondhjem.org> <20071107003950.13713.24126.stgit@heimdal.trondhjem.org> <1194618806.7459.44.camel@heimdal.trondhjem.org> <1194619730.7459.48.camel@heimdal.trondhjem.org> <1194622369.7459.52.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfsv4@linux-nfs.org, Chuck Lever , "Talpey, Thomas" , nfs@lists.sourceforge.net To: Trond Myklebust Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1IqX7K-0007QT-Pe for nfs@lists.sourceforge.net; Fri, 09 Nov 2007 08:54:02 -0800 Received: from mx2.netapp.com ([216.240.18.37]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IqX7Q-0007Ch-7Q for nfs@lists.sourceforge.net; Fri, 09 Nov 2007 08:54:08 -0800 In-Reply-To: <1194622369.7459.52.camel@heimdal.trondhjem.org> References: <20071107003834.13713.73536.stgit@heimdal.trondhjem.org> <20071107003950.13713.24126.stgit@heimdal.trondhjem.org> <1194618806.7459.44.camel@heimdal.trondhjem.org> <1194619730.7459.48.camel@heimdal.trondhjem.org> <1194622369.7459.52.camel@heimdal.trondhjem.org> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net At 10:32 AM 11/9/2007, Trond Myklebust wrote: > >On Fri, 2007-11-09 at 10:25 -0500, Talpey, Thomas wrote: >> At 09:48 AM 11/9/2007, Trond Myklebust wrote: >> > The state change occurs while we're >> >inside the call to ->shutdown(), so there is no delay. >> >> I don't think so, in the case that the network is disconnected and >> there is some data pending in the TCP output queue. The FIN won't >> be sent until the window advances to allow it, and this could happen >> much later. In the meantime, the xprt isn't even marked CLOSING. > >Oh, I see what you mean. So, correction: the TCP_FIN_WAIT1 state means >that the FIN has been _queued_ by the TCP layer. It may or may not have >hit the wire yet. Correct. And even if were sent, the FINWAIT1 state does not mean the peer has transitioned. You need to see the ACK (which often comes in the same packet as the peer's FIN). All this is a gawd-awful layering violation, you know. :-) Tom. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs