[tor-bugs] #9969 [Tor]: We launch 50 microdesc requests, spread out over just three guards?
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Mar 5 18:00:07 UTC 2014
#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
More information about the tor-bugs
mailing list