[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file
#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--------------------------+------------------------------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: Medium | Milestone: Tor: 0.3.1.x-final
Component: Core Tor/Tor | Version: Tor: 0.3.0.7
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------+------------------------------------
Comment (by teor):
Replying to [comment:4 teor]:
> Replying to [ticket:22400 arma]:
> > And it launches a parallel fetch to an authority too, just like it's
supposed to:
> > {{{
> > May 25 20:58:07.185 [info] directory_send_command(): Downloading
consensus from 154.35.175.225:443 using /tor/status-vote/current
/consensus-
microdesc/0232AF+14C131+23D15D+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
> > }}}
>
> No, that's a bug: #20604.
>
> There's no need for every client to contact an authority: they didn't in
0.2.8, and they all worked fine. But when the exponential backoff code was
merged, there was no provision for a set initial delay, and we couldn't
define the schedules so that we'd get a short delay without blowing out
the remaining attempts. So we got this compromise.
Sorry, I was wrong.
This happened because we never reset download statuses before we use them.
See #17750.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22400#comment:6>
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