From owner-freebsd-net@FreeBSD.ORG Sun Apr 4 15:26:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFFA816A4CE for ; Sun, 4 Apr 2004 15:26:45 -0700 (PDT) Received: from out009.verizon.net (out009pub.verizon.net [206.46.170.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C58643D1D for ; Sun, 4 Apr 2004 15:26:45 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040404222644.FMEC29216.out009.verizon.net@mac.com>; Sun, 4 Apr 2004 17:26:44 -0500 Message-ID: <40708B96.4050905@mac.com> Date: Sun, 04 Apr 2004 18:26:30 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Erhart References: <6.0.2.0.2.20040404152043.01c83320@mx1.erhartgroup.com> <4070860F.6030701@mac.com> <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> In-Reply-To: <6.0.2.0.2.20040404160622.01c84428@mx1.erhartgroup.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [68.160.247.127] at Sun, 4 Apr 2004 17:26:44 -0500 cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2004 22:26:45 -0000 Brandon Erhart wrote: [ ... ] > Any advice on the timeouts? I don't really care about the RFC , honestly > :-P. Like I said, I'm going for sheer speed. My advice was to read the RFC as it contains significant discussion about these timeouts, but you're free to disregard it if you please. In particular, the discussion of FIN/ACK handling is relevant, since a TCP implementation ought to move through the various FIN_WAIT states rapidly if both sides agree to close and don't have more data to send. Using tcpdump to verify what's going on might help you figure out why the connections are lingering around... -- -Chuck