aboutsummaryrefslogtreecommitdiff
path: root/src/or/connection.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2014-04-18 12:50:04 -0400
committerNick Mathewson <nickm@torproject.org>2014-04-18 12:58:58 -0400
commit0d75344b0e0eafc89db89a974e87b16564cd8f0a (patch)
treec5dbe44f5b4ddbfa0855ce8cb3066c1095384d3a /src/or/connection.c
parentbb9b4c37f8e7f5cf78918f382e90d8b11ff42551 (diff)
downloadtor-0d75344b0e0eafc89db89a974e87b16564cd8f0a.tar
tor-0d75344b0e0eafc89db89a974e87b16564cd8f0a.tar.gz
Switch to random allocation on circuitIDs.
Fixes a possible root cause of 11553 by only making 64 attempts at most to pick a circuitID. Previously, we would test every possible circuit ID until we found one or ran out. This algorithm succeeds probabilistically. As the comment says: This potentially causes us to give up early if our circuit ID space is nearly full. If we have N circuit IDs in use, then we will reject a new circuit with probability (N / max_range) ^ MAX_CIRCID_ATTEMPTS. This means that in practice, a few percent of our circuit ID capacity will go unused. The alternative here, though, is to do a linear search over the whole circuit ID space every time we extend a circuit, which is not so great either. This makes new vs old clients distinguishable, so we should try to batch it with other patches that do that, like 11438.
Diffstat (limited to 'src/or/connection.c')
-rw-r--r--src/or/connection.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/src/or/connection.c b/src/or/connection.c
index 4f74a1d04..96e6a471b 100644
--- a/src/or/connection.c
+++ b/src/or/connection.c
@@ -251,8 +251,6 @@ dir_connection_new(int socket_family)
*
* Set timestamp_last_added_nonpadding to now.
*
- * Assign a pseudorandom next_circ_id between 0 and 2**15.
- *
* Initialize active_circuit_pqueue.
*
* Set active_circuit_pqueue_last_recalibrated to current cell_ewma tick.