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

Closed (moved)
Open
Opened Jun 04, 2014 by George Kadianakis@asn

Revisit flags passed to entry_is_live() around entrynodes.c

It seems that we are almost always passing need_capacity=True to entry_is_live().

The only case where we don't, is in choose_random_entry_impl() where we actually pick an entry guard. In that case, we pass whatever cpath_build_state_t.need_capacity is set to (which makes sense).

However, in other calls, like the one at entry_guard_register_connect_status(), we always call entry_is_live() with need_capacity set to true. Is this needed?

In entry_guard_register_connect_status(), if we just connected for the first time to a new guard, we re-activate all the previous live guards since it might be a sign that our network was down and it just came back up. However, since entry_is_live() is used with need_capacity we only reactivate the Fast guards.

However, as I understand it, there is no requirement that guards need to be Fast. So it might be the case, that if our primary guard is not fast, we don't reactivate it.

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