[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3015 [BridgeDB]: Enhance bucket functionality
#3015: Enhance bucket functionality
-------------------------+--------------------------------------------------
Reporter: kaner | Owner: kaner
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: BridgeDB | Version:
Keywords: | Parent:
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by karsten):
So, after discussing this on IRC and trying out the code, I think BridgeDB
does ''not'' remove non-running bridges from file buckets. At least the
number of bridges never decreased, but always stayed the same or increased
in my tests. This also makes sense in the code, because Bucket.py does
not import anything from Bridges.py, and Bridges.py is where we store
which bridges are running.
(I think what confused me on IRC was that when we dump bridge pool
assignments, we look at the running bridges in Bridges.py and obtain the
pseudo distributors from Buckets.py. We do not, however, simply iterate
over all the bridges in Buckets.py. That's why we only dump pool
assignments of running bridges.)
The fact that we dump non-running bridges to file buckets is a bug, and we
shouldn't fix it by only removing bridges that haven't been running for a
day or two. I don't see how distributing bridges via HTTPS/email or via
Twitter/social networks is different in that we make sure we give out only
running bridges in the former case but not in the latter. And we do have
the information which bridges are running, so I think we should use it.
Here's my idea:
We could make the BucketManager in Buckets.py, that decides which bridges
are written to which file, extend from Bridges.BridgeHolder in the same
way as the *Distributor classes in Dist.py do. That's how the
BucketManager would learn which bridges are running at the moment.
We could also remove the command-line option to dump bridges to buckets
and simply dump them whenever we're done reloading the network status and
bridge descriptors. External tools wouldn't have to run BridgeDB with the
command-line option, but could simply read the files whenever they like.
As a side-effect, this approach would implement the first half of #2755 by
removing the time gap between dumping bridges to file buckets (and thereby
possibly changing their pseudo distributors) and dumping assignments upon
the next HUP.
Does that make sense?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3015#comment:4>
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