[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4483 [Tor]: If k of n authorities are down, k/n bootstrapping clients are delayed for minutes
#4483: If k of n authorities are down, k/n bootstrapping clients are delayed for
minutes
-------------------------------------------------+-------------------------
Reporter: arma | Owner: teor
Type: defect | Status:
Priority: High | needs_review
Component: Tor | Milestone: Tor:
Severity: Normal | 0.2.8.x-final
Keywords: performance, bootstrap, dirauth- | Version:
dos-resistance, tor-client, large-feature, | Resolution:
prop210, 028-triage, TorCoreTeam201512, | Actual Points:
MikePerry201512R | Points:
Parent ID: #2664 | medium/large
Sponsor: SponsorU |
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:41 nickm]:
> bc8f21f7bd4ed3ea52da94f44c58f34919841307 (Add attempt-based connection
schedules)
All fixups for this commit are in 8e50ae7.
> * download_status_schedule_helper dereferences dls before it does
tor_assert(dls); coverity won't like that, I think.
Oops, but by the power of C99, I can swap those lines.
> * download_status_schedule_helper seems like a bad name. It doesn't
have a verb. Maybe it should be ..._get_interval?
It's actually getting a delay, so I have modified the name of the function
and the variables in the function to reflect this.
> * Somewhere, we need to explain how a dls actually works -- what it
means, how to interpret it. I don't think the documentation in or.h
really explains. Honestly, I'm not sure how this commit '''works'''. I
think that an expanded comment on download_schedule_t type might be in
order.
I have updated the comments on:
* download_schedule_t
* download_want_authority_t
* download_schedule_increment_t
* download_status_t
* download_status_increment_failure
I hope this explains how the code works better, let me know if there's
anything that could be clearer.
I also made sure n_download_attempts is incremented for all schedules. It
doesn't make sense to only track it for attempt-based schedules.
> 3244f51e18832cd507957a589e89452bd98164b3 (Multiple simultaneous
connections for clients)
See fixup cc6b228 for the change for this commit.
> * N_CONSENSUS_BOOTSTRAP_SOURCES concerns me. What if we think
(someday) that we should try three fallbacks and an authority? Or that we
should try an authority only after three fallbacks have failed? How much
code would we need to discard?
TL;DR: We currently try 3 fallbacks and 2 authorities, if we need to.
Sorry for naming N_CONSENSUS_BOOTSTRAP_SOURCES badly, it's actually the
number of different schedules used to download a document, not the number
of sources.
(Modified the name to N_CONSENSUS_BOOTSTRAP_SCHEDULES.)
I think that this commit is unclear because the previous commit was poorly
documented.
The schedules determine how many authorities and fallbacks are attempted,
and in which order.
For example, the current default schedules are:
{{{
TestingClientBootstrapConsensusAuthorityDownloadSchedule 10, 11, ...
TestingClientBootstrapConsensusFallbackDownloadSchedule 0, 1, 4, 11, ...
}}}
This means that:
A fallback is tried immediately.
If a connection hasn't been successful after 1 second, another fallback is
tried.
If a connection hasn't been successful after 5 seconds (1+4), another
fallback is tried.
If a connection hasn't been successful after 10 seconds, an authority is
tried.
If a connection hasn't been successful after 16 seconds (1+4+11), another
fallback is tried.
If a connection hasn't been successful after 21 seconds (10+11), another
authority is tried.
(We can tune the schedules to manage the tradeoff between fallback load,
authority load, and bootstrap success rate.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4483#comment:43>
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