New consensus params "bwconnrate" and "bwconnburst"

...to let us
rate-limit client connections as they enter the network. It's
controlled in the consensus so we can turn it on and off for
experiments. It's starting out off. Based on proposal 163.

diff --git a/ChangeLog b/ChangeLog
index c7c8fcc655229473cad69682db9c833ff2ad1fc3..caf72eec43eda657a1185c9229b7951bc98267c8 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,4 @@
-Changes in version 0.2.2.7-alpha - 2009-??-??
+Changes in version 0.2.2.7-alpha - 2009-12-??
   o Major features (performance):
     - When choosing which cells to relay first, we can now favor circuits
       that have been quiet recently, so as to get lower latency for
@@ -8,10 +8,15 @@ Changes in version 0.2.2.7-alpha - 2009-??-??
       use it.  You can override this default by using the new
       "CircuitPriorityHalflife" config option.  Design and code by Ian
       Goldberg, Can Tang, and Chris Alexander.
+    - New consensus params "bwconnrate" and "bwconnburst" to let us
+      rate-limit client connections as they enter the network. It's
+      controlled in the consensus so we can turn it on and off for
+      experiments. It's starting out off. Based on proposal 163.
 
   o Major features (relay selection):
     - Switch to a StrictNodes config option, rather than the previous
-      "StrictEntryNodes" / "StrictExitNodes" separation.
+      "StrictEntryNodes" / "StrictExitNodes" separation that was missing a
+      "StrictExcludeNodes" option.
     - If EntryNodes, ExitNodes, ExcludeNodes, or ExcludeExitNodes
       change during a config reload, mark and discard all our origin
       circuits. This fix should address edge cases where we change the

diff --git a/src/or/connection_or.c b/src/or/connection_or.c
index 84023f5a7ee5b3d24d5f2079c472c8d258a3569b..6704af8f099d5e1402636524f5436dc2566ee396 100644 (file)
--- a/src/or/connection_or.c
+++ b/src/or/connection_or.c
@@ -320,6 +320,19 @@ connection_or_finished_connecting(or_connection_t *or_conn)
   return 0;
 }
 
+/** Return 1 if identity digest <b>id_digest</b> is known to be a
+ * currently or recently running relay. Otherwise return 0. */
+static int
+connection_or_digest_is_known_relay(const char *id_digest)
+{
+  if (router_get_consensus_status_by_id(id_digest))
+    return 1; /* It's in the consensus: "yes" */
+  if (router_get_by_digest(id_digest))
+    return 1; /* Not in the consensus, but we have a descriptor for
+               * it. Probably it was in a recent consensus. "Yes". */
+  return 0;
+}
+
 /** If we don't necessarily know the router we're connecting to, but we
  * have an addr/port/id_digest, then fill in as much as we can. Start
  * by checking to see if this describes a router we know. */
@@ -331,10 +344,24 @@ connection_or_init_conn_from_address(or_connection_t *conn,
 {
   or_options_t *options = get_options();
   routerinfo_t *r = router_get_by_digest(id_digest);
-  conn->bandwidthrate = (int)options->BandwidthRate;
-  conn->read_bucket = conn->bandwidthburst = (int)options->BandwidthBurst;
   connection_or_set_identity_digest(conn, id_digest);
 
+  if (connection_or_digest_is_known_relay(id_digest)) {
+    /* It's in the consensus, or we have a descriptor for it meaning it
+     * was probably in a recent consensus. It's a recognized relay:
+     * give it full bandwidth. */
+    conn->bandwidthrate = (int)options->BandwidthRate;
+    conn->read_bucket = conn->bandwidthburst = (int)options->BandwidthBurst;
+  } else { /* Not a recognized relay. Squeeze it down based on the
+            * suggested bandwidth parameters in the consensus. */
+    conn->bandwidthrate =
+      (int)networkstatus_get_param(NULL, "bwconnrate",
+                                   (int)options->BandwidthRate);
+    conn->read_bucket = conn->bandwidthburst =
+      (int)networkstatus_get_param(NULL, "bwconnburst",
+                                   (int)options->BandwidthBurst);
+  }
+
   conn->_base.port = port;
   tor_addr_copy(&conn->_base.addr, addr);
   tor_addr_copy(&conn->real_addr, addr);