[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