commit a45591af98741f5b4d7cf9a6cd5fbd1603c3bfe8 Author: Isis Lovecruft <isis@torproject.org> Date: Thu Apr 9 06:44:43 2015 +0000 Why were there ever unreachable subhashrings? Kill them with fire. As part of #4297, $SOMEONE added the prepopulateRings() methods, which are used when BridgeDB parses incoming descriptors. These methods add subhashrings and allocate bridges to them. When a client requests bridges, they are either requesting IPv4 or IPv6 bridges, and thus clients *always* have either filterBridgesByIPv4 or filterBridgesByIPv6, respectively. So why is there an extra subhashring with no IP version filters if clients *can never get to it*? Blame $SOMEONE. The $SOMEONE who authored the commit below would be a good start. * BUGFIX on e6ce57e728802689544c130867edcadfeecd38ec. * REMOVE the "filterless" subhashring from the IPBasedDistributor. * UPDATE documentation for IPBasedDistributor.prepopulateRings(). --- lib/bridgedb/Dist.py | 34 +++++++++++++--------------------- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/lib/bridgedb/Dist.py b/lib/bridgedb/Dist.py index 954b570..0658504 100644 --- a/lib/bridgedb/Dist.py +++ b/lib/bridgedb/Dist.py @@ -233,33 +233,25 @@ class IPBasedDistributor(Distributor): | Subhashrings | | | | | | | | (total, assigned)| (6,0) | (6,1) | (6,2) | (6,3) | (6,4) | (6,5) | +------------------+------------+------------+------------+------------+------------+------------+ - | Filtered | (6,0) | (6,1) | (6,2) | (6,3) | (6,4) | (6,5) | - | Subhashrings +------------+------------+------------+------------+------------+------------+ - | bBy requested | (6,0)-IPv4 | (6,1)-IPv4 | (6,2)-IPv4 | (6,3)-IPv4 | (6,4)-IPv4 | (6,5)-IPv4 | - | bridge type) +------------+------------+------------+------------+------------+------------+ - | | (6,0)-IPv6 | (6,1)-IPv6 | (6,2)-IPv6 | (6,3)-IPv6 | (6,4)-IPv6 | (6,5)-IPv6 | + | Filtered | (6,0)-IPv4 | (6,1)-IPv4 | (6,2)-IPv4 | (6,3)-IPv4 | (6,4)-IPv4 | (6,5)-IPv4 | + | Subhashrings | | | | | | | + | bBy requested +------------+------------+------------+------------+------------+------------+ + | bridge type) | (6,0)-IPv6 | (6,1)-IPv6 | (6,2)-IPv6 | (6,3)-IPv6 | (6,4)-IPv6 | (6,5)-IPv6 | + | | | | | | | | +------------------+------------+------------+------------+------------+------------+------------+ - The "filtered subhashrings" are essentially copies of their respective - subhashring, that is, subhashring ``(6,0)`` contains both IPv4 and - IPv6 bridges, meaning that its contents are a superset of the filtered - subhashrings ``(6,0)-IPv4`` and ``(6,0)-IPv6``. (I have no idea of - the relation between ``(6,0)-IPv4`` and ``(6,0)-IPv6``, including - whether or not their contents are disjoint. I didn't design this shit, - I'm just redesigning it.) - - "Why does the ``(6,0)`` superset subhashring exist then?" + The "filtered subhashrings" are essentially filtered copies of their + respective subhashring, such that they only contain bridges which + support IPv4 or IPv6, respectively. (I have no idea of the relation + between ``(6,0)-IPv4`` and ``(6,0)-IPv6``, including whether or not + their contents are disjoint. I didn't design this shit, I'm just + redesigning it.) - you might ask. That's a very good question. I don't know either. - I'm inclined to think it shouldn't exist, unless we wish to allow - clients to request IPv4 bridges and IPv6 bridges simultaneously - (there's currently no interface to do this, however). - - Thus, in this example, we end up with **18 total subhashrings**. + Thus, in this example, we end up with **12 total subhashrings**. """ logging.info("Prepopulating %s distributor hashrings..." % self.name) # populate all rings (for dumping assignments and testing) - for filterFn in [None, filterBridgesByIP4, filterBridgesByIP6]: + for filterFn in [filterBridgesByIP4, filterBridgesByIP6]: n = self.nClusters for category in self.categories: g = filterAssignBridgesToRing(self.splitter.hmac,