Good day.
Is there any chance that torpy (https://github.com/torpyorg/torpy) was
triggered this issue
https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ?
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
way?)
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
https://gitlab.torproject.org/tpo/core/tor/-/issues/40239
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?
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev