summaryrefslogtreecommitdiff
path: root/src/or/connection_or.c
diff options
context:
space:
mode:
authorMike Perry <mikeperry-git@torproject.org>2017-02-21 21:28:00 -0500
committerNick Mathewson <nickm@torproject.org>2017-05-08 13:49:22 -0400
commitd5a151a06788c28ac1c50398c6e571d484774f47 (patch)
treed2e4f2719130250e428f1991a01511c89e589a29 /src/or/connection_or.c
parentb0e92634d85a3bf7612a6ce0339b96e4aad1e0bb (diff)
downloadtor-d5a151a06788c28ac1c50398c6e571d484774f47.tar.gz
tor-d5a151a06788c28ac1c50398c6e571d484774f47.zip
Bug 17592: Clean up connection timeout logic.
This unifies CircuitIdleTimeout and PredictedCircsRelevanceTime into a single option, and randomizes it. It also gives us control over the default value as well as relay-to-relay connection lifespan through the consensus. Conflicts: src/or/circuituse.c src/or/config.c src/or/main.c src/test/testing_common.c
Diffstat (limited to 'src/or/connection_or.c')
-rw-r--r--src/or/connection_or.c30
1 files changed, 8 insertions, 22 deletions
diff --git a/src/or/connection_or.c b/src/or/connection_or.c
index 40c28e60e5..5d32217c86 100644
--- a/src/or/connection_or.c
+++ b/src/or/connection_or.c
@@ -815,24 +815,6 @@ connection_or_update_token_buckets(smartlist_t *conns,
});
}
-/** How long do we wait before killing non-canonical OR connections with no
- * circuits? In Tor versions up to 0.2.1.25 and 0.2.2.12-alpha, we waited 15
- * minutes before cancelling these connections, which caused fast relays to
- * accrue many many idle connections. Hopefully 3-4.5 minutes is low enough
- * that it kills most idle connections, without being so low that we cause
- * clients to bounce on and off.
- *
- * For canonical connections, the limit is higher, at 15-22.5 minutes.
- *
- * For each OR connection, we randomly add up to 50% extra to its idle_timeout
- * field, to avoid exposing when exactly the last circuit closed. Since we're
- * storing idle_timeout in a uint16_t, don't let these values get higher than
- * 12 hours or so without revising connection_or_set_canonical and/or expanding
- * idle_timeout.
- */
-#define IDLE_OR_CONN_TIMEOUT_NONCANONICAL 180
-#define IDLE_OR_CONN_TIMEOUT_CANONICAL 900
-
/* Mark <b>or_conn</b> as canonical if <b>is_canonical</b> is set, and
* non-canonical otherwise. Adjust idle_timeout accordingly.
*/
@@ -840,9 +822,6 @@ void
connection_or_set_canonical(or_connection_t *or_conn,
int is_canonical)
{
- const unsigned int timeout_base = is_canonical ?
- IDLE_OR_CONN_TIMEOUT_CANONICAL : IDLE_OR_CONN_TIMEOUT_NONCANONICAL;
-
if (bool_eq(is_canonical, or_conn->is_canonical) &&
or_conn->idle_timeout != 0) {
/* Don't recalculate an existing idle_timeout unless the canonical
@@ -851,7 +830,14 @@ connection_or_set_canonical(or_connection_t *or_conn,
}
or_conn->is_canonical = !! is_canonical; /* force to a 1-bit boolean */
- or_conn->idle_timeout = timeout_base + crypto_rand_int(timeout_base / 2);
+ or_conn->idle_timeout = channelpadding_get_channel_idle_timeout(
+ TLS_CHAN_TO_BASE(or_conn->chan), is_canonical);
+
+ log_info(LD_CIRC,
+ "Channel " U64_FORMAT " chose an idle timeout of %d.",
+ or_conn->chan ?
+ U64_PRINTF_ARG(TLS_CHAN_TO_BASE(or_conn->chan)->global_identifier):0,
+ or_conn->idle_timeout);
}
/** If we don't necessarily know the router we're connecting to, but we