Chelsea Komlo ckomlo@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.