[tor-dev] Existing Tor Guard Selection Algorithm

[George Kadianakis]

Chelsea Komlo <ckomlo at thoughtworks.com> writes:

> Hi George,
>
> Thanks for your help with this!
>
> We wrote up our high-level understanding of the current Tor guard selection
> algorithm here:
>
> https://gist.github.com/chelseakomlo/2acbe15314b5a809c6f4
>
> This has more than our python simulation, but less than the actual Tor
> implementation. For example, it is missing conditions like prioritization
> by uptime, capacity, etc.
>
> https://github.com/twstrike/tor_guardsim/blob/develop/lib/original_client.py
>
> If you wouldn't mind taking a look at this and letting us know anything
> that is missing/should change, that would be really helpful.
>

Your pseudocode looks pretty accurate based on what I remember from the guard
algorithm and from quickly skimming the code.

One inaccuracy might be that if IIRC in RECEIVE_NEW_CONSENSUS we don't remove
guards that are not listed in the latest consensus. Instead we mark them as 'bad'
which rules them out of retries etc. till they reappear on the consensus.
See entry_guard_set_status() and its caller for how this works.

Also in "Otherwise (if the list of live guards contains only 1):" if the list
of live guards contains only 1 entry, and we are looking for one guard,
shouldn't we be be happy about it?

Also, the directory guards case is not handled in your spec (where we have
NumDirectoryGuards=3). Maybe that's on purpose though.