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_revision
     Priority:  major   |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 In dir_fetch_type:
   * I don't like those complicated conditional expressions.  In
 particular, every time I see something like the following, I need to go
 look at a table of operator precedence.  I think that in this case it is
 wrong: bitwise OR binds more tightly than ?, so the result of the
 conditional will always be "MICRODESC_DIRINFO"... but the problem here is
 probably that conditional expressions are Just Too Error-Prone.
 {{{
       return V3_DIRINFO |
                      (resource && !strcmp(resource,"microdesc") ?
 MICRODESC_DIRINFO :
 NO_DIRINFO);
 }}}

 In directory_send_command:
   * Not all directory requests are tunneled over Tor. (Some connections
 from nodes to authorities in particular are not tunneled.)  Should we
 perhaps retain this warning in the non-tunneled case?

 In initiate_descriptor_downloads:
   * Changing from 8 to 4 seems wrong; you've left off the space for the
 terminating NUL character.
   * Perhaps we should refactor this thing to use a smartlist and
 smartlist_join_strings(), to avoid the possibility of further such
 mistakes in the code.

 In get_min_requests:
   * This function probably needs a more descriptive name
   * Why is the minimum ''higher'' now?  We want to be launching fewer
 requests.  Two per guard still seems like a high minimum.  This feels more
 like a maximum than a minimum

 Overall:
   * This needs unit tests; let me know if you need any help writing them.
   * Are we doing anything to make sure that all of the requests don't all
 go to the same guard?
   * Are we doing anything to lower the _maximum_ number of concurrent
 requests?

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