[or-cvs] r15357: start sending "COUNT=%d RECOMMENDATION=%s" key/values on boo (in tor/trunk: doc doc/spec/proposals src/or)
arma at seul.org
arma at seul.org
Thu Jun 19 04:50:07 UTC 2008
Author: arma
Date: 2008-06-19 00:50:06 -0400 (Thu, 19 Jun 2008)
New Revision: 15357
Modified:
tor/trunk/doc/TODO
tor/trunk/doc/spec/proposals/137-bootstrap-phases.txt
tor/trunk/src/or/control.c
Log:
start sending "COUNT=%d RECOMMENDATION=%s" key/values on bootstrap
problem status events, so the controller can hear about problems even
before tor decides they're worth reporting for sure.
Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO 2008-06-19 04:22:27 UTC (rev 15356)
+++ tor/trunk/doc/TODO 2008-06-19 04:50:06 UTC (rev 15357)
@@ -340,15 +340,17 @@
o directory authorities shouldn't complain about bootstrapping problems
just because they do a lot of reachability testing and some of
it fails.
-R - if your bridge is unreachable, it won't generate enough connection
+R * if your bridge is unreachable, it won't generate enough connection
failures to generate a bootstrap problem event.
R - if "no running bridges known", an application request should make
us retry all our bridges.
-R - get matt to fix vidalia so it moves to a "starting tor" bootstrap
+ o get matt to fix vidalia so it moves to a "starting tor" bootstrap
state if it hasn't gotten any status events. Maybe it can even be
more certain by checking the version (<0211) and/or looking at the
results of the getinfo.
-R - in circuituse.c,
+R - get matt to make vidalia do a getinfo status/bootstrap-phase to
+ get caught up after it connects.
+R * in circuituse.c,
/* XXX021 consider setting n_conn->socket_error to TIMEOUT */
For 0.2.1.x:
Modified: tor/trunk/doc/spec/proposals/137-bootstrap-phases.txt
===================================================================
--- tor/trunk/doc/spec/proposals/137-bootstrap-phases.txt 2008-06-19 04:22:27 UTC (rev 15356)
+++ tor/trunk/doc/spec/proposals/137-bootstrap-phases.txt 2008-06-19 04:50:06 UTC (rev 15357)
@@ -30,7 +30,8 @@
So in this case we send
650 STATUS_CLIENT NOTICE/WARN BOOTSTRAP \
- PROGRESS=num TAG=Keyword SUMMARY=String WARNING=String REASON=Keyword
+ PROGRESS=num TAG=Keyword SUMMARY=String \
+ [WARNING=String REASON=Keyword COUNT=num RECOMMENDATION=Keyword]
The arguments MAY appear in any order. Controllers MUST accept unrecognized
arguments.
@@ -47,8 +48,10 @@
(severity notice) or an indication of a bootstrapping problem
(severity warn). If severity warn, it should also include a "warning"
argument string with any hints Tor has to offer about why it's having
- troubles bootstrapping, and a "reason" string that lists of the reasons
- allowed in the ORConn event.
+ troubles bootstrapping, a "reason" string that lists one of the reasons
+ allowed in the ORConn event, a "count" number that tells how many
+ bootstrap problems there have been so far at this phase, and a
+ "recommendation" keyword to indicate how the controller ought to react.
3. The bootstrap phases.
@@ -182,21 +185,23 @@
When an OR Conn fails, we send a "bootstrap problem" status event, which
is like the standard bootstrap status event except with severity warn.
We include the same progress, tag, and summary values as we would for
- a normal bootstrap event, but we also include 'warning' and 'reason'
- strings.
+ a normal bootstrap event, but we also include "warning", "reason",
+ "count", and "recommendation" key/value combos.
- The reason strings are long-term-stable controller-facing tags to
+ The "reason" values are long-term-stable controller-facing tags to
identify particular issues in a bootstrapping step. The warning
- strings, on the other hand, are human-readable. Controllers SHOULD
- NOT rely on the format of any warning string.
+ strings, on the other hand, are human-readable. Controllers SHOULD
+ NOT rely on the format of any warning string. Currently the possible
+ values for "recommendation" are either "ignore" or "warn" -- if ignore,
+ the controller can accumulate the string in a pile of problems to show
+ the user if the user asks; if warn, the controller should alert the
+ user that Tor is pretty sure there's a bootstrapping problem.
- Currently Tor ignores the first nine bootstrap problem reports for
- a given phase, reports the tenth to the controller, and then ignores
- further problems at that phase. Hopefully this is a good balance between
- tolerating occasional errors and reporting serious problems quickly. (We
- will want to revisit this approach if there are many different 'reason'
- values being reported among the first ten problem reports, since in
- this case the controller will only hear one of them.)
+ Currently Tor uses recommendation=ignore for the first nine bootstrap
+ problem reports for a given phase, and then uses recommendation=warn
+ for subsequent problems at that phase. Hopefully this is a good
+ balance between tolerating occasional errors and reporting serious
+ problems quickly.
5. Suggested controller behavior.
@@ -217,7 +222,7 @@
Controllers should also have some mechanism to alert their user when
bootstrapping problems are reported. Perhaps we should gather a set of
help texts and the controller can send the user to the right anchor in a
- "bootstrapping problems" help page?
+ "bootstrapping problems" page in the controller's help subsystem?
6. Getting up to speed when the controller connects.
Modified: tor/trunk/src/or/control.c
===================================================================
--- tor/trunk/src/or/control.c 2008-06-19 04:22:27 UTC (rev 15356)
+++ tor/trunk/src/or/control.c 2008-06-19 04:50:06 UTC (rev 15357)
@@ -3858,13 +3858,16 @@
int status = bootstrap_percent;
const char *tag, *summary;
char buf[BOOTSTRAP_MSG_LEN];
+ const char *recommendation = "ignore";
if (bootstrap_percent == 100)
return; /* already bootstrapped; nothing to be done here. */
- if (++bootstrap_problems != BOOTSTRAP_PROBLEM_THRESHOLD)
- return; /* no worries yet */
+ bootstrap_problems++;
+ if (bootstrap_problems >= BOOTSTRAP_PROBLEM_THRESHOLD)
+ recommendation = "warn";
+
while (status>=0 && bootstrap_status_to_string(status, &tag, &summary) < 0)
status--; /* find a recognized status string based on current progress */
@@ -3872,9 +3875,11 @@
status, summary, warn,
orconn_end_reason_to_control_string(reason));
tor_snprintf(buf, sizeof(buf),
- "BOOTSTRAP PROGRESS=%d TAG=%s SUMMARY=\"%s\" WARNING=\"%s\" REASON=%s",
+ "BOOTSTRAP PROGRESS=%d TAG=%s SUMMARY=\"%s\" WARNING=\"%s\" REASON=%s "
+ "COUNT=%d RECOMMENDATION=%s",
bootstrap_percent, tag, summary, warn,
- orconn_end_reason_to_control_string(reason));
+ orconn_end_reason_to_control_string(reason), bootstrap_problems,
+ recommendation);
tor_snprintf(last_sent_bootstrap_message,
sizeof(last_sent_bootstrap_message),
"WARN %s", buf);
More information about the tor-commits
mailing list