[tor-dev] DirAuth usage and 503 try again later
jbrown299 at yandex.com
Mon Jan 11 22:20:29 UTC 2021
Is there any chance that torpy (https://github.com/torpyorg/torpy) was
triggered this issue
Some wary facts:
- Torpy using old fashion consensus (not mircodesc)
- When consensus not present in cache (first time usage) it downloads
consensus from random directory authorities only.
- Before August 2020 it was using plain HTTP requests to DirAuths. Now
it creates "CREATE_FAST" circuits to DirAuths (is that right way by the
From other side:
- Torpy store consensus on disk (so whenever client restart it must not
download full consensus again)
- It will try download consensus after time which sets by valid_time
field from consensus which more than 1 hour (so it's not so often)
- Torpy try get consensus by "diff" feature (so it's minimize traffic)
Still may be some of this features not working well in some conditions.
Which could cause a lot of consensus downloads in Jan 2020... Or may be
you know more info about this situation?
Do you have some recommendations for tor client implementation?
Can you explain in several paragraphs what behavior of original tor
client is? As far as I understand when first time original tor starts it
tries download consensus from fallback dirs not from DA? Is this key point?
There is one more issue
which I'm not understand correctly. Let's imagine it's first run of tor
client and that time coincidentally coincided with DA voting. That means
client will not be able to download consensus? That is strange decision.
Or do you mean clients must download consensus from fallback dirs which
never in "voting" process?
More information about the tor-dev