[tor-bugs] #2372 [BridgeDB]: Export BridgeDB's pool assignments

[Tor Bug Tracker & Wiki]

#2372: Export BridgeDB's pool assignments
--------------------------+-------------------------------------------------
  Reporter:  karsten      |              Owner:       
      Type:  enhancement  |             Status:  new  
  Priority:  normal       |          Milestone:       
 Component:  BridgeDB     |            Version:       
  Keywords:               |             Parent:  #2537
    Points:               |   Actualpointsdone:       
Pointsdone:               |       Actualpoints:       
--------------------------+-------------------------------------------------

Comment(by nickm):

 Replying to [comment:7 karsten]:
 > Replying to [comment:5 nickm]:
 > > Adding another log and using it to log more information should be
 pretty easy.  Dumping all allocations should be relatively simple, but the
 format above is a little nontrivial to output.  The simplest format would
 be sorted by distributor, then by subring, then by ring position, so any
 bridge that appeared in multiple places would need to be postprocessed
 into one place.
 >
 > I don't understand the second half of your last sentence.  I noticed
 that bridges appear in multiple places in the logs, because they occur
 multiple times in the bridge-descriptors file, right?  But shouldn't the
 same bridge be allocated to the very same ring and subrings when parsing
 its descriptors, because the allocation is based on the bridge identity
 and the networkstatus-bridges file?

 Yeah.  My point was that there's nothing in principle that keeps a bridge
 from being assigned to more than one place at a time.  I don't think
 there's anything in bridgedb that does that currently thoguh.


 > The suggested log format was derived from the log file I had.  We can
 change the format if that makes things easier.  How about we take a) the
 subrings including IP ring X, stable, or port-443 subring, and b) the
 bridge IP address out of the new log format?  I don't know what to do with
 the information that a bridge is contained in IP ring X, and all flags,
 ports, and IP addresses are contained in the bridge descriptors that we
 already have.  The information I'm hoping to learn from the new log format
 is whether a bridge is allocated to the email or web pool or not allocated
 at all.  How about this new format:
 >
 > {{{
 > bridge-pool-assignment 2011-01-10 01:41:14
 > abcdef0123456789abcdef0123456789abcdef01 unallocated
 > 0123456789abcdef0123456789abcdef01234567 web
 > 4567890987654321234567890abcdefedcbabcde email
 > }}}

 Probably also doable.  Let me see what I can do.  I'm thinking of
 including the extra information that you say you don't know what to do
 with, just in case later there's a use for it.

 > Replying to [comment:6 nickm]:
 > > To add: if that approach I just described is good enough, I think the
 way you'd want to do it is to add a function to BridgeHolder that dumped
 its contents to a string or an open file or something.  We'd need to think
 a little, though, about how that would work with unallocated bridges and
 bridges assigned to "distributors" that only exist in the DB.
 >
 > I don't know much about Python, but I can try to work on a BridgeDB
 patch.  I have a working BridgeDB installed on a local machine here.  Can
 you give me some more guidance how to implement the format described in
 this comment?

 I hacked up some totally untested code in branch "dump" in my public
 bridgedb repo.  It doesn't handle unallocated bridges yet, and nothing
 calls it yet, but it should be a good starting point for a patch.  Let me
 know if you have any questions about it.

 > I also don't quite understand the last sentence of your second comment.
 The logs I had (see original task description above) contained lines for
 unallocated bridges.  What distributors are there that only exist in the
 database, and why do we have to treat them specially?

 Thanks to kaner's "buckets" thing, there are some distributors that just
 mean that some "unallocated" bridges are written out to files.  These
 bridges (like other unallocated bridges) don't currently exist at all in-
 memory for bridgedb.  I'm starting to think that choice was iffy.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2372#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online