[or-cvs] r9431: TODO items: Defer complicated solution to BEGIN_DIR memory p (in tor/trunk: . doc)

[nickm at seul.org]

Author: nickm
Date: 2007-01-27 02:57:01 -0500 (Sat, 27 Jan 2007)
New Revision: 9431

Modified:
   tor/trunk/
   tor/trunk/doc/TODO
Log:
 r11550 at catbus:  nickm | 2007-01-27 02:56:48 -0500
 TODO items: Defer complicated solution to BEGIN_DIR memory problem; mark the simple one partially implemented; note a forward compatibility TODO.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r11550] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/doc/TODO
===================================================================
--- tor/trunk/doc/TODO	2007-01-27 05:15:53 UTC (rev 9430)
+++ tor/trunk/doc/TODO	2007-01-27 07:57:01 UTC (rev 9431)
@@ -57,46 +57,12 @@
     TunnelDirConns and PreferTunneledDirConns
 R   - actually cause the directory.c functions to know about or_port
       and use it when we're supposed to.
-N   - for tunneled edge conns, stop reading to the bridge connection
+N   o for tunneled edge conns, stop reading to the bridge connection
       when the or_conn we're writing to has a full outbuf.
-      - This is iffy.  Really, it would've been better to stop writing
-        on the dir conn when the edge conn's inbuf is getting full.
-        But the issue there is that we package from edge
-        connections aggressively until we hit their package windows or the
-        circuit package windows, even if the buffer on the corresponding OR
-        connection is pretty damn big.  This sucks from a RAM usage POV.
-        Now, we could try to stop reading on the edges (or just the edges
-        connected to a local bridge) when an or_conn's outbuf is full.  But
-        if we're a server, and we stop reading on some exit conns when OR
-        conns are full, soon OR conns will contain only traffic from other OR
-        conns, and the exit data in question  will never get written.
+      . make directory bridge data not get produced when the corresponding
+        or_conn is full, and accept the sometimes directory data will just
+        never get written.
 
-      - The right solution in the long run (0.2.0) is probably as follows:
-        - Remove socketpair-based bridges: use shared (or connected) buffers
-          for communication, rather than sockets.
-        - When relaying cells from an OR conn to an OR conn, have them wait
-          in a queue on the or_circuit_t object; don't move them onto the
-          target conn until there is space in the target conn's outbuf.
-          Also, only package data from exitconns when there is space in the
-          target conn's outbuf.
-          - As an added advantage, this would let us kill stalled _circuits_
-            when their buffers get too full, rather than killing entire OR
-            conns.  But we must think about anonymity implications of that.
-        - We'll probably want to do some kind of big refactoring of our
-          dataflow when we do these changes; stuff is hairy enough already,
-          and it will only get harrier with this stuff.
-
-      - For the short run, our options seem to be:
-        - Disable BEGIN_DIR support at the server-side unless it's
-          explicitly turned on.
-        - Go ahead and make directory bridge data not get produced when the
-          corresponding or_conn is full, and accept the sometimes directory
-          data will just never get written.
-        - Rate-limit directory bridge data somehow when the corresponding
-          or_conn is full.  Possibly based on the flush rate of the or_conn?
-        - Reject BEGIN_DIR requests that we think will be insanely big.
-
-
 N - DNS improvements
     . Asynchronous DNS
       - Make evdns use windows strerror equivalents.
@@ -157,7 +123,11 @@
       a descriptor.
 NR    - Design
 N     - Implement, if we think it's smart.
+    - Check for any outstanding checks we do on the form or number of client
+      certificates that would prevent us from executing certain
+      blocking-resistance strategies.
 
+
 Topics to think about during 0.1.2.x development:
   * Figure out incentives.
     - (How can we make this tolerant of a bad v0?)
@@ -197,6 +167,29 @@
       - What do we do about the fact that people can't read zlib-
         compressed files manually?
 
+  - Change the way we handle cells, flow-control, and bridges.
+    - The issue is that we package from edge connections aggressively until
+      we hit their package windows or the circuit package windows, even if
+      the buffer on the corresponding OR connection is pretty damn big.  This
+      sucks from a RAM usage POV.  Now, we could try to stop reading on the
+      edges (or just the edges connected to a local bridge) when an or_conn's
+      outbuf is full.  But if we're a server, and we stop reading on some
+      exit conns when OR conns are full, soon OR conns will contain only
+      traffic from other OR conns, and the exit data in question will never
+      get written.
+    - Remove socketpair-based bridges: use shared (or connected) buffers for
+      communication, rather than sockets.
+    - When relaying cells from an OR conn to an OR conn, have them wait in a
+      queue on the or_circuit_t object; don't move them onto the target conn
+      until there is space in the target conn's outbuf.  Also, only package
+      data from exitconns when there is space in the target conn's outbuf.
+      - As an added advantage, this would let us kill stalled _circuits_
+        when their buffers get too full, rather than killing entire OR
+        conns.  But we must think about anonymity implications of that.
+    - We'll probably want to do some kind of big refactoring of our
+      dataflow when we do these changes; stuff is hairy enough already,
+      and it will only get harrier with this stuff.
+
   - If the client's clock is too far in the past, it will drop (or
     just not try to get) descriptors, so it'll never build circuits.
   - Tolerate clock skew on bridge relays.