[tor-dev] DirAuth usage and 503 try again later

[Anthony Korte]

I have an unrelated question... where could I go with similar minds so that
I may ask or would it be appropriate and acceptable to do that here ,
thanks .

On Mon, Jan 11, 2021, 6:21 PM James <jbrown299 at yandex.com> wrote:

> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20210120/42769451/attachment.htm>