[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r15357: start sending "COUNT=%d RECOMMENDATION=%s" key/values on boo (in tor/trunk: doc doc/spec/proposals src/or)

To: or-cvs@xxxxxxxxxxxxx
Subject: [or-cvs] r15357: start sending "COUNT=%d RECOMMENDATION=%s" key/values on boo (in tor/trunk: doc doc/spec/proposals src/or)
From: arma@xxxxxxxx
Date: Thu, 19 Jun 2008 00:50:07 -0400 (EDT)
Delivered-to: archiver@xxxxxxxx
Delivered-to: or-cvs-outgoing@xxxxxxxx
Delivered-to: or-cvs@xxxxxxxx
Delivery-date: Thu, 19 Jun 2008 00:50:10 -0400
Reply-to: or-dev@xxxxxxxxxxxxx
Sender: owner-or-cvs@xxxxxxxxxxxxx

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);

Prev by Author: [or-cvs] r15355: check-spaces, fix a typo (tor/trunk/src/or)
Next by Author: [or-cvs] r15366: Big bridge bugfixes. Backport candidates. If you have more t (in tor/trunk: . src/or)
Previous by thread: [or-cvs] r15356: Heh. Log messages are the root of all evil.. Or was that pre (torbutton/trunk/src/components)
Next by thread: [or-cvs] r15358: Vidalia now has po files directly in the Vidalia repository. (translation/trunk/projects)
Index(es):
- Author
- Thread