[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #2755 [BridgeDB]: Reconsider BridgeDB's pool assignment file implementation and deployment
#2755: Reconsider BridgeDB's pool assignment file implementation and deployment
----------------------+-----------------------------------------------------
Reporter: karsten | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: BridgeDB | Version:
Keywords: | Parent:
Points: | Actualpoints:
----------------------+-----------------------------------------------------
While deploying the new BridgeDB feature that dumps bridge pool
assignments to disk, I had two ideas for improving that feature. Neither
of these ideas are critical, and I wanted to see how well the current
implementation works before making it even more perfect. Maybe we should
revisit these ideas in a month or two from now.
- We only write to assignments.log after parsing a new network status
file, but not after dumping unallocated bridges to file buckets. That
means we might miss the fact that, say, Twitter distributes new bridges
for up to 30 minutes between dumping to file buckets and reading the next
network status. Does that matter? Should we also write to
assignments.log after dumping to file buckets?
- Appending to a single assignments.log file and rsyncing that to the
host that sanitizes it won't scale forever. We could run a monthly or
weekly cronjob that runs `"mv assignments.log assignments.log.old"`.
metrics-db can handle multiple input files and will read both files, as
long as they are rsync'ed correctly.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2755>
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