Bridges now behave like clients with respect to time intervals for

downloading new consensus documents. Bridge users now wait until
the end of the interval, so their bridge will be sure to have a
new consensus document.

svn:r12696

diff --git a/ChangeLog b/ChangeLog
index ccd9accc15a2e6667fabbbdc369d94f59a06157f..a6f31582640abf9695cf3d177a6dda43220905a5 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -17,6 +17,12 @@ Changes in version 0.2.0.13-alpha - 2007-12-??
     - Stop being so aggressive about fetching v2 dir info if your
       DirPort is on but your ORPort is off.
 
+  o Major features:
+    - Bridges now behave like clients with respect to time intervals for
+      downloading new consensus documents. Bridge users now wait until
+      the end of the interval, so their bridge will be sure to have a
+      new consensus document.
+
   o Minor bugfixes:
     - The fix in 0.2.0.12-alpha cleared the "hsdir" flag in v3 network
       consensus documents when there are too many relays at a single

diff --git a/doc/spec/proposals/125-bridges.txt b/doc/spec/proposals/125-bridges.txt
index 9601de4e1ef40cf51c4725bb53ed849f56215846..a0d51f3fe39880a792a473942b50fd31d4fa3482 100644 (file)
--- a/doc/spec/proposals/125-bridges.txt
+++ b/doc/spec/proposals/125-bridges.txt
@@ -24,11 +24,13 @@ Status: Open
 1.1. PublishServerDescriptor
 
   To configure your relay to be a bridge relay, just add
+    BridgeRelay 1
     PublishServerDescriptor bridge
   to your torrc. This will cause your relay to publish its descriptor
   to the bridge authorities rather than to the default authorities.
 
   Alternatively, you can say
+    BridgeRelay 1
     PublishServerDescriptor 0
   which will cause your relay to not publish anywhere. This could be
   useful for private bridges.
@@ -40,28 +42,17 @@ Status: Open
   can supply their bridge users with cached copies of all the various
   Tor network information.
 
-  Right now (0.2.0.11-alpha) we require that bridges turn their DirPort on
-  -- which means both that we answer BEGIN_DIR requests and that we fetch
-  and cache directory information in an aggressive way like other servers.
-
-  But:
-  a) we don't enforce that DirPort is on, since it's not clear how to
-  detect if the user meant to be a bridge. So it's easy to set up a bridge
-  relay that silently refuses BEGIN_DIR requests and is thus useless.
-  b) We don't actually care if they have an open or reachable DirPort. So
-  at some point we should separate having an open DirPort from answering
-  directory questions. Which leads to:
-  c) We need to investigate if there are any anonymity worries with
-  answering BEGIN_DIR requests when our DirPort is off. If there aren't,
-  we should drop the DirPort requirement.
-
-  I claim that we don't open any new attacks by answering BEGIN_DIR
-  questions when DirPort is off: it's still a fine question to ask what
-  partitioning attacks there are when you can query a Tor client about
-  its current directory opinions, but these attacks already exist when
-  DirPort is on.
-
-  We need to answer this issue in 0.2.0.x.
+  As for Tor 0.2.0.13-alpha, bridges will answer begin_dir questions
+  (and cache dir info they see so the answers will be more useful)
+  whether their DirPort is enabled or not. (After all, we don't care if
+  they have an open or reachable DirPort to answer begin_dir questions.)
+
+  We need to investigate if there are any anonymity worries with answering
+  BEGIN_DIR requests when our DirPort is off. I claim that we don't open
+  any new attacks: it's still a fine question to ask what partitioning
+  attacks there are when you can query a Tor client about its current
+  directory opinions, but these attacks already exist when DirPort is on.
+  We should investigate this in 0.2.1.x.
 
 1.3. Exit policy
 

diff --git a/src/or/dirserv.c b/src/or/dirserv.c
index f36ac55b672a04436283e70e27b58f0971b79a23..e0d4d05a10e6b788652e157265b18cc74d26d574 100644 (file)
--- a/src/or/dirserv.c
+++ b/src/or/dirserv.c
@@ -1096,8 +1096,11 @@ dirserv_dump_directory_to_string(char **dir_out,
 int
 directory_fetches_from_authorities(or_options_t *options)
 {
+  /* XXX if options->FetchDirInfoEagerly, return 1 */
   if (options->DirPort == 0)
     return 0;
+  if (options->BridgeRelay == 1)
+    return 0;
   /* XXX if dirport not advertised, return 0 too */
   if (!server_mode(options))
     return 0;

diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c
index 54a9da4c23c7389e7859afb2cdf1664c6b028a08..605c8d5f7624312d8c394eb0f15c9772c96e8b65 100644 (file)
--- a/src/or/networkstatus.c
+++ b/src/or/networkstatus.c
@@ -1058,12 +1058,21 @@ update_consensus_networkstatus_fetch_time(time_t now)
       /* But only in the first half-interval after that. */
       dl_interval = interval/2;
     } else {
-      /* Give all the caches enough time to download the consensus.*/
+      /* We're an ordinary client or a bridge. Give all the caches enough
+       * time to download the consensus. */
       start = c->fresh_until + (interval*3)/4;
-      /* But download the next one before this one is expired. */
+      /* But download the next one well before this one is expired. */
       dl_interval = ((c->valid_until - start) * 7 )/ 8;
-    /* XXX020 do something different if
-     * directory_fetches_dir_info_like_bridge_user() */
+
+      /* If we're a bridge user, make use of the numbers we just computed
+       * to choose the rest of the interval *after* them. */
+      if (directory_fetches_dir_info_like_bridge_user(options)) {
+        /* Give all the *clients* enough time to download the consensus. */
+        start = start + dl_interval + CONSENSUS_MIN_SECONDS_BEFORE_CACHING;
+        /* But try to get it before ours actually expires. */
+        dl_interval = (c->valid_until - start) -
+                      CONSENSUS_MIN_SECONDS_BEFORE_CACHING;
+      }
     }
     if (dl_interval < 1)
       dl_interval = 1;