[tor-bugs] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Nov 1 02:18:56 UTC 2016


#19969: tor client does not immediately open new circuits after standby
-------------------------------------------------+-------------------------
 Reporter:  weasel                               |          Owner:
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.2.9.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.8.6
 Severity:  Normal                               |     Resolution:
 Keywords:  regression 029-backport              |  Actual Points:
  028-backport                                   |
Parent ID:                                       |         Points:  2
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arma):

 In other news, I can confirm that indeed the bottom of
 run_main_loop_once() is only run when we have an active linked connection.
 Here is the simple patch that lets you see for yourself:
 {{{
 diff --git a/src/or/main.c b/src/or/main.c
 index ebaab5c..70fcc28 100644
 --- a/src/or/main.c
 +++ b/src/or/main.c
 @@ -2576,6 +2576,7 @@ run_main_loop_once(void)
      }
    }

 +  log_notice(LD_NET, "at bottom of main loop");
    /* This will be pretty fast if nothing new is pending. Note that this
 gets
     * called once per libevent loop, which will make it happen once per
 group
     * of events that fire, or once per second. */
 }}}

 So now that we have a bit more clarity, the bug in 0.2.8 (regression over
 0.2.7) is two-fold:

 A) If !have_dir_info, new stream requests get put onto a pending queue
 which is never looked at, and eventually they expire. The old behavior was
 that they would trigger a reset in directory downloads, which would
 hopefully cause have_dir_info to become true, and they would check once a
 second if it is.

 B) New stream requests get put onto a pending queue which is examined
 sometime in the next second (each time run_scheduled_events() happens). So
 on average we have an extra 0.0-1.0 (average 0.5) seconds of latency added
 to stream requests. The old behavior was to try each new stream
 immediately.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19969#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list