Re: [tor-bugs] #9969 [Tor]: We launch 50 microdesc requests, spread out over just three guards?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9969: We launch 50 microdesc requests, spread out over just three guards?
------------------------+--------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  needs_review
     Priority:  major   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------

Comment (by nickm):

 Hm. That patch is less complicated than I feared, since it has a few other
 things in it that are beyond what this ticket needs.  I think I should
 split it up into logical parts before we merge it.

  * I should check whether there's a faster mechanism here than
 connection_get_by_type_addr_port_purpose.  If there is, we should use it.
 If not, we shouldn't necessarily add one unless this shows up in profiles.

  * In router_pick_directory_server_impl, I think n_busy needs to get reset
 to 0 before the "goto retry_without_exclude", or things get double-
 counted.

  * The "busy_out" field for router_pick_directory_server_impl() needs
 documentation.

  * I like the changes in initiate_descriptor_downloads()... but I'm not so
 sure about "digest_len += 1".  What "NULL" are we talking about? 'digest'
 isn't NUL-terminated.

  * Gotta make sure it compiles with --enable-gcc-warnings on gcc and
 clang.

  * How long does it take us to retry the directory fetch after we decide
 not to launch one because the server is busy?  It would be bad to re-check
 too fast, and it would be bad to re-check too slow.  We'd better look at
 this.

  * Can max_dl_per_request return a higher number for TunnelDirConns for
 SERVERDESC too?

  * Does max_dl_per_request need to look at whether a particular connection
 will be tunneled, or does options->TunnelDirConns ensure that all these
 dir conns actually will be tunneled? I should check.

 This is still on my plate, unless somebody else wants to pick up some/all
 of the above.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9969#comment:12>
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