Re: [tor-bugs] #12595 [Tor]: Think of better data structures for guard nodes

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#12595: Think of better data structures for guard nodes
------------------------+--------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-guard
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------

Comment (by nickm):

 Replying to [comment:1 asn]:
 > One of the possible designs discussed during the dev meeting, is to have
 two guard lists. One list is the `entry_guards` list, and the other is the
 `directory_guards` list.

 Seems plausible to me.

 > Some more ideas that were thrown around during the dev meeting, and
 would make guard selection smoother:
 > - `All guards should be directory caches` which will happen as part of
 #12597.

 Remember that we can't rely on "All guards are directory caches" until all
 server versions before 0.2.6 are obsolete.

 > - `All guards should be considered fast/stable`, '''or''' `Relays can be
 guards iff they are fast/stable`. This will make it more likely that
 guards on the top of our list can be used for our purposes, since we will
 not have to skip guards till we find a stable guard for stable circuits.
 However, because of the analysis in #12204, this is not very likely to
 happen anyway.

 "All guards should be considered fast/stable" seems okay to me, unless I'm
 missing something.

 > Also, it's worth noting that designing data structures with the
 assumption that we are only going to have 1 primary guard is probably
 easier than designing data structures that can accommodate N primary
 guards.

 Hmmm.  No, I don't agree with that one.  We need to have some notion of
 what we're going to do when we move back and forth between versions of Tor
 that use the old state file and the new one.  We should also know what to
 do when our main guard is down for a while, then comes back up.  I think
 that the data structure we need to handle both of those problems will be
 not too far from the one that we would need to keep support for N guards.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12595#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs