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
  • #25885

Closed (moved)
Open
Opened Apr 22, 2018 by Nick Mathewson@nickm🐙

count_acceptable_nodes() would be more accurate using node_has_preferred_descriptor()

On a github review for #25691 (moved), Teor notes about count_acceptable_nodes():

I think this code is correct, but it's not obvious:

  1. new_route_len() is the only caller
  2. new_route_len() will fail if count_acceptable_nodes() is less than the route length.
  3. later functions will fail if there is no guard
  4. later functions will fail if there are not enough subsequent nodes for the rest of the route

So this check can spuriously succeed when we have no guards, or when we have many bridges, and no subsequent nodes. But it can never fail when there are actually enough nodes for the path. So this is just an optimisation to stop us trying to build lots of circuits when we have no descriptors.

We could return the number that pass for_direct_connect = 1 and for_direct_connect = 0, but that seems unnecessarily complicated.

I think that we should probably adjust this function to do the careful count, but it's safe to defer.

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