Delivery-Date: Mon, 15 Feb 2016 16:27:06 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id C1AB51E0864;
	Mon, 15 Feb 2016 16:27:04 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B4DD238E6E;
	Mon, 15 Feb 2016 21:27:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7346838E6E
 for <tor-talk@lists.torproject.org>; Mon, 15 Feb 2016 21:26:56 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JpWB8z8Cbh0o for <tor-talk@lists.torproject.org>;
 Mon, 15 Feb 2016 21:26:56 +0000 (UTC)
Received: from continuum.iocl.org (continuum.iocl.org [217.140.74.2])
 by eugeni.torproject.org (Postfix) with ESMTP id D246338E60
 for <tor-talk@lists.torproject.org>; Mon, 15 Feb 2016 21:26:55 +0000 (UTC)
Received: (from krey@localhost)
 by continuum.iocl.org (8.11.3/8.9.3) id u1FLQpP29112;
 Mon, 15 Feb 2016 22:26:51 +0100
Date: Mon, 15 Feb 2016 22:26:51 +0100
From: Andreas Krey <a.krey@gmx.de>
To: tor-talk@lists.torproject.org
Message-ID: <20160215212651.GA16220@inner.h.apk.li>
References: <56C1BB18.1070703@beroal.in.ua> <56C1BF86.1050102@openmailbox.org>
 <20160215130731.GA657@riseup.net> <56C1DF24.1070009@openmailbox.org>
 <CE28579E-71E4-414D-AB4E-F58B02F3B8DE@frii.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CE28579E-71E4-414D-AB4E-F58B02F3B8DE@frii.com>
User-Agent: Mutt/1.4.2.1i
X-message-flag: What did you expect to see here?
Subject: Re: [tor-talk] How to make the Tor service to stop faster?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Mon, 15 Feb 2016 11:48:45 +0000, Ken Cline wrote:
> > On 15 Feb 2016, at 7:22 AM, nusenu <nusenu@openmailbox.org> wrote:
...
> > It is just the nicer way to say goodbye to clients - I guess.

Also, tor then has a chance to gracefully shut down circuits so
that at least short-lived connections don't break by the shutdown.

> I bet shutdown delay has to have something to do with TCP connection finalization semantics,

Nope.

> which can leave client processes stuck in a FIN_WAIT_2 state if tor
> closes too quickly.  My memory is a little vague here, but it is a result
> of interrupting the FIN-> ACK<- FIN<- ACK-> dialogue ... the client
> won't close the connection until it receive's that last ACK form tor,
> which tor can't send if it closes before it gets the client's FIN.

If a socket is stuck in FIN_WAIT_2 then the connection is half-closed,
the local side has sent its FIN and got the ACK, but the other side
didn't close its direction by sending its FIN.

It doesn't actually matter whether the tor process is still alive or
not - the kernel keeps the socket existing even when tor has terminated.

The only reason why keeping tor around for a bit helps here may be
that, when shutting down, it sends some sort of close message that
causes the other side to close as well, and it doesn't when it is
hard-killed, *and* the other side then won't shutdown the socket.

Would surprise me for tor-tor connections.

> Then it's up to the TCP stack to close the connection after it times out.

The fun part is that strictly there can be no timeout on FIN_WAIT_2. The
other side is still permitted to send data, and to do so infinitely long.
Practially, there often is a timeout.

An'on borrowed time'dreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

