Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Tue, 06 November 2007 19:04 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTic-0007TJ-LW; Tue, 06 Nov 2007 14:04:10 -0500
Received: from tcpm by with local (Exim 4.43) id 1IpTib-0007M2-Fd for; Tue, 06 Nov 2007 14:04:09 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpTib-0007Lt-4G for; Tue, 06 Nov 2007 14:04:09 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IpTia-0008SQ-LP for; Tue, 06 Nov 2007 14:04:09 -0500
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id lA6J3f7T027706; Tue, 6 Nov 2007 11:03:42 -0800 (PST)
Message-ID: <>
Date: Tue, 06 Nov 2007 11:03:26 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
Subject: Re: [tcpm] Is this a problem?
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc:, Lloyd Wood <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0198109138=="

> This behaviour can and does get exhibited by standard web servers also, it's not only our application.

So multiple apps are broken - this has happened before.

> The solution must
> work in scenarios where the application can cleanup its connection state, expecting TCP to deliver the data reliably to the peer after that.

There is a disconnect in believing that TCP ever needs to clean up its
connection state. TCP tends to leave state around and clean it up when a
new connection overtakes it; it does not tend to clean things up.

> It's not a broken application, this is a perfectly legal scenario. As far as the app is concerned, it's done with that connection, it can devote
> that connection memory and resources  to another user or client, thus increasing goodput.

As you note the resources don't get released until the data is
transferred or the connection is aborted, so it's a misconception that
the application should close a connection to release memory and resources.

Finally, it sounds like you didn't want a nonblocking CLOSE; you want to
use a blocking CLOSE with an application timeout timer.


tcpm mailing list