Re: [tcpm] Is this a problem?

Ethan Blanton <eblanton@cs.ohiou.edu> Tue, 06 November 2007 19:39 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 1IpUGk-0003WT-1F; Tue, 06 Nov 2007 14:39:26 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpUGi-0003WN-R4 for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:39:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUGi-0003WF-Ha for tcpm@ietf.org; Tue, 06 Nov 2007 14:39:24 -0500
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUGf-0005Qy-7U for tcpm@ietf.org; Tue, 06 Nov 2007 14:39:24 -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 1IpUGZ-0005ls-58; Tue, 06 Nov 2007 19:39:20 +0000
Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id DD0F22BE21; Tue, 6 Nov 2007 14:39:12 -0500 (EST)
Received: by colt.internal (Postfix, from userid 3000) id 259CE283F2; Tue, 6 Nov 2007 14:39:12 -0500 (EST)
Date: Tue, 6 Nov 2007 14:39:12 -0500
From: Ethan Blanton <eblanton@cs.ohiou.edu>
To: Joe Touch <touch@ISI.EDU>, tcpm@ietf.org
Subject: Re: [tcpm] Is this a problem?
Message-ID: <20071106193912.GF5881@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> <20071106192746.GE5881@elb.elitists.net>
MIME-Version: 1.0
In-Reply-To: <20071106192746.GE5881@elb.elitists.net>
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: -104.1 (---------------------------------------------------)
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc:
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="===============1452877758=="
Errors-To: tcpm-bounces@ietf.org

Ethan Blanton spake unto us the following wisdom:
> 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.

SO_LINGER is indeed more flexible than I have used it for -- it can be
used to solve both of these problems.  For the benefit of those
listening:

1) Set SO_LINGER with l_onoff != 0 and l_linger = timeout in seconds.
2) If a nonblocking close returns EWOULDBLOCK, the linger timeout
   expired, so:
   2a) set SO_LINGER with l_onoff != 0 and l_linger = 0
   2b) call close, which will emit a RST

I recant my previous claims -- this can be handled cleanly with
standard sockets.

> > > 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.

I do stand by this, however.

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