Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #18113

Closed (moved)
Open
Opened Jan 20, 2016 by Isis Lovecruft@isis

Dynamically allocate clients to default Tor Browser bridges of a certain type

Right now, if I've understood correctly, a client wanting to use Tor Browser's default bridges tries the first bridge of whichever bridge type they've selected, then the second, then third, etc. This is suboptimal because it leads to:

  1. The first default bridge gets hammered with many clients.
  2. The other bridges possibly aren't getting enough clients.
  3. The clients will only move to using a different default bridge if the ones previously tried are already overloaded, which means that a client waits longer to bootstrap Tor.
  4. The clients who do end up all sharing the first default bridge are probably having a bad time because they're all sharing the bandwidth and CPU capacities of one over-stressed bridge.

Can we just pick a random number, mod the total number of default bridges for that type, and use that bridge? Is there anything smarter we could do? Would we need to store state somewhere on which ones were previously tried?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#18113