[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1772 [Tor Client]: Counting circuit timeouts when we can't establish any TLS connection
#1772: Counting circuit timeouts when we can't establish any TLS connection
------------------------+---------------------------------------------------
Reporter: arma | Owner: mikeperry
Type: defect | Status: needs_review
Priority: major | Milestone: Tor: 0.2.2.x-final
Component: Tor Client | Version:
Keywords: | Parent:
------------------------+---------------------------------------------------
Comment(by arma):
Replying to [comment:11 mikeperry]:
> Re your B: If the close_ms == timeout_ms, it shouldn't cause any *extra*
timeouts, right? Either way, the circuit would get closed and a new one
would have to be launched.. Also, gcc doesn't like == or != comparisons
for floating point values, and it will warn if I do that...
By close_ms == timeout_ms, I meant when
{{{
cbt->total_build_times < circuit_build_times_min_circs_to_observe()
}}}
In this case, the timeout_ms and close_ms are set equal to each other, so
there's no point switching the circuit over to purpose
CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT.
Also, there is a difference, since if we fail before the first hop, we
blame the relay, kill the connection attempt, and kill all streams asking
for this relay via connection_ap_fail_onehop(). Also, in the above
example, we're launching a second circuit to that relay right before
declaring the relay dead and giving up on the directory fetch that was
destined for it -- and since the relay is actually the one at fault, the
next circuit fails too and we count a second circuit timeout at
2147483646. It seems that if we know we're going to do that one second
later, we should do it now, and save ourselves the trouble of wasting a
circuit.
See commit ceb3d4d578f4ebb8d in arma/bug1772 for my fix.
A different approach would be for circuit_build_times_init() to set
timeout_ms to circuit_build_times_get_initial_timeout(), and set close_ms
to 2*that. I have a mild preference against that approach though, since it
just complicates things.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1772#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs