summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2008-06-19 04:50:06 +0000
committerRoger Dingledine <arma@torproject.org>2008-06-19 04:50:06 +0000
commitd76d0493d64c512e36e1bd1d3b9e9aaf73f7df1e (patch)
tree5a33f4fe5462d4211654ab91a5f798c9396c312a
parentad6b2e75233168fbe27052f56e201fc355d63e98 (diff)
downloadtor-d76d0493d64c512e36e1bd1d3b9e9aaf73f7df1e.tar.gz
tor-d76d0493d64c512e36e1bd1d3b9e9aaf73f7df1e.zip
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. svn:r15357
-rw-r--r--doc/TODO8
-rw-r--r--doc/spec/proposals/137-bootstrap-phases.txt39
-rw-r--r--src/or/control.c13
3 files changed, 36 insertions, 24 deletions
diff --git a/doc/TODO b/doc/TODO
index d43a7f6327..bb729af13e 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -340,15 +340,17 @@ R - investigate: it looks like if the bridge authority is unreachable,
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:
diff --git a/doc/spec/proposals/137-bootstrap-phases.txt b/doc/spec/proposals/137-bootstrap-phases.txt
index a77b03340a..fb949f8cfb 100644
--- a/doc/spec/proposals/137-bootstrap-phases.txt
+++ b/doc/spec/proposals/137-bootstrap-phases.txt
@@ -30,7 +30,8 @@ Status: Open
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 @@ Status: Open
(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 @@ Status: Open
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.
-
- 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.)
+ 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 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 @@ Status: Open
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.
diff --git a/src/or/control.c b/src/or/control.c
index bb756b4eef..bef6028c75 100644
--- a/src/or/control.c
+++ b/src/or/control.c
@@ -3858,12 +3858,15 @@ control_event_bootstrap_problem(const char *warn, int reason)
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 @@ control_event_bootstrap_problem(const char *warn, int reason)
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);