[tor-commits] [tor/release-0.2.4] nickm wants us to prioritize tap in a currently-rare edge case

[arma@xxxxxxxxxxxxxx]

commit c6f1668db3010de6aed22bd87850aa846911d43b
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
Date:   Wed Sep 4 19:43:46 2013 -0400

    nickm wants us to prioritize tap in a currently-rare edge case
---
 src/or/onion.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/or/onion.c b/src/or/onion.c
index cabd055..41fe7b6 100644
--- a/src/or/onion.c
+++ b/src/or/onion.c
@@ -217,8 +217,21 @@ decide_next_handshake_type(void)
   if (!ol_entries[ONION_HANDSHAKE_TYPE_NTOR])
     return ONION_HANDSHAKE_TYPE_TAP; /* no ntors? try tap */
 
-  if (!ol_entries[ONION_HANDSHAKE_TYPE_TAP])
+  if (!ol_entries[ONION_HANDSHAKE_TYPE_TAP]) {
+
+    /* Nick wants us to prioritize new tap requests when there aren't
+     * any in the queue and we've processed k ntor cells since the last
+     * tap cell. This strategy is maybe a good idea, since it starves tap
+     * less in the case where tap is rare, or maybe a poor idea, since it
+     * makes the new tap cell unfairly jump in front of ntor cells that
+     * got here first. In any case this edge case will only become relevant
+     * once tap is rare. We should reevaluate whether we like this decision
+     * once tap gets more rare. */
+    if (ol_entries[ONION_HANDSHAKE_TYPE_NTOR])
+      ++recently_chosen_ntors;
+
     return ONION_HANDSHAKE_TYPE_NTOR; /* no taps? try ntor */
+  }
 
   /* They both have something queued. Pick ntor if we haven't done that
    * too much lately. */



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits