[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7157 [Tor]: "Low circuit success rate %u/%u for guard %s=%s."
#7157: "Low circuit success rate %u/%u for guard %s=%s."
-----------------------------------------+----------------------------------
Reporter: arma | Owner:
Type: enhancement | Status: needs_revision
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-client, MikePerry201212 | Parent: #5456
Points: | Actualpoints: 19
-----------------------------------------+----------------------------------
Comment(by mikeperry):
Replying to [comment:26 nickm]:
> Replying to [comment:25 mikeperry]:
> > I did not do anything with timestamp_dirty yet. I'm pretty sure we
want to keep at least the hidserv timestamp_dirty additions.. Do you just
want me to move the timestamp_dirty change to the cannibalization code? It
does appear like that might make us decide against re-cannibalizing it,
and may impact our use of cannibalized circuits under predictive building
conditions + new identity.. hrmm...
>
> At this point, I think whichever option is simplest would be best here.
This is tricky stuff, and at least your existing code is tested... but if
it breaks functionality we care about, we need to think of the simplest
fix there. Regressions are teh suxx0r.
>
> > If you want me to switch to another path_state_t flag, I can do that,
but it's a bit more changes+refactoring.
I do like the idea of having symmetry in the path_state_t transitions..
Right now we have BUILD_ATTEMPTED, BUILD_SUCCEEDED, and USE_SUCCEEDED, but
no USE_ATTEMPTED. USE_ATTEMPTED would allow us to stop abusing
timestamp_dirty as part of our path_state_t state machine, and *might*
stave off future bugs due to additional future use of timestamp_dirty..
If you're willing to hold off on merging this to review #7341 and #7691,
it probably makes sense to make this change now. That way, I can retest
all three bugs with the same tests once I fix any changes you want me to
make to those two bugs (and I'm sure there will be at least a few).
Or, we can file a separate ticket for this path_state_t change, and do the
retesting for it and those two after you review them.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7157#comment:27>
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