Re: [tcpm] Is this a problem?

Ethan Blanton <eblanton@cs.ohiou.edu> Tue, 06 November 2007 19:27 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpU5e-00070T-IO; Tue, 06 Nov 2007 14:27:58 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpU5d-0006yw-Jg for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:27:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpU5d-0006yo-A4 for tcpm@ietf.org; Tue, 06 Nov 2007 14:27:57 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpU5a-00059p-SV for tcpm@ietf.org; Tue, 06 Nov 2007 14:27:57 -0500
Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <eblanton@cs.ohiou.edu>) id 1IpU5V-0004y1-2f; Tue, 06 Nov 2007 19:27:54 +0000
Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id D1B1F2BE21; Tue, 6 Nov 2007 14:27:46 -0500 (EST)
Received: by colt.internal (Postfix, from userid 3000) id 1DC44283F2; Tue, 6 Nov 2007 14:27:46 -0500 (EST)
Date: Tue, 6 Nov 2007 14:27:46 -0500
From: Ethan Blanton <eblanton@cs.ohiou.edu>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] Is this a problem?
Message-ID: <20071106192746.GE5881@elb.elitists.net>
Mail-Followup-To: Joe Touch <touch@ISI.EDU>, tcpm@ietf.org
References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu>
MIME-Version: 1.0
In-Reply-To: <4730BC89.5000909@isi.edu>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: -104.1 (---------------------------------------------------)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0777269282=="
Errors-To: tcpm-bounces@ietf.org

(Apologies for the duplicate, Joe, I didn't reply-to-list.)

Joe Touch spake unto us the following wisdom:
> > This comment of Murali's, specifically, is a case that the application
> > *cannot* (portably or cleanly) handle, at least under the Berkeley
> > sockets API.  He is correct that once an application writes the end of
> > its data and calls close() or shutdown(), the TCP socket may persist
> > indefinitely in the kernel, and the application would never know (if
> > there are no application-level acknowledgments, as there are not in
> > simple HTTP responses).
> 
> Why would a blocking CLOSE not solve that?

It is my understanding (correct me if I am wrong) that close() returns
immediately, regardless of queued data in the send buffer.  In
addition, I am not aware of any way to force a reset on a TCP socket
without pending data in the read buffer.

> > It does not seem unreasonable to add a zero-window timeout tunable to
> > any given TCP implementation; I don't necessarily think it is a TCP
> > standardization issue, however, as there is no wire impact.
> 
> Protocols are more than just what is on the wire. They include state at
> the endpoints, and APIs.

Agreed, to some extent.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm