[or-cvs] r9491: cleanups based on looking through svn commits (in tor/trunk: . doc doc/spec src/or)

[arma@xxxxxxxx]

Author: arma
Date: 2007-02-05 19:27:03 -0500 (Mon, 05 Feb 2007)
New Revision: 9491

Modified:
   tor/trunk/ChangeLog
   tor/trunk/doc/spec/path-spec.txt
   tor/trunk/doc/tor.1.in
   tor/trunk/src/or/circuitbuild.c
   tor/trunk/src/or/connection_or.c
Log:
cleanups based on looking through svn commits


Modified: tor/trunk/ChangeLog
===================================================================
--- tor/trunk/ChangeLog	2007-02-06 00:02:31 UTC (rev 9490)
+++ tor/trunk/ChangeLog	2007-02-06 00:27:03 UTC (rev 9491)
@@ -29,8 +29,15 @@
       pointer loops.
     - Fix a memory leak when sending a 503 response for a networkstatus
       request.
-    - If we're not marking exits as guards, ignore exit bandwidth
-      when we're deciding the required bandwidth to become a guard.
+    - If exits are rare enough that we're not marking exits as guards,
+      ignore exit bandwidth when we're deciding the required bandwidth
+      to become a guard.
+    - When we're handling a directory connection tunneled over Tor,
+      don't fill up internal memory buffers with all the data we want
+      to tunnel; instead, only add it if the OR connection that will
+      eventually receive it has some room for it. (This can lead to
+      slowdowns in tunneled dir connections; a better solution will have
+      to wait for 0.2.0.)
 
   o Minor bugfixes:
     - When computing clock skew from directory HTTP headers, consider what
@@ -58,12 +65,6 @@
       us from downloading a bunch of descriptors we don't need.
     - Do not log IPs with TLS failures for incoming TLS
       connections. (Fixes bug 382.)
-    - When we're handling a directory connection tunneled over Tor,
-      don't fill up internal memory buffers with all the data we want
-      to tunnel; instead, only add it if the OR connection that will
-      eventually receive it has some room for it. (This can lead to
-      slowdowns in tunneled dir connections; a better solution will have
-      to wait for 0.2.0.)
     - If the user asks to use invalid exit nodes, be willing to use the
       unstable ones.
     - Handle TTL values correctly on reverse DNS lookups.
@@ -76,12 +77,13 @@
   o Major features:
     - Weight directory requests by advertised bandwidth. Now we can
       let servers enable write limiting but still allow most clients to
-      succeed at their directory requests.
+      succeed at their directory requests. (We still ignore weights when
+      choosing a directory authority; I hope this is a feature.)
 
   o Minor features:
     - Create a new file ReleaseNotes which was the old ChangeLog. The
-      new ChangeLog file now includes the summaries for even development
-      versions.
+      new ChangeLog file now includes the summaries for all development
+      versions too.
     - Check for addresses with invalid characters at the exit as well
       as at the client, and warn less verbosely when they fail. You can
       override this by setting ServerDNSAllowNonRFC953Addresses to 1.

Modified: tor/trunk/doc/spec/path-spec.txt
===================================================================
--- tor/trunk/doc/spec/path-spec.txt	2007-02-06 00:02:31 UTC (rev 9490)
+++ tor/trunk/doc/spec/path-spec.txt	2007-02-06 00:27:03 UTC (rev 9491)
@@ -270,7 +270,8 @@
 
   We use Guard nodes (also called "helper nodes" in the literature) to
   prevent certain profiling attacks.  Here's the risk: if we choose entry and
-  exit nodes at random, and an attacker controls C out of N servers, then the
+  exit nodes at random, and an attacker controls C out of N servers
+  (ignoring advertised bandwidth), then the
   attacker will control the entry and exit node of any given circuit with
   probability (C/N)^2.  But as we make many different circuits over time,
   then the probability that the attacker will see a sample of about (C/N)^2
@@ -298,13 +299,14 @@
   A guard is unusable for a particular circuit if any of the rules for path
   selection in 2.2 are not met.  In particular, if the circuit is "fast"
   and the guard is not Fast, or if the circuit is "stable" and the guard is
-  not Stable, Tor can't use the guard for that circuit.
+  not Stable, or if the guard has already been chosen as the exit node in
+  that circuit, Tor can't use it as a guard node for that circuit.
 
   If the guard is excluded because of its status in the networkstatuses for
   over 30 days, Tor removes it from the list entirely, preserving order.
 
   If Tor fails to connect to an otherwise usable guard, it retries
-  periodically: every hour for six hours, every for hours for 3 days, every
+  periodically: every hour for six hours, every 4 hours for 3 days, every
   18 hours for a week, and every 36 hours thereafter.  Additionally, Tor
   retries unreachable guards the first time it adds a new guard to the list,
   since it is possible that the old guards were only marked as unreachable

Modified: tor/trunk/doc/tor.1.in
===================================================================
--- tor/trunk/doc/tor.1.in	2007-02-06 00:02:31 UTC (rev 9490)
+++ tor/trunk/doc/tor.1.in	2007-02-06 00:27:03 UTC (rev 9491)
@@ -58,14 +58,15 @@
 .LP
 .TP
 \fBBandwidthRate \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP
-A token bucket limits the average bandwidth usage on this node to the
-specified number of bytes per second. (Default: 3 MB)
+A token bucket limits the average incoming bandwidth usage on this node
+to the specified number of bytes per second, and the average outgoing
+bandwidth usage to that same value. (Default: 3 MB)
 .LP
 .TP
 \fBBandwidthBurst \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP
 Limit the maximum token bucket size (also known as the burst) to the
-given number of bytes. This value should be at least twice your
-BandwidthRate. (Default: 6 MB)
+given number of bytes in each direction. This value should be at least
+twice your BandwidthRate. (Default: 6 MB)
 .LP
 .TP
 \fBMaxAdvertisedBandwidth \fR\fIN\fR \fBbytes\fR|\fBKB\fR|\fBMB\fR|\fBGB\fR|\fBTB\fP

Modified: tor/trunk/src/or/circuitbuild.c
===================================================================
--- tor/trunk/src/or/circuitbuild.c	2007-02-06 00:02:31 UTC (rev 9490)
+++ tor/trunk/src/or/circuitbuild.c	2007-02-06 00:27:03 UTC (rev 9491)
@@ -1735,7 +1735,7 @@
   info = tor_malloc_zero(sizeof(extend_info_t));
   strlcpy(info->nickname, s->nickname, sizeof(info->nickname));
   memcpy(info->identity_digest, s->identity_digest, DIGEST_LEN);
-  info->onion_key = NULL; /* routerstatus doesn't include this! */
+  info->onion_key = NULL; /* routerstatus doesn't know this */
   info->addr = s->addr;
   info->port = s->or_port;
   return info;

Modified: tor/trunk/src/or/connection_or.c
===================================================================
--- tor/trunk/src/or/connection_or.c	2007-02-06 00:02:31 UTC (rev 9490)
+++ tor/trunk/src/or/connection_or.c	2007-02-06 00:27:03 UTC (rev 9491)
@@ -779,9 +779,14 @@
   return 0;
 }
 
-/** DOCDOC */
+/** A high waterlevel for whether to refill this OR connection
+ * with more directory information, if any is pending. */
 #define BUF_FULLNESS_THRESHOLD (128*1024)
-/** DOCDOC */
+/** A bottom waterlevel for whether to refill this OR connection
+ * with more directory information, if any is pending. We don't want
+ * to make this too low, since we already run the risk of starving
+ * the pending dir connections if the OR conn is frequently busy with
+ * other things. */
 #define BUF_EMPTINESS_THRESHOLD (96*1024)
 
 /** Return true iff there is so much data waiting to be flushed on <b>conn</b>