[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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):

 Fixed most of the above issues.  In response to my questions:

 > * 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.

 There isn't a faster one.  Let's leave it for now.

 > * 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.

 It looks like we do a reasonable job here.

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

 I think we can.  Making the fix.

 > 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 one is still up in the air.  It looks like
 directory_command_should_use_begindir() can return 0 for several reasons
 other than having TunnelDirConns==0.

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