[tor-commits] [bridgedb/develop] Why were there ever unreachable subhashrings? Kill them with fire.

[isis@xxxxxxxxxxxxxx]

commit a45591af98741f5b4d7cf9a6cd5fbd1603c3bfe8
Author: Isis Lovecruft <isis@xxxxxxxxxxxxxx>
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,



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits