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

Re: [tor-bugs] #4862 [Tor]: Consider disabling dynamic intro point formula (numerology)

#4862: Consider disabling dynamic intro point formula (numerology)
-------------------------+-------------------------------------------------
     Reporter:  hellais  |      Owner:
         Type:           |     Status:  needs_review
  enhancement            |  Milestone:  Tor: 0.2.7.x-final
     Priority:  major    |    Version:  Tor: 0.2.7
    Component:  Tor      |   Keywords:  needs-proposal, tor-hs,
   Resolution:           |  027-triaged-1-in, SponsorR
Actual Points:           |  Parent ID:
       Points:           |
  medium/large           |
-------------------------+-------------------------------------------------

Comment (by dgoulet):

 Replying to [comment:30 arma]:
 > I haven't looked much at the overall patch, but I think George is right
 to ask about this part. The original code said "if you are going to have
 enough intro points still, you're done." The new code with this change
 seems to go through a weird "if you have more than enough, then proceed
 with the function, and then the for() loop is a no-op, and then we hit
 > {{{
 >     /* If there's no need to launch new circuits, stop here. */
 >     if (!intro_point_set_changed)
 >       continue;
 > }}}
 > "
 >
 > So I think the change above just adds a tiny bit of inefficiency and
 confusion, rather than actually changing behavior. But it still looks like
 simplifying and unconfusing would be wise.

 If I recall correctly (thus adding a comment is very wise! :P) with this
 patch we always have a fixed number of intro points so if we have the same
 amount of *non* expired IPs (`n_intro_points_unexpired`) and IPs the
 service wants (`service->n_intro_points_wanted`), we have nothing more to
 do so we stop right there and move on to the next service with that
 `continue`. If we do not, it means we have to create new IP(s) thus
 getting in the for loop just after the check.

 I unfortunately don't see how this adds inefficiency?

 Looking at this code more closely now, I think that the check is not
 useful since we have now a fix number of IPs so only testing
 `intro_point_set_changed == 1` should be enough.

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