Browse Source

Merge commit 'ioerror/DirFetchInfoExtraEarly'

Conflicts:
	ChangeLog
Nick Mathewson 15 years ago
parent
commit
2b0e8fb39f
5 changed files with 28 additions and 2 deletions
  1. 6 0
      ChangeLog
  2. 7 0
      doc/tor.1.in
  3. 5 0
      src/or/config.c
  4. 7 2
      src/or/networkstatus.c
  5. 3 0
      src/or/or.h

+ 6 - 0
ChangeLog

@@ -32,6 +32,12 @@ Changes in version 0.2.2.1-alpha - 2009-07-2?
     - Time and memory units in the configuration file can now be set to
       fractional units.  For example, "2.5 MB" is now a valid value for
       AccountingMax.
+    - Certain Tor clients (such as those behind check.torproject.org) may
+      want to fetch the consensus in an extra early manner. To enable this
+      a user may now set FetchDirInfoExtraEarly to 1. This also depends on
+      setting FetchDirInfoEarly to 1. Previous behavior will stay the same
+      as only certain clients who must have this information sooner should
+      set this option.
 
   o Deprecated and removed features:
     - The controller no longer accepts the old obsolete "addr-mappings/"

+ 7 - 0
doc/tor.1.in

@@ -241,6 +241,13 @@ fetching early. Normal users should leave it off.
 (Default: 0)
 .LP
 .TP
+\fBFetchDirInfoExtraEarly \fR\fB0\fR|\fB1\fR\fP
+If set to 1, Tor will fetch directory information before other
+directory caches. It will attempt to download directory information closer to
+the start of the consensus period. Normal users should leave it off.
+(Default: 0)
+.LP
+.TP
 \fBFetchHidServDescriptors \fR\fB0\fR|\fB1\fR\fP
 If set to 0, Tor will never fetch any hidden service descriptors from
 the rendezvous directories. This option is only useful if you're using

+ 5 - 0
src/or/config.c

@@ -215,6 +215,7 @@ static config_var_t _option_vars[] = {
   V(FirewallPorts,               CSV,      ""),
   V(FastFirstHopPK,              BOOL,     "1"),
   V(FetchDirInfoEarly,           BOOL,     "0"),
+  V(FetchDirInfoExtraEarly,      BOOL,     "0"),
   V(FetchServerDescriptors,      BOOL,     "1"),
   V(FetchHidServDescriptors,     BOOL,     "1"),
   V(FetchUselessDescriptors,     BOOL,     "0"),
@@ -3195,6 +3196,10 @@ options_validate(or_options_t *old_options, or_options_t *options,
     REJECT("HSAuthorityRecordStats is set but we're not running as "
            "a hidden service authority.");
 
+  if (options->FetchDirInfoExtraEarly && !options->FetchDirInfoEarly)
+    REJECT("FetchDirInfoExtraEarly requires that you also set "
+           "FetchDirInfoEarly");
+
   if (options->ConnLimit <= 0) {
     r = tor_snprintf(buf, sizeof(buf),
         "ConnLimit must be greater than 0, but was set to %d",

+ 7 - 2
src/or/networkstatus.c

@@ -1133,8 +1133,13 @@ update_consensus_networkstatus_fetch_time(time_t now)
       /* We want to cache the next one at some point after this one
        * is no longer fresh... */
       start = c->fresh_until + CONSENSUS_MIN_SECONDS_BEFORE_CACHING;
-      /* But only in the first half-interval after that. */
-      dl_interval = interval/2;
+      /* Some clients may need the consensus sooner than others. */
+      if (options->FetchDirInfoExtraEarly) {
+        dl_interval = 60;
+      } else {
+        /* But only in the first half-interval after that. */
+        dl_interval = interval/2;
+      }
     } else {
       /* We're an ordinary client or a bridge. Give all the caches enough
        * time to download the consensus. */

+ 3 - 0
src/or/or.h

@@ -2452,6 +2452,9 @@ typedef struct {
    * means directly from the authorities) no matter our other config? */
   int FetchDirInfoEarly;
 
+  /** Should we fetch our dir info at the start of the consensus period? */
+  int FetchDirInfoExtraEarly;
+
   char *VirtualAddrNetwork; /**< Address and mask to hand out for virtual
                              * MAPADDRESS requests. */
   int ServerDNSSearchDomains; /**< Boolean: If set, we don't force exit