[tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Nov 7 14:15:11 UTC 2016


#20499: A running Tor won't update the microdesc consensus
-------------------------------------------+-------------------------------
 Reporter:  rubiate                        |          Owner:
     Type:  defect                         |         Status:
                                           |  needs_revision
 Priority:  High                           |      Milestone:  Tor:
                                           |  0.2.9.x-final
Component:  Core Tor/Tor                   |        Version:  Tor:
                                           |  0.2.9.4-alpha
 Severity:  Normal                         |     Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:                                 |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by nickm):

 Replying to [comment:30 teor]:
 > Code review of `20499_part1_029`:
 >
 > I'm surprised your compiler didn't warn about the assignment here:
 > {{{
 > if (dls->backoff = DL_SCHED_DETERMINISTIC)
 > }}}

 Yikes.  Added a fixup commit for that.

 > Replying to [comment:21 arma]:
 > > ...
 > > It seems to me that any design that effectively has a "now you won't
 ask for the consensus anymore" possible outcome is a scary one here.
 >
 > We should think carefully about what we want the default maximum to be,
 and if we want it to be the same in every case:
 > {{{
 > *max = INT_MAX;
 > }}}
 >
 > Perhaps the network could deal with slow zombies if they only retried
 every day/week/month. Or perhaps we really do want them to stop asking. Or
 perhaps we want clients to do one thing, and relays another.
 >
 > Currently, some schedules do have INT_MAX as their maximum, others have
 2, 12, or 73 hours.

 My thinking here was that we're backing off to infinite retries, so we
 might as well let the delays get arbitrarily large.  We might want to cut
 the maximum back down if it turns out to be a problem in practice, but I'd
 like to be cautious about zombies for now.

 > All the other commits look fine, but I'm not sure they're enough to
 solve this issue.

 Me neither!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20499#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list